Metro Ethernet and Q-in-Q: does customer's switch need to support it?

Question

We're looking at getting a LAN extension for a branch office; we'd like head office VLANs to be present at this new location. Local telco says they can do Q-in-Q, but I don't believe our current switches support Q-in-Q.

From what I'm reading, it sounds like the agreed-upon VLANs would be tagged on the customer's egress port (i.e. our switch), and then the telco's CPE switch would handle the Q-in-Q and vice-versa on the other end, so presumably we'd just have to tag the appropriate VLANs on our switch ports.

Just want to be sure that Q-in-Q is not a required switch feature on the customer's side of the equation.

Thanks

Answer 1

You're correct. The usual service is that the client-side frames are encapsulated at the network edge within service-side frames which then appear as usual 802.1q frames to other switches within the service provider. A de-encapsulation occurs at the far network edge, and the client-set VLAN tags are presented at the client-facing interface.

Having said this, the "typical" practice of a service provider and your particular service provider's practice may vary, which in this case would be enough reason in this case to choose a more typical service provider. You should ask for a technical service description for any service you buy.

That service description will also list other important parameters, such as how many MAC addresses can be visible to the service, and what happens when that number is exceeded. Practice there varies widely, with "one per client-facing interface" and "shutdown until manually restored" being common for services designed to run between IP routers (eg, connections into LINX), and maybe a few thousand being typical for services designed to run between a central router and a remote office switch.

You want to ensure that the service description allows untagged frames to be passed. I know it would be weird for a service not to do this, but I have come across this case.

Ensure the service provider's service description is be clear about the types of BPDUs which will be transparently transported across the service. You at least want to be able to pass your spanning-tree and LLDP PDUs unaltered. In an ideal service, all BPDUs are passed unaltered between your equipment. The stress-test service here is usually the control BPDUs for supporting MacSec encryption (and you really should think about running MacSec between your service-provider facing interfaces, it's the simplest way to protect yourself from subversion of the service provider's infrastructure; there's even SFPs which will run MacSec internally).

Answer 2

If the telco says they would do QinQ, then you won't need it on your equipment. Moreover, you won't need to agree the transport VLAN and set it on your switch, as this is the setting on the device that actually does the QinQ. From outside-the-QinQ perspective you just have a pure VLAN-agnostic ethernet connection to the remote location.