Nokia NRS I study materials
Nokia NRS I study resources

CPM Filter Order and BGP Session Drop

Nokia NRS I · Put your knowledge to work in context.

All case studies

CPM Filter Order and BGP Session Drop

A 7750 SR PE provides internet peering and management access. Its CPM is protected by a CPM filter applied to the management interface. The filter currently has entries: 1) permit SSH from 10.10.10.0/24; 2) permit SNMP from 10.10.10.20; 3) permit ICMP from any; 4) deny all. After a security audit, the operator adds a new entry at the top: deny IP from 203.0.113.0/24, because that prefix was seen scanning the router. Within minutes, the eBGP session to 203.0.113.1 (AS 64512) drops and does not re-establish. The router still has reachability to 203.0.113.1 in the base routing table. CPM CPU is low, and no interface is down. The management network is 10.10.10.0/24; the BGP peer is reachable via a separate data-plane interface. The operator wants to keep blocking scanning hosts but restore the BGP session.

1. Why did the BGP session drop?

Read the worked answer

The CPM filter is evaluated top-down, first match wins. The new deny entry matches all IP from 203.0.113.0/24 before any permit, including TCP 179 from 203.0.113.1. BGP keepalives are destined to the CPM, so the session times out. The base route-table entry only proves forwarding; it does not bypass the CPM filter. Low CPU and interface-up state are irrelevant. This is a control-plane filter ordering mistake, not a routing failure.

2. Propose a corrected filter order and default action, including management and BGP.

Read the worked answer

Order: permit TCP dst-port 179 from 203.0.113.1; permit TCP dst-port 22 from 10.10.10.0/24; permit UDP dst-port 161 from 10.10.10.20; permit ICMP from 10.10.10.0/24; deny IP from 203.0.113.0/24; deny all. The scanner entry can stay if it is after the BGP permit but before the default deny. Apply the filter to CPM ingress with default-action deny. Do not end with permit any. If the peer uses MD5, allow the TCP option; the filter should not inspect payload.

3. How would you block scanning hosts without impairing the peer, and what logging or rate-limiting would you add?

Read the worked answer

Keep the BGP permit for the peer, then deny the scanner prefix for other ports. Add logging on the deny entry and rate-limit ICMP. Use control-plane policing so a scan cannot overwhelm the CPM. On the data plane, apply uRPF and edge ACLs. This preserves the session and still blocks scans. Review logs to distinguish scanning from legitimate peer traffic, and do not block the entire prefix if the peer is inside it.