An In-Depth Look at RD and RT, Pt. 3
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.
Because PE1 and PE4 use the same RD for the VRF, P3 will choose only a single route:
P3 chosse the route from PE1 as best, and this is what PE2 sees:
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:
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.
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).
Last updated