Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Configuring Q-in-Q Tunneling and VLAN Q-in-Q Tunneling and VLAN Translation

Understanding Q-in-Q Tunneling and VLAN Translation

Q-in-Q tunneling and VLAN translation allow service providers to create a Layer 2 Ethernet connection between two customer sites. Providers can segregate different customers’ VLAN traffic on a link (for example, if the customers use overlapping VLAN IDs) or bundle different customer VLANs into a single service VLAN. Data centers can use Q-in-Q tunneling and VLAN translation to isolate customer traffic within a single site or to enable customer traffic flows between cloud data centers in different geographic locations.

Using Q-in-Q tunneling, providers can segregate or bundle customer traffic into fewer VLANs or different VLANs by adding another layer of 802.1Q tags. Q-in-Q tunneling is useful when customers have overlapping VLAN IDs, because the customer’s 802.1Q (dot1Q) VLAN tags are prepended by the service VLAN (S-VLAN) tag. The Juniper Networks Junos operating system (Junos OS) implementation of Q-in-Q tunneling supports the IEEE 802.1ad standard.

This topic describes:

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 VLAN, a customer-specific 802.1Q tag is added to the packet. This additional tag is used to segregate traffic into service-provider-defined service VLANs (S-VLANs). The original customer 802.1Q tag of the packet remains and is transmitted transparently, passing through the service provider's network. As the packet leaves the S-VLAN in the downstream direction, the extra 802.1Q tag is removed.

Note:

All of the VLANs in an implementation can be service VLANs. That is, if the total number of supported VLANs is 4090, all of them can be service VLANs.

When Q-in-Q tunneling is enabled on Juniper Networks EX Series Ethernet Switches, trunk interfaces are assumed to be part of the service provider network and access interfaces are assumed to be customer facing. An access interface can receive both tagged and untagged frames in this case.

Note:

Starting with Junos OS 14.1X53-D30, you can configure the same interface to be an S-VLAN/NNI interface and a C-VLAN/UNI interface. This means that the same physical interface can transmit single-tagged and double-tagged frames simultaneously. This allows you maximum flexibility in your network topology and lets you maximize the use of your interfaces.

An interface can be a member of multiple S-VLANs. You can map one C-VLAN to one S-VLAN (1:1) or multiple C-VLANs to one S-VLAN (N:1). Packets are double-tagged for an additional layer of segregating or bundling of C-VLANs. C-VLAN and S-VLAN tags are unique; 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. Class-of-service (CoS) values of C-VLANs are unchanged in the downstream direction. You may, optionally, copy ingress priority and CoS settings to the S-VLAN. On non-ELS switches, you can use private VLANs to isolate users to prevent the forwarding of traffic between user interfaces even if the interfaces are on the same VLAN.

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

Note:

Priority tagged packets are not supported with Q-in-Q tunneling on QFX5100 and EX4600 switches.

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.

You can use the native option to specify an S-VLAN for untagged and priority tagged packets when using many-to-one bundling and mapping a specific interface approaches to map C-VLANs to S-VLANs. (This does not apply to switches supporting ELS.) Otherwise the 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 the S-VLAN. See the Mapping C-VLANs to S-VLANs section of this document for information on the methods of mapping C-VLANs to S-VLANs.

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.

On non-ELS switches, firewall filters allow you to map an interface to a VLAN based on a policy. Using firewall filters to map an interface to a VLAN is useful when you want a subset of traffic from a port to be mapped to a selected VLAN instead of the designated VLAN. To configure a firewall filter to map an interface to a VLAN, the vlan option has to be configured as part of the firewall filter and the mapping policy option must be specified in the interface configuration for each logical interface using the filter.

Note:

On an EX4300 switch, you can configure multiple logical interfaces on the same Ethernet port, but each logical interface supports only single-tagged packets and that tag must include a different VLAN ID than those supported by the other logical interfaces. Given this situation, you cannot enable Q-in-Q tunneling on Ethernet ports with multiple logical subinterfaces.

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. Incoming packets whose tags do not match the C-VLAN tag are dropped, unless additional VLAN translation configuration for those tags exist.

To configure VLAN translation, use the mapping swap statement at the [edit vlans interface] hierarchy level. As long as the C-VLAN and S-VLAN tags are unique, you can configure more than one C-VLAN-to-S-VLAN translation on an access port. If you are translating only one VLAN on an interface, you do not need to include the dot1q-tunneling statement in the S-VLAN configuration. If you are translating more than one VLAN, you must use the dot1q-tunneling statement.

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. You can configure only 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.

Note:

VLAN translation is not supported on QFabric systems.

Using Dual VLAN Tag Translation

Starting with Junos OS Release 14.1X53-D40, you can use the dual VLAN tag translation (also known as dual VLAN tag rewrite) feature to deploy switches in service-provider domains, allowing dual-tagged, single-tagged, and untagged VLAN packets to come into or exit from the switch. Table 1 shows the operations that are added for dual VLAN tag translation.

Table 1: Operations Added with Dual VLAN Tag Rewrite

Operation

Function

swap-push

Swap a VLAN tag and push a new VLAN tag

pop-swap

Pop an outer VLAN tag and swap an inner VLAN tag

swap-swap

Swap both outer and inner VLAN tags

Dual VLAN tag translation supports:

  • Configuration of S-VLANs (NNI) and C-VLANs (UNI) on the same physical interface

  • Control protocols such as VSTP, OSPF, and LACP

  • IGMP snooping

  • Configuration of a private VLAN (PVLAN) and VLAN on a single-tagged interface

  • Use of TPID 0x8100 on both inner and outer VLAN tags

