OECG – Chapter 12


Last but not least in this journey of BGP discovery, the BGP process has to actually put routes in the local router’s IP routing table. Often, this process is as simple as BGP choosing the best route (based on the criteria in last section of the chapter), and using that to populate the IP routing table. But there can be other considerations.

Let’s first consider adding eBGP routes to the IP routing table.

  • The eBGP route in the BGP table must be considered the “best” route.
  • If that same prefix is learned another way (i.e. through another routing protocol), then the administrative distance must be lower for BGP than for the other ways the prefix was learned.
    • eBGP routes have an AD of 20, which means eBGP routes are going to trump almost any other routing protocol, the exception of EIGRP summary routes with an AD of 5 coming to mind.
    • The reason for this low AD is that you’re unlikely to learn a route from outside your AS that’s also inside your AS.
  • If you wish to tweak the default AD’s of BGP learned routes, you can do so with the “distance bgp <external-distance> <internal-distance> <local-distance>” BGP paragraph command to tweak the AD of routes learned via eBGP (20 by default), iBGP (200 by default) or injected locally (200 by default). Alternately, you can tweak AD using the distance command, allowing you to refer to an ACL to define routes whose AD’s will be tweaked.
  • Remember that the NEXT_HOP PA will be carried forward from BGP to the IP routing table. So…if that next-hop is not local, then the router will do a recursive route lookup before forwarding the packet.
  • In cases where eBGP and an IGP are both advertising the same prefix, you can run into trouble where eBGP is preferred because of the low AD, even though the IGP advertised path would be preferred. While it’s possible to resolve this problem with distance commands, you could instead resolve it with a “network xx.xx.xx.xx backdoor” command, where xx.xx.xx.xx is the prefix you wish to prefer the IGP path for. Using this command instructs BGP to treat that route not as an eBGP route, but rather as a local-injected route, bumping the AD up to 200. In addition, that route will not advertise that prefix with BGP. When this happens, the IGP AD will be preferred, and traffic will converge in the accordance with the IGP.

