[c-nsp] Wierd MPLS/VPLS issue

[Saku Ytti]

On 13 January 2017 at 01:47, James Bensley <jwbensley at gmail.com> wrote:

Hey,

>> Now some people on the list propose control-word. This does not fix
>> the problem in Juniper, it does fix the problem in Cisco (EZChip),
>> because Cisco does not have platforms which inspect inside
>> pseudowires.

> See Warris' recent post to C-NSP which linked to documentation about
> the load balancing behaviour of MPLS labelled traffic for the
> ME3600X/ME3800X and ASR920 boxes, they are two examples of Cisco
> devices which look into the pseudowire.

Thanks, I worded that poorly, should have worded it to talk about
EZChip platforms (ES+, Trident, Typhoon, Tomahawk).

While it can be quick solution to balancing issues, it's going to be
heuristic, it cannot be always correct no matter what you do when you
try to peek inside pseudowire. There is no way to reliably tell what
is being carried.

> They also detect if there is or isn't a control-word.

You also cannot reliably detect presence or absence of control-word as
it could be start of a valid DMAC. What 100% control-word allows you
to do, is reliably do hashing on IPv4/IPv6 and no hashing on
pseudowires (if no peaking). But if you intend to detect i there is
pseudowire and start ethernet header detection on offset based on that
guess, it's only going to be 'mostly right'. But if you're unlucky,
you can end up with nearly impossible to debug problems.

The always correct behaviour is entropy or fat + control-word + no
peek inside pseudowires and balance on labels.

> For stuff like the 7600 is more basic:
>
> "MPLS Layer 2 VPN Load Balancing: Load balancing is based on the VC
> label in the MPLS core if the first nibble of the MAC address in the
> customer Ethernet frame is not 4."


-- 
  ++ytti