See Setting Up a Dual VLAN Tag Translation Configuration on QFX Switches.

Sending and Receiving Untagged Packets

To enable an interface to send and receive untagged packets, you must specify a native VLAN for a physical interface. When the interface receives an untagged packet, it adds the VLAN ID of the native VLAN to the packet in the C-VLAN field and adds the S-VLAN tag as well (so the packet is double-tagged), and sends the newly tagged packet to the mapped interface.

The preceding paragraph does not apply to:

  • Non-ELS switches.

  • EX4300 switches running under a Junos release prior to Junos OS Release 19.3R1.

When the switches in the short list above receive an untagged packet, they add the S-VLAN tag to the packet (so the packet is single-tagged) and send the newly tagged packet to the mapped interface.

Note:

Ensure that all switches configured in your Q-in-Q setup operate with either the single-tag approach or the double-tag approach. The setup will not work if the switches do not have the same approach.

Starting in Junos OS Release 19.3R1, you can configure EX4300 switches to use the double-tag approach. Set the configuration statement input-native-vlan-push to enable and ensure that the input-vlan-map configuration statement is set to push, as shown in the following example:

Note:

On switches that support this feature, except for the EX4300 switch, the input-native-vlan-push statement is set to enable by default. (The input-native-vlan-push statement is set to disable by default on the EX4300 switch.) However, we recommend that you check the configuration to ensure that input-vlan-map is set to push—the feature does not work if that setting isn’t in place.

To specify a native VLAN, use the native-vlan-id statement at the [edit interfaces interface-name] hierarchy level. The native VLAN ID must match the C-VLAN or S-VLAN ID or be included in the VLAN ID list specified on the logical interface.

For example, on a logical interface for a C-VLAN interface, you might specify a C-VLAN ID list of 100-200. Then, on the C-VLAN physical interface, you could specify a native VLAN ID of 150. This configuration would work because the native VLAN of 150 is included in the C-VLAN ID list of 100-200.

We recommend configuring a native VLAN when using any of the approaches to map C-VLANs to S-VLANs. See the Mapping C-VLANs to S-VLANs section in this topic for information about the methods of mapping C-VLANs to S-VLANs.

Disabling MAC Address Learning

In a Q-in-Q deployment, customer packets from downstream interfaces are transported without any changes to source and destination MAC addresses. You can disable MAC address learning at global, interface, and VLAN levels:

  • To disable learning globally, disable MAC address learning for the switch.

  • To disable learning for an interface, disable MAC address learning for all VLANs of which the specified interface is a member.

  • To disable learning for a VLAN, disable MAC address learning for a specified VLAN.

Disabling MAC address learning on an interface disables learning for all the VLANs of which that interface is a member. When you disable MAC address learning on a VLAN, MAC addresses that have already been learned are flushed.

If you disable MAC address learning on an interface or a VLAN, you cannot include 802.1X authentication in that same VLAN configuration.

When a routed VLAN interface (RVI) is associated with either an interface or a VLAN on which MAC address learning is disabled, the Layer 3 routes resolved on that VLAN or that interface are not resolved with the Layer 2 component. This results in routed packets flooding all the interfaces associated with the VLAN.

Mapping C-VLANs to S-VLANs

There are multiple ways to map C-VLANs to an S-VLAN:

Note:

If you configure multiple mapping methods, the switch gives priority to mapping a specific interface, then to many-to-many bundling, and last to all-in-one bundling. However, for a particular mapping method, setting up overlapping rules for the same C-VLAN is not supported.

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

  • Many-to-many bundling—Use many-to-many bundling when you want a subset of the C-VLANs on the access switch to be part of multiple S-VLANs.

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

If you configure multiple methods, the switch gives priority to mapping a specific interface, then to many-to-one bundling, and last to all-in-one bundling. However, you cannot have overlapping rules for the same C-VLAN under a given approach. For example, you cannot use many-to one bundling to map C-VLAN 100 to two different S-VLANs.

All-in-One Bundling

All-in-one bundling maps all packets from all C-VLAN interfaces to an S-VLAN.

The C-VLAN interface accepts untagged and single-tagged packets. An S-VLAN 802.1Q tag is then added to these packets, and the packets are sent to the S-VLAN interface, which accepts untagged, single-tagged, and double-tagged packets.

Note:

The C-VLAN and S-VLAN interfaces accept untagged packets provided that the native-vlan-id statement is configured on these interfaces.

Many-to-One Bundling

Many-to-one bundling is used to specify which C-VLANs are mapped to an S-VLAN. Many-to-one bundling is configured using the customer-vlans option.

Many-to-one bundling is used when you want a subset of the C-VLANs on the access switch to be part of the S-VLAN. When using many-to-one bundling, untagged and priority tagged packets can be mapped to the S-VLAN when the native option is specified along with the customer-vlans option.

Many-to-Many Bundling

Many-to-many bundling is used to specify which C-VLANs are mapped to which S-VLANs.

Use many-to-many bundling when you want a subset of the C-VLANs on the access switch to be part of multiple S-VLANs. With many-to-many bundling, the C-VLAN interfaces accept untagged and single-tagged packets. An S-VLAN 802.1Q tag is then added to these packets, and the packets are sent to the S-VLAN interfaces, which accept untagged, single-tagged, and double-tagged packets.

Note:

