Stacking and Rewriting Gigabit Ethernet VLAN Tags
VLAN stacking encapsulates multiple VLAN tags within Ethernet frames, enabling hierarchical tagging and extending the VLAN space. VLAN tag rewriting facilitates dynamic tag translation across network boundaries.
Stacking and rewriting Gigabit Ethernet VLAN Tags is also referred to as Q-in-Q tunneling.
VLAN stacking encapsulates multiple VLAN tags within Ethernet frames, enabling hierarchical
tagging and extending the VLAN space. VLAN tag rewriting facilitates dynamic tag translation
across network boundaries. When properly configured, these techniques significantly enhance
interoperability and traffic engineering across diverse platforms. You can configure rewrite
operations to stack (push), remove (pop), or rewrite
(swap) tags on single-tagged frames and dual-tagged frames. If a port is
untagged, rewrite operations are not supported on any logical interface associated with that
port.
VLAN tagging is a method used to identify and segregate network traffic based on VLAN IDs (Identifiers). Tag manipulation allows for various operations on VLAN tags. You can configure the following VLAN rewrite operations:
-
pop—Remove a VLAN tag from the top of the VLAN tag stack. The outer VLAN tag of the frame is removed. -
pop-pop—For Ethernet IQ2, 10-Gigabit Ethernet LAN/WAN PIC, and IQ2-E interfaces, remove both the outer and inner VLAN tags of the frame. -
pop-swap—For Ethernet IQ2, 10-Gigabit Ethernet LAN/WAN PIC, and IQ2-E interfaces, remove the outer VLAN tag of the frame, and replace the inner VLAN tag of the frame with a user-specified VLAN tag value. The original inner tag becomes the outer tag in the final frame. -
push—Add a new VLAN tag to the top of the VLAN stack. An outer VLAN tag is pushed in front of the existing VLAN tag. -
push-push—For Ethernet IQ2, 10-Gigabit Ethernet LAN/WAN PIC, and IQ2-E interfaces, push two VLAN tags in front of the frame. -
swap-push—For Ethernet IQ2, 10-Gigabit Ethernet LAN/WAN PIC, and IQ2-E interfaces, replace the outer VLAN tag of the frame with a user-specified VLAN tag value. A user-specified outer VLAN tag is pushed in front. The original outer tag becomes an inner tag in the final frame. -
swap-swap—For Ethernet IQ2, 10-Gigabit Ethernet LAN/WAN PIC, and IQ2-E interfaces, replace both the inner and the outer VLAN tags of the incoming frame with a user-specified VLAN tag value.
You configure VLAN rewrite operations for logical interfaces in the input VLAN map for
incoming frames and in the output VLAN map for outgoing frames. To configure the input VLAN
map, include the input-vlan-map statement:
input-vlan-map { ...interface-specific configuration... }
input-vlan-map
statement. To configure the output VLAN map, include the output-vlan-map
statement:
output-vlan-map { ...interface-specific configuration... }
You can include both statements at the following hierarchy levels:
-
[edit interfaces interface-name unit logical-unit-number] -
[edit logical-systems logical-system-name interfaces interface-name unit logical-unit-number]
The type of VLAN rewrite operation permitted depends upon whether the frame is single-tagged or dual-tagged. https://www.juniper.net/documentation/us/en/software/junos/multicast-l2/topics/task/interfaces-rewriting-the-vlan-tag.html and https://www.juniper.net/documentation/us/en/software/junos/multicast-l2/topics/topic-map/interfaces-rewriting-vlan-tag-untagged-frames.html describe supported rewrite operations and whether they can be applied to single-tagged frames or dual-tagged frames. The table also indicates the number of tags being added or removed during the operation.
|
Rewrite Operation |
Untagged |
Single-Tagged |
Dual-Tagged |
Number of Tags |
|---|---|---|---|---|
| pop |
No |
Yes |
Yes |
– 1 |
| push |
Sometimes |
Yes |
Yes |
+1 |
| swap |
No |
Yes |
Yes |
0 |
| push-push |
Sometimes |
Yes |
Yes |
+2 |
| swap-push |
No |
Yes |
Yes |
+1 |
| swap-swap |
No |
No |
Yes |
0 |
| pop-pop |
No |
No |
Yes |
– 2 |
| pop-swap |
No |
No |
Yes |
– 1 |
The rewrite operations push and push-push can be valid in
certain circumstances on frames that are not tagged. For example, a single-tagged logical
interface (interface 1) and a dual-tagged logical interface (interface 2) have the following
configurations:
Interface 1
[edit interfaces interface-name unit logical-unit-number] input-vlan-map { pop; } output-vlan-map { push; }
Interface 2
[edit interfaces interface-name unit logical-unit-number] input-vlan-map { pop-pop; } output-vlan-map { push-push; }
When a frame is received on the interface as a result of the input-vlan-map
operation, the frame is not tagged. As it goes out of the second interface, the
output-vlan-map operation push-push is applied to it. The
resulting frame will be dual-tagged at the logical interface output.
Depending on the VLAN rewrite operation, you configure the rewrite operation for the interface in the input VLAN map, the output VLAN map, or in both the input VLAN map and the output VLAN map. The following table describes what rewrite operation combinations you can configure. None means that no rewrite operation is specified for the VLAN map.
|
Output VLAN Map |
|||||||||
|---|---|---|---|---|---|---|---|---|---|
|
Input VLAN Map |
none |
push |
pop |
swap |
push-push |
swap-push |
swap-swap |
pop-pop |
swap-pop |
|
none |
Yes |
No |
No |
Yes |
No |
No |
Yes |
No |
No |
|
push |
No |
No |
Yes |
No |
No |
No |
No |
No |
No |
|
pop |
No |
Yes |
No |
No |
No |
No |
No |
No |
No |
|
swap |
Yes |
No |
No |
Yes |
No |
No |
No |
No |
No |
|
push-push |
No |
No |
No |
No |
No |
No |
No |
Yes |
No |
|
swap-push |
No |
No |
No |
No |
No |
No |
No |
No |
Yes |
|
swap-swap |
Yes |
No |
No |
No |
No |
No |
Yes |
No |
No |
|
pop-pop |
No |
No |
No |
No |
Yes |
No |
No |
No |
No |
|
pop-swap |
No |
No |
No |
No |
No |
Yes |
No |
No |
No |
Before you configure the VLAN rewrite operation:
-
Ensure that the VLAN rewrite operation is valid and applied to the input or output VLAN maps.
-
Check if the rewrite operation requires you to include statements to configure the inner and outer TPIDs and inner and outer VLAN IDs in the input or output VLAN maps.
For information about configuring inner and outer TPIDs and inner and outer VLAN IDs, see Configuring Inner and Outer TPIDs and VLAN IDs.
Automatic and Derived VLAN translation dynamically maps VLAN IDs based on predefined rules or
contextual information. This enables seamless VLAN stacking (Q-in-Q) and Gigabit Ethernet VLAN
tag rewriting, supporting scalable, multi-tenant network segmentation and interoperability.
VLAN translation involves changing the VLAN ID of a packet as it traverses the network. This
translation can be configured manually or derived automatically. Virtual Private LAN Service
(VPLS) is set up to use Automatic and Derived VLAN translation in such a way that the customer
VLANs can be automatically matched to the provider VLANs .To provide a VPLS service, the
network administrator or service provider (referred to as the operator) is responsible for
configuring and managing the VPLS instance. The operator typically sets up the VPLS instance
and adds logical interfaces to it. In most cases, these logical interfaces carry traffic with
similar VLAN tags. If a logical interface uses VLAN tags that differ from those used by other
interfaces in the VPLS domain, the operator can normalize the VLAN tags by applying
vlan-map commands. VPLS is connected to a bridge domain by configuring a
routing instance with the instance-type set to vpls. For
more information, see Configuring-vpls-and-integrated-routing-and-bridging.
In Juniper Networks EVPN (Ethernet VPN) environments, automatic or derived VLAN translation enables seamless handling of overlapping or differing VLAN IDs across the EVPN fabric. VLAN tags are translated at the network edge, allowing multiple customer VLANs, whether they use the same VLAN ID (overlapping VLANs) or different VLAN IDs, to be mapped appropriately within the EVPN-VXLAN fabric. This ensures proper traffic segregation and forwarding. For more information, see Overlapping VLAN Support Using VLAN Translation in EVPN-VXLAN Networks.
The Bridge Domain can be configured in one of following modes:
|
Mode |
Description |
|---|---|
|
Default |
Valid on MX Series routers. You must configure a VLAN map on an IFL to normalize VLAN IDs. VLAN tags in packets entering or exiting the bridge domain are transparent and depend on the IFL’s VLAN configuration and any applied VLAN map. |
|
VLAN none |
Normalizes packets to ensure they are untagged. Packets entering or exiting the bridge domain do not carry VLAN tags. This is achieved using automatic VLAN maps (push/pop/swap). Packets from the CE (Customer Edge) to the core network are sent without any VLAN tag, and packets arriving from the core network are also untagged. Example: |
|
VLAN <vid> |
Normalizes packets to ensure they carry a single, specified VLAN ID <vid>. Packets entering or exiting the bridge domain are tagged with the configured VLAN ID. Packets from the CE to the core network carry the specified VLAN ID, and packets from the core network arrive with the same VLAN ID. Example: |
|
VLAN <dual-tags> |
Normalize the packet to include the specified VLAN tag stack, like outer and inner VLAN IDs. Packets that enter or exit the BD will have dual VLAN tag. These VLAN tags are the BD's configured VLAN tags. Packets from the CE to the core network carry both specified VLAN tags, and packets from the core network arrive with the same dual-tag structure. Example: |
|
VLAN all |
Transparently carries any VLAN ID present in the packet. Packets entering or exiting the bridge domain retain their VLAN tag. For single-tagged IFLs, this is the single VLAN ID; for double-tagged IFLs, it is the inner VLAN ID. The VLAN ID is used to qualify learned MAC addresses. VLAN tags are preserved and switched transparently across the network. Example: Note:
vlan-id all is typically used to handle
traffic from multiple VLANs without modifying their tags. |
Example of VLAN none mode
interfaces {
ge-1/0/0 {
encapsulation ethernet-bridge;
unit 0;
}
ge-1/0/1 {
encapsulation flexible-ethernet-services;
flexible-VLAN-tagging;
unit 0 {
encapsulation VLAN-bridge;
VLAN-id 100;
}
}
ge-1/0/2 {
encapsulation flexible-ethernet-services;
flexible-VLAN-tagging;
unit 0 {
encapsulation VLAN-bridge;
VLAN-tags outer 100 inner 200;
}
}
}
bridge-domains {
blue {
domain-type bridge;
+ VLAN-id none;
interface ge-1/0/0.0;
interface ge-1/0/1.0;
interface ge-1/0/2.0;
}
}
Automatic VLAN-maps performed for above IFLs
IFL input output
--------------------------------
ge-1/0/0.0 none none
ge-1/0/1.0 pop push
ge-1/0/2.0 pop-pop push-push
Example of VLAN single mode
interfaces {
ge-1/0/0 {
encapsulation flexible-ethernet-services;
flexible-VLAN-tagging;
unit 0 {
encapsulation VLAN-bridge;
VLAN-id 100;
}
}
ge-1/0/1 {
encapsulation flexible-ethernet-services;
flexible-VLAN-tagging;
unit 0 {
encapsulation VLAN-bridge;
VLAN-id 200;
}
}
ge-1/0/2 {
1encapsulation flexible-ethernet-services;
flexible-VLAN-tagging;
unit 0 {
encapsulation VLAN-bridge;
VLAN-tags outer 2000 inner 100;
}
}
ge-1/0/3 {
encapsulation flexible-ethernet-services;
flexible-VLAN-tagging;
unit 0 {
encapsulation VLAN-bridge;
VLAN-tags outer 2000 inner 200;
}
}
}
bridge-domains {
VLAN-100 {
domain-type bridge;
+ VLAN-id 100;
interface ge-1/0/0.0;
interface ge-1/0/1.0;
interface ge-1/0/2.0;
interface ge-1/0/3.0;
}
}
Automatic VLAN-maps performed for above IFLs
IFL input output
--------------------------------
ge-1/0/0.0 none none
ge-1/0/1.0 swap swap
ge-1/0/2.0 pop push
ge-1/0/3.0 pop-swap swap-push
Example of VLAN dual mode
interfaces {
ge-1/0/0 {
encapsulation flexible-ethernet-services;
flexible-VLAN-tagging;
unit 0 {
encapsulation VLAN-bridge;
VLAN-tags outer 100 inner 200;
}
}
ge-1/0/1 {
encapsulation flexible-ethernet-services;
flexible-VLAN-tagging;
unit 0 {
encapsulation VLAN-bridge;
VLAN-id 200;
}
}
ge-1/0/2 {
encapsulation flexible-ethernet-services;
flexible-VLAN-tagging;
unit 0 {
encapsulation VLAN-bridge;
VLAN-tags outer 100 inner 300;
}
}
ge-1/0/3 {
encapsulation flexible-ethernet-services;
flexible-VLAN-tagging;
unit 0 {
encapsulation VLAN-bridge;
VLAN-tags outer 1000 inner 2000;
}
}
}
bridge-domains {
VLAN-100-200 {
domain-type bridge;
+ VLAN-tags outer 100 inner 200;
interface ge-1/0/0.0;
interface ge-1/0/1.0;
interface ge-1/0/2.0;
interface ge-1/0/3.0;
}
}
Automatic VLAN-maps performed for above IFLs
IFL input output
--------------------------------
ge-1/0/0.0 none none
ge-1/0/1.0 push pop
ge-1/0/2.0 nop-swap nop-swap
ge-1/0/3.0 swap-swap swap-swap
Example of VLAN all mode
interfaces {
ge-1/0/0 {
encapsulation flexible-ethernet-services;
flexible-VLAN-tagging;
unit 0 {
encapsulation VLAN-bridge;
VLAN-id-range 1-4094;
}
}
ge-1/0/1 {
encapsulation flexible-ethernet-services;
flexible-VLAN-tagging;
unit 0 {
encapsulation VLAN-bridge;
VLAN-tags outer 200 inner-range 1-4094;
}
}
}
bridge-domains {
all-customer-VLANs {
domain-type bridge;
+ VLAN-id all;
interface ge-1/0/0.0;
interface ge-1/0/1.0;
}
}
Automatic VLAN-maps performed for above IFLs
IFL input output
--------------------------------
ge-1/0/0.0 none none
ge-1/0/1.0 pop push
IRB Configuration on ACX, MX, and PTX Platforms
When configuring Integrated Routing and Bridging (IRB) with VLAN translation, it's
important to note that the vlan-id all configuration is not supported with
IRB on any platform. This is because IRB must be associated with a single VLAN ID.
-
ACX platforms typically support IRB with explicitly defined VLAN IDs. The
vlan-id allconfiguration is not supported. -
MX platforms support advanced IRB configurations, including per-VLAN IRB interfaces. However,
vlan-id allis still not supported with IRB. -
PTX platforms are primarily designed for high-performance routing. They may have limited support for IRB with
vlan-id all.
VPLS, EVPN, and ELAN/ELINE Handling on ACX, MX, and PTX Platforms
The ACX, MX, and PTX platforms support VPLS, EVPN, and ELAN/ELINE differently based on their architecture, capabilities, and intended use cases:
|
VPLS (Virtual Private LAN Service) |
EVPN (Ethernet VPN) |
ELAN (Ethernet LAN)/ELINE (Ethernet Line) |
|
|---|---|---|---|
|
ACX |
Supports VPLS for multipoint Layer 2 VPN services across a packet-switched network. Ideal for service providers extending LAN services over large areas. |
Supports EVPN for Layer 2 and Layer 3 VPN services with features like MAC learning, redundancy, and scalability. |
Supports ELAN (multipoint) and ELINE (point-to-point) services for flexible Layer 2 connectivity between customer sites. |
|
MX |
Supports advanced VPLS features, including hierarchical VPLS (H-VPLS), for scalable and simplified deployments in service provider networks. |
Provides robust EVPN support for both data center interconnects and service provider networks, using MPLS and VXLAN encapsulations. | Offers comprehensive ELAN and ELINE support with high performance and reliability, suitable for services with strict SLAs. |
|
PTX |
Limited VPLS support; primarily focused on high-capacity IP/MPLS routing in core networks. |
Supports EVPN in high-throughput, large-scale environments such as data center interconnects and service provider networks. |
Supports ELAN and ELINE, but optimized for high-performance Ethernet transport in backbone and core networks. |