Why BGP Uses TCP and IGPs Don't
By stretch | Thursday, June 24, 2010 at 1:52 a.m. UTC
Recently there was an engaging question posed over on networking-forum.com: Why does BGP use TCP, while interior routing protocols like OSPF and EIGRP do not? There were a number of astute observations made in the thread which followed, and I thought it might be worthwhile to catalog them here.
Arguably the most obvious motivation to design BGP to run over TCP is simple convenience. Remember that BGP is essentially just another application layer protocol to the TCP/IP stack; at the time of BGP's creation TCP was already out there and working, so why not take advantage of it? From RFC 4271:
BGP uses TCP as its transport protocol. This eliminates the need to implement explicit update fragmentation, retransmission, acknowledgement, and sequencing.
Unlike other IPv4 routing protocols, BGP does not provide its own security mechanism. Sure, you can secure neighbor adjacencies using MD5 digests, but these aren't actually carried within the BGP header. Rather, security is facilitated by a TCP option defined in RFC 2385, the TCP Authentication Option (kind 19).
This TCP option was originally created specifically to secure BGP adjacencies (which typically have quite long lifetimes), and for a decade or so has worked quite well. However, as MD5 is beginning to show its age, a new RFC (5925) was published just this month to provide a more resilient alternative.
No Need for Neighbor Discovery
Unlike interior routing protocols, BGP has no requirement for dynamic neighbor discovery. As BGP adjacencies are (or more accurately, should be) very carefully weighed design considerations, BGP neighbors must be configured statically at both ends. This is in contrast to a protocol like OSPF, which uses hello packets to automatically discover and form adjacencies with neighbors.
Adjacency Traffic is Always Point-to-Point
A corollary of our last point, we know that BGP unicasts advertisements to each of its adjacent neighbors separately. This is in contrast to interior routing protocols, which typically employ multicast transmissions to more efficiently communicate with one or more other neighbors on a multiaccess segment.
About the Author
Jeremy Stretch is a network engineer living in the Raleigh-Durham, North Carolina area. He is known for his blog and cheat sheets here at Packet Life. You can reach him by email or follow him on Twitter.
Posted in Routing
June 24, 2010 at 5:16 a.m. UTC
Well, the primary reason was definitely convenience, sometimes expressed as "don't reinvent the wheel" or (coming from a marketing person) "doing more with less". It makes no sense to reinvent a transport-layer protocol if all you need is reliable transport of data between two IP hosts.
LDP is very similar: it uses UDP multicasts to discover adjacent MPLS-enabled routers, then switches to (unicast) TCP to exchange labels.
June 25, 2010 at 7:18 a.m. UTC
There was also a Google Tech Talk in 2007 about BGP protocol design. Those who don't know it, should really take the time and watch it. The talk is very interesting and entertaining.
July 2, 2010 at 1:06 p.m. UTC
To add to Ivan's comment...
Since it is Peer peer basis, there is no need to add multicast into the loop, let alone flooding it on the internet.
TCP pretty much covers when it comes to maintaining connections, so why reinvent the wheel...
May 20, 2011 at 10:44 a.m. UTC
I must say I always had this question from the day one I learned that BGP uses TCP 179.
Now I'm much more clear..
March 1, 2013 at 9:15 a.m. UTC
Thanks Stretch.. Good one.. quite useful
December 12, 2013 at 5:13 p.m. UTC
The ccnp book does not tell us about these, thank you very much.
September 8, 2014 at 8:44 p.m. UTC
Thanks a lot but i have 2 question 1. what is the relation between Neighbor Discovery and TCP used 2.Also what is the relation betweenTraffic is Always Point-to-Point and TCp used