Let’s next consider adding iBGP routes to the IP routing table (initially the same criteria as eBGP, but with additional considerations related to synchronization, route reflectors and confederations).

  • The iBGP router in the BGP table must be considered the “best” route.
  • If that same prefix is learned another way (i.e. through another routing protocol), then the administrative distance must be lower for BGP than for the other ways the prefix was learned.
  • Now, it’s possible that your iBGP routers are not directly connected – that there is another in between the 2 iBGP neighbors that isn’t speaking BGP. It’s possible then for your iBGP neighbors to talk to one another about routes that the middleman knows nothing about. And yet, the middleman becomes a transit router for this traffic, with one humongous catch. The catch being that if you aren’t redistributing your BGP routes into an IGP, your middleman transit router may know nothing about the BGP routes, making the middleman router a blackhole for those routes. What’s worse, other ASNs may converge on the ASN with the blackhole. In effect, you have 2 problems – the blackhole itself, and the advertisement of the blackholed routes to other ASNs. You can solve these problem in a number of ways.
    • Synchronization
      • BGP synchronization forces the router to operate with the following logic as it considers BGP prefixes: an iBGP route can’t be a “best” unless that exact prefix was learned from an IGP an is in the routing table. This solves the problem of the BGP router advertising routes as “best” when in actuality they are blackholed. The router will infer that the non-BGP routers in the ASN will be able to forward traffic for the prefix if the BGP router learned the prefix from an IGP.
      • The problem of the ignorant middleman router is solved by redistributing BGP routes into the IGP in the routers appropriate to the design.
      • A final odd note is to realize that if OSPF is the IGP of choice, then BGP synchronization requires that the OSPF and iBGP RIDs match, before the route will be considered a candidate for “best”.
    • Disabling sync, and running BGP on all routers in an ASN is another way to solve this problem, but implies a full iBGP mesh and the associated overhead that goes with running BGP. Remember that the full mesh is required, as iBGP routers do not advertise routes learned from iBGP routers to other iBGP routers.
    • Confederations
      • A confederation helps overcome the need for a full iBGP mesh, and still allows all routers within a AS to know about a specific prefix.
      • Confederations are BGP routers grouped in sub-ASNs within the larger ASN. Think of it as an ASN tiering system, where the confederation ASNs are tier 2, and the “real” ASNs are tier 1.
      • Consider that you have 3 confederations within the ASN 100. Let use sub-ASNs drawn from the private ASN range of 64512-65535, ergo 64997, 64998 and 64999.
      • The 3 sub-ASNs 64997, 64998 and 64999 would be logical members of the main ASN 100.
      • To each other, however, these ASNs would act as eBGP/iBGP groups, where a router in 64997 would have a conceptual eBGP relationship to routers in 64998 and 64999, but routers within 64997 would have a conceptual iBGP relationship to each other.
      • Using this system, you can overcome the problem of the blackhole router, and not require a full iBGP mesh. Let’s say a router in 64997 is eBGP from primary ASN 100 to another ASN 200. Routes advertised from ASN 200 would flow into ASN 100 via the sub ASN 64997. The eBGP router in 64997 would tell his iBGP neighbors in the 64997 confederation of those ASN 200 routes. Those iBGP neighbors would not tell each other, because iBGP routes are not advertised to other iBGP neighbors. A router in ASN 64997 would advertise the ASN 200 routes to via confederation to ASN 64998, like an eBGP neighbor. That ASN 64998 router would advertise those ASN 200 routes to the other 64998 routers via confederation iBGP. One of the routers in 64998 would advertise the ASN 200 routes to an ASN 64999 router via confederation eBGP, who would then propagate via iBGP to 64999 neighbors.
      • You might be wondering what happens to the AS_PATH in all of this, as we’ve introduces 3 new ASNs that are “tier 2” or sub-ASNs. BGP routes that traverse a confederation track the confederation sub-ASNs in the AS_CONFED_SEQ and AS_CONFED_SET fields, just as “normal” AS paths are stored in the AS_SEQ and AS_SET fields.
      • Other points to ponder:
        • Inside of a sub-ASN, you still need a full iBGP mesh.
        • Confederation eBGP connections (connections between routers in different sub-ASNs) act like any other eBGP connection, where iBGP routes are advertised, assuming the AS_PATH indicates this would be loop-free.
        • Confederation eBGP connections still have a default TTL of 1, so you’ll need to use “neighbor ebgp-multihop” to overcome this if your neighbor is more that one hop away, which is implied in the use of loopback interfaces as update-sources, don’t forget.
        • In all other ways, confederation eBGP connections act like iBGP conenctions. NEXT_HOP is not changed by default.
        • Confederation ASNs are not used as part of the AS_PATH when a router determines shortest AS path for a route.
        • Confederation routers will strip confederation AS_PATH information out before advertising to routers that are not a part of the confederation. So, routers outside the confederation have no knowledge of it.
      • When configuring confederations, realize that your “true” ASN as configured on the router will actually be that of the sub-ASN. You’ll use a “bgp confederation identifier <ASN>” statement to indicate the parent ASN the confederation router is a part of. That implies that while migrating to a new ASN can be tough, as you’ll be taking BGP routers off the air while reconfiguring them for the confederation.
    • Route reflectors
      • A route reflector (RR) behaves as its name implies: upon receipt of a route from a particular source, the route reflector will send BGP updates of that received route to client and non-client routers, dependent on a set of rules:
        • If the prefix is learned from a client, the RR will advertise the route to both clients and non-clients.
        • If the prefix is learned from a non-client, the RR will advertise the route to clients, but not to non-clients.
        • If the prefix is learned from an eBGP neighbor, the RR will advertise the route to clients and non-clients.
      • A group of RRs with their clients create a RR cluster.
      • Non-RRs are not aware that they are a part of a RR cluster, or are peered with an RR. They received and process BGP updates in accordance with normal BGP rules.
      • RRs are usually fully-meshed to other RRs.
      • As you’re mulling this all over, you might be thinking that routing loops could be a challenge in this scenario. There are a number of tools employed to avoid routing loop, however:
        • A RR adds his cluster ID to the CLUSTER_LIST PA before advertising a route. RRs examine this PA, and discard advertisements where their cluster ID is listed.
        • The ORIGINATOR_ID PA lists the RID of the first iBGP peer to propagate that prefix into the ASN. A router will not use or forward a received route that contains his own RID in the ORIGINATOR_ID PA.
        • A RR will only advertise “best” routes.
By Ethan Banks

Ethan Banks is a podcaster and writer with a BSCS and 20+ years in enterprise IT. He's operated data centers with a special focus on infrastructure — especially networking. He's been a CNE, MCSE, CEH, CCNA, CCNP, CCSP, and CCIE R&S #20655. He's the co-founder of Packet Pushers Interactive, LLC where he creates content for humans in the hot aisle.