Arista EOS VLAN Troubleshooting: Native VLAN and Trunks

VLAN problems on Arista EOS almost always come down to four mistakes: the VLAN was never created, the port is in the wrong mode, the allowed VLAN list is narrower than intended, or the native VLAN differs between the two ends of a trunk. This article gives a fixed troubleshooting order that moves from the access port outward, with the EOS commands that answer each question, and the security hardening that stops native VLAN mismatch from being exploitable in the first place.

What makes EOS native VLAN and trunk faults awkward is that nothing announces them. EOS does not run CDP, so the familiar "%CDP-4-NATIVE_VLAN_MISMATCH" message that Cisco IOS prints on the console never appears here. A native VLAN mismatch instead surfaces indirectly: spanning tree recomputes, MAC addresses seem to move between ports, an uplink that carries voice and data behaves differently from the same uplink after a failover, and a host that worked yesterday is unreachable today without a single configuration change. Because the visible symptom sits far from the actual cause, a fixed diagnostic order beats inspecting whatever looks suspicious. Work the five steps below in sequence: each one either clears the fault or eliminates a whole class of causes.

Step 1 - Does the VLAN Exist?

switch# show vlan
switch# show vlan id 20
switch# show vlan brief
switch# show vlan id 20 detail

There is no vlan.dat on EOS: the VLAN database is part of the running configuration, so a VLAN created but not saved disappears after reload. Confirm both the VLAN's state (active, not suspended) and its presence before looking at anything else.

A suspended VLAN is the trap worth calling out first. state suspend keeps the VLAN defined, keeps its row in the VLAN table and keeps every port association visible, but the ports stop forwarding. If a VLAN was suspended during a maintenance window and never reactivated, every show command in the remaining steps will look perfectly healthy and the traffic will still be dead. Compare the state field on both ends of the link rather than only on the switch you happen to be logged into.

Two VLANs that were meant to be the same ID are the second version of this mistake: VLAN 20 exists locally and VLAN 200 exists on the peer, so the trunks agree on nothing, MAC learning stays empty on both sides and no amount of trunk configuration will help until the IDs match.

Step 2 - Port Mode and Access VLAN

switch# show interfaces Ethernet1 switchport
switch# show mac address-table interface Ethernet1
switch# show mac address-table vlan 20

Output that says "Administrative Mode: access, Access Mode VLAN: 1 (default)" while the design expects VLAN 20 is the single most common cause of "the host cannot reach the gateway". A port that never learns a MAC address in the expected VLAN has either the wrong access VLAN or a physical problem - check show interfaces Ethernet1 counters errors before chasing spanning tree.

Read show interfaces ... switchport as three separate facts rather than one. First the administrative mode: what the configuration asks for. Second the operational mode: what the port is actually doing, which can differ when a trunk group or a dynamic protocol is in play. Third the VLAN in effect for that mode - Access Mode VLAN for an access port, Trunking Native Mode VLAN plus the active VLAN list for a trunk. A port whose administrative mode is trunk but whose operational mode is down is a different fault from a port that is happily trunking the wrong VLAN list.

switch(config-if-Et1)# switchport mode access
switch(config-if-Et1)# switchport access vlan 20
switch(config-if-Et1)# no switchport trunk native vlan
switch(config-if-Et1)# no switchport trunk allowed vlan
switch# show interfaces Ethernet1 switchport

Residual trunk statements are a real source of confusion when a port is repurposed from uplink to access. Removing them explicitly keeps the running configuration honest, and it prevents the port from reverting to surprising behaviour the next time someone clears a trunk group.

Step 3 - Trunk Allowed List

switch(config-if-Et49)# switchport trunk allowed vlan 10,20,30
switch(config-if-Et49)# switchport trunk allowed vlan add 50,60
switch(config-if-Et49)# switchport trunk allowed vlan remove 60
switch# show interfaces Ethernet49 switchport
switch# show interfaces trunk

