In this Community Roundtable episode, returning guests Russ White and Nick Russo start our three part deep dive into the Border Gateway Protocol, or BGP, with a look at terminology, how peer relationships form, the differences between internal and external BGP, and scaling techniques.

 

Show Links

https://tools.ietf.org/html/rfc4271

https://www.ietf.org/rfc/rfc1771.txt

http://bgp.us/

 

Show Notes

Overview

• BGP is an external gateway protocol used widely in both the public internet and with enterprise organizations
• BGP is the only external gateway protocol and is traditionally used primarily to connect networks to other networks
• BGP was built primarily for policy propagation to provide reliability, scalability, and control
• BGP v4 is created which is the base version we still use today though updated over the year

 

Terminology

• Devices running BGP are called speakers
  • A connection between two speakers is called a peering session
  • The two speakers are often called peers or neighbors
• Network Layer Reachability Information is a key term to remember — NLRI
  • Address Families (AFs) carry NLRIs for different topologies and different kinds of reachability information (v4, v6, ethernet, mpls, etc.
• Autonomous System–a set of bgp speakers contained within a single administrative domain (with some rather loose definition of an administrative domain here)

 

Forming Neighbor Relationships

• Runs over TCP
• Relies on TCP for flow control, three way handshake, mtu discovery, reliable transport
• Because of this, there is nothing like a DR/DIS/etc. — it’s a one-to-one peering
• This can cause issues with large scale peering
• These issues are normally solved by sending multiple copies of the same packet to each neighbor — peer groups

 

iBGP vs eBGP Overview

• iBGP is not a policy edge
• All iBGP speakers are supposed to appear to have a consistent policy from outside the AS
• eBGP is not really a routing edge, but rather a policy edge
• The idea is to allow multiple operators to run their networks without interference from peering operators
• This is not entirely “clean,” but it’s the goal
• Speakers send all routes to eBGP peers
• Speakers only send eBGP learned routes to iBGP peers
• This is because BGP relies on the AS path to prevent loops; there is no AS Path within an AS!
• How iBGP and eBGP differ in next-hop processing
• eBGP multi-hop designs (also discuss the “TTL misunderstanding”)
  • Multiple paths with a single next hop for load sharing

 

iBGP scaling techniques

• Route Reflectors
  • RR: regionalization matters sometimes (not always), route deflection
  • MPLS is a natural solution to this, for VPN and global transport
  • RR’s add an AS Path within the AS — the cluster list
  • This allows BGP speakers to send routes learned from an iBGP speaker to another iBGP speaker
  • The RR problem is the routes are not always optimal — hence add paths, optimal route reflection
  • Combination of RRs and direct iBGP sessions → optimal routing, since RRs sometimes hide topology. Generally easier than add-paths, ORR, and other techniques since you just n