BGP Tips! multipath load balancing

Previous thoughts on load balancing BGP were that it is not a load balancing protocol and in order to achieve any sort of balanced traffic you would have to perform some sort of route balancing. These days with BGP finding its way into our core IGP ( think MPLS VRF WAN ) a number of options for load balancing BGP have shown up.

Multipath BGP

While IGPs tend to manage most load balancing scenarios automagicly, BGPs mechanisms are configured manually. To allow multipath eBGP you configure the maximum number of paths to install using the maximum-paths route configuration command. However, multipath route installation does have to meet a few criteria including matching attributes. These attributes include weight, local preference, AS path, origin code, MED, and IGP metric. The next hop address for each path must also be different in order for that path to be considered.

Although the BGP path selection algorithm only considers the AS path length when comparing paths, the actual values (ASNs) of the path attribute have to match for the two routes to be installed

These stipulations are fine when sharing a load across multiple routes to a single ISP. But what if we had two different ISPs? Our attributes may match in every instance, except for the AS numbers in each path. Fortunately, there is an undocumented Cisco command that allows us to consider those routes, despite the differences in the AS numbers inside the path. Introducing bgp bestpath as-path multipath-relax

Testing

Here we’re attempting to load share across 2 egress points inside an MPLS VRF. First, our VRF configuration on the PE router. Here we’ve added the multipath and multipath-relax commands.

!
router bgp 65510 
no synchronization
bgp log-neighbor-changes
bgp bestpath as-path multipath-relax
neighbor 10.3.3.3 remote-as 65510  
neighbor 10.3.3.3 update-source Loopback0
neighbor 10.7.7.7 remote-as 65510  
neighbor 10.7.7.7 update-source Loopback0 
no auto-summary  
!
address-family vpnv4
neighbor 10.3.3.3 activate
neighbor 10.3.3.3 send-community extended
neighbor 10.7.7.7 activate
neighbor 10.7.7.7 send-community extended  
exit-address-family  
!
address-family ipv4 vrf VPN_A
redistribute rip
maximum-paths eibgp 2
exit-address-family
!
address-family ipv4 vrf VPN_B
no synchronization
exit-address-family
!

In the following output you can see that both paths are indeed sourced from separate networks, while the AS path length is the same, the AS numbers are not.

R5#show ip bgp vpnv4 vrf VPN_A 0.0.0.0
BGP routing table entry for 100:1:0.0.0.0/0, version 9
Paths: (2 available, best #1, table VPN_A)
Multipath: eiBGP
Flag: 0x820
 Not advertised to any peer
 103 101
   10.3.3.3 (metric 30) from 10.3.3.3 (10.3.3.3)
     Origin incomplete, metric 0, localpref 100, valid, internal, multipath, best
     Extended Community: RT:100:1
     mpls labels in/out nolabel/20
 107 106
   10.7.7.7 (metric 30) from 10.7.7.7 (10.7.7.7)
     Origin incomplete, metric 0, localpref 100, valid, internal, multipath
     Extended Community: RT:100:1
     mpls labels in/out nolabel/29

R5#show ip route vrf VPN_A 0.0.0.0
Routing entry for 0.0.0.0/0, supernet
 Known via "bgp 65510", distance 200, metric 0, candidate default path
 Tag 103, type internal
 Redistributing via rip
 Last update from 10.3.3.3 00:00:12 ago
 Routing Descriptor Blocks:
   10.7.7.7 (Default-IP-Routing-Table), from 10.7.7.7, 00:00:12 ago
     Route metric is 0, traffic share count is 1
     AS Hops 2
     Route tag 103
 * 10.3.3.3 (Default-IP-Routing-Table), from 10.3.3.3, 00:00:12 ago
     Route metric is 0, traffic share count is 1
     AS Hops 2
     Route tag 103

As always, if you have any questions please feel free to leave a comment and I’ll try to get back with you as soon as possible.