Bgp Routing Advanced

BGP routing advanced is the discipline of crafting resilient, scalable, and predictable inter-autonomous system (AS) connectivity. It matters when a network spans multiple data centers, cloud providers, and ISPs, and where traffic must be load-balanced, failover-transparent, and policy-driven across heterogeneous infrastructure. This is the layer where network engineers fine-tune reachability, influence path selection, and implement dynamic routing under high availability and low-latency constraints.

Route Selection and Path Attributes

When multiple BGP paths exist to the same destination, the decision process prioritizes paths using a defined set of attributes. The router evaluates paths in this order:

1. Weight (local to the router, highest preference)
2. Local Preference (inter-AS, default 100)
3. AS Path Length (fewer AS hops preferred)
4. Origin Type (IGP < EGP < Incomplete)
5. MED (Multi-Exit Discriminator) (lower is better)
6. EBGP over IBGP
7. IGP cost to the next hop
8. Router ID (for tiebreaking)

To influence path selection, configure local preference globally:

configure terminal
router bgp 65001
 bgp router-id 192.0.2.1
 neighbor 192.0.2.2 remote-as 65002
 neighbor 192.0.2.2 local-preference 200
 neighbor 192.0.2.3 remote-as 65003
 neighbor 192.0.2.3 local-preference 150
 exit

MEDs are advertised with default-metric and can be set per neighbor or with route maps:

router bgp 65001
 network 10.0.0.0 mask 255.255.255.0
 neighbor 192.0.2.2 remote-as 65002
 neighbor 192.0.2.2 route-map SET-MED out
!
route-map SET-MED permit 10
 match ip address 101
 set metric 150
 set metric-type external
!
ip access-list standard 101
 permit 10.0.0.0 0.0.0.255

A common pitfall: MEDs are only compared within the same AS unless always-compare-med is enabled. Without it, MEDs from different ASes are ignored in path selection.

Route Reflection and Scalability

In large IBGP topologies, full mesh IBGP becomes unmanageable. Route reflection solves this by introducing route reflectors (RRs) that accept routes from clients and reflect them to other clients.

An RR is configured with a cluster ID and client list:

router bgp 65001
 bgp cluster-id 10.0.0.1
 neighbor 192.0.2.10 remote-as 65001
 neighbor 192.0.2.10 update-source Loopback0
 neighbor 192.0.2.10 route-reflector-client

Clients advertise routes to the RR, which then reflects them to all other clients. The RR also acts as a BGP speaker to external peers.

The cluster list in the CLUSTER_LIST attribute tracks the path of reflections. When a route is reflected multiple times, the cluster list grows. A route is considered “optimal” if it has traversed all clusters without loops.

A subtle failure mode: if a route is reflected from cluster A to cluster B, and then back to A, a loop is introduced. The RR detects this via the cluster list and prevents routing loops by comparing cluster IDs.

Additionally, route reflector hierarchy allows multiple levels of RRs. A Level 1 RR reflects routes from multiple Level 0 RRs, enabling scalability beyond a single point of failure.

BGP Communities and Policy Automation

BGP communities are 32-bit values used to tag routes for policy application. They are encoded as AS:VALUE, where AS is the autonomous system number and VALUE is an arbitrary number.

To apply policies, routers advertise routes with specific communities:

router bgp 65001
 neighbor 192.0.2.2 remote-as 65002
 neighbor 192.0.2.2 send-community
 neighbor 192.0.2.2 route-map MARK-INTERNET in
!
route-map MARK-INTERNET permit 10
 match ip address 102
 set community 65001:100
 set community 65001:200 additive
!
ip access-list standard 102
 permit 203.0.113.0 0.0.0.255

The receiving router uses community values to trigger actions:

• 65001:100 – Route is for internet-facing services
• 65001:200 – Route is for backup path
• 65001:300 – Route is for low-latency applications

A common use case: a cloud provider sends routes for virtual machines with community 65001:100. A core router applies a route map that sets:

• Local preference to 200 for 65001:100
• MED to 50 for 65001:100
• Redistributes these routes into OSPF with metric type 1

router bgp 65001
 redistribute ospf 100 metric 100 route-map OSPF-IMPORT
!
route-map OSPF-IMPORT permit 10
 match community 65001:100
 set local-preference 200
 set metric 50
 set metric-type 1
!

The additive keyword in set community ensures that existing communities are preserved while adding new ones.

Route Flap Damping

Route flapping occurs when a route frequently goes up and down, causing BGP to re-advertise the route repeatedly. This leads to instability and increased control plane load.

BGP implements route flap damping to suppress flapping routes. Each route maintains a penalty that increases when the route flaps and decays over time.

The algorithm uses three parameters:

• Half-life (default 10 minutes): the time it takes for a penalty to halve
• Maximum penalty (default 2000): the threshold at which a route is suppressed
• Reuse threshold (default 750): when penalty drops below this, route is reused

To enable damping on a neighbor:

