BGP sessions, messages and neighbour states

Why does Active mean no routes yet?

R1 has been configured to peer with ISP A at 192.0.2.1, but no routes arrive. Where a number of received prefixes should be, show ip bgp summary says Active. It sounds healthy, but it means R1 has not established the BGP conversation and is waiting for a TCP connection. A brief Active state can be part of startup; a persistent one calls for investigation. The state alone does not identify the fault. It starts with how a session forms.

A BGP session is the conversation used by two routing processes to exchange route information. A neighbour, also called a peer, is the router at the other end. Established means that conversation is ready to exchange routes. It does not mean that a user's application is reachable.

We use one Ethernet link: R1 Gi0/0 is 192.0.2.2/30 in AS 64500; ISP A's interface is 192.0.2.1/30 in AS 64501. R1's BGP router ID is 1.1.1.1. The neighbour address is an interface IP, not a website URL, an AS number or the router ID. The /30 is the subnet prefix length. Both routers have a connected route to this link.

How a session forms

In this lab, each router is configured with the neighbour's IP address and AS number, the identifier of its routing domain. It opens a TCP connection to destination port 179. The initiating side normally uses a temporary source port; not every packet has both ports set to 179. TCP provides reliable, ordered delivery. BGP sends the eligible initial routes, then normally sends changes rather than periodically repeating a complete table. Route refresh or reconnection can cause routes to be sent again.

The routers next exchange OPEN messages to identify themselves and negotiate supported features. A KEEPALIVE confirms that the OPEN was accepted. Once the session is Established, an UPDATE can announce a prefix or withdraw a previously announced path. A withdrawal tells the receiver to stop using that path; it does not physically shut down the destination network.

First prove that the session is Established; then check which routes it actually exchanges.

The five message types

BGP keeps its protocol small. Five message types cover everything a session needs, and only one of them carries routes. Knowing which message does what tells you which counter or log line to look at when something fails.

Keepalive and hold timers

Each router expects a qualifying message from its neighbour within the hold time. In Established state, receiving an UPDATE or KEEPALIVE restarts this timer. A NOTIFICATION instead reports an error and closes the session. On Cisco IOS the usual defaults are a keepalive every 60 seconds and a hold time of 180 seconds. The two routers offer their hold times in the OPEN and both use the lower one, so the timers do not have to match for the session to come up. A negotiated hold time of zero disables the hold timer and periodic keepalives; nonzero hold times must be at least three seconds.

When the hold time runs out, the router sends a NOTIFICATION (hold timer expired), closes the session and removes paths learned through it in ordinary operation. A directly detected interface failure can bring the session down before this timer expires. Shorter timers detect silent failures sooner, but leave less room for delayed messages or an overloaded router. Agree changes with the peer rather than reducing timers on every neighbour as a first troubleshooting step.

Neighbour states, from Idle to Established

A neighbour moves through a fixed set of states. Reading them in order shows how far a session got, and therefore which layer to inspect. TCP trouble keeps the neighbour in Connect or Active. Trouble in the OPEN exchange sends it back to Idle with a NOTIFICATION. Only Established carries routes.

Reading show ip bgp summary

One command shows every neighbour on one line. Learn to read the last column first, because it tells you whether the session is up before you look at anything else.

R1#show ip bgp summary
BGP router identifier 1.1.1.1, local AS number 64500
BGP table version is 5, main routing table version 5
...
Neighbor        V           AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
10.255.0.2      4        64500      28      30        5    0    0 00:21:40        1
192.0.2.1       4        64501      31      29        5    0    0 00:21:52        1

R1#show ip bgp summary | begin Neighbor
Neighbor        V           AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
192.0.2.1       4        64501       0       0        1    0    0 never    Active

R1#show ip bgp neighbors 192.0.2.1 | include BGP state
  BGP state = Established, up for 00:21:52

The router ID

Each BGP router has a 32-bit router ID (BGP identifier). With the conventional Cisco IOS IPv4 selection rules, it uses the bgp router-id command if set, otherwise the highest IPv4 address on a loopback, otherwise the highest IPv4 address on an active interface. Keep IDs unique within the AS, including iBGP neighbours. It breaks ties late in best-path selection. Setting it by hand keeps it stable when interfaces change.

Where sessions usually fail

• Persistent Active or Connect: investigate TCP establishment. Check the neighbour address, route, peer configuration and TCP 179 permissions; the state alone cannot identify a blocked port.
• Repeated resets: read the last reset reason and logs. A Bad Peer AS NOTIFICATION points to an unacceptable AS in an OPEN; compare each remote-as with the opposite router's local AS. An Idle/Active cycle alone does not prove an AS mismatch.
• eBGP to a loopback address: by default Cisco IOS only starts an eBGP session to an address on a directly connected subnet, and sends its packets with a TTL of 1. Peering with a loopback needs an extra command, covered in the eBGP multihop lesson.
• Established, but 0 prefixes: the session is ready, but zero may be intentional, as in the lab below. If routes are expected, check address-family activation, origination and policy before changing TCP settings.

Use show ip bgp neighbors 192.0.2.1 and show logging to connect a state change to its cause. A Bad Peer AS error means an OPEN was processed on that connection, so TCP had worked at that point. It does not prove the path is still working now. Observe the recovery after correcting the confirmed cause; avoid repeatedly resetting a peer just to see whether its state changes.

Build and check a two-router session

Use a Cisco IOS or IOS XE IPv4-unicast lab. Configure and enable the two Ethernet interfaces with the /30 addresses above first. The following commands start in global configuration mode and create an eBGP session only; they do not originate a prefix. Release-specific address-family commands may be required on your chosen image.

1. Run show ip interface brief and ping 192.0.2.1 on R1. Confirm the intended link is up and the directly connected neighbour replies.
2. Run show ip bgp summary. With no originated routes, expect a numeric 0 after establishment. That is the intended result at this stage.
3. Run show ip bgp neighbors 192.0.2.1. Find the BGP state, remote AS, negotiated hold time and any last reset reason. If the session fails, use those clues before changing configuration.

For a failure exercise, shut the lab ISP interface, observe the state change, then restore it with no shutdown. Direct link-down detection may act before the hold timer. Do not expect this exercise to demonstrate a full 180-second timeout.

Technical references: RFC 4271, route refresh, RFC 2918, graceful restart, RFC 4724 and Cisco's BGP troubleshooting guide. These commands and outputs are written examples, not captures from a tested router image.

Test yourself on BGP sessions