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 <[email protected]> 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. > _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
