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