The C-VLAN and S-VLAN interfaces accept untagged packets provided that the native-vlan-id statement is configured on these interfaces.

Mapping a Specific Interface

Use specific interface mapping when you want to assign an S-VLAN to a specific C-VLAN on an interface. The configuration applies only to the specific interface, not to all access interfaces.

Specific interface mapping has two suboptions: push and swap. When traffic that is mapped to a specific interface is pushed, the packet retains its original tag as it moves from the C-VLAN to the S-VLAN and an additional S-VLAN tag is added to the packet. When traffic that is mapped to a specific interface is swapped, the incoming tag is replaced with a new VLAN tag. This is sometimes known VLAN rewriting or VLAN translation.

Typically, this method is used to keep data from different customers separate or to provide individualized treatment of the packets on a certain interface. You might also use this method map VLAN traffic from different customers to a single S-VLAN.

When using specific interface mapping, the C-VLAN interfaces accept untagged and single-tagged packets, while the S-VLAN interfaces accept untagged, single-tagged, and double-tagged packets.

Note:

The C-VLAN and S-VLAN interfaces accept untagged packets provided that the native-vlan-id statement is configured on these interfaces.

Combining Methods and Configuration Restrictions

If you configure multiple methods, the switch gives priority to mapping a specific interface, then to many-to-one bundling, and last to all-in-one bundling. An access interface configured under all-in-one bundle cannot be part of a many-to-one bundle. It can have additional mappings defined, however.

To ensure deterministic results, the following configuration restrictions apply:

  • Mapping cannot be defined for untagged vlans.

  • An access interface can have multiple customer VLAN ranges, but an interface cannot have overlapping tags across the VLANs.

    For example, the following configuration is not allowed:

    Because the customer-2 configuration creates overlapping customer-vlan ranges for ge-0/0/0, it is invalid.

  • An access interface can have a single rule that maps an untagged packet to a VLAN.

  • Each interface can have at most one mapping swap rule per VLAN.

  • You can push a VLAN tag only on the access ports of a Q-in-Q VLAN. This restriction applies to all three methods of pushing a VLAN tag: that is, all-in-one bundling, many-to-one-bunding, and mapping a specific interface using push.

  • You can push different C-VLAN tags for a given S-VLAN on different interfaces. This could potentially result in traffic leaking across VLANs, depending on your configuration.

Routed VLAN Interfaces on Q-in-Q VLANs

Routed VLAN interfaces (RVIs) are supported on Q-in-Q VLANs.

Packets arriving on an RVI that is using Q-in-Q VLANs will get routed regardless of whether the packet is single or double tagged. The outgoing routed packets contain an S-VLAN tag only when exiting a trunk interface; the packets exit the interface untagged when exiting 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:

  • Q-in-Q tunneling supports only two VLAN tags.

  • Q-in-Q tunneling does not support most access port security features. There is no per-VLAN (customer) policing or per-VLAN (outgoing) shaping and limiting with Q-in-Q tunneling unless you configure these security features by using firewall filters.

  • With releases of Junos OS Release 13.2X51 previous to Release 13.2X51-D20, you cannot create a regular VLAN on an interface if you have created an S-VLAN or C-VLAN on that interface for Q-in-Q tunneling. This means that you cannot create an integrated routing and bridging (IRB) interface on that interface because regular VLANs are a required part of IRB configuration. With Junos OS Release 13.2X51-D25, you can create a regular VLAN on a trunk interface that has an S-VLAN, which means that you can also create an IRB interface on the trunk. In this case, the regular VLAN and S-VLAN on the same trunk interface cannot share the same VLAN ID. Junos OS Release 13.2X51-D25 does not allow you to create a regular VLAN on an access interface that has a C-VLAN.

  • Starting with Junos OS Release 14.1X53-D40, integrated routing and bridging (IRB) interfaces are supported on Q-in-Q VLANs—you can configure the IRB interface on the same interface as one used by an S-VLAN, and you can use the same VLAN ID for both the VLAN used by the IRB interface and for the VLAN used as an S-VLAN.

    Packets arriving on an IRB interface that is using Q-in-Q VLANs will get routed regardless of whether the packet is single tagged or double tagged. The outgoing routed packets contain an S-VLAN tag only when exiting a trunk interface; the packets exit the interface untagged when exiting an access interface.

    Note:

    You can configure the IRB interface only on S-VLAN (NNI) interfaces, not on C-VLAN (UNI) interfaces.

  • Most access port security features are not supported with Q-in-Q tunneling and VLAN translation.

  • Configuring Q-in-Q tunneling and VLAN rewriting/VLAN translation on the same port is not supported.

  • You can configure at most one VLAN rewrite/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.

  • You cannot use the native VLAN ID.

  • 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 rewriting/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

Configuring Q-in-Q Tunneling on QFX Series Switches

Q-in-Q tunneling and VLAN translation allow service providers to create a Layer 2 Ethernet connection between two customer sites. Providers can segregate different customers’ VLAN traffic on a link (for example, if the customers use overlapping VLAN IDs) or bundle different customer VLANs into a single service VLAN. Data centers can use Q-in-Q tunneling to isolate customer traffic within a single site or when customer traffic flows between cloud data centers in different geographic locations.

