Arista EOS VLAN Translation and dot1q-tunnel CLI

Most EOS VLAN guides stop at create, assign and trunk - and that is enough for a flat campus. The moment you interconnect two domains that both insist on the same VLAN IDs, or you need to hand a provider a tagged frame that survives your own tag stack, EOS gives you two distinct tools that are easy to confuse: VLAN translation and dot1q-tunnel. This article shows what each one does to the frame on ingress and egress, the exact CLI for subinterfaces, and how to verify the rewrite from the switch rather than from a packet capture.

What a Tagged Frame Looks Like on the Wire

An 802.1Q frame carries a four-byte tag inserted between the source MAC address and the EtherType: a two-byte Tag Protocol Identifier (0x8100) and a two-byte Tag Control Information field that holds a three-bit priority, a one-bit Drop Eligible Indicator and the twelve-bit VLAN ID. Twelve bits is why VLAN IDs stop at 4094, and four bytes is why a tagged frame is 1522 bytes at the maximum standard size - the detail that later becomes an MTU problem.

Everything in this article is a decision about that twelve-bit field. Access ports strip and add it, trunk ports add and remove it, and the two features below do something different again: translation changes the value while keeping one tag, and dot1q-tunnel adds a second tag so the original value survives untouched inside. Once you picture the two operations on that field, the CLI starts to make sense.

VLAN Translation vs. QinQ: Different Problems

• VLAN translation (tag rewrite): one VLAN ID is replaced by another as the frame enters or leaves the switch. The frame still carries a single 802.1Q tag; the value simply changes. Typical use: two sites or tenants that reuse VLAN 100 with no coordination.
• dot1q-tunnel (QinQ): the customer's tagged frame is preserved and an outer tag is pushed on top, so up to 4094 customer VLANs ride inside one service VLAN. Typical use: carrier or provider edge, and lab isolation where you must carry identical VLAN IDs across a shared core.

The decision rule is about who owns the VLAN number. If the VLAN ID is meaningful only on your side of the link and you want your own number to appear in the rest of your network, use translation. If the VLAN ID must be preserved end to end because the far side also uses it - or because the far side is a customer who must not see your numbering - use dot1q-tunnel. Translation destroys information; tunnelling preserves it. Choose accordingly, because neither can be undone by the other.

Tag Rewrite with encapsulation dot1q

Translation is configured on an Ethernet interface or subinterface, and the vlan_id in the command is the external (wire-side) VLAN, not the internal one:

switch(config)# interface Ethernet1
switch(config-if)# encapsulation dot1q 100

switch(config)# interface Ethernet1.101
switch(config-subif)# encapsulation dot1q 101
switch(config-subif)#

In the classic mapping case the physical interface maps the external VLAN to an internal SVI elsewhere on the switch, while subinterface configuration is used when the VLAN identifies the subinterface itself. Values are 1-4094 and the command supports a no encapsulation dot1q vlan default form to return to default tagging.

The two shapes answer two different questions, and getting them backwards is the most common mistake with this feature. On a routed port, encapsulation dot1q 100 tells EOS which external VLAN to accept on the wire and hand to the subinterface's L3 context - the internal VLAN number never appears on the wire at all. On a switched interface, the translation is about which VLAN the frame lands in once it has been received, so that a frame tagged 100 from one domain is treated as your VLAN 200 everywhere else on the switch.

Practical consequences follow from this. Because the rewrite happens at the port, it is per-link and per-direction: the far side of the link keeps its own numbering, and you do not need to change any SVI, spanning-tree instance or DHCP scope on your side. Because it is per-port, it does not scale to a whole fabric - if five uplinks need the same rewrite, all five ports need the command. And because the VLAN ID on the wire is the external one, a packet capture taken on the link will show the original numbering, while every other port on the switch shows the rewritten value. Confusing those two views has cost many engineers an afternoon.

QinQ with dot1q-tunnel

Tunnel mode is a switchport mode in EOS, so the port stops behaving like an access or trunk port:

switch(config)# interface Ethernet2
switch(config-if)# switchport mode dot1q-tunnel
switch(config-if)# no switchport trunk allowed vlan         ! optional: restrict inner VLANs
switch(config-if)# show interfaces Ethernet2 switchport

Restrictions worth remembering: dot1q-tunnel mode is not available on all platforms (Arista documents it as unavailable on Petra-based switches), and tap/tool aggregation modes are limited to specific silicon families. Verify your platform before writing the change into a template.

