Rate and give feedback:  Feedback Received. Thank You!

Rate and give feedback: 

X

This document helped resolve my issue

Yes No

Additional Comments

800 characters remaining

May we contact you if necessary?

Name:  

E-mail: 

Enter a valid Email ID

Need product assistance? Contact Juniper Support

Submit

This site is protected by hCaptcha and its Privacy Policy and Terms of Service apply.

English  

English

Understanding Q-in-Q Tunneling and VLAN Translation

How Q-in-Q Tunneling Works

In Q-in-Q tunneling, as a packet travels from a customer VLAN (C-VLAN) to a service provider's or data center VLAN (S-VLAN), another 802.1Q tag for the appropriate S-VLAN is added before the C-VLAN tag. The C-VLAN tag remains and is transmitted through the network. As the packet leaves the S-VLAN in the downstream direction, the S-VLAN 802.1Q tag is removed.

An interface can be a member of multiple S-VLANs. You can map one C-VLAN to one S-VLAN or multiple C-VLANs to one S-VLAN. C-VLAN and S-VLAN tags use separate name spaces, so you can have both a C-VLAN 101 and an S-VLAN 101, for example. You can limit the set of accepted customer tags to a range of tags or to discrete values.

When Q-in-Q tunneling is enabled, trunk interfaces are assumed to be part of the service provider or data center network. Access interfaces are assumed to be customer-facing and accept both tagged and untagged frames. When using many-to-one bundling or mapping a specific interface, you must use the native option to specify an S-VLAN for untagged and priority tagged packets if you want to accept these packets. (Priority tagged packets have their VLAN ID set to 0, and their priority code point bits might be configured with a CoS value.) If you do not specify an S-VLAN for them, untagged packets are discarded. The native option is not available for all-in-one bundling because there is no need to specify untagged and priority tagged packets when all packets are mapped to an S-VLAN.

On QFabric systems only, you can use the native option to apply a specified inner tag to packets that ingress as untagged on access interfaces. This functionality is useful if your QFabric system connects to servers that host customer virtual machines that send untagged traffic and each customer’s traffic requires its own VLAN while being transported through the QFabric. Instead of using individual VLANs for each customer (which can quickly lead to VLAN exhaustion), you can apply a unique inner (C-VLAN) tag to each customer’s traffic and then apply a single outer tag (S-VLAN) tag for transport through the QFabric. This allows you to segregate your customers’s traffic while consuming only one QFabric VLAN. Use the inner-tag option of the mapping statement to accomplish this.

Q-in-Q tunneling does not affect any class-of-service (CoS) values that are configured on a C-VLAN. These settings are retained in the C-VLAN tag and can be used after a packet leaves an S-VLAN. CoS values are not copied from C-VLAN tags to S-VLAN tags.

Depending on your interface configuration, you might need to adjust the MTU value on your trunk or access ports to accommodate the 4 bytes used for the tag added by Q-in-Q tunneling. For example, if you use the default MTU value of 1514 bytes on your access and trunk ports, you need to make one of the following adjustments:

• Reduce the MTU on the access links by at least 4 bytes so that the frames do not exceed the MTU of the trunk link when S-VLAN tags are added.
• Increase the MTU on the trunk link so that the link can handle the larger frame size.

Note: You can configure Q-in-Q tunneling only on access ports (not trunk ports).

How VLAN Translation Works

VLAN translation replaces an incoming C-VLAN tag with an S-VLAN tag instead of adding an additional tag. The C-VLAN tag is therefore lost, so a single-tagged packet is normally untagged when it leaves the S-VLAN (at the other end of the link). If an incoming packet has had Q-in-Q tunneling applied in advance, VLAN translation replaces the outer tag and the inner tag is retained when the packet leaves the S-VLAN at the other end of the link.

To configure VLAN translation, use the mapping swap statement at the [edit vlans interface] hierarchy level.