Starting in Junos OS Release 19.4R1, the QFX10000 line of switches support the third and fourth Q-in-Q tags as payload (also known as a pass-through tag) along with the existing two tags (for VLAN matching and operations). The QFX10000 switches support multiple Q-in-Q tags for both Layer 2 bridging and EVPN-VXLAN cases. The Layer 2 access interfaces accept packets with three or four tags (all tags with the TPID value 0x8100). All the tags beyond the fourth tag (that is, from the fifth tag onward) are considered part of the Layer 3 payload and are forwarded transparently.

Note:

In a one or two tagged packet, the tags, tag 1 and tag 2 can carry any TPID values such as 0x8100, 0x88a8, 0x9100, and 0x9200.

Before you begin setting up Q-in-Q tunneling, make sure you have created and configured the necessary customer VLANs on the neighboring switches. See Configuring VLANs on Switches.

To configure Q-in-Q tunneling:

  1. Create the service VLAN (S-VLAN) and configure an ID for it:
  2. Enable Q-in-Q tunneling on the S-VLAN:
  3. Set the allowed customer VLANs (C-VLANs) on the S-VLAN (optional). Here, the C-VLANs are identified by a range:
  4. Configure a global value for the tag protocol identifier (EtherType) of the service VLAN tags (optional):

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.

Configuring Q-in-Q Tunneling on EX Series Switches with ELS Support

Note:

This task uses Junos OS for EX Series switches with support for the Enhanced Layer 2 Software (ELS) configuration style. If your switch runs software that does not support ELS, see Configuring Q-in-Q Tunneling on EX Series Switches. For ELS details, see Using the Enhanced Layer 2 Software CLI.

Q-in-Q tunneling enables service providers on Ethernet access networks to segregate or bundle customer traffic into different VLANs by adding another layer of 802.1Q tags. You can configure Q-in-Q tunneling on EX Series switches.

Note:

You cannot configure 802.1X user authentication on interfaces that have been enabled for Q-in-Q tunneling.

When Q-in-Q tunneling is configured on EX Series switches, trunk interfaces are assumed to be part of the service-provider network and access interfaces are assumed to be part of the customer network. Therefore, this topic also refers to trunk interfaces as service-provider VLAN (S-VLAN) interfaces (network-to-network interfaces [NNI]), and to access interfaces as customer VLAN (C-VLAN) interfaces (user-network interfaces [UNI]).

Before you begin configuring Q-in-Q tunneling, make sure you set up your VLANs. See Configuring VLANs for EX Series Switches with ELS Support (CLI Procedure) or Configuring VLANs for EX Series Switches (J-Web Procedure).

Configure Q-in-Q tunneling by using one of the following methods to map C-VLANs to S-VLANs:

Configuring All-in-One Bundling

You can configure Q-in-Q tunneling by using the all-in-one bundling method, which maps packets from all C-VLAN interfaces on a switch to an S-VLAN.

To configure the all-in-one bundling method on a C-VLAN interface:

  1. Enable the transmission of packets with no or a single 802.1Q VLAN tag:
  2. Enable extended VLAN bridge encapsulation:
  3. Map packets from all C-VLANs to a logical interface:
    Note:

    You can apply no more than eight VLAN identifier lists to a physical interface.

  4. Enable a C-VLAN interface to send and receive untagged packets:

    When specifying a native VLAN ID on a C-VLAN physical interface, the value must be included in the VLAN ID list specified on the C-VLAN logical interface in step 3.

  5. Specify that packets traveling from a C-VLAN interface to an S-VLAN interface are tagged with the VLAN ID of the S-VLAN:
  6. Specify that the 802.1Q S-VLAN tag is removed as packets exit an S-VLAN interface.
  7. Configure a name for the S-VLAN, and associate the logical interface configured in step 3 with the S-VLAN:

The following configuration on the C-VLAN interface ge-0/0/1 enables Q-in-Q tunneling and maps packets from C-VLANs 100 through 200 to logical interface 10, which is in turn associated with S-VLAN v10. In this sample configuration, a packet originated in C-VLAN 100 includes a tag with the VLAN ID 100. When this packet travels from the interface ge-0/0/1 to the S-VLAN interface, a tag with VLAN ID 10 is added to it. As the packet exits the S-VLAN interface, the tag with the VLAN ID 10 is removed.

To configure the all-in-one bundling method on an S-VLAN interface:

  1. Enable the transmission of packets with no, one, or two 802.1Q VLAN tags:

  2. Enable extended VLAN bridge encapsulation:

  3. Map packets from the logical interface specified in the C-VLAN interface configuration to the S-VLAN:

  4. Enable the S-VLAN interface to send and receive untagged packets:

    When specifying a native VLAN ID on an S-VLAN physical interface, the value must match the VLAN ID specified on the S-VLAN logical interface in step 3.

  5. Associate the S-VLAN interface with the S-VLAN that was configured in the C-VLAN interface procedure:

For example, the following configuration on the S-VLAN interface ge-1/1/1 enables Q-in-Q tunneling and maps packets with a VLAN ID tag of 10 to logical interface 10, which is in turn associated with S-VLAN v10. .

Configuring Many-to-Many Bundling

You can configure Q-in-Q tunneling by using the many-to-many bundling method, which maps packets from multiple C-VLANs to multiple S-VLANs.

To configure the many-to-many bundling method on a C-VLAN interface:

  1. Enable the transmission of packets with no or a single 802.1Q VLAN tag:
  2. Enable extended VLAN bridge encapsulation:
  3. Map packets from specified C-VLANs to a logical interface:
  4. Enable a C-VLAN interface to send and receive untagged packets:

    When specifying a native VLAN ID on a C-VLAN physical interface, the value must be included in the VLAN ID list specified on the C-VLAN logical interface in step 3.

  5. Specify that packets traveling from a C-VLAN interface to an S-VLAN interface are tagged with the VLAN ID of the S-VLAN:
  6. Specify that the 802.1Q S-VLAN tag is removed as packets exit an S-VLAN interface:
  7. Configure a name for an S-VLAN, and associate the logical interface configured in step 3 with the S-VLAN:

