NSR/GRES Upgrade Window with BFD and Lo0 Filter
A provider schedules a Junos upgrade on a core P router at 02:00. The router runs IS-IS, RSVP-TE, LDP, and BGP VPNv4 with 4,000 VPN routes; NSR and GRES are enabled, and BFD is configured for OSPF and BGP. During the RE switchover, OSPF adjacencies to two peers drop, BGP VPNv4 sessions reset, and traffic is lost for 45 seconds. The lo0 firewall filter has a term that permits OSPF but counts BFD as 0; a later term permits BGP. The peer routers have graceful-restart configured but not helper. During reconvergence, the voice queue on the core link drops packets even though the class-of-service configuration marks EF traffic and gives it 30 percent bandwidth.
1. NSR and GRES are enabled, yet the BGP VPNv4 session resets during the RE switchover. Explain the likely interaction with BFD and what you would verify before the next window. Does the peer's graceful-restart configuration help?
Read the worked answer
NSR replicates routing protocol state to the backup RE so the sessions survive a switchover; GRES keeps the forwarding plane alive. BFD is a separate fast-detection protocol and is not always replicated with NSR. If BFD sessions reset during the switchover, BFD reports the neighbor down, and OSPF/BGP tear down even though NSR is configured. That matches the 45-second loss and the two OSPF adjacency drops.
Check show task replication for the protocol and BFD state, show bfd session extensive for the session state and whether it is replicated, show system switchover, and show chassis routing-engine. Confirm commit synchronize is used and that nsr is enabled under both OSPF and BGP. Check whether any enabled feature is not NSR-capable; if so, remove it or accept a maintenance window with GR instead. The peer's graceful-restart helps when the peer restarts and this router acts as helper; it does not protect a local RE switchover. For the local switchover, NSR is the mechanism, and BFD must either be replicated or disabled/relaxed during the window. Verify with a controlled request chassis routing-engine master switch in a lab.
2. The lo0 filter counted zero BFD packets. Show a corrected filter design and explain why the original filter dropped BFD even though it had an OSPF term.
Read the worked answer
The original filter likely had a term such as from { protocol ospf; } then { count OSPF; } without accept, so OSPF packets were counted and then continued to the next term; a later term rejected everything not matched, including BFD. A term with only count does not accept. Because BFD uses UDP 3784/3785 and was not explicitly permitted, the counter showed zero only if the packet never reached that term or a prior term consumed it.
Correct order:
term bfd { from { protocol udp; destination-port 3784-3785; } then accept; }
term ospf { from { protocol ospf; } then accept; }
term bgp { from { protocol tcp; destination-port bgp; } then accept; }
term ntp { from { protocol udp; destination-port ntp; } then accept; }
term ssh { from { protocol tcp; destination-port ssh; } then accept; }
term snmp { from { protocol udp; destination-port [ snmp snmptrap ]; } then accept; }
term icmp { from { protocol icmp; } then accept; }
term reject { then { count DROPPED; discard; } }
Apply as filter LO0-IN on lo0.0 with family inet. Verify with show firewall filter LO0-IN and show interfaces lo0.0 | match filter. Keep the reject term last and count it; if BFD must be policed, use a policer after the accept, not before.
3. During reconvergence the EF queue drops packets although EF has 30 percent bandwidth. What CoS and traffic checks would you perform, and what design change would you recommend?
Read the worked answer
Check whether the drop is a CoS drop or a physical oversubscription drop. Use show interfaces queue ge-x/y/z to see per-queue drops and show class-of-service interface ge-x/y/z and show class-of-service scheduler-map to confirm EF is mapped to a strict-high priority queue with 30 percent bandwidth. During reconvergence, traffic shifts from the failed link to the surviving link, so the offered EF load may exceed 30 percent of the link even if it was within budget before. If EF is strict-high, it should be scheduled first, but it can still drop if the queue buffer overflows or if a policer is attached.
Recommend: keep EF in a strict-high queue, add a policer to cap EF at the contracted rate, and ensure the remaining bandwidth is allocated so that EF plus control traffic fits on a single-link failure. Put routing protocol and BFD traffic in a network-control class with a small guaranteed bandwidth. Verify with show interfaces queue before and after a controlled failure, and test with a traffic generator at the expected post-failure rate.