Category - BGP

BGP Failover Troubleshooting

Border Gateway Protocol

Border Gateway Protocol (BGP) is the protocol which is used to make core routing decisions on the Internet; it involves a table of IP networks or “prefixes” which designate network reachability among autonomous systems (AS). BGP is a path vector protocol or a variant of a Distance-vector routing protocol. BGP does not involve traditional Interior Gateway Protocol (IGP) metrics, but routing decisions are made based on path, network policies and/or rule-sets. For this reason, it is more appropriately ermed a reachability protocol rather than routing protocol.

BGP - Border Gateway Protocol

BGP performs interdomain routing in Transmission-Control Protocol/Internet Protocol (TCP/IP) networks. BGP is an exterior gateway protocol (EGP), which means that it performs routing between multiple autonomous systems or domains and exchanges routing and reachability information with other BGP systems.

  1. BGP Adjacency States
  2. BGP path Selection
  3. BGP Attributes
  4. AS Override

AS Override

AS Override

The AS override feature allows a provider edge (PE) router to change the private autonomous system (AS) number used by a customer edge (CE) device on an external BGP (EBGP) session running on a VPN routing and forwarding (VRF) access link. The private AS number is changed to the PE AS number. Another CE device connected to another PE device sees the EBGP route coming from the first site with an AS path of provider-ASN provider-ASN, instead of provider-ASN site1-ASN. This allows enterprise networks to use the same private ASN on all sites.

The AS override feature offers a clear management advantage to the service provider because BGP by default does not accept BGP routes with an AS path attribute that contains the local AS number.

In an enterprise network with multiple sites, you might wish to use a single AS number across sites. Suppose, for example that two CE devices are in AS 64512 and that the provider network is in AS 65534.

When the service provider configures a Layer 3 VPN with this setup, even if the MPLS network has routes towards Device CE1 and Device CE2, Device CE1 and Device CE2 do not have routes to each other because the AS path attribute would appear as 64512 65534 64512. BGP uses the AS path attribute as its loop avoidance mechanism. If a site sees its own AS number more than once in the AS path, the route is considered invalid.

One way to overcome this difficulty is with the as-override statement, which is applied to the PE devices. The as-override statement replaces the CE device’s AS number with that of the PE device, thus preventing the customer AS number from appearing more than once in the AS path attribute.

If a customer uses AS path prepending to make certain paths less desirable and the service provider uses AS override, each CE AS number occurrence in the AS-path is changed to the service provider AS number. For example, suppose that all customer sites use the same AS number, say 64512. If the ISP uses AS number 65534, one customer site sees the path to another site as 65534 65534. If the customer prepends 64512 on a particular path to make it less desirable, another customer site sees that path as 65534 65534 65534.


The Basics of BGP Route Reflection

Configuring Border Gateway Protocol (BGP) can be quite onerous, particularly with large numbers of peering sessions that must be configured manually. In fact, in a large network, the full-mesh requirement for IBGP can be a provisioning nightmare.

BGP’s answer to the IBGP pairing configuration nightmare that is the full mesh is called route reflection. Route reflection allows sharing of routing information among a group of routers without having to send the exact same information to each of them individually. It’s sort of like giving information to one person and having them distribute it to all their peers.

IBGP comes with a significant restriction: IBGP peers should not re-advertise IBGP-learned routes to other IBGP speakers, which is why they all need to be fully meshed. If you can’t re-advertise IBGP routes, you must be directly connected to the originator of the route, hence the full mesh requirement. Remember, IBGP has no dedicated loop prevention mechanism, and this is why you need route reflectors for large networks.

The concept of route reflection allows you to designate one or more of your routers as route reflectors. BGP relaxes the re-advertising restriction on these route reflectors, allowing them to accept and propagate IBGP routes to their clients.




Because of the IBGP full-mesh requirement, this topology would require 15 IBGP peering sessions per router, or 120 distinct IBGP sessions within the network. However, if you designate router 4 as a route reflector, you can start to minimize this requirement. For example, look at what happens in with the routers directly connected to router 4.




In this part of the topology, router 4 has three directly-connected routers. If just this part of the topology is running IBGP, you have to configure a full mesh between the 4 routers. However, if you designate router 4 as a route reflector, BGP only requires that every route reflector client have an IBGP connection to the route reflector (not to each other).




With the new configuration, the IBGP routes from routers 1, 2, and 3 are sent to the route reflector. Router 4, acting as the route reflector, re-advertises these routes to all of its clients.

In this way, router 1 and router 2 are connected via IBGP, through their shared route reflector, router 4. This group of routers is called a cluster, and each cluster is uniquely identified by its cluster ID (a 32-bit number similar to an IP address).

Looking back at the original 16-router network, if you make similar route reflectors with routers 8, 12, and 16, you can create four route reflectors and reduce the number of IBGP sessions.



The 16-router fully meshed route reflector network

However, all 16 routers are still in the same AS, which means that IBGP has to fully connect all 16 routers. How do you do this?

Ultimately, you must have connectivity somewhere. That connectivity occurs at the route reflector level. The route reflectors must be fully meshed, meaning that you must have IBGP peering sessions between each of the four route reflectors.

Essentially, you have drastically reduced the number of IBGP sessions in your network. Where you previously needed 120 sessions to fully mesh your network, you now need only three sessions from each route reflector to its clients and an additional six sessions to fully mesh the route reflectors (for a total of 18 IBGP sessions).

Copyright ©2010 - 2022 | Privacy Policy | Terms & Conditions