The following configuration on the C-VLAN interface ge-0/0/1 for customer 1 enables Q-in-Q tunneling and maps packets from C-VLANs 100 through 120 to logical interface 10, which is in turn associated with S-VLAN v10.

The configuration on the C-VLAN interface ge-0/0/2 for customer 2 enables Q-in-Q tunneling and maps packets from C- VLANs 30 through 40, 50 through 60, and 70 through 80 to logical interface 30, which is in turn associated with S- VLAN v30.

In this sample configuration, a packet originated in C-VLAN 100 includes a tag with the VLAN ID 100. When this packet travels from the interface ge-0/0/1 to the S-VLAN interface, a tag with a VLAN ID of 10 is added to it. As the packet exits the S-VLAN interface, the tag with the VLAN ID of 10 is removed.

Customer 1

Customer 2

To configure the many-to-many bundling method on an S-VLAN interface:

  1. Enable the transmission of packets with no, one, or two 802.1Q VLAN tags:

  2. Enable extended VLAN bridge encapsulation:

  3. Map packets from each logical interface specified in the C-VLAN interface configuration to an S-VLAN:

  4. Enable an S-VLAN interface to send and receive untagged packets:

    When specifying a native VLAN ID on an S-VLAN physical interface, the value must match an S-VLAN ID specified on the S-VLAN logical interface in step 3.

  5. Associate the S-VLAN interface with the S-VLANs that were configured in the C-VLAN interface procedure:

For example, the following configuration on the S-VLAN interface ge-1/1/1 enables Q-in-Q tunneling and maps incoming C-VLAN packets to logical interfaces 10 and 30, which are in turn associated with S-VLANs v10 and v30, respectively.

Configuring a Specific Interface Mapping with VLAN Rewrite Option

You can configure Q-in-Q tunneling by mapping packets from a specified C-VLAN to a specified S-VLAN. In addition, while the packets are transmitted to and from the S-VLAN, you can specify that the 802.1Q C-VLAN tag be removed and replaced with the S-VLAN tag or vice versa.

To configure a specific interface mapping with VLAN rewriting on the C-VLAN interface:

  1. Enable the transmission of packets with no or one 802.1Q VLAN tag:
  2. Enable extended VLAN bridge encapsulation:
  3. Map packets from a specified C-VLAN to a logical interface:
  4. Enable the C-VLAN interface to send and receive untagged packets:

    When specifying a native VLAN ID on a C-VLAN physical interface, the value must match the VLAN ID specified on the C-VLAN logical interface in step 3.

  5. Specify that the existing 802.1Q C-VLAN tag is removed from packets traveling from a C-VLAN interface to an S-VLAN interface and replaced with the 802.1Q S-VLAN tag:
  6. Specify that the existing 802.1Q S-VLAN tag is removed from packets traveling from an S-VLAN interface to a C-VLAN interface and replaced with the 802.1Q C-VLAN tag:
  7. Configure a name for the S-VLAN, and associate the logical interface configured in step 3 with the S-VLAN:

For example, the following configuration on the C-VLAN interface ge-0/0/1 enables Q-in-Q tunneling and maps incoming packets from C-VLAN 150 to logical interface 200, which is in turn associated with VLAN v200. Also, as packets travel from the C-VLAN interface ge-0/0/1 to an S-VLAN interface, the C-VLAN tag 150 is removed and replaced with the S-VLAN tag 200. As packets travel from an S-VLAN interface to C-VLAN interface ge-0/0/1, the S-VLAN tag 200 is removed and replaced with the C-VLAN tag of 150.

To configure a specific interface mapping with VLAN rewriting on the S-VLAN interface:

  1. Enable the transmission of packets with no, one, or two 802.1Q VLAN tags:

  2. Enable extended VLAN bridge encapsulation:

  3. Map packets from the logical interface specified in the C-VLAN interface configuration to the S-VLAN:

  4. Enable the S-VLAN interface to send and receive untagged packets:

    When specifying a native VLAN ID on an S-VLAN physical interface, the value must match the VLAN ID specified on the S-VLAN logical interface in step 3.

  5. Associate the S-VLAN interface with the S-VLAN that was configured in the C-VLAN interface procedure: :

For example, the following configuration on the S-VLAN interface ge-1/1/1 enables Q-in-Q tunneling and maps packets with VLAN ID 200 to logical interface 200, which is in turn associated with S-VLAN v200.

Configuring Q-in-Q Tunneling on EX Series Switches

Note:

This task uses Junos OS for EX Series switches that does not support the Enhanced Layer 2 Software (ELS) configuration style.

Q-in-Q tunneling allows service providers on Ethernet access networks to segregate or bundle customer traffic into different VLANs by adding another layer of 802.1Q tags. You can configure Q-in-Q tunneling on EX Series switches.

Note:

You cannot configure 802.1X user authentication on interfaces that have been enabled for Q-in-Q tunneling.

Before you begin configuring Q-in-Q tunneling, make sure you set up your VLANs. See Configuring VLANs for EX Series Switches or Configuring VLANs for EX Series Switches (J-Web Procedure).