A tunnel port is not a trunk with extra tags - it is a port whose entire job is to keep the customer's tag stack intact. The outer tag identifies the service VLAN, and the inner tag is opaque payload as far as the switch is concerned. That has three consequences that shape how you deploy it. First, the outer VLAN must exist on the switch and be carried across the core, but the inner VLANs must not: they are never created locally, so show vlan will not list them. Second, since the inner tags are payload, the port has no per-inner-VLAN policy - there is no spanning-tree instance per customer VLAN and no MAC learning on the inner ID at the tunnel edge. Third, MTU is no longer a theoretical concern: 1500-byte customer payloads become 1526-byte frames on the wire, so every link that carries the tunnel must be configured for at least 1526 bytes, and preferably more if the customer might send tagged frames larger than the minimum.

Where the tunnel meets the rest of the network, an SVI on the service VLAN can route the whole tunnel as one VLAN, or a second EOS switch can strip the outer tag and hand individual VLANs back out - the pattern used in provider hand-offs and in labs where a test platform must believe it is on its own flat network.

Verifying the Tag Rewrite

show vlan
show vlan internal usage
show interfaces Ethernet1 switchport
show interfaces Ethernet1 counters
show mac address-table interface Ethernet1

show vlan internal usage matters more than it looks: when an interface becomes a routed port, EOS allocates an SVI from the internal VLAN range and forbids you from configuring that VLAN ID manually. If a VLAN refuses to configure, check the internal allocation before assuming a bug.

For a tunnel port, add the MTU and counter checks: show interfaces Ethernet2 reports the configured MTU, and a rising count of oversized or fragment-needing frames on the uplink is the signature of a segment that was never increased. For a translated port, the fastest sanity check is the MAC table: if the frames are landing in the VLAN you intended, the learned MAC address will appear against that interface and that VLAN ID, and nowhere else. If translation is silently not working, the MAC entry still appears - just in the wrong VLAN, which is why reading the VLAN column rather than the interface column is what actually proves the configuration.

When Tag Rewriting Meets MLAG, EVPN and Spanning Tree

Tag rewriting is a local, per-port operation, and that is both its strength and the reason it surprises people in a fabric. Three interactions are worth spelling out before you schedule the change.

MLAG. If the port you are rewriting is a member of an MLAG bundle, the rewrite must be identical on both chassis, and the peer link must carry the rewritten VLAN rather than the external one. A mismatch here does not produce a clean failure: the two MLAG peers disagree about which VLAN a frame belongs to, and because each keeps the same LACP system ID, the server sees a healthy bundle while the two switches treat the same flow differently. Check show mlag on both switches after the change, and verify the peer link's allowed VLAN list.

EVPN and VXLAN. In an EVPN-VXLAN fabric the VLAN ID on an access port is mapped to a VNI. Translation therefore decides which VNI a customer frame enters, so the rewrite must happen before the mapping - at the access port, not at the leaf uplink. If translation is applied on an uplink instead, the frame may be mapped and encapsulated in the original VLAN's VNI, and the far-end leaf will deliver it into the wrong tenant. As a rule, do the rewrite at the edge of your domain and leave the fabric to treat the rewritten ID as the real one.

Spanning tree and storm control. A translated port joins a different VLAN, so it inherits that VLAN's spanning-tree instance and its storm-control thresholds. Moving a port from an unused VLAN into a production VLAN can therefore introduce a new STP topology change and a new broadcast limit in the same command. Run show spanning-tree and check the target VLAN's storm control before committing, particularly on a port that faces an unmanaged switch or a hypervisor.

For a tunnel port the same logic applies in mirror image: because the inner tags are opaque, spanning tree runs only on the outer service VLAN, so the tunnel cannot be used to disable spanning tree for a customer - it just hides the customer's topology from yours. That is exactly what you want at a provider edge, and exactly the wrong thing to assume about loop protection inside the tunnel.

Change Control Tips

1. Do the change in a configuration session and review the diff: configure session tag-rewrite, make edits, show session-config diffs, then commit.
2. Never translate or tunnel on a port that also carries MLAG or the peer link without checking the MLAG state afterwards.
3. Confirm the far side sees the expected VLAN after the change; tag rewrite failures are usually invisible in interface counters.

Add two rules to that list from hard experience. First, check the MTU on the entire path before you bring up a tunnel, not after - increasing it on one switch and forgetting the uplink is a one-directional failure that looks like an application problem. Second, when you change the VLAN a translated port maps into, treat it as a broadcast-domain change and expect ARP and DHCP to be retested; the port comes up in a second, but the clients behind it may hold stale leases and ARP entries for minutes.

Related reading: Arista EOS VLAN configuration step by step, EOS VLAN trunk and port-channel guide and EOS configuration sessions, commit and rollback.

原文链接：https://www.arista.com/en/um-eos/eos-virtual-lans-vlans