Adding VLANs to an existing trunk requires add; without it the new list replaces the old one and silently blackholes every VLAN you did not retype. The verification output lists the operational trunking VLANs, which is authoritative when a configuration looks right but the VLAN still is not passing.

EOS also lets you group trunks so that one statement keeps several uplinks in step. A trunk group is the right structure when four spine links must always carry the same VLAN set, because a change made in one place cannot drift on the others. The group is created implicitly the first time an interface references it:

switch(config-if-Et49)# switchport trunk group FABRIC-UPLINKS
switch(config-if-Et50)# switchport trunk group FABRIC-UPLINKS
switch(config-if-Et51)# switchport trunk group FABRIC-UPLINKS
switch(config-if-Et52)# switchport trunk group FABRIC-UPLINKS
switch(config)# show interfaces trunk

Two field-level details matter in the trunk output. "Vlans in spanning tree forwarding state" tells you which VLANs are actually in the forwarding state after STP, while the allowed and active lists tell you which ones you configured - a VLAN can be permitted and still be blocked by STP, and that looks identical from the host's point of view. "Trunking VLANs Enabled" versus "Trunking VLANs Active" separates intent from reality in the same way. When a VLAN is missing from both lists, the fault is in the allowed list; when it appears in enabled but not active, the fault is STP or a missing VLAN definition on the peer.

Step 4 - Native VLAN Match

Untagged frames on a trunk land in the native VLAN, and BPDUs are usually sent untagged too. If the two ends disagree, native-VLAN traffic is misclassified, other VLANs behave intermittently and spanning tree may flap. Fix it on both sides and stop using VLAN 1 for user traffic:

switch(config)# vlan 999
switch(config-vlan-999)# name NATIVE-UNUSED
switch(config-vlan-999)# state active
switch(config-if-Et49)# switchport trunk native vlan 999
switch(config-if-Et49)# switchport trunk allowed vlan add 999

Remember to add the native VLAN to the allowed list. On EOS the native VLAN must be permitted on the trunk for its tagged traffic to cross; the untagged traffic rides along regardless, which is exactly why a one-sided change can look partly functional. If your design needs the native VLAN to be tagged as well - common on links to hypervisors and on some provider handoffs - use the tag keyword on both ends:

switch(config-if-Et49)# switchport trunk native vlan 999 tag
switch# show interfaces Ethernet49 switchport

Verification is a two-device exercise - compare Trunking Native Mode VLAN on both ends of the link, and keep the allowed list explicit on both sides rather than relying on the default "all".

Step 5 - Physical Layer, Counters and Speed

switch# show interfaces Ethernet1 status
switch# show interfaces Ethernet1 counters errors
switch# show interfaces Ethernet1 transceiver
switch# show interfaces Ethernet1 description

Only after the logical checks come the physical ones. Growing CRC or input-error counters point at a cable, optic or duplex fault and explain symptoms that look like VLAN problems: a link that carries small frames but loses larger ones can present as a VLAN that "sometimes" works. Check that both ends agree on speed and duplex, and that the description field matches the intended peer - a mislabelled patch can move a whole uplink onto the wrong switch pair without anyone noticing until the VLAN list stops matching.

Native VLAN and Spanning Tree Interaction

switch# show spanning-tree
switch# show spanning-tree vlan 20
switch# show spanning-tree blockedports
switch# show spanning-tree inconsistentports

Because untagged BPDUs are classified by the native VLAN, a native VLAN mismatch can put two switches into a state where each believes the other is in a different topology. The classic signatures are a port that oscillates between forwarding and blocking, an unexpected root bridge election, or STP topology-change counters that climb steadily on a stable network. Comparing show spanning-tree vlan 20 on both ends, including the root bridge ID and the port role, makes the disagreement visible in seconds. If the root bridge changed hands recently and no one touched the topology, treat that as evidence for step 4 rather than as a separate spanning tree problem.

