Arista EOS VLAN Configuration Step-by-Step with CLI Examples

VLAN configuration is the first task every engineer performs on an Arista EOS switch, and the model is refreshingly simple: VLANs exist only after you create them (VLAN 1 is the sole exception), and every physical or port-channel interface is a switched port until you say otherwise. This step-by-step guide walks through creating VLANs, assigning access and trunk ports, building SVIs for inter-VLAN routing, verifying the result with the right show commands, and the design rules that keep a leaf switch clean - the exact sequence you need when commissioning a new Arista access or leaf switch.

Step 1: Create the VLANs

Enter global configuration mode and create the VLAN with the vlan command. Creating a VLAN also enters the VLAN configuration view, where you can assign a name:

switch> enable
switch# configure terminal
switch(config)# vlan 10
switch(config-vlan-10)# name servers
switch(config-vlan-10)# exit
switch(config)# vlan 20
switch(config-vlan-20)# name voice
switch(config-vlan-20)# exit

VLAN numbers range from 1 to 4094. VLAN 1 exists by default and cannot be deleted. A VLAN can be put into the suspended state, which blocks all traffic on that VLAN while keeping the configuration intact:

switch(config)# vlan 99
switch(config-vlan-99)# state suspend

Ranges and lists save typing when you commission a switch with dozens of VLANs. EOS expands the range and creates one VLAN per number, and a range that already exists is left alone:

switch(config)# vlan 100-110
switch(config)# vlan 200,220,240
switch(config)# no vlan 200,220,240

Two numbering details are worth remembering. First, VLAN 4094 and the internal VLANs used for routed ports are reserved: EOS allocates internal VLANs from the top of the range downwards when you convert a port to no switchport, and show vlan lists them. Second, an interface is a switched port by default, so a freshly cabled port already belongs to VLAN 1 - which is exactly why you should configure the port before you enable it in production.

Step 2: Assign an Access Port

Access ports carry traffic for exactly one VLAN and drop tagged frames from other VLANs. Assigning an access VLAN implicitly creates the VLAN if it does not exist:

switch(config)# interface Ethernet1
switch(config-if-Et1)# switchport mode access
switch(config-if-Et1)# switchport access vlan 10
switch(config-if-Et1)# no shutdown

Choose the interface speed and description at the same time; a description is the cheapest documentation you will ever write:

switch(config-if-Et1)# description SRV-01-nic1
switch(config-if-Et1)# exit

If the connected device is a phone, configure the voice VLAN so the phone can tag its own traffic while the PC behind it stays untagged:

switch(config)# interface Ethernet5
switch(config-if-Et5)# switchport mode access
switch(config-if-Et5)# switchport access vlan 10
switch(config-if-Et5)# switchport voice vlan 20

Step 3: Configure a Trunk Port

Trunk ports carry multiple tagged VLANs. Set the mode to trunk, optionally adjust the native VLAN, and define the allowed VLAN list - restricting the allowed list is good hygiene so unexpected VLANs cannot traverse the trunk:

switch(config)# interface Ethernet2
switch(config-if-Et2)# switchport mode trunk
switch(config-if-Et2)# switchport trunk native vlan 10
switch(config-if-Et2)# switchport trunk allowed vlan 10,20
switch(config-if-Et2)# no shutdown

To bundle multiple physical links carrying VLANs, add them to a port channel with LACP active mode and apply the same switchport statements to the port-channel interface. The members inherit the port-channel configuration, so configure the port-channel and not the members:

switch(config)# interface Port-Channel10
switch(config-if-Po10)# switchport mode trunk
switch(config-if-Po10)# switchport trunk allowed vlan 10,20
switch(config-if-Po10)# exit
switch(config)# interface Ethernet3-4
switch(config-if-Et3-4)# channel-group 10 mode active

Incremental changes to the allowed list are supported and are much safer than retyping the whole list on a production trunk:

switch(config-if-Et2)# switchport trunk allowed vlan add 30
switch(config-if-Et2)# switchport trunk allowed vlan remove 30
switch(config-if-Et2)# switchport trunk allowed vlan except 999

By default the native VLAN travels untagged. If you would rather tag it - which removes an entire class of VLAN-hopping mistakes - use switchport trunk native vlan tag and make sure both ends agree.

Step 4: Create an SVI for Inter-VLAN Routing

A Switch Virtual Interface (SVI) provides Layer 3 processing for a VLAN - typically the default gateway for the subnet. Enable IP routing globally, then configure the SVI:

switch(config)# ip routing
switch(config)# interface vlan 10
switch(config-if-Vl10)# ip address 172.16.10.1/24
switch(config-if-Vl10)# no shutdown
switch(config)# interface vlan 20
switch(config-if-Vl20)# ip address 172.16.20.1/24
switch(config-if-Vl20)# no shutdown

With SVIs in place and ip routing enabled, hosts in VLAN 10 and VLAN 20 can reach each other through the switch.

An SVI comes up only when at least one port in that VLAN is up, unless you disable that dependency. no autostate keeps the interface up regardless, which is useful for loopback-like SVIs, MLAG peer addresses and management gateways on sparse VLANs:

switch(config-if-Vl10)# no autostate
switch(config-if-Vl10)# mtu 9214

Raising the MTU on an SVI matters as soon as you plan to run VXLAN, because the encapsulation adds overhead to every inner frame. If the switch is a leaf in an EVPN fabric, use a routed model instead: interface Ethernet1 with no switchport and an IP address, and leave the SVIs to the VLANs that genuinely need them.