To configure Q-in-Q tunneling:

  1. Enable Q-in-Q tunneling on the S-VLAN:
  2. Set the allowed C-VLANs on the S-VLAN (optional). Here, the C-VLANs are identified by VLAN range:
  3. Change the global Ethertype value (optional):
  4. Disable MAC address learning on the S-VLAN (optional):

Configuring Q-in-Q Tunneling Using All-in-One Bundling

You can configure Q-in-Q tunneling using the all-in-one bundling method, which forwards all packets that ingress on a C-VLAN interface to an S-VLAN. (Packets are forwarded to the S-VLAN regardless of whether they are tagged or untagged prior to ingress.) Using this approach saves you the effort of specifying a specific mapping for each C-VLAN.

First configure the S-VLAN and its interface:

  1. Assign a logical interface (unit) to be a member of the S-VLAN.
    Note:

    Do not use logical interface unit 0. You must later bind a VLAN tag ID to the unit you specify in this step, and you cannot bind a VLAN tag ID to unit 0. Also note that you do not create a VLAN ID for the S-VLAN. The ID is created automatically for the appropriate logical interface.

  2. Enable the interface to transmit packets with two 802.1Q VLAN tags:
  3. Enable extended VLAN bridge encapsulation on the interface:
    Note:

    If you configure an enterprise-style configuration such as PVLAN on the same physical interface on which you are configuring Q-in-Q tunneling, use set encapsulation flexible-ethernet-services . See Understanding Flexible Ethernet Services Encapsulation on Switches.

  4. Enable the S-VLAN interface to send and receive untagged packets:
  5. Bind the logical interface (unit) of the interface that you specified in step 1 to the automatically created VLAN ID for the S-VLAN:
Note:

If you configured flexible-ethernet-services, configure vlan-bridge encapsulation on the logical interface:

For example, the following configuration makes xe-0/0/0.10 a member of VLAN 10, enables Q-in-Q tunneling on interface xe-0/0/0, enables xe-0/0/0 to accept untagged packets, and binds the VLAN ID of S-VLAN v10 to a logical interface of xe-0/0/0.

Now configure all-in-one bundling on a C-VLAN interface:

  1. Assign a logical interface (unit) of the C-VLAN interface to be a member of the S-VLAN.

  2. Enable the interface to transmit packets with 802.1Q VLAN tags :

  3. Enable extended VLAN bridge encapsulation on the interface:

  4. Enable the C-VLAN interface to send and receive untagged packets:

  5. Configure a logical interface to receive and forward any tagged packet whose VLAN ID tag matches the list of VLAN IDs you specify:

    CAUTION:

    You can apply no more than eight VLAN identifier lists to a physical interface. This limitation does not apply to QFX10000 switches.

  6. Configure the system to add an S-VLAN tag (outer tag) as packets travel from a C-VLAN interface to the S-VLAN:

    Note:

    You can configure vlan-id on input-vlan-map, but doing so is optional.

  7. Configure the system to remove the S-VLAN tag when packets are forwarded (internally) from the S-VLAN interface to the C-VLAN interface:

For example, the following configuration makes xe-0/0/1.10 a member of S-VLAN v10, enables Q-in-Q tunneling, maps packets from C-VLANs 100 through 200 to S-VLAN 10, and enables xe-0/0/1 to accept untagged packets. If a packet originates in C-VLAN 100 and needs to be sent across the S-VLAN, a tag with VLAN ID 10 is added to the packet. When a packet is forwarded (internally) from the S-VLAN interface to interface xe-0/0/1, the tag with VLAN ID 10 is removed.

Configuring Q-in-Q Tunneling Using Many-to-Many Bundling

You can configure Q-in-Q tunneling using the many-to-many bundling method, which maps packets from multiple C-VLANs to multiple S-VLANs. This method is convenient for mapping a range of C-VLANs without having to specify each one individually. (You can also use this method to configure only one C-VLAN to be mapped to an S-VLAN.)

First configure the S-VLANs and assign them to an interface:

  1. Assign a logical interface (unit) to be a member of one of the S-VLANs. Do not use logical interface unit 0.
    Note:

    Note that you do not create a VLAN ID for the S-VLAN. The ID is created automatically for the appropriate logical interface.

  2. Repeat step 1 for the other S-VLANs.
  3. Enable the physical interface to transmit packets with two 802.1Q VLAN tags:
  4. Enable extended VLAN bridge encapsulation on the interface:
  5. Enable the S-VLAN interface to send and receive untagged packets:
  6. Bind one of the logical units of the interface to the VLAN ID for one of the S-VLANs.
  7. Repeat step 6 to bind the automatically-created VLAN IDs for the other S-VLANs to the other logical units of the interface:

For example, the following configuration creates S-VLANs v10 and v30 and associates them with interface xe-0/0/0.10, enables Q-in-Q tunneling, enables xe-0/0/0 to accept untagged packets, and maps incoming C-VLAN packets to S-VLANs v10 and v30.

