BGP uses TCP Port 179 as its underlying delivery mechanism. This allows the TCP layer to handle the basics of acknowledgement, retransmission, and sequencing. TCP also handles the MD5 authentication. You can see, BGP is simply a TCP application.

BGP is a path vector routing protocol. It uses this path to ensure a loop free environment (for eBGP). If a router receives an advertisement with its own AS in the path, it discards the update. Since routers within the same iBGP domain have the same AS, there is no loop protection mechanism inherent to the protocol. That is the reason why BGP advertisements are not learned from one neighbor by a router and then passed to another neighbor by the router that just learned it. And that is the reason a full mesh (or route reflector) is required for iBGP Peers.

BGP is considered a WAN protocol because it is not concerned with the details of the topologies within each AS. It can be said that BGP takes a higher view of the entire internetwork than an IGP does. Because this view is not compatible with the view seen by an IGP, Cisco IOS maintains a separate RIB to hold BGP routes. The command show ip bgp shows the BGP RIB table.

When there are parallel, equal-cost paths to a particular destination, the IOS implementation of BGP by default selects only one path—in contrast to other IP routing protocols, in which the default is to load balance across up to four paths. As with the other IP routing protocols, the maximum-paths command changes the default maximum number of parallel paths in the range from 1 to 16.

When two neighbors first establish a BGP peer connection, they exchange their entire BGP routing tables. After that, they exchange incremental, partial updates; that is, they exchange routing information only when something changes, and only information about what changed. Because BGP does not use periodic routing updates, the peers must exchange keepalive messages to ensure that the connection is maintained. The IOS default keepalive interval is 60 seconds (RFC 4271 does not specify a standard keepalive time); if three intervals (180 seconds) pass without a peer receiving a keepalive message, the peer declares its neighbor down. You can change these intervals with the timers bgp command. These timers can also be set on a per neighbor basis.

We probably want to know about the BGP messages and neighbor formation. Since BGP is a TCP application, the neighbors must first go through the TCP three-way handshake. Once that connection is established, all BGP messages are unicast to one neighbor over the TCP connection. There are 4 message types that BGP uses:

  • Open
  • Keepalive
  • Update
  • Notification

A fifth, Route Refresh, might not be supported across all implementations.

The Open Message is used after the TCP session is established to identify each neighbor’s identity and specify its BGP operational paramaters, including:

  • BGP Version Number
  • AS number
  • Hold time
  • BGP identifier (determined same was as OSPF router-id)
  • optional paramaters such as authentication, route refresh, etc

Keepalive Messages are sent every 60 seconds by default in IOS. The first one is sent immediately after the router has accepted the paramters specified in its neighbor’s open message. This keepalive interval as well as the holddown interval can be changed for the entire BGP process or on a per neighbor basis.

Update Messages advertise feasible routes, withdrawn routes, or both. It includes the following information:

  • Network Layer Reachability Information (NLRI): this is one or more (Length, Prefix) tuples that advertise destination prefixes and lengths.
  • Path attributes: the attributes of the advertised NLRI
  • Withdrawn Routes: (Length, Prefix) tuples describing destinations that have become unreachable or otherwise are being withdrawn from service

Notification Messages are sent when an error is detected and always cause the BGP connection to be closed.

Now that we have covered the Message types, let’s review the BGP state machine. Here is a picture to review.

There are a total of 6 states in the BGP state machine:

  • Idle State: the beginning state where a TCP connection towards a neighbor is initialized
  • Connect State: state where TCP connection is being established
  • Active State: the BGP process tries further to initiate a TCP connection with its neighbor
  • OpenSent State: after succesfull TCP connection an Open Message is sent to the neighbor and state moves to OpenSent
  • OpenConfirm State: BGP process waits for a keepalive (state transitions to established) or a Notification message (state transitions to Idle)
  • Established State: BGP peer connection is fully established

BGP Process Model

To model the BGP process, imagine that each BGP speaker has different pools of routes and different policy engines applied to the routes. The model would involve the following components:

  • a pool of routes that the router receives from its peers
  • an Input Policy Engine that can filter the routes or manipulate their attributes
  • a decision process that decides which routes the router itself will use
  • a pool of routes that the router itself uses
  • an Output Policy Engine that can filter the routes or manipulate their attributes
  • a pool of routes that the router advertises to other peers

BGP routes are stored in the RIBs - that’s right RIBs as in plural. Routes received from other BGP speakers are stored in the Adj-RIB-In; routes that will be used by the local router are stored in the Loc-RIB; finally, routes that will be advertised to other peers must be present in the Adj-RIB-Out. If a BGP speaker does advertise a route to a peer, it may add or modify the path’s attributes before advertising it to the peer.

The other item to conceptually remember is that an Adj-RIB-In and an Adj-RIB-Out is associated with each peer. The Input Policy Engine acts on the collective pool of Adj-RIB-In routes to determine the Loc-RIB. Likewise, each peer has an associated Adj-RIB-Out - routes are advertised on a per peer basis after the Output Policy Engine has been run on the Loc-RIB. If a route is not in the Loc-RIB, it cannot be a candidate for the Adj-RIB-Out.

The actual implementation of this is with pointers, not with separate per peer tables.

In addition the the routes in the Loc-RIB, the Output Policy Engine also examines routes generated locally by the router for placement into the Adj-RIB-Out.