BGP explained: sessions, attributes and best path

BGP, the Border Gateway Protocol version 4, is how autonomous systems exchange routes. An autonomous system is a network under one routing policy, identified by its AS number.

Unlike OSPF, BGP discovers nothing. Every peer is configured by hand, and the session runs over TCP, port 179. Each route carries the list of autonomous systems it has crossed, and that list is what stops loops between them.

Four messages do all the work. OPEN starts the session and carries the version, the AS number, the hold time and the BGP identifier. UPDATE carries routes. KEEPALIVE says the peer is still there. NOTIFICATION reports an error and closes the session. Huawei also lists route refresh, to ask a peer to send its routes again.

The session moves through six states: Idle, Connect, Active, OpenSent, OpenConfirm and Established. A peer stuck in Active is retrying TCP, and failing.

Two timers keep a session alive. The hold time is how long a router waits without hearing from its peer before it closes the session, and keepalives go out at a third of it.

Cisco, Huawei and Aruba default to a 60 second keepalive and a 180 second hold time. Juniper and the RFC suggest 30 and 90. They still peer, because each side uses the smaller hold time of the two OPEN messages, so a Cisco router facing a Juniper one runs at 90 seconds. A hold time of one or two seconds is refused.

A session between two autonomous systems is external BGP, eBGP. Inside one autonomous system it is internal BGP, iBGP, and the rules change. Toward an eBGP peer, a router adds its own AS number to the path, and a router that finds its own number in a received path drops the route. That is the loop protection.

Inside the AS the path does not change, so iBGP needs another rule: a route learned from an iBGP peer is never passed to another iBGP peer. That is why iBGP routers must be fully meshed.

A full mesh of n routers needs n times n minus one, divided by two, sessions. Twenty routers, one hundred and ninety sessions.

A route reflector bends the rule on purpose. Its clients peer only with the reflector, and the reflector passes their routes on. Two attributes stop the loops this could create: the originator ID, the router that first announced the route, and the cluster list, the reflectors it has crossed. A reflector drops any route that already lists its own cluster ID.

Every route carries attributes. Origin says how the route entered BGP. AS path is the list of autonomous systems. Next hop is where to send the traffic.

Local preference stays inside your AS, defaults to 100, and the highest wins: it is how you choose your exit. MED, the multi exit discriminator, is a hint to a neighbour about which of your links to use, and the lowest wins. By default, routers compare MED only between routes from the same neighbouring AS.

When several paths lead to the same prefix, Cisco checks them in order: the highest weight, the highest local preference, a locally originated route, the shortest AS path, the lowest origin, the lowest MED, eBGP over iBGP, the lowest IGP metric to the next hop, the oldest external path, the lowest router ID, the shortest cluster list and the lowest neighbour address.

Weight is Cisco specific and never leaves the router: 32,768 for routes it originates, zero for the rest. Huawei calls the same idea PrefVal, and Aruba calls it administrative weight.

Juniper starts elsewhere. Junos first checks that the next hop resolves, then compares protocol preference, 170 for BGP, then local preference, and its documented order has no weight step. Huawei checks the cluster list before the router ID, where Cisco and Juniper check it after. On Aruba the router ID is compared only if you turn it on; otherwise the oldest route stays.

Mix vendors, and the same routes can break a tie differently.

The most common reason a route sits in the BGP table unused is its next hop. A route learned over eBGP keeps its next hop when it is passed to iBGP peers: the address of the external neighbour. If your interior routers cannot reach that address, the route is in BGP but never installed.

Huawei's own example shows it: the route appears with an i and no best marker, because the next hop is unreachable. The fix is next hop self on the border router, or carrying that link in the IGP.

Each vendor has a summary command. Cisco: show ip bgp summary, where the last column is the state or the number of prefixes received. Huawei: display bgp peer. Aruba: show bgp all summary. Juniper: show bgp summary.

Anything other than established in that column, Idle, Active or Connect, is a session that is down.

Two settings protect every session. The first is maximum prefix. Without it, a peer that leaks a full table sends you hundreds of thousands of routes, and you accept them.

With it, Cisco warns at 75 percent, and over the limit tears the session down with a NOTIFICATION: cease, maximum number of prefixes reached. The summary then reads Idle, prefix count, and the session stays down until you clear it, unless you set a restart timer.

Huawei calls it route limit and Juniper prefix limit, and Juniper only logs unless you add teardown.

The second is authentication. The classic option is a TCP MD5 password, RFC 2385, the same on both ends. Its own RFC notes security weaknesses, and Huawei says MD5 carries potential risks.

Its replacement is TCP-AO, RFC 5925, with key chains that change keys without dropping the session. Cisco, Aruba and Juniper document it for BGP.

One warning: on Cisco, adding a password to a running session does not reset it, so a mismatch only shows at the next reset.

NacTrack reads BGP from every router over SSH, whatever the vendor, and lists every session on one page: its state, the prefixes received, whether a maximum prefix is set, and whether BFD protects it.

For example: a full internet table arriving on a session marked not limited.