Path Selection for Routes Across MPLS Network

[LIONEL GRIFFITH]

Customer hub site has two CE routers with two links connected to two seperate PE routers in the Carrier's MPLS network. At the customer's remote site one CE router on a single link is connected to PE router in MPLS network.

How can I configure the CE routers at the hub site to advertised the same network across the MPLS network to the CE router at the remote site? Also, how can I configure the CE router at the remote site to select on of the router as the primary and the other as secondary? Can I use local-preference on the CE router at the remote site to selected on path over the other.

I'm not sure if this makes any sense. Any help will be appreciated. Thanks

[Harold Ritter]

Even if you configure the two CE routers at the hub site to advertise the same prefixes, the PE router at the spoke site would select only one of them and pass it to the CE router. Bear in mind that by advertising the same prefixes from the two hub CE routers you should still get some load-sharing. Is it what you are trying to achieve?

Thanks,

Thanks,

[LIONEL GRIFFITH]

Thanks for the response.

The customer wants the capability to load-share traffic across the two links connecting to hub site CE rouers as well as use these links for redundancy.

Customer has remote CE routers globally connected to the MPLS network and need to have the remote CEs in the US sent traffic to networks at the hub site over one of the two links and the CEs in Rest-of-World use the other link at the hub site. If one of the hub link fails, traffic from all remote CEs will use the available link.

Will this design work across the MPLS network? If not, what are some other solutions that will accomplish meet these requirements?

[Harold Ritter]

Bear in mind that if you advertise the same prefixes from both hub ce routers, the best path decision will be taken in the providers core (either PE or RR, which must people use). The PE will only pass the best path to the spoke CE router and the CE has therefore no way to prefer one hub over the other.

One way to accomplish what you described is to advertise different prefixes from the two hub CE routers. For instance, you could originate the US specific prefixes and a summary prefix for the rest of the world (or a default route) on the US hub CE router. In the same way you would originate the rest of the world specific prefixes as well as a summary prefix for the US address space (or a default route)on the "rest-of-the-world" hub CE. This would provide for both loadsharing and redundancy.

Hope this helps,

[dtangent]

Harold,

I have a similar question with this setup. In my case, my customer is running EIGRP between PE-CE. They want to achieve load balancing and redundancy.

Off of one hub site, they have two core routers with two access links into the MPLS VPN cloud.

Here's my guess, please comment:

1. If both routers are connected to the same PE, then load balancing and redundancy will automatically occur. From the remote CE, it will pass all traffic to the remote PE (one access link, so no other choices). The remote PE will see two identical VPNv4 prefixes coming from the hub PE. It doesn't matter which route the remote PE installs, since it's to the same hub PE anyway. Remote PE will send traffic to the hub PE, when hub PE is sending traffic to customer site, the EIGRP process within the VRF will load balance, and provide redundancy.

2. If the two hub routes are connected to two different PEs for some reason, then I would imagine you would have to configure IBGP multipath for the load balancing and redundacy to work, assuming the two paths are "equal".

[Harold Ritter]

1. In this scenario, the remote PE only seex one VPNv4 route since the local PE only sendx one BGP update. You are correct though in saying that loadbalancing will happen naturally. The local PE generates one label per network per VRF, which causes the traffic to be loadbalanced properly.

2. Assuming that the the IGP metric to both PE is equal, you would need iBGP multipath on the remote PEs to loadbalance between the two hub site PEs. Care should be taken if you use route reflectors in this scenario as the route reflectors would select only the best path and advertise it to the remote PEs. The way around this issue would be to have a different RD on the two PEs connected to the hub site so that the route reflectors consider these two VPNv4 routes as different and doesn't compare them. This way the remote PEs receive both routes and can use them both.

Hope this helps,

[dtangent]

Even with multiple RDs for VRFs belonging to the same VPN, you still need IBGP multipath, correct? Multiple RDs is just to get around the RR restriction.

Also, you posted this message a while back:

"If you have many VPN customers all using the same addresses (most likely rfc1918), the fact that they have different RDs and that the PE prepends the RD to the prefixes exchanged between PEs will make the same prefixes different in the MPLS VPN core

cust1 advertises 192.168.1.0/24 with RD 1:1 therefore

VPNv4 prefix is 1:1:192.168.1.0

cust2 advertises 192.168.1.0/24 with RD 1:2 therefore

VPNv4 prefix is 1:2:192.168.1.0"

My test lab does not support the IBGP multipath command, and thus even with different RDs, it still only installs one best path.

I understand that RD = make unique VPNv4 routes in SP space, and that RT = what to import into the VRF. However, I am having a hard time visualizing the scenario with mutiple RDs for the same VPN for load balancing purposes. I am trying to understand the logic behind it.

Per your example, if both 1:1 and 1:2 are received by the remote PE, assuming IBGP multipath is enabled, why would the remote PE load balance between the two links? Why would it assume that the hub subnets are reachable via two different PEs, and that it's not two different, isolated VPNs altogether?

Is it b/c you imported both 1:1 and 1:2 into a VRF at the remote PE?

[Harold Ritter]

You are correct iBGP multipath is still required.

As far as your second question is concerned, the remote PE would know to import and use the two VPNv4 prefixes because both of these prefixes have been exported with a common RT.

Hope this helps,

[dtangent]

Thanks for all your help. It cleared a lot of my confusions.

[dtangent]

Ignore