Load sharing in MPLS/VPN networks with route reflectors
Some of the e-mails and comments I received after writing the “Changing VPNv4 route attributes” post illustrated common MPLS/VPN misconceptions, so it’s worth addressing them in a series of posts. Let’s start with the simplest scenario: load balancingsharing toward a multi-homed customer site. We’ll use a very simple MPLS/VPN network with three customer sites, four CE-routers, four PE-routers a route reflector:
Let’s assume that we use the default MPLS/VPN RT/RD design rules: one RD and one import/export RT per simple VPN. The IPv6 (or IPv4) default routes received by PE-A and PE-B are transformed into VPNv6 (or VPNv4) routes ([RD]::/0 or RD:0.0.0.0/0) and sent to RR.
RR receives two identical VPNv6 (or VPNv4) routes from two sources (PE-A and PE-B), installs both of them in its BGP table, selects the best one and sends the best one to the other BGP neighbors. PE-C and PE-D thus receive only a single default route and forward all traffic toward PE-A or PE-B (based on the decision BGP made on RR). There is absolutely no way to change the RR behavior – it’s one of those BGP rules that nobody wanted to touch (yet): only the best routes in the BGP table are propagated to BGP neighbors.
The above statement is not entirely correct – the BGP Best External feature is violating that rule and advertising best external route even when better internal route exists.
To enable PE-C and PE-D to forward traffic toward PE-A and PE-B, you have to make the two default routes somehow different. The only trick that works is changing the RD on one of them:
- PE-A advertises the default route received from CE-A as [RD1]::/0 (or RD1:0.0.0.0/0)
- PE-B advertises the default route received from CE-B as [RD2]::/0 (or RD2:0.0.0.0/0)
- RR receives two different routes (within the VPNv6 address family, [RD1]::/0 and [RD2]::/0 are different routes) and propagates both of them to PE-C and PE-D.
- PE-C and PE-D receive both routes and import both of them into the same VRF (remember: imports are based on RT, not RD) , enabling true load sharing toward PE-A and PE-B.
You have to configure BGP load sharing with the maximum-paths ibgp number router configuration command within the IPv4 VRF address family on PE-C and PE-D, otherwise they will not insert more than one BGP route into the VRF IP routing table (even though two routes are present in the BGP table).
More information
If you’re considering MPLS/VPN deployment in your enterprise network, watch the Enterprise MPLS/VPN Deployment webinar.
http://www.cisco.com/en/US/docs/ios/12_2t/12_2t11/feature/guide/ft11bmpl.html
or, Ivan, is it load balancing? :-E
http://puck.nether.net/pipermail/cisco-nsp/2006-November/036134.html
please, enlighten us, I hate to speak with impreciseness :)
http://blog.shafagh.com/2010/09/05/bgp-multipath-part-two/
http://blog.shafagh.com/2010/09/07/bgp-multipath-part-three/
Also, you HAVE TO enable IBGP multipath on PE-C and PE-D, otherwise they will not install additional BGP routes into the VRF routing table. Somehow I had the feeling it wasn't needed, but a quick lab test proved otherwise.
I hope I get green light to implement it in a production network (2 8M IMA bundles)...
I hope I get green light to implement it in a production network (2 8M IMA bundles)...
address-family vpnv4
bgp additional-paths install
I have two RR in a cluster. Without metric I can see both prefix.
Network Next Hop Metric LocPrf Weight Path
Route Distinguisher: 100:100
*>i 172.16.20.4/30 10.0.0.2 0 100 0 ?
*>i 192.168.1.1/32 10.0.0.2 0 100 0 65506 i
Route Distinguisher: 100:102
*>i 172.16.20.0/30 10.0.0.1 0 100 0 ?
*>i 192.168.1.1/32 10.0.0.1 0 100 0 65506 i
Route Distinguisher: 100:103
*>i 172.16.20.76/30 10.0.0.5 0 100 0 ?
*>i 192.168.1.3/32 10.0.0.5 0 100 0 65506 i