[c-nsp] LACP and QinQ

[Tom Hill]

On 16/07/18 18:21, David Wilkinson wrote:
> #show etherchannel load-balance
> EtherChannel Load-Balancing Configuration:
>         src-dst-port
> 
> EtherChannel Load-Balancing Addresses Used Per-Protocol:
> Non-IP: Source XOR Destination MAC address
>   IPv4: Source XOR Destination TCP/UDP (layer-4) port number
>   IPv6: Source XOR Destination IP address

> It feels like it the switches are not looking at the right headers
> within the packet and not matching on the Layer 3/4 headers, possibly
> due to the packets being double tagged assuming it does the XOR before
> the outer tag is removed?
> Any ideas on what might be going on here?

The evidence would suggest that this is a hashing problem, and more
specifically I would expect that it's actually trying to read the
payload EtherType, but hitting the 8021q EtherType instead - because
that's been moved along 4B. 0x8100 would balance as 'non-IP'.

Though this would assume that the ASIC is pushing on the 8021ad tag
before sending it off to be egressed on the Etherchannel.

Assuming that I'm right, I'm going to guess that - despite the QinQ port
- the CP device receiving the frames is a single router with the same
source MAC being used on multiple sub-interfaces? Hence there's no
difference when hashed on DST MAC?

There's no way I can see to adjust this behaviour in a 4948, again
assuming I'm right about what it's doing. If you had multiple
source/dest MACs you could potentially improve on this, but it'd still
be clunky.

The 4948E is - I believe - SUP6E based, and that can perform one-to-one
VLAN mapping. This swaps the C-tag for a configured S-tag (and
vice-versa). You'd use a lot of tags, but hopefully there's space in
this case. Critically I don't believe then that it will double-tag when
configured as such.


FYI, and in case anyone else is watching (and learning) you would
probably want to add 'vlan dot1q tag native' to your config:

"(Optional) Sets the switch to enable tagging of native VLAN packets on
all 802.1Q trunk ports. When not set, and a customer VLAN ID is the same
as the native VLAN, the trunk port does not apply a metro tag, and
packets could be sent to the wrong destination."

... And I'd configure 'switchport nonegotiate' to disable DTP, too:

"Dynamic Trunking Protocol (DTP) is not compatible with 802.1Q tunneling
because you must manually configure asymmetric links with tunnel ports
and trunk ports."


-- 
Tom