Border Gateway Protocol, The Routing Protocol of the Internet

IGP, OSPF, BGP, As, Oh My!

From last week’s overview of Internet routing, you should realize that routing in the Internet is comprised of two parts: the internal fine-grained portions that are managed by an IGP such as OSPF, and the interconnections of those autonomous systems (AS) via BGP.

Everyone on the Internet has at least one unique AS number, and they use BGP to advertise their networks to their peers. BGP is a path-vector protocol, because it advertises the paths required to get to a certain destination. BGP does not say anything about how a packet will get routed within the AS, nor does it know about the entire network as OSPF does.� BGP can be called a distance-vector protocol, because it’s similar, excluding a few twists.

BGP itself is a Layer 4 protocol that sits on top of TCP. BGP is much simpler than OSPF, because it doesn’t have to worry about the things TCP will handle. This works because BGP is very connection-oriented anyway, since it requires two manually configured peers, who configure their routers then exchange routes. BGP peers (neighbors) will generally be directly connected, but some masochists like to set up BGP sessions between multi-hop peers—which is okay, since BGP uses TCP (port 179) and doesn’t rely on broadcasts or link-local multicast.

If you, as a router, import a route and then advertise it to one of your peers, you must prepend your own AS to the AS-Path before announcing the route. Naturally, this provides a “path” that one can take, as the route is advertised further from the source AS. Generally, but not always, routers will choose the shortest path to an AS. BGP only knows about these paths based on updates it receives. Unlike RIP (that distance-vector protocol) BGP does not broadcast its entire routing table. At boot, your peer will hand over their entire table, but after that everything relies on updates received.

Route updates are stored in a Routing Information Base (RIB). A routing table will only store one route per destination, but the RIB usually contains multiple paths to a destination. It is up to the router to decide which routes will make it into the routing table, i.e. which paths will actually be used. In the event that a route is withdrawn, another to the same place can be taken from the RIB. The RIB is only used to keep track of possible routes we could use. We never advertise a route to a peer that we aren’t using, because that would be false information. We only advertise what we have in our routing table. If a route withdrawal is received and it only existed in the RIB, we don’t need to send an update to our peers, instead we silently delete it from the RIB. The RIB entries never time out, they stick around until we think that route is no longer valid.