The use of QinQ to separate customers seems to me fundamentally flawed, and this isn't brought out in the documents. Please correct me if I'm wrong.
Typically, A VLAN represents a broadcast domain; MAC addresses must be unique within a particular broadcast domain.
However, MAC addresses don't HAVE to be unique across a network; in fact, a device connected to multiple VLANs may often exhibit the same MAC address, and that is totally valid.
For example, the VRRP MAC commonly appears 00-00-5E-00-01-00 in different vlans/broadcast domains.
QinQ Stacked VLAN tags add a VLAN tag to a separate service; however, they do not change the MAC address.
Imagine this scenario: a service provider uses a VPLS instance to provide layer-2 services to different customers. They're using the service tags (the outer VLAN tag ) to identify and separate customers. However, within the VPLS instance, no such distinction is made; customers' MAC addresses all appear in the same table. This opens a scenario where one customer's Mac address could be identical to another customer's Mac, ( especially likely with the VRRP mac ) this could likely cause forwarding issues, I wonder if this issue is responsible for random forwarding issues that no one is ever able to get to the bottom of , problems caused by this certainly would be ephemeral, I've certainly encountered problems with service providers where they told me I couldn't use a particular Mac address, which seemed bizarre at the time.
I'm currently re-studying JNCIP-SP, which reminded me of this issue.


I've running through the Juniper course on this, the "inner-all" actually makes the situation worse.
If the VLAN-aware option is used (vlan-id vlan-all), customers will be separated, but they can still clash with identical C tags within the same customer. This is less of an issue, but it could cause some strange, difficult-to-diagnose forwarding issues.

In my example here, macs:14 and 24 are for Customer A, and :15 and :25 are for a different customer. By choosing the correct MAC, one customer could DOS another customer.
Of course, the correct way and a better practice would be to have a separate VPLS instance per customer.
I'm just surprised, given the above, QinQ is even mentioned as a valid method for separating customers.
------------------------------
JNCIE-ENT 907
------------------------------