router bgp 65001
 neighbor 192.0.2.10 remote-as 65002
 neighbor 192.0.2.10 dampening 10 2000 750 20

This command sets:

• Half-life: 10 minutes
• Maximum penalty: 2000
• Reuse threshold: 750
• Suppress threshold: 20

A route that flaps continuously accumulates penalty. When it exceeds 2000, it is suppressed — not advertised to peers until its penalty drops below 2000 again.

A silent failure: if a route flaps for 15 minutes, the penalty increases but the route is not suppressed because the decay time is not long enough. The default half-life of 10 minutes means the penalty decays only 60% of its value after 15 minutes.

To fine-tune, set the maximum suppress time (default 60 minutes) to prevent routes from being suppressed indefinitely.

neighbor 192.0.2.10 dampening 10 2000 750 20 60

BGP Multiprotocol Extensions (MP-BGP)

MP-BGP extends BGP to carry routes for multiple network layer protocols beyond IPv4 unicast.

To advertise IPv6 unicast routes, enable the capability:

router bgp 65001
 address-family ipv6 unicast
  neighbor 192.0.2.2 remote-as 65002
  neighbor 192.0.2.2 activate
  neighbor 192.0.2.2 send-community
  network 2001:db8::/32
  exit

The address-family block defines the scope of configuration for a specific protocol.

To support multiple address families simultaneously:

router bgp 65001
 address-family ipv4 multicast
  neighbor 192.0.2.3 remote-as 65003
  neighbor 192.0.2.3 activate
  neighbor 192.0.2.3 send-community
  exit
!
 address-family ipv6 multicast
  neighbor 192.0.2.4 remote-as 65004
  neighbor 192.0.2.4 activate
  neighbor 192.0.2.4 send-community
  exit

Each address family maintains its own set of neighbors, route maps, and policies.

For VPNv4 (VRF-based MPLS), use:

router bgp 65001
 address-family vpnv4 unicast
  neighbor 192.0.2.5 remote-as 65005
  neighbor 192.0.2.5 activate
  neighbor 192.0.2.5 send-community both
  neighbor 192.0.2.5 route-map EXPORT-TO-VPN out
  exit
!
route-map EXPORT-TO-VPN permit 10
 set extcommunity rt 65001:100
 set extcommunity so 65001:200

The extended communities (RT for route target, SO for site of origin) allow VRFs to import and export routes across an MPLS backbone.

BGP Graceful Restart

When a BGP router restarts, it can maintain forwarding state while re-establishing adjacency. This minimizes traffic loss during upgrades or failures.

To enable graceful restart, both peers must advertise support:

router bgp 65001
 neighbor 192.0.2.10 remote-as 65002
 neighbor 192.0.2.10 graceful-restart
 neighbor 192.0.2.10 restart-time 120

The restart-time indicates how long the restarting router can remain in the BGP session while reinitializing.

The peer sends a Graceful Restart Capability TLV in the OPEN message:

Type: 64 (Graceful Restart Capability)
Length: 10
Flags: 0x01 (Restart Flag)
Restart Time: 120

During restart, the peer continues to forward packets using old routing information. Upon reconnection, it sends a Restart Notification message with the following fields:

• Restart Time: how long the peer can maintain state
• Restart Reason: 1 = Graceful Restart, 2 = Route Refresh, 3 = Other
• Restart Flags: 0x01 = Restarting, 0x02 = Restart Complete

The receiver processes the notification and begins to update its forwarding table.

A common failure: the receiving router does not receive the Restart Notification message, so it does not update its forwarding state. The router continues to use old routes, but the new peer does not advertise its updated routes. This leads to suboptimal routing during the restart window.

To avoid this, ensure that both peers are configured for graceful restart and that the BGP session is re-established with the correct capability exchange.

BGP Route Refresh

When a BGP peer changes its policy (e.g., route maps, filter lists), it must re-advertise all routes. The Route Refresh capability allows a peer to request a full resynchronization without tearing down the session.

To trigger a route refresh:

bgp 65001
 neighbor 192.0.2.10 route-refresh

The sender responds with a Route Refresh Message containing:

• Address Family Identifier (AFI): 1 (IPv4), 2 (IPv6), etc.
• Subsequent Address Family Identifier (SAFI): 1 (Unicast), 2 (Multicast), etc.
• Refresh Reason: 0x01 (Initiated by peer), 0x02 (Policy change), etc.

The receiving router then sends all routes for the specified AFI/SAFI pair.

To automate, use a route refresh interval:

router bgp 65001
 neighbor 192.0.2.10 route-refresh
 neighbor 192.0.2.10 route-refresh-interval 300

This sends a route refresh every 300 seconds, ensuring that configuration changes propagate smoothly.

A subtle point: route refresh does not require the session to be re-established. It can be sent on an existing session, and the sender can continue to exchange new updates during the refresh.

This page was rewritten on 17 October 2026. It replaced a templated version that was not specific to its own title. How these pages are written and checked. If anything here is wrong, tell us at [email protected] and we will correct it.