Layer 3 and Inter-VLAN Routing Checks

switch# show ip interface brief
switch# show interfaces Vlan20
switch# show ip route
switch# show ip interface vlan 20

An SVI only comes up when at least one port in that VLAN is up and forwarding in STP, so an SVI that stays down usually points back at step 2. For inter-VLAN traffic also confirm ip routing is enabled globally, that the SVI has the intended address and mask, and that the peer device has a route or an on-link address in the same subnet. A default gateway that answers pings but not real traffic is often an SVI that is up in VLAN 1 rather than the VLAN you intended.

Security Hardening Around the Native VLAN

switch(config-if-Et49)# switchport trunk native vlan 999
switch(config-if-Et49)# switchport trunk allowed vlan 10,20,30,999
switch(config-if-Et1)# switchport mode access
switch(config-if-Et1)# switchport access vlan 20

The native VLAN is both a troubleshooting topic and a security topic, because untagged frames are trusted implicitly. Three habits remove most of the exposure. Move the native VLAN off VLAN 1 so that a misconfigured access port cannot join a control-plane broadcast domain. Keep the allowed list explicit instead of all, so an unplanned VLAN cannot cross an uplink by accident. And make user ports access ports rather than "trunk that happens to work", which is what closes the door on double-tagged frames leaving the access layer and arriving somewhere they should not. Where a design genuinely requires a tagged native VLAN, apply tag consistently at every hop and document it, because a single untagged hop in the middle is enough to break the whole path.

The Whole Order on One Page

1. VLAN defined, correct ID, state active on both switches.
2. Port mode and VLAN as intended on the access side.
3. Allowed list contains every VLAN that must cross, on both ends.
4. Native VLAN identical on both ends, moved off VLAN 1, tagged if the design says so.
5. Physical layer, counters, speed and neighbour identity.
6. Layer 3: SVI up, ip routing enabled, route or on-link address present.

Common Faults and the Step That Finds Them

Host cannot reach its gateway: step 2, wrong access VLAN or a port still in trunk mode. A single VLAN works while others do not: step 3, an allowed list that was replaced rather than extended. Intermittent loss and STP churn: step 4, native VLAN mismatch. Nothing works at all after a reload: step 1, an unsaved VLAN that was never written to the startup configuration. Everything looks correct but the SVI stays down: step 2 and step 5 together, because the SVI only comes up when a member port forwards. Working the list in order means you rarely reach the end without having found the fault.

Frequently Asked Questions

Why does EOS not warn me about a native VLAN mismatch? Because EOS uses LLDP rather than CDP, the Cisco-style mismatch syslog has no equivalent. Detect the mismatch by comparing show interfaces ... switchport output at both ends, or by watching spanning tree stability. LLDP neighbour information confirms the identity of the peer but does not compare VLAN configuration for you.

Should the native VLAN appear in the allowed list? Yes on EOS. The untagged traffic associates with the native VLAN automatically, but its tagged frames are governed by the allowed list, so leaving it out creates an asymmetric path that is hard to reason about later.

Can I keep VLAN 1 as the native VLAN on lab links? On a lab link with no user traffic, yes, as long as both ends agree. On any production uplink the cost of changing it once is far lower than the cost of a single misconfigured access port bridging into the control plane.

How do I prove the fix worked? Re-run the two-device comparison: show interfaces trunk on both ends, matching native VLAN and allowed list, plus show mac address-table vlan 20 showing the expected MAC on the expected uplink.

The full configuration side of these steps, including SVIs, port channels and voice VLANs, is in the Arista EOS VLAN create/trunk/SVI examples, MAC-table behaviour is documented in EOS MAC address table show commands, and the wider fault-isolation workflow lives in the Arista EOS troubleshooting cookbook.

原文链接：https://aivoid.dev/vlan-mastery-2026/common-vlan-issues/