Control-Plane Filter Blocks a New Spine's BGP and SSH
Two border leaves run eBGP to the WAN and iBGP/EVPN to three spine switches. Each border leaf has a loopback filter named PROTECT-RE applied as family inet filter input on lo0. Its terms are: accept OSPF (protocol 89) from any source; accept TCP port 179 from a prefix-list named BGP-PEERS containing 10.0.0.1/32 through 10.0.0.5/32; accept TCP port 22 from 10.10.5.0/24; accept ICMP; then discard and count. A new spine, 10.0.0.6, is added. Its OSPF adjacency with both borders comes up, but its BGP session stays in Active. SSH from the new spine's loopback to the border leaf also fails, while SSH from the NOC jump host at 10.10.5.20 works normally. On the border leaf, the discard counter in show firewall filter PROTECT-RE rises whenever the new spine attempts to connect.
1. Diagnose the failure using the filter logic. What is happening to the BGP and SSH packets from 10.0.0.6?
Read the worked answer
The filter is behaving exactly as written. OSPF succeeds because there is an unconditional term for protocol 89, so 10.0.0.6 matches it regardless of source. BGP does not, because the TCP 179 term is constrained by BGP-PEERS, which lists only 10.0.0.1 through 10.0.0.5; 10.0.0.6 matches nothing and hits the final discard, which is why the counter rises and the session stays Active.
SSH behaves the same way for a different reason. The jump host 10.10.5.20 is inside 10.10.5.0/24 and matches the SSH term. Router-originated traffic from the new spine uses 10.0.0.6 as its source, which is outside that prefix, so it also falls to the discard. The rising counter is the key evidence: it proves packets arrive and are dropped by policy rather than lost in transit.
2. What is the correct fix, and how do you verify it without loosening the filter more than necessary?
Read the worked answer
Add 10.0.0.6/32 to BGP-PEERS rather than removing the source constraint, and decide deliberately whether SSH should come from loopbacks or only from the management subnet. If the new spine must be managed from its loopback, add a specific term permitting TCP 22 from 10.0.0.6/32 rather than widening the 10.10.5.0/24 entry.
Run commit check, apply, then verify in layers: show firewall filter PROTECT-RE should stop incrementing the discard counter for that source, show bgp summary should move the session to Established, and an SSH attempt from 10.0.0.6 should succeed. Remember that both border leaves need the change, and check the new spine's own loopback filter as well, because return traffic may be filtered there. Keep the final discard; it is the safety net that made this visible.
3. Why does the NOC jump host still work while the spine's loopback does not, and how would you confirm source-address selection?
Read the worked answer
Junos chooses the source address of router-originated traffic from the outgoing interface or, for protocols such as BGP and SSH, from the loopback when configured. The jump host is an external host with a fixed address in 10.10.5.0/24, so its packets match the SSH term. The spine sources its management and BGP traffic from its loopback 10.0.0.6, which is not in any permitted source range, so the filter drops it.
Confirm by checking the new spine's configuration for the loopback and any system host-name/routing-options router-id settings, then run show bgp summary on the border to see the expected peer address, and test with ping 10.0.0.6 source 10.10.5.20 style source selection where applicable. A packet capture or the rising filter counter confirms the source address being dropped, which is the fact you need before deciding whether to permit the loopback or change the traffic's source.