Hi Guys,
I have a couple of nexus 5600 switches connected via a physical dark fibre line. We carry our own VLAN tags over the link. But I would now like to make a port connected at one location be able to transparently pass through all ethernet frames & protocols to a port at the other end, that way all VLAN tags will pass through from port to port, our switches don’t need to recognise the tags, we just need to pass them through.
What protocols exist for that kind of service?
James.
MPLS L2VPN is what you are looking for, of course you’ll have to setup the devices as MPLS PE’s.
Hello James
What you are describing sounds exactly like QinQ, also known as 802.1Q tunneling. This is a technique used to pass multiple VLANs within a single VLAN. It’s essentially adding an inner tag and an outer tag. The inner tag is ignored by the edge switches and is decapsulated. Once the outer tag is removed, the inner tags are processed normally on the internal networks at each site.
More about QinQ and how it is configured can be found here:
It’s called QinQ because it places an 802.1Q tag within another 801.2Q tag, so it is a Q inside a Q.
I hope this has been helpful!
Laz
Hello Matthew
MPLS L2VPN is indeed another option, but in order for it to fulfill the requirement of sending VLAN tags that are ignored, you must employ the QinQ feature. This can be done in MPLS L2VPN as well, and is further described here.
I hope this has been helpful!
Laz
Hi Guys,
Thanks, I think QnQ tunnelling will do what I need over a VLAN with two access ports, I was a bit confused about how the source tags were encapsulated, but that makes sense to me now.
However, what if I have VLAN handoff from one switch to another utilising a trunk port. How would I embed tags and get at the inside tags at either end on the same switches. Eg. VLAN 10 is the ethernet handoff to the remote trunk port, but I need to carry packets from VLAN50. The SVI for VLAN50 is also on the same switches. Can we map VLAN50 to an inner tag, and get it translated at the other end?
Thanks again.
Hello James
I’m not sure I quite understand what it is you want to do, but I believe that this explanation may be helpful to clarify.
QinQ is typically employed by ISPs within their infrastructure. You can do it on your own network as well, but you must make a distinction between the portion of the network doing the tunnelling (the “ISP” network) and the customer network. Take a look at this example:
The “magic” of QinQ happens at the Gi0/3 interface of SW2 and SW3. The link between SWC1 and SW2 is a strange entity because on SWC1’s end, it is configured as a trunk, and on SW2’s side it is configured as an access port. Any frames arriving on Gi0/3 of SW2 will be placed on the VLAN of that access port, say VLAN 10, and forwarded throughout the ISP network on that VLAN. But remember, the original VLAN tags remain intact. SW2 simply interprets them as untagged frames, so that they can be further tagged with the VLAN of that particular customer on the ISP.
So SWC1 can send tagged frames on multiple VLANs, and all of those VLANs are encapsulated into a single VLAN 10 on the ISP network, a VLAN that belongs to that particular customer.
When those frames reach Gi0/3 of SW3, that outer VLAN tag containing the VLAN ID of 10 is removed, and the frames reach SWC2 with their original VLAN tags intact. VLAN ID 10 is considered the outer tag, while the multiple VLAN tags of the customer network are considered the inner tags. As shown in the lesson, this appears like so, with the green tag as the outer tag and the blue tag as the inner tag.
So you see, SWC1 actually thinks it is directly connected with SWC2. To clarify this further, if SWC1 sends a CDP update it will be encapsulated by SW2, encapsulated by SW3, and reach SWC2 unmodified. If you do a show cdp neighbors on SWC1 it will show SWC2 as its directly connected neighbor. CDP can’t “see” any of the switches in the ISP network.
I hope this has been helpful!
Laz
