q-in-q and subinterface MAC address

[wintermute000]

Is there any issue running Q-in-Q if the tunnel ports face dot1q interfaces terminating on the same device's sub-interfaces - which use the same MAC address?


Cisco says this which is worrying, but even more irritatingly they use the word 'may'
http://www.cisco.com/c/en/us/td/docs/switches/datacenter/sw/5_x/nx-os/interfaces/configuration/guide/if_cli/if_qinq_tunnel.pdf

"MAC address learning for Q-in-Q tagged packets is based on the outer VLAN (Service Provider VLAN) tag. Packet forwarding issues may occur in deployments where a single MAC address is used across multiple inner (customer) VLANs."
On one hand, you can see how having the same MAC address that was split across multiple VLANs now mashed into a single L2 domain (the SP or outer VLAN) can cause issues.
On the other hand, once the Q-in-Q switch strips away the outer VLAN, you're back in the correct inner VLAN, so whats the problem?
Might have to resort to a HW lab, but anyone got any XP on this?

[wintermute000]

The brains trust here have concluded that the warning is there if you use virtual generated MACs etc. on different devices hooking into the same Q-in-Q domain.
If its a straight point to point (For example) then it doesn't matter as the outer tag is stripped then the frame is dropped into the appropriate VLAN.
It only becomes an issue if the MAC address comes from different switches

[Dieselboy]

Short answer, no. This was a design I was involved in. We had multiple 4948E switches. On one switch we had a 4GB Etherchannel comprised of short Cat6 crossover cables. All 4 cables connected back into the same switch and set up to do the encapsulation on one side of the channel and decapsulation on the otherside. Previous to upgrading the 3750s to 4948's we needed a dedicated pair of ports per customer to do this. The 4948s support the config above as a feature. This reduced costs and increased port density and throughput!

QinQ is just another 802.1Q VLAN tag. You can actually do QinQinQinQinQ if you want. But your path MTU needs to support it, because your DATA packet can be 1500bytes and 4 bytes get added on with each inQ.

You've mentioned the virtual mac issue - use HSRPv2 for the virtual mac addresses and ensure each virtual interface mac is unique on the inner. The problem happens when it's encapsulated because then instead of having mac addresses which are unique per-vlan, there are now many many mac addresses all in the same SP VLAN.

Remember what data is contained in the 4byte 802.1Q tag, because only this is changing each time the packet is "encapsulated". The data is not really encapsulated at all so this is an incorrect term to put it simply. source/dest mac/ip remain the same, hence the issue with duplicate macs.

QinQ is fun stuff but the transit ISP we sourced in kept trying to do the encapsulation / decapsulation themselves when we already agreed to maintain full control. Basically, their deployments always did not work from day0.