To configure the many-to-many bundling method on a C-VLAN interface, perform the following steps for each customer:

  1. Assign a logical interface (unit) of one C-VLAN interface to be a member of one S-VLAN.

  2. Repeat step 1 to assign another C-VLAN interface (physical interface) to be a member of another S-VLAN.

  3. Enable the interface to transmit packets with 802.1Q VLAN tags:

  4. Enable extended VLAN bridge encapsulation on the interface:

  5. Enable the C-VLAN interface to send and receive untagged packets:

  6. For each physical interface, configure a logical interface (unit) to receive and forward any tagged packet whose VLAN ID tag matches the list of VLAN IDs you specify:

    To configure only one C-VLAN to be mapped to an S-VLAN, specify only one VLAN ID after vlan-id-list.

    CAUTION:

    You can apply no more than eight VLAN identifier lists to a physical interface. This limitation does not apply to QFX10000 switches.

  7. For each physical interface, configure the system to add an S-VLAN tag (outer tag) as packets travel from the C-VLAN interface to the S-VLAN:

  8. For each physical interface, configure the system to remove the S-VLAN tag when packets are forwarded from the S-VLAN interface to the C-VLAN interface:

For example, the following configuration makes xe-0/0/1.10 a member of S-VLAN v10, enables Q-in-Q tunneling, and maps packets from C-VLANs 10 through 20 to S-VLAN 10. The configuration for customer 2 makes xe-0/0/2.30 a member of S-VLAN v30, enables Q-in-Q tunneling, and maps packets from C-VLANs 30 through 40, 50 through 60, and 70 through 80 to S-VLAN 30. Both interfaces are configured to accept untagged packets.

If a packet originates in C-VLAN 10 and needs to be sent over the S-VLAN, a tag with a VLAN ID 10 is added to the packet. If a packet is forwarded internally from the S-VLAN interface to xe-0/0/1.10, the tag with VLAN ID 10 is removed. The same principles apply to the C-VLANs configured on interface xe-0/0/2.

Note:

Notice that you can use the same tag value for an S-VLAN and C-VLAN. For example, the configuration for customer 1 maps C-VLAN ID 10 to S-VLAN ID 10. C-VLAN and S-VLAN tags use separate name spaces, so this configuration is allowed.

Configuration for customer 1:

Configuration for customer 2:

Configuring a Specific Interface Mapping with VLAN ID Translation Option

You can configure Q-in-Q tunneling by mapping packets from a specified C-VLAN to a specified S-VLAN. In addition, you can configure the system to replace a C-VLAN tag with an S-VLAN tag or replace an S-VLAN tag with a C-VLAN tag (instead of double tagging). This is call VLAN translation or VLAN rewriting. VLAN translation is particularly useful if a service provider’s Layer 2 network that connects a customer’s sites does not support double tagged packets.

When you use VLAN translation, both ends of the link normally must be able to swap the tags appropriately. That is, both ends of the link must be configured to swap the C-VLAN tag for the S-VLAN tag and swap the S-VLAN tag for the C-VLAN tag so that traffic in both directions is tagged appropriately while in transit and after arrival.

First configure the S-VLAN and its interface:

  1. Assign a logical interface to be a member of the S-VLAN. Do not use unit 0.
    Note:

    Note that you do not create a VLAN ID for the S-VLAN. The ID is created automatically for the appropriate logical interface.

  2. Enable the interface to transmit packets with 802.1Q VLAN tags:
  3. Enable the S-VLAN interface to send and receive untagged packets:
  4. Enable extended VLAN bridge encapsulation on the interface:
  5. Bind the logical interface (unit) of the interface that you specified earlier to the VLAN ID for the S-VLAN:

For example, the following configuration creates S-VLAN v200, makes xe-0/0/0.200 a member of that VLAN, enables Q-in-Q tunneling on interface xe-0/0/0, enables xe-0/0/0 to accept untagged packets, and binds a logical interface of xe-0/0/0 to the VLAN ID of VLAN v200.

Now configure a specific interface mapping with optional VLAN ID translation on the C-VLAN interface:

  1. Assign a logical interface of the C-VLAN interface to be a member of the S-VLAN.

  2. Enable the interface to transmit packets with 802.1Q VLAN tags:

  3. Enable the C-VLAN interface to send and receive untagged packets:

  4. Enable extended VLAN bridge encapsulation on the interface:

  5. Configure a logical interface (unit) to receive and forward any tagged packet whose VLAN ID tag matches the VLAN IDs you specify:

  6. Configure the system to remove the existing C-VLAN tag and replace it with the S-VLAN tag when packets ingress on the C-VLAN interface and are forwarded to the S-VLAN:

  7. Configure the system to remove the existing S-VLAN tag and replace it with the C-VLAN tag when packets are forwarded from the S-VLAN interface to the C-VLAN interface:

  8. To configure an S-VLAN and associate it with the appropriate C-VLAN interface:

For example, the following configuration on C-VLAN interface xe-0/0/1.200 enables Q-in-Q tunneling, enables xe-0/0/1 to accept untagged packets, and maps incoming packets from C-VLAN 150 to logical interface 200, which is a member of S-VLAN 200. Also, when packets egress from C-VLAN interface xe-0/0/1 and travel to the S-VLAN interface, the C-VLAN tag of 150 is removed and replaced with the S-VLAN tag of 200. When packets travel from the S-VLAN interface to the C-VLAN interface, the S-VLAN tag of 200 is removed and replaced with the C-VLAN tag of 150.

Example: Setting Up Q-in-Q Tunneling on QFX Series Switches

Service providers can use Q-in-Q tunneling to transparently pass Layer 2 VLAN traffic between customer sites without removing or changing the customer VLAN tags or class-of-service (CoS) settings. Data centers can use Q-in-Q tunneling to isolate customer traffic within a single site or when customer traffic flows between cloud data centers in different geographic locations.

Note:

