Episode 17 – BGP: Peering and Reachability

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





Show Notes


  • 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



  • 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 need to add a session
  • Confederation: handy in some cases, maybe a merger
  • Not a scaling technique per se, but important design notes:
    • There is no rule that RR/confed must be used. iBGP full mesh is NOT REQUIRED, it depends on what connectivity is needed.
    • DMVPN phase 3 with hub aggregate → no RR needed
    • DMVPN phase 1 with only hub DC subnet reachability → no RR needed



  • BGP next-hop changes as they affect MPLS label allocation
  • BGP-free core designs
    • BGP often (almost always in some peering relationships!)  relies on recursive routing
    • The next hop may or may not be directly connected, but it is almost always reachable because some other protocol has supplied this information
    • Two speakers may be connected through a router that either does, or does not, run BGP
    • If two iBGP speakers are connected through another router, and the router in the middle is not running BGP, the router in the middle does not know how to forward traffic, so the traffic is dropped
    • You can redistribute BGP into the underlying protocol — don’t do this, it’s a bad idea (Old design, no longer used)
    • You can tunnel traffic edge to edge over the underlying network — MPLS is the normal mechanism here


Russ White
Nicholas Russo

Jordan Martin
Eyvonne Sharp
Phil Gervasi

Outro Music:
Danger Storm Kevin MacLeod (incompetech.com)
Licensed under Creative Commons: By Attribution 3.0 License


  1. December 22, 2017

    BGP best path selection is missing where the interesting pieces of BGP sit such as oldest route & eBGP>iBGP . BGP Policies mapping at the edge, policies at the edge for iBGP and eBGP.
    BGP Origin and Path validation using PKI Infra would be useful.

    • December 22, 2017


      You’re a bit ahead of the curve on this one. Since BGP is such a large topic we’ve decided to split it into 3 different shows. The first was exclusively about BGP peering and reachability. The next show will be all about traffic engineering and will touch on path selection techniques. The final show will focus on securing BGP. That content is coming!

      Thanks for listening/watching!

      – Jordan

  2. December 24, 2017

    Sure Jordan. BGP implementation in Edge [ Filtering Policies], ISP Edge and BGP in DC would also be a good topic to cover.
    Dynamic BGP peering and also BGP new RFCs GR Shut and BGP session Culling.
    Sending Emojis over BGP 🙂

Leave a Reply

Your email address will not be published. Required fields are marked *