[c-nsp] CEF-based per-packet load-sharing under MPLS VPN

[Oliver Boehmer (oboehmer)]

Everton,

I assume you are talking about static PE-CE routing?
Have you considered a recursive load-sharing? I.e. instead of doing

ip route vrf FOO 10.0.0.0 255.255.0.0 Serial0/0/0
ip route vrf FOO 10.0.0.0 255.255.0.0 Serial0/0/1

do something like

ip route vrf FOO 10.0.0.0 255.255.0.0 1.1.1.1
ip route vrf FOO 1.1.1.1 255.255.255.255 Serial0/0/0
ip route vrf FOO 1.1.1.1 255.255.255.255 Serial0/0/1

This way you should be able to address at least the challenges in your
first scenario (1).

For dynamic PE-CE routing, iBGP/eiBGP multipath should give you the
knobs to import multiple paths into your BGP table(s).

I assume if you have scenario 1 working, you don't need the 2nd setup
(load-shared interfaces in multiple vrfs) anymore?

	oli



Everton da Silva Marques <> wrote on Tuesday, March 29, 2005 2:59 PM:

> We often sell MPLS VPNs with a single site
> attached to one PE thru multiple parallel links,
> hence the need to perform load sharing. We
> run IOS 12.0(27)S4 on multiple 7507 routers.
> 
> We used to rely on MLPPP for load sharing,
> but several problems are pushing us away from
> such option: (a) low bundle/member limit per
> VIP, (b) need to spare MLPPP LFI for QoS/voice,
> (c) experienced IOS instabilities.
> 
> Thus we are considering CEF-based per-packet
> load-sharing for VPN sites with parallel links.
> Problem is, as long as Cisco-aided troubleshooting
> has led us to believe, such CEF-based load-sharing
> won't work properly for the general MPLS VPN case.
> 
> For one VPN site attached to one PE thru parallel
> links:
> 1) If all parallel links attach to a single
>    VRF on the same PE:
>    (a) Packets coming from VRFs in remote PEs
>        are properly balanced among those multiple
>        parallel links.
>    (b) But VRFs at the same PE install only one
>        route pointing directly to only one of the
>        parallel output links, breaking the balance.
> 2) If each parallel link attach to a distinct
>    VRF on the same PE, we see the opposite:
>    (a) Packets coming from other VRFs of the
>        same PE are properly balanced among
>        the parallel output links.
>    (b) But now packets coming from VRFs of
>        remote PEs can't be balanced because
>        there's only one interface in the
>        destination VRF, breaking load-sharing
>        as well.
> 
> Result is, given one PE with parallel links
> towards a customer's site, by combining other
> VRFs in the same PE with VRFs from remote PEs
> to build the customer's VPN, we break output
> per-packet load-sharing.
> 
> Cisco is telling us the solution is MLPPP.
> Unfortunately, the MLPPP option clearly won't
> address our MPLS VPN load-balance problem
> much longer.
> 
> Has anyone tackled similar MPLS VPN
> load-sharing issues?
> 
> Regards,
> Everton
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/