Are we still cool with using BGP?
TL;DR — “There is no evidence of the imminent collapse of BGP” and none of the metrics indicate that growth is anything other than within router capacity.
When we look at BGP (•) performance, and possible issues, there are two main things we tend to be concerned about
- • Routing Table Size : since each router has a local db containing all the prefixes for each routing peer, and each of its line cards contains a decent subset thereof. Which translates to, at line speed, the need to do an imprecise 32-bit lookup on this ever-growing db in less than 5ns (yes, that’s hard!)
- • Update frequency (route churn) : As this goes up, the router starts to lag, and eventually just drop, updates. At best, this means “ghost routes”, with the router reflecting some past state of the network. At worst, router loops, where a packet just goes round and round till it times out. Each just worsens the problem.
Geoff Huston looks at these problems, with metrics, and, definitively finds out that we are still A-OK .
Read on for more at http://www.potaroo.net/ispcol/2018-01/bgp2017.html
(•) Best one-paragraph summary of BGP yet —
BGP is an instance of a Bellman-Ford distance vector routing algorithm. This algorithm allows a collection of connected devices (BGP speakers) to each learn the relative topology of the connecting network. The basic approach of this algorithm is very simple: each BGP speaker tells all its other neighbours about what it has learned if the new learned information alters the local view of the network. This is a lot like a social rumour network, where every individual who hears a new rumour immediately informs all their friends. BGP works in a very similar fashion: each time a neighbour informs a BGP speaker about reachability to an IP address prefix, the BGP speaker compares this new reachability information against its stored knowledge that was gained from previous announcements from other neighbours. If this new information provides a better path to the prefix then the local speaker moves this prefix and associated next hop forwarding decision to the local forwarding table and informs all its immediate neighbours of a new path to a prefix, implicitly citing itself as the next hop. In addition, there is a withdrawal mechanism, where a BGP speaker determines that it no longer has a viable path to a given prefix, in which case it announces a “withdrawal” to all its neighbours. When a BGP speaker receives a withdrawal, it stores the withdrawal against this neighbour. If the withdrawn neighbour happened to be the currently preferred next hop for this prefix, then the BGP speaker will examine its per-neighbour data sets to determine which stored announcement represents the best path from those that are still extant. If it can find such an alternative path, it will copy this into its local forwarding table and announce this new preferred path to all its BGP neighbours. If there is no such alternative path, it will announce a withdrawal to its neighbors, indicating that it no longer can reach this prefix.

Comments