[c-nsp] MPLS L3 VPN over TE - Load Balancing per Customer

Oliver Boehmer (oboehmer) oboehmer at cisco.com
Wed Apr 16 12:04:36 EDT 2008


Peter Rathlev <mailto:peter at rathlev.dk> wrote on Wednesday, April 16,
2008 5:45 PM:

> And TE is a very exciting subject; it's always fun to have more
> control. :-)

Hehe, more control, more complexity :)

> By the way: Is this loss of load sharing you mention specific to FRR,
> or is it an integral thing to TE generally?

Well, its integral to TE and depends on how you set up your tunnels. If
you set up a tunnel between two edge routers, the traffic will take only
one path through your core, while it could be load-shared over multiple
paths when packets followed your IGP paths. You might need to set up
multiple tunnels between the two endpoints to mimic this behaviour. This
might or might not be an issue depending on number of tunnels in the
mesh and the specific traffic matrix/volume, but something to consider
when planning it.

	oli

 
> 
> Regards,
> Peter
> 
> On Wed, 2008-04-16 at 17:33 +0200, Oliver Boehmer (oboehmer) wrote:
>> Agreed, but I was rather asking why people start selectively route
>> vrfs over specific tunnels? If you deploy a FRR solution, you might
>> as well send all traffic over it (some caveats might apply, for
>> example a possible loss of load-sharing) by enabling
>> autoroute-announce.. 
>> 
>> Another thought on this: core link failures are usually your least
>> concern when it comes to L3VPN convergence, you can generally achieve
>> sub-second tuning your IGP (some caveats might apply, depending on
>> platform and environment). PE node or PE-CE link failures are much
>> more "critical", and TE-FRR will not help you address either of
>> these failures. 
>> 
>> 	oli
>> 
>> alaerte.vidali at nsn.com <mailto:alaerte.vidali at nsn.com> wrote on
>> Wednesday, April 16, 2008 4:09 PM:
>> 
>>> Tks Oli,
>>> 
>>> I believe it is a trend due to FastReroute recovery for VPN
>>> customers. Maybe it change soon with IP FastReroute. Maybe not :)
>>> 
>>> I will test it again with your suggestion.
>>> 
>>> Tks again,
>>> Alaerte
>>> 
>>> -----Original Message-----
>>> From: ext Oliver Boehmer (oboehmer) [mailto:oboehmer at cisco.com]
>>> Sent: Wednesday, April 16, 2008 5:43 AM
>>> To: Vidali Alaerte (NSN - BR/Rio de Janeiro);
>>> cisco-nsp at puck.nether.net
>>> Subject: RE: [c-nsp] MPLS L3 VPN over TE - Load Balancing per
>>> Customer 
>>> 
>>> alaerte.vidali at nsn.com <> wrote on Tuesday, April 15, 2008 10:18 PM:
>>> 
>>>>  Hi,
>>>> 
>>>> Considering the topology where MPLS VPN over TE is used: (2 links
>>>> between PE1--PE2) 
>>>> 
>>>> CustA------PE1========PE2----CustA
>>>>             |          |
>>>> CustB_______|          |_____CustB
>>>> 
>>>> 
>>>> What are the possibilities of loading balance traffic in the way
>>>> CustA
>>> 
>>>> traffic goes through link 1 and CustB traffic goes through link 2?
>>>> (considering BGP next hop is the same for CustA and CustB)
>>> 
>>> Why are you using TE in this setup?
>>> 
>>> The TE tunnel will only use one of the two links. If you really
>>> want to achieve what you describe, you need two tunnels and use bgp
>>> next-hop manipulation to steer the traffic over the respective
>>> tunnel. But you could also use two tunnels and use CEF load-sharing
>>> for a single bgp next-hop. TE also allows to do unequal-cost
>>> loadsharing, but you are probably aware of this already.
>>> 
>>> 	oli
>>> 
>>> P.S: This is the third time L3VPN over TE has come up in the past
>>> few weeks. Is this a trend? ;-)
>> _______________________________________________
>> 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/


More information about the cisco-nsp mailing list