In part 3, we’ll use RD to facilitate multipathing for a multi-homed customer.
We’ll add another CE for CUSTOMER_A, CE5. The customer wants you, the provider, to make sure that 10.20.0.0/16 traffic is load balanced between CE1 and CE5. Both CE1 and CE5 will advertise this prefix.
Let’s advertise 10.20.0.0/16 from both CE1 and CE5 and see what happens by default. We’ll continue to use the same RD and RT for CUSTOMER_A, 123:100, on PE4.
#CE1
int lo20
ip address 10.20.0.1 255.255.0.0
!
router bgp 65000
network 10.20.0.0 mask 255.255.0.0
#CE5
int lo20
ip address 10.20.0.1 255.255.0.0
!
router bgp 65002
network 10.20.0.0 mask 255.255.0.0
Because PE1 and PE4 use the same RD for the VRF, P3 will choose only a single route:
P3#show bgp vpnv4 unicast rd 123:100 | begin Network
Network Next Hop Metric LocPrf Weight Path
Route Distinguisher: 123:100
*>i 10.0.0.0/24 1.1.1.1 0 100 0 65000 i
*>i 10.0.1.0/24 2.2.2.2 0 100 0 65001 i
*>i 10.10.10.0/24 1.1.1.1 0 100 0 65000 i
*>i 10.20.0.0/16 1.1.1.1 0 100 0 65000 i
* i 4.4.4.4 0 100 0 65002 i
P3 chosse the route from PE1 as best, and this is what PE2 sees:
RP/0/0/CPU0:PE2#show bgp vrf CUSTOMER_A ipv4 unicast | be Network
Fri Jul 22 02:43:05.698 UTC
Network Next Hop Metric LocPrf Weight Path
Route Distinguisher: 123:100 (default for vrf CUSTOMER_A)
*>i10.0.0.0/24 1.1.1.1 0 100 0 65000 i
*> 10.0.1.0/24 100.64.1.6 0 0 65001 i
*>i10.10.10.0/24 1.1.1.1 0 100 0 65000 i
*>i10.20.0.0/16 1.1.1.1 0 100 0 65000 i
So how do we accomplish the customer’s request? We need PE2 to load balance traffic destined to 10.20.0.0/16 to PE1 and PE4.
First we need to set ibgp maximum-paths to 2 for the VRF under BGP. At minimum we need to do this for PE2 in our lab, but in the real world you’d do this on all PEs participating in the L3VPN.
Now PE2 will load balance up to 2 paths, but we still only have 1 path received on PE2. In order to make the RR (P3) send both paths to PE2, we’ll simply use a unique RD on PE4.
We have two routes now for 10.20.0.0/16 but PE2 is not load balancing them:
RP/0/0/CPU0:PE2#show bgp vrf CUSTOMER_A ipv4 uni | be Network
Fri Jul 22 03:53:59.276 UTC
Network Next Hop Metric LocPrf Weight Path
Route Distinguisher: 123:100 (default for vrf CUSTOMER_A)
*>i10.0.0.0/24 1.1.1.1 0 100 0 65000 i
*>i10.10.10.0/24 1.1.1.1 0 100 0 65000 i
*>i10.20.0.0/16 1.1.1.1 0 100 0 65000 i
* i 4.4.4.4 0 100 0 65002 i
RP/0/0/CPU0:PE2#sho route vrf CUSTOMER_A 10.20.0.0/16
Fri Jul 22 03:59:22.594 UTC
Routing entry for 10.20.0.0/16
Known via "bgp 123", distance 200, metric 0
Tag 65000, type internal
Installed Jul 22 03:59:15.855 for 00:00:06
Routing Descriptor Blocks
1.1.1.1, from 3.3.3.3
Nexthop in Vrf: "default", Table: "default", IPv4 Unicast, Table Id: 0xe0000000
Route metric is 0
No advertising protos.
This is because by default, BGP will only load balance routes if they have the same AS path. We’ll add a command to relax the as-path check for multipathing under the BGP VRF config. This is needed because we used a unique private AS at each customer location.
RP/0/0/CPU0:PE2#show route vrf CUSTOMER_A 10.20.0.0/16
Fri Jul 22 03:58:51.886 UTC
Routing entry for 10.20.0.0/16
Known via "bgp 123", distance 200, metric 0
Tag 65000, type internal
Installed Jul 22 03:58:12.089 for 00:00:39
Routing Descriptor Blocks
1.1.1.1, from 3.3.3.3, BGP multi path
Nexthop in Vrf: "default", Table: "default", IPv4 Unicast, Table Id: 0xe0000000
Route metric is 0
4.4.4.4, from 3.3.3.3, BGP multi path
Nexthop in Vrf: "default", Table: "default", IPv4 Unicast, Table Id: 0xe0000000
Route metric is 0
No advertising protos.
Conclusion
By using a unique RD value per-PE for a VRF, we can achieve multipathing. This technique is very easy to implement, and causes the RR to view prefixs received from each PE as unique, instead of prefixes from each VRF among all PEs as unique (when using the same RD everywhere).
