Routing

 View Only
last person joined: 2 days ago 

Ask questions and share experiences about ACX Series, CTP Series, MX Series, PTX Series, SSR Series, JRR Series, and all things routing, including portfolios and protocols.

QinQ VPLS fundamental Issues Not discussed

  • 1.  QinQ VPLS fundamental Issues Not discussed

    Posted 10 days ago
    Edited by Simon Bingham (technical debt collector) 10 days ago

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