Routing

 View Only

QinQ VPLS fundamental Issues Not discussed

  • 1.  QinQ VPLS fundamental Issues Not discussed

    Posted 01-08-2026 09:15
    Edited by Simon Bingham (technical debt collector) 01-08-2026 09:21

    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
    ------------------------------