BGP neighbour states, messages and troubleshooting sessions and missing routes

The neighbour states

BGP messages

• OPEN: version, ASN, hold time, router ID and capabilities such as 4-byte ASNs, multiprotocol support and route refresh.
• UPDATE: new routes with their attributes, and withdrawn routes.
• KEEPALIVE: sent periodically (every 60 seconds on Cisco by default) so the peer knows the session is alive. The hold time defaults to 180 seconds.
• NOTIFICATION: reports an error and closes the session, with a code such as "bad peer AS" or "hold timer expired".
• ROUTE-REFRESH (RFC 2918): asks the peer to resend all its routes.

Active and passive roles

Both peers normally try to open the TCP connection. If both attempts succeed, BGP keeps the connection opened by the router with the higher router ID and closes the other. You can make one side wait for the other with neighbor x transport connection-mode passive, which helps when one side sits behind a firewall that only allows connections in one direction. show ip bgp neighbors shows which side opened the session: one uses port 179 locally, the other a random high port.

When the session will not come up

1. Reachability: ping the configured neighbour address from the source address you use. Stuck in Active nearly always means TCP 179 cannot connect.
2. Addresses: each side must point at the address the other uses as its source. For loopback peering, check update-source.
3. TTL: eBGP to a non-adjacent address needs multihop or disable-connected-check.
4. Filters: an ACL or firewall may block TCP 179 in one direction.
5. AS numbers: a wrong remote-as causes a NOTIFICATION with "bad peer AS"; the session reaches OpenSent and then resets.
6. Authentication: mismatched MD5 passwords leave TCP failing silently; the router logs invalid MD5 digests.
7. Router ID: two routers with the same router ID cannot peer.

show ip bgp summary
show ip bgp neighbors 198.51.100.1
debug ip bgp 198.51.100.1 events

When routes are missing

An Established session does not guarantee routes. Check, in order: is the prefix in the sender's BGP table and marked best; does the network statement match the routing table exactly; is the next hop reachable on the receiver; is an inbound or outbound filter or route map dropping it; and, for iBGP, did the route come from another iBGP peer (which is not passed on)? show ip bgp neighbors x advertised-routes on the sender and received-routes or routes on the receiver show where it disappears.

Applying policy changes: soft reconfiguration and route refresh

Route maps and filters only affect new updates. A hard reset with clear ip bgp x tears the session down and disrupts traffic. Better options are soft reconfiguration inbound, which keeps an unfiltered copy of everything received (using extra memory), or the route refresh capability, which asks the peer to resend its routes. Nearly every modern router supports route refresh, so clear ip bgp x soft in works without storing extra copies.

Real-world example: a university's new backup link to a research network stayed in Active for hours. Ping between the peer addresses worked, but show ip bgp neighbors showed no TCP connection at all. The firewall in the path allowed TCP 179 only from the research network inwards, while the research network had configured its router as passive, waiting for the university to connect first. Neither side could open the session. The engineer added a firewall rule allowing the university router to connect out to the peer address on TCP 179, and the session reached Established within seconds.