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

David Curran dcurran at nuvox.com
Wed Apr 23 08:45:16 EDT 2008


+1

We've gotten great results with IGP/BGP tuning.


> From: "Oliver Boehmer (oboehmer)" <oboehmer at cisco.com>
> Date: Wed, 16 Apr 2008 17:33:26 +0200
> To: <alaerte.vidali at nsn.com>, <cisco-nsp at puck.nether.net>
> Conversation: [c-nsp] MPLS L3 VPN over TE - Load Balancing per Customer
> Subject: Re: [c-nsp] MPLS L3 VPN over TE - Load Balancing per Customer
> 
> 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/



This email and any attachments ("Message") may contain legally privileged and/or confidential information.  If you are not the addressee, or if this Message has been addressed to you in error, you are not authorized to read, copy, or distribute it, and we ask that you please delete it (including all copies) and notify the sender by return email.  Delivery of this Message to any person other than the intended recipient(s) shall not be deemed a waiver of confidentiality and/or a privilege.


This email and any attachments ("Message") may contain legally privileged and/or confidential information.  If you are not the addressee, or if this Message has been addressed to you in error, you are not authorized to read, copy, or distribute it, and we ask that you please delete it (including all copies) and notify the sender by return email.  Delivery of this Message to any person other than the intended recipient(s) shall not be deemed a waiver of confidentiality and/or a privilege.


More information about the cisco-nsp mailing list