Note: You can configure VLAN translation on access ports only. You cannot configure it on trunk ports, and you cannot configure Q-in-Q tunneling on the same access port.

Note: VLAN translation is not supported on QFabric systems.

Mapping C-VLANs to S-VLANs

The three ways to map C-VLANs to an S-VLAN are:

• All-in-one bundling—Use the edit vlans s-vlan-name dot1q-tunneling statement without specifying customer VLANs. All packets received on all access interfaces (including untagged packets) are mapped to the S-VLAN.
• Many-to-one bundling—Use the edit vlans s-vlan-name dot1q-tunneling customer-vlans statement to specify which C-VLANs are mapped to the S-VLAN. Use this method when you want a subset of the C-VLANs to be part of the S-VLAN. If you want untagged or priority tagged packets to be mapped to the S-VLAN, use the native option with the customer-vlans statement. (Priority tagged packets have their VLAN ID set to 0, and their priority code point bits might be configured with a CoS value.)
• Mapping a specific interface—Use the edit vlans s-vlan-name interface interface-name mapping statement to specify a C-VLAN for a given S-VLAN. This configuration applies to only one interface—not all access interfaces as with all-in-one and many-to-one bundling. If you want untagged or priority tagged packets to be mapped to the S-VLAN, use the native option with the customer-vlans statement.

  This method has two options: swap and push. With the push option, a packet retains its tag and an additional VLAN tag is added. With the swap option, the incoming tag is replaced with an S-VLAN tag. (This is VLAN translation.)

  • You can configure multiple push rules for a given S-VLAN and interface. That is, you can configure an interface so that the same S-VLAN tag is added to packets arriving from multiple C-VLANs.
  • You can configure only one swap rule for a given S-VLAN and interface.

  This functionality is typically used to keep traffic from different customers separate or to provide individualized treatment for traffic on a certain interface.

1. Specific interface mapping
2. Many-to-one bundling
3. All-in-one bundling

You cannot configure overlapping rules for the same C-VLAN using the same mapping method. For example, you cannot use many-to one bundling to map C-VLAN 100 to two different S-VLANs.

Routed VLAN Interfaces on Q-in-Q VLANs

Routed VLAN interfaces (RVIs) are supported on Q-in-Q VLANs. Routing is based on the S-VLAN, and the original C-VLAN tag is dropped when a packet leaves the VLAN that it originated in. Outgoing routed packets retain any S-VLAN tag only when exiting a trunk interface—S-VLAN tags are dropped when traffic exits an access interface.

Constraints for Q-in-Q Tunneling and VLAN Translation

Be aware of the following constraints when configuring Q-in-Q tunneling and VLAN translation:

• Most access port security features are not supported with Q-in-Q tunneling and VLAN translation.
• Configuring Q-in-Q tunneling and VLAN translation on the same port is not supported.
• You can configure at most one VLAN translation for a given VLAN and interface. For example, you can create no more than one translation for VLAN 100 on interface xe-0/0/0.
• The combined total of VLANs and rules for Q-in-Q tunneling and VLAN translation cannot exceed 6000. For example, you can configure and commit 4000 VLANs and 2000 rules for Q-in-Q tunneling and VLAN translation. However, you cannot configure 4000 VLANs and 2500 rules for Q-in-Q tunneling and VLAN translation. If you try to commit a configuration that exceeds the limit, you see CLI and syslog errors that inform you about the problem.
• MAC addresses are learned from S-VLANs, not C-VLANs.
• Broadcast, unknown unicast, and multicast traffic is forwarded to all members in the S-VLAN.
• The following features are not supported with Q-in-Q tunneling:
  • DHCP relay
  • Fibre Channel over Ethernet
  • IP Source Guard
• The following features are not supported with VLAN translation:
  • Fibre Channel over Ethernet
  • Firewall filter applied to a port or VLAN in the output direction
  • Private VLANs
  • VLAN Spanning Tree Protocol
  • Reflective relay