This example uses a Junos OS release that does not support the Enhanced Layer 2 Software (ELS) configuration style. If your switch runs software that supports ELS, see Configuring Q-in-Q Tunneling on QFX Series, NFX Series, and EX4600 Switches with ELS Support.

This example describes how to set up Q-in-Q tunneling:

Requirements

This example requires one QFX Series device with Junos OS Release 12.1 or later.

Before you begin setting up Q-in-Q tunneling, make sure you have created and configured the necessary customer VLANs on the neighboring switches. See Configuring VLANs on Switches.

Overview and Topology

In this service provider network, there are multiple customer VLANs mapped to one service VLAN.

Table 2 lists the settings for the sample topology.

Table 2: Components of the Topology for Setting Up Q-in-Q Tunneling
Interface Description

xe-0/0/11.0

Tagged S-VLAN trunk port

xe-0/0/12.0

Untagged customer-facing access port

xe-0/0/13.0

Untagged customer-facing access port

xe-0/0/14.0

Tagged S-VLAN trunk port

Configuration

CLI Quick Configuration

To quickly create and configure Q-in-Q tunneling, copy the following commands and paste them into the switch terminal window:

Procedure

Step-by-Step Procedure

To configure Q-in-Q tunneling:

  1. Set the VLAN ID for the S-VLAN:

  2. Enable Q-in-Q tunneling and specify the customer VLAN ranges:

  3. Set the port mode and VLAN information for the interfaces:

  4. Set the Q-in-Q Ethertype value (optional):

Results

Check the results of the configuration:

Verification

Confirm that the configuration is working properly.

Verifying That Q-in-Q Tunneling Was Enabled

Purpose

Verify that Q-in-Q tunneling was properly enabled.

Action

Use the show vlans command:

Meaning

The output indicates that Q-in-Q tunneling is enabled and that the VLAN is tagged and shows the associated customer VLANs.

Example: Setting Up Q-in-Q Tunneling on EX Series Switches

Service providers can use Q-in-Q tunneling to transparently pass Layer 2 VLAN traffic from a customer site, through the service provider network, to another customer site without removing or changing the customer VLAN tags or class-of-service (CoS) settings. You can configure Q-in-Q tunneling on EX Series switches.

This example describes how to set up Q-in-Q:

Requirements

This example requires one EX Series switch with Junos OS Release 9.3 or later for EX Series switches.

Before you begin setting up Q-in-Q tunneling, make sure you have created and configured the necessary customer VLANs. See Configuring VLANs for EX Series Switches or Configuring VLANs for EX Series Switches (J-Web Procedure).

Overview and Topology

In this service provider network, there are multiple customer VLANs mapped to one service VLAN.

Table 3 lists the settings for the example topology.

Table 3: Components of the Topology for Setting Up Q-in-Q Tunneling
Interface Description

ge-0/0/11.0

Tagged S-VLAN trunk port

ge-0/0/12.0

Untagged customer-facing access port

ge-0/0/13.0

Untagged customer-facing access port

ge-0/0/14.0

Tagged S-VLAN trunk port

Configuration

CLI Quick Configuration

To quickly create and configure Q-in-Q tunneling, copy the following commands and paste them into the switch terminal window:

Procedure

Step-by-Step Procedure

To configure Q-in-Q tunneling:

  1. Set the VLAN ID for the S-VLAN:

  2. Enable Q-in-Q tuennling and specify the customer VLAN ranges:

  3. Set the port mode and VLAN information for the interfaces:

  4. Set the Q-in-Q Ethertype value:

Results

Check the results of the configuration:

Verification

To confirm that the configuration is working properly, perform these tasks:

Verifying That Q-in-Q Tunneling Was Enabled

Purpose

Verify that Q-in-Q tunneling was properly enabled on the switch.

Action

Use the show vlans command:

Meaning

The output indicates that Q-in-Q tunneling is enabled and that the VLAN is tagged and shows the associated customer VLANs.

Setting Up a Dual VLAN Tag Translation Configuration on QFX Switches

Starting with Junos OS Release 14.1X53-D40, you can use the dual VLAN tag translation (also known as dual VLAN tag rewrite) feature to deploy switches in service-provider domains, allowing dual-tagged, single-tagged, and untagged VLAN packets to come into or exit from the switch.

The following example configuration shows use of the swap-swap, pop-swap, and swap-push dual tag operations.

Verifying That Q-in-Q Tunneling Is Working on Switches

Purpose

After creating a Q-in-Q VLAN, verify that it is set up properly.

Action

  1. Use the show configuration vlans command to determine if you successfully created the primary and secondary VLAN configurations:

  2. Use the show vlans command to view VLAN information and link status:

Meaning

The output confirms that Q-in-Q tunnling is enabled and that the VLAN is tagged, and lists the customer VLANs that are associated with the tagged VLAN.

Release History Table
Release
Description
19.4R1
Starting in Junos OS Release 19.4R1, the QFX10000 line of switches support the third and fourth Q-in-Q tags as payload (also known as a pass-through tag) along with the existing two tags (for VLAN matching and operations).
14.1X53-D40
Starting with Junos OS Release 14.1X53-D40, you can use the dual VLAN tag translation (also known as dual VLAN tag rewrite) feature to deploy switches in service-provider domains, allowing dual-tagged, single-tagged, and untagged VLAN packets to come into or exit from the switch.
14.1X53-D30
Starting with Junos OS 14.1X53-D30, you can configure the same interface to be an S-VLAN/NNI interface and a C-VLAN/UNI interface.