A BGP neighbor showing Active is not a working session: the router is trying to establish the TCP connection needed for BGP.[1] The practical interview question is: What do you check when BGP stays in Active even though you can ping the peer?
Short answer: Verify the exact peer and source addresses, bidirectional reachability, TCP port 179, eBGP TTL/connected-peer checks, and TCP authentication before investigating BGP OPEN errors.[2] A successful ping alone does not prove that the BGP TCP connection is permitted.
What does BGP Active actually mean?
Active belongs to BGP session establishment, not route selection: a successful TCP attempt leads toward OpenSent, while failed retries can move the session between Active and Connect.[1] Once OPEN processing succeeds, OpenConfirm waits for a KEEPALIVE before Established permits route exchange.[1]
Use this simplified successful packet flow as a mental model, not a complete state-machine diagram:
Peer A Peer B
TCP SYN, ephemeral source port ------------> TCP destination port 179
<---------------------------------- SYN-ACK
ACK -------------------------------------->
BGP OPEN <--------------------------------> BGP OPEN
BGP KEEPALIVE <----------------------------> BGP KEEPALIVE
Established
BGP UPDATE <------------------------------> BGP UPDATE
Cisco's examples show a local ephemeral TCP port paired with the remote port 179; the establishment sequence then uses OPEN and KEEPALIVE messages.[1] Either router may initiate the connection, so inspect the actual direction rather than assuming one permanent client.
Start with evidence, not a session reset
Record the current state, last reset reason, neighbor addresses, and TCP state on both routers. On Cisco IOS/IOS XE, the following are useful starting points; adapt commands for your release and VRF.[2]
show ip bgp all summary
show ip bgp neighbors 192.0.2.2
show ip route 192.0.2.2
show tcp brief all
show logging
The addresses in this article are illustrative. These commands and the lab below are examples, not output from an executed router test.
On Cisco summary output, the State/PfxRcd column displays a prefix count when the session is established.[1] Consequently, a numeric zero is not the same symptom as the word Active: first confirm the detailed neighbor state, then investigate missing routes separately.
BGP Active troubleshooting checklist
| Check | What to verify | What to do next |
|---|---|---|
| Peer identity | Each neighbor statement points to the intended remote endpoint | Compare both configurations, not just the local one.[2] |
| Source address | The local TCP source is the address configured as neighbor on the far end | For loopback peering, check update-source.[2] |
| Routing | Both endpoints have usable routes to the opposite peering address | Test using the intended source; check the correct VRF.[2] |
| TCP reachability | TCP/179 reaches the peer and the reply returns | Inspect path ACLs, firewall policy, TCP state and control-plane handling.[2] |
| eBGP distance | TTL and connected-peer checks match the actual topology | Use a deliberate multihop or directly connected loopback design.[2] |
| Authentication | Both ends agree on TCP authentication | Inspect authentication logs; compare secrets securely, never paste them into tickets.[2] |
| OPEN negotiation | TCP works, but BGP still resets | Read NOTIFICATION/reset details and check remote AS and capabilities.[2] |
Treat this as an isolation order, not a claim that every Active session has the same cause.
1. Test from the real BGP source
For loopback peering, an ordinary ping can use the outgoing interface address instead of the loopback, which tests a different source/destination pair.[2] Use an explicitly sourced test, then repeat from the other router:
ping 192.0.2.2 source Loopback0
Check the return route to the local loopback as carefully as the forward route. If the session lives in a VRF, perform the lookup and test inside that VRF rather than relying on the global routing table.
A useful question to ask aloud in an interview is: “Which source IP does the remote router actually see?” That moves the discussion from generic reachability to the precise peering endpoints.
2. Separate ICMP success from TCP success
Cisco recommends checking TCP/179 and provides TCP-state and open-port commands when the TCP session is not established.[2] Ping success only answers the ICMP question; use a narrowly scoped packet capture and policy counters to understand TCP.
Here is a packet-analysis decision tree based on the handshake:
- No SYN leaves: inspect local routing context, neighbor configuration and local session activation.
- SYN leaves but is not seen remotely: investigate the path, filters and TTL.
- SYN arrives but no SYN-ACK leaves: investigate the remote listener, configured peer/source match, authentication and control-plane policy.
- SYN-ACK leaves remotely but never returns locally: investigate the reverse path and filters.
- TCP completes, then BGP closes: inspect OPEN/NOTIFICATION details instead of continuing to assume a port block.
These are diagnostic hypotheses, not definitive diagnoses from one packet. A timeout alone does not identify which device dropped traffic.
For a stateful firewall, validate the permitted session and its return traffic. With stateless ACLs, remember that the reply targets the initiator's ephemeral port, not destination port 179; Cisco's neighbor output demonstrates this TCP port pairing.[1] Do not “fix” the issue by allowing all traffic.
3. Check eBGP TTL without blindly enabling multihop
Cisco IOS/IOS XE normally uses TTL 1 for eBGP and also performs a directly connected peer check.[2] Loopback-to-loopback eBGP on physically adjacent routers needs deliberate handling of that check, while peers separated by transit routers require an appropriate multihop setting.[2]
Do not add a large multihop value as a universal repair. First draw the routed path and confirm the expected peer addresses. If TTL security is already configured, review the platform's matching requirements rather than layering unrelated changes on top.
4. Distinguish authentication failures from AS mismatches
Cisco documents missing or invalid MD5 digest messages as TCP authentication problems, while a wrong remote AS can produce a BGP OPEN error reporting “peer in wrong AS.”[2] That distinction matters: an AS mismatch is not proof that SYN packets are blocked.
A repeatedly resetting session may be sampled in Active even if it briefly reached a later stage. Read the last error and correlate timestamps across both ends before naming the root cause.
Mini-lab: reachable loopbacks, wrong BGP source
Consider an isolated iBGP lab with two routers in AS 65001:
R1 Loopback0: 192.0.2.1/32
R2 Loopback0: 192.0.2.2/32
Underlay routing: both loopbacks reachable in both directions
Intended IOS/IOS XE BGP configuration fragments:
! R1
router bgp 65001
neighbor 192.0.2.2 remote-as 65001
neighbor 192.0.2.2 update-source Loopback0
address-family ipv4 unicast
neighbor 192.0.2.2 activate
exit-address-family
! R2
router bgp 65001
neighbor 192.0.2.1 remote-as 65001
neighbor 192.0.2.1 update-source Loopback0
address-family ipv4 unicast
neighbor 192.0.2.1 activate
exit-address-family
The update-source setting makes the loopback the session source, matching Cisco's guidance for loopback-based iBGP.[2] These fragments omit interface and underlay configuration; apply them only to a disposable lab with the stated prerequisites.
Lab exercise: remove update-source on one router, observe the actual TCP source and neighbor state, and compare a normal ping with a loopback-sourced ping. Restore the setting and verify Established plus stable uptime. The expected lesson is that a route to the peer does not guarantee that the TCP source matches the remote neighbor definition; exact retry/reset behavior can vary by implementation.
Common interview pitfalls
- “Active means healthy.” The operational target is Established, not Active.[1]
- “Ping works, so the firewall is fine.” TCP/179 needs its own verification.[2]
- “Change local preference first.” Session establishment precedes route exchange and path selection.[1]
- “Wrong AS always prevents TCP.” Cisco's wrong-AS example is a BGP NOTIFICATION, so check the stage and error.[2]
- “Clear every BGP session.” Preserve evidence and avoid broad disruptive resets; use a targeted action only when needed and approved.
- “Enable all debugs.” Start with show commands and bounded captures; assess platform load before using debug commands.
A concise interview answer
“Active means BGP is still trying to establish its TCP connection; it is not exchanging routes yet.[1] I check the configured endpoints, the actual source address, routes in both directions, TCP/179 filtering, eBGP TTL and authentication.[2] I then read the last reset reason: if TCP completes and BGP reports an OPEN error, I investigate AS and capability negotiation instead of blaming basic reachability.”[2]
Related reading
Summary
Treat BGP Active as a session-establishment problem: verify the exact endpoints and TCP exchange before moving to route-policy troubleshooting.[1][2] The strongest explanation connects each check to an observed packet, state or error.
Preparing for a network engineering interview? Reproduce the source-address mismatch in a lab, then explain which observation proves the fault. Share your sanitized findings and platform version in the comments—never authentication secrets or customer details.
Post a Comment