For first-hop redundancy, a pair of Arista switches can share one virtual IP with VARP, which behaves like an active-active gateway on top of the whole MLAG construct rather than a master/backup election.

Step 5: Verify and Save

Use the show commands to confirm the VLAN table, port membership and SVI status:

switch# show vlan
switch# show vlan id 10
switch# show interfaces switchport
switch# show interfaces Ethernet2 switchport
switch# show interfaces status
switch# show ip interface brief
switch# show ip route
switch# write memory

show interfaces switchport prints the administrative and operational mode, native VLAN and the allowed VLAN list for each port, which makes it the fastest way to verify a trunk after configuration. show interfaces status gives the one-line-per-port view (link state, speed, type, VLAN) that tells you instantly whether a port came up at all, and show ip interface brief confirms that the SVIs are up/up and numbered as intended.

switch# show interfaces Ethernet2 switchport
Name: Et2
Switchport: Enabled
Administrative Mode: trunk
Operational Mode: trunk
Access Mode VLAN: 1 (default)
Trunking Native Mode VLAN: 10 (servers)
Trunking VLANs Allowed: 10,20
Voice VLAN: none

Remember that write memory (equivalent to copy running-config startup-config) is what survives a reload. On EOS you can also commit the whole session or roll back with the configuration session feature, but for a fresh switch the classic save command is the one that matters.

VLAN Translation and Tunnelling

Two features extend the basic model when two domains disagree about numbering. VLAN translation rewrites the tag as traffic crosses a port, so VLAN 10 on the customer side can become VLAN 110 in the core without renumbering anything. dot1q-tunnel (QinQ) pushes an outer tag onto every frame, which lets a service provider carry an entire customer VLAN plan across one access VLAN on the provider side:

switch(config)# interface Ethernet6
switch(config-if-Et6)# switchport mode dot1q-tunnel
switch(config-if-Et6)# switchport access vlan 900
switch(config-if-Et6)# l2-protocol encapsulation dot1q

Both features are easy to test and hard to debug in production, so verify with show interfaces Ethernet6 switchport and a packet capture on both sides before you declare victory.

EOS VLAN Commands vs Cisco IOS Habits

Engineers moving from IOS to EOS rarely struggle with the VLAN model itself, but a few muscle-memory commands do not exist. The mapping is short:

• show vlan in IOS becomes show vlan in EOS, but show vlan brief is replaced by show vlan plus show interfaces status.
• IOS switchport trunk encapsulation dot1q has no EOS equivalent - 802.1Q is the only encapsulation.
• IOS vlan database mode does not exist; VLANs are created in global configuration.
• IOS write works, but the canonical EOS save is write memory or copy running-config startup-config.
• IOS shutdown on an SVI behaves the same, but autostate semantics are the thing to check when an SVI refuses to come up.
• Interface naming is Ethernet1, not GigabitEthernet0/1, and ranges use Ethernet1-4.

VLANs on an EVPN-VXLAN Leaf

On a leaf switch that participates in a VXLAN fabric, every VLAN you create is a candidate for a Layer 2 VNI, and the VLAN-to-VNI mapping is what ties the local broadcast domain to the overlay. That changes the design conversation: VLAN IDs are locally significant again, but the VNI is not, so the fabric must agree on VNI numbers while each leaf may number its VLANs as it likes. Keep the mapping documented, keep the SVIs either entirely distributed or entirely centralized, and remember that the MTU on every trunk and SVI in the path has to accommodate the extra encapsulation overhead.

VLAN Design Notes

• Keep the native VLAN consistent at both ends of a trunk; a mismatch silently mis-tags untagged traffic.
• Prune the allowed list on trunks that do not need every VLAN, and remember that VLANs in a trunk group are pruned from ports outside that group.
• Do not use VLAN 1 for user traffic - leave it as the default native VLAN and place real traffic in dedicated VLANs.
• Reuse one VLAN-to-subnet mapping across the fabric so that troubleshooting a host means checking one number, not three.
• Reserve a range for infrastructure (management, peer links, storage) and keep user VLANs out of it.
• Document the voice VLAN and the access VLAN together; the phone tags and the PC does not, and getting that backwards produces one-way audio rather than a clean outage.

Frequently Asked Questions

Does assigning an access VLAN create the VLAN automatically? Yes, as does an SVI. That convenience is also a source of surprises when a typo silently creates VLAN 1001 instead of failing.

Why is my SVI down/up? No member port in that VLAN is up. Either bring up a port or add no autostate.

Can a trunk port carry an untagged VLAN and a tagged VLAN with the same number? In EOS the native VLAN is untagged inside the trunk, so a frame arriving untagged is classified into the native VLAN; use switchport trunk native vlan tag if you want it tagged instead.

What is the difference between an access port and a routed port? A routed port (no switchport) has no VLAN membership at all and consumes an internal VLAN; an access port belongs to exactly one VLAN and needs an SVI if it is to be routed.

Related reading: Arista EOS VLAN trunk SVI port-channel runbook, Arista EOS port channel LACP configuration, Arista EOS VARP: Active-Active Gateway with MLAG and Arista EOS VLAN Troubleshooting: Native VLAN and Trunks.

Original article: https://www.arista.com/en/um-eos/eos-virtual-lans-vlans