[c-nsp] Nightmare for load balancing of L2VPN traffic on CRS (traffic from ME3600)

Darren Liew darrenssliu at gmail.com
Sun Apr 12 21:33:17 EDT 2015


Hi Adam & Mark,

We have opened Cisco TAC case to check, apparently the FAT-PW feature is
not on Cisco ME3600 roadmap for now.

Even with FAT-PW solution, it doesn't sounds ideal as it requires other
equipment to change config to overcome the shortcoming of CRS. Imagine we
already have few thousands of PW around the network.

We are talking to Cisco on this. Will keep you guys posted of the outcome.
Cheers !

Rgds
Darren Liu



On Sun, Apr 12, 2015 at 10:29 PM, Mark Tinka <mark.tinka at seacom.mu> wrote:

>
>
> On 9/Apr/15 09:31, Adam Vitkovsky wrote:
> > Hi Darren,
> >
> > Been in the same shituation though I'm not familiar with CRS MPLS
> hashing algo I guess it also looks at the next header field after the
> bottom of the stack label and if it won't find 0x4 or 0x6 (hopefully in
> case of L2VPNs) it won't do src/dst IP address hash so for L2VPNs the
> hashing is done solely based on the VC label which is a bummer.
> >
> > And yes I've been asking for FAT-PW on MEs some time ago and there's no
> will at all...
> >
> > In our case we carried a bulk of VLANs in the high bandwidth PWs so we
> broke them into ever smaller PWs and that kind of helped to balance the
> traffic a little better.
> >
> > Otherwise without FAT-PW I guess the only option is to get MPLS-TE
> involved then you can tell which PW should use which TE tunnel thus balance
> the traffic "evenly" across the backbone.
>
> This thread is timely, as I was looking at FAT (RFC 6391) just last week.
>
> So implementation in IOS and IOS XE seems cumbersome, i.e., there is
> some kind of "interface pseudowire" thing that looks clumsy, and yet the
> IOS XR implementation is more as one would expect.
>
> At any rate, I see the code in the ME3600X software, but have no tried
> it. Are folk saying the code is there but it doesn't execute?
>
> Mark.
>


More information about the cisco-nsp mailing list