3

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

4

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

| improve this answer | |
  • Excellent answer. This remote location is small, with ~20 nodes and a single switch (and no room for more bums in seats), so I wasn't planning on participating in the existing spanning tree (MST) topology as there won't be a redundant path between remote/head office; this metro LAN will be hanging off of an access switch unfortunately, not the core. I guess it wouldn't hurt though. – gravyface May 30 '18 at 10:38
0

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.

| improve this answer | |
  • Interesting. They mention a limit of number of C-VLANs on their service offering and we need to agree upon those VLANs in advance. – gravyface May 30 '18 at 10:24
  • That strongly suggests that the Q-in-Q encapsulation is not occurring at the service-provider network edge. Which in turn suggests bad things happen to BPDUs (which in turn makes managing your network harder). You should explore this more fully with the service provider, because whilst it's not a show-stopper it's not a good sign either. – vk5tu May 30 '18 at 10:35
  • Limits are usually to save their infrastructure resources - are you sure they weren't speaking about MAC-addresses? As for the sub-VLANs (your's), why would anyone need to agree upon them? If they are limiting their service, they might want't you to give them a list to be set up, just like they might want you to give them you MAC addresses to be locked on ports. But these would be a business issues, not technical: more VLANs, more $$$. – Tomasz Pala May 30 '18 at 10:35
  • Sorry, to clarify, they want a list of VLANs submitted and there are a max limit of 5 customer VLANs for this service. Knowing telcos, they'll gouge you where they can, so this could be purely a financial/service model "limit". – gravyface May 30 '18 at 10:45

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.