How to Manage VLANs on Arista EOS: Create, Assign and Verify

2026年8月31日 LOG admin

Arista EOS handles VLANs the same way industry-standard 802.1Q networks expect, but the exact CLI steps are worth having memorized: create the VLAN, name it, assign ports in access or trunk mode, save, and verify. This quickstart walks through the complete lifecycle of a VLAN on an Arista switch — from the first vlan 10 to deletion — with copy-pasteable commands for your lab or production rollout.

Whether you are standing up a fresh pair of 7050X switches or slotting one more segmentation VLAN into an existing fabric, the workflow never changes: define the VLAN, attach it to ports, decide whether it needs a routed interface, persist the change, and prove it works. The sections below follow that exact order, and every command is written the way you would type it into an SSH session on an EOS device.

Create a VLAN on Arista EOS

Access the switch CLI via SSH, console or Telnet, then enter privileged and configuration mode:

enable
configure terminal

Create the VLAN and give it a descriptive name. Valid VLAN IDs range from 1 to 4094:

vlan 10
name Marketing

The name is optional as far as the switch is concerned, but it is not optional for the humans who read show vlan at two in the morning during an incident. A VLAN called Marketing costs nothing and removes an entire class of "which one was VLAN 137?" questions from your change reviews.

You can define several VLANs in a single pass, either with consecutive statements or with a compact list and range:

vlan 10-12,20,30
name Shared-Services

Two defaults are worth knowing. The reserved VLAN range 1002 to 1005 exists by default for legacy Token Ring and FDDI translation and cannot be used for normal traffic — leave it alone. VLAN 1 also exists by default and carries untagged traffic on every port until you change it, which is exactly why most production designs move management traffic off VLAN 1 into a dedicated VLAN with an explicit native VLAN on trunks.

Assign Ports to the VLAN

To assign an access port (single untagged VLAN):

interface Ethernet1
switchport mode access
switchport access vlan 10

To make the port a trunk carrying VLAN 10:

interface Ethernet1
switchport mode trunk
switchport trunk allowed vlan add 10

Note the word add. On a trunk, switchport trunk allowed vlan 10 replaces the entire allowed list, whereas add 10 appends to it. Getting that wrong on a carrying link drops every other VLAN on the port and is the single most common self-inflicted outage in VLAN work. To remove one VLAN without disturbing the rest, use switchport trunk allowed vlan remove 10; to permit everything except a handful, use switchport trunk allowed vlan except 10,20.

Access ports do not have to be configured one at a time. For a wiring closet where ports 1 through 20 all serve identical desk drops, use an interface range:

interface Ethernet1-20
switchport mode access
switchport access vlan 10
spanning-tree portfast
spanning-tree bpduguard enable

Pairing portfast with BPDU Guard is standard practice for edge ports that connect to a single host: the port comes up immediately instead of waiting through listening and learning states, and an accidental loop-causing device plugged into a desk port is error-disabled rather than allowed to melt the network.

If a trunk also needs an untagged VLAN for untagged management frames, set the native VLAN explicitly and keep it identical on both ends of the link:

interface Ethernet1
switchport mode trunk
switchport trunk native vlan 999

Create a VLAN Interface (SVI) When the VLAN Needs Routing

A VLAN that only switches traffic between its own member ports needs nothing more. The moment it must be reachable from another subnet, it needs a switched virtual interface:

interface Vlan10
ip address 10.10.10.1/24
no shutdown

The SVI is what gives hosts in the VLAN a default gateway. Verify it comes up as connected — an SVI stays down until at least one member port in that VLAN is up, which is a frequent source of confusion on freshly cabled switches. In an MLAG or VARP design the SVI address is normally a shared virtual address rather than a unique per-switch address, and the virtual router MAC must be consistent across the peer pair.

Save the Configuration

Exit to privileged EXEC mode and write the configuration to flash so the changes survive a reboot:

write memory

write memory is the EOS equivalent of Cisco's copy running-config startup-config, and EOS also accepts that longer form verbatim if it is already in your muscle memory. Because the running configuration is separate from the startup configuration, an unsaved VLAN disappears at the next reload — which is the most common reason a "disappearing VLAN" ticket ever gets opened.

Verify the VLAN Configuration

show vlan
show vlan brief

show vlan brief gives a compact table of VLAN IDs, names and member ports — the fastest way to confirm your assignment took effect. For a deeper look at a specific port, use:

show interfaces Ethernet1 switchport
show interfaces Ethernet1 trunk
show interfaces status
show interfaces Vlan10

Together these four commands answer every practical question: which mode the port is really in, which VLANs are actually allowed on the trunk, whether the link is up at the expected speed, and whether the SVI has an address and line protocol. When a host cannot reach its gateway, the answer is almost always visible in one of them. For a single VLAN on a switch carrying hundreds, show vlan 10 prints only that entry, which is far easier to read than scrolling the full table.

Delete a VLAN

To remove a VLAN that is no longer in use:

no vlan 10
write memory

Make sure the VLAN is not assigned to any active interface or virtual interface before deleting it, or the deletion will fail. In practice that means clearing access ports, removing the VLAN from every trunk's allowed list, and shutting down or deleting the SVI first. A tidy teardown order is: shut the SVI, remove the VLAN from trunks, reassign access ports, delete the SVI, delete the VLAN, then write memory.

VLANs in an MLAG or VARP Design

On a leaf pair running MLAG, VLANs must be defined identically on both switches, and the MLAG peer link carries every VLAN that spans the pair. Two habit rules prevent most MLAG VLAN faults: create the VLAN on both switches before assigning ports, and keep the trunk allowed lists on the peer link identical. A VLAN present on one peer but not the other produces intermittent, maddening traffic loss because every other frame arrives on the wrong switch. With VARP, the SVI address becomes a virtual address with ip virtual-router address, and both peers answer for it, giving you active-active first-hop redundancy without spanning tree blocking a link.

Common Mistakes and How to Spot Them

Wrong port mode. The "Operational Mode" line in show interfaces <port> switchport tells the truth regardless of what you believe you configured.
Trunk allowed list replaced instead of extended. If half your VLANs went dark right after adding one, confirm with show interfaces <port> trunk and re-add with add.
Native VLAN mismatch. Both ends must agree; EOS logs the mismatch and untagged traffic is dropped.
SVI stuck down. No active member port means no routed interface, even with an address configured.
Unsaved configuration. Everything looked perfect until the reload.

Two related guides go deeper on these: our Arista EOS VLAN troubleshooting guide for native VLAN and trunk faults and the VLAN translation and dot1q tunnel walkthrough.

A Practical Troubleshooting Sequence

When a host cannot talk to its gateway, work outward from the wall jack rather than guessing at the fabric. The sequence below resolves the overwhelming majority of VLAN faults in under two minutes.

Confirm the interface is administratively up and physically up: show interfaces status should say connected, not notconnect or errdisabled.
Confirm the operational mode and VLAN: show interfaces Ethernet1 switchport. If the access VLAN is wrong, nothing downstream matters.
If the port is a trunk, confirm the VLAN is in the allowed list: show interfaces Ethernet1 trunk.
Confirm the VLAN exists at all: show vlan 10. Traffic cannot be forwarded for a VLAN that has no entry.
Confirm the SVI is up with the right address: show interfaces Vlan10.
Confirm the host is actually in the VLAN by checking the MAC table: show mac address-table vlan 10.
Confirm the change was saved: compare show running-config with show startup-config.

If the MAC table shows the host in the right VLAN but pings still fail, the problem has moved up the stack — an incomplete ARP entry, a firewall policy on the SVI, or a routing table that simply does not have the destination. The VLAN itself is fine at that point, and it is worth saying so out loud before anyone starts editing switch configuration.

VLANs, Port Channels and the Allowed List

When several physical links are bundled into a port channel, the allowed VLAN list lives on the port channel interface, not on the individual members. Configure it once on Port-Channel1 and let the member links inherit it:

interface Port-Channel1
switchport mode trunk
switchport trunk allowed vlan 10,20,30
interface Ethernet1-2
channel-group 1 mode active

Adding a VLAN to the members instead of the bundle is a classic mistake: the configuration appears to take effect on the physical ports while the forwarding logic still uses the bundle's list. Our Arista EOS port-channel and LACP configuration guide covers the full bundle workflow.

Roll Changes Out Safely

On a production switch, make the change inside a configuration session so you can review the whole candidate before it is applied:

configure session vlan10-rollout
vlan 10
name Marketing
show session-config diffs
commit

Sessions let you diff pending changes against the running configuration and abort cleanly with abort if something looks wrong, which is far safer than typing live on a switch carrying customer traffic. For fleet-wide work, the same VLAN definitions can be generated from templates and pushed with Ansible rather than typed per device.