Extreme EXOS VLAN Configuration: Tagged and Untagged

ExtremeXOS handles VLANs differently from Cisco or Aruba in one important way: the default VLAN owns every port until you explicitly remove them, and untagged ports cannot belong to two VLANs at once. That single rule explains the "Protocol conflict when adding untagged port" error most engineers hit on their first EXOS build. This article walks through a complete VLAN deployment, including the port-move step that everyone forgets.

Create the VLAN, then move the ports

create vlan accounting
configure accounting ipaddress 132.15.121.1/24

! the crucial step - ports belong to Default until you remove them
configure default delete ports 2:1-2:3,2:6,4:1,4:2
configure accounting add ports 2:1-2:3,2:6,4:1,4:2

If you skip the configure default delete ports line, the second command fails with:

Error: Protocol conflict when adding untagged port 1:2.
Either add this port as tagged or assign another protocol to this VLAN.

The exception is a protocol-based VLAN: assign a non-default protocol first, and untagged ports can be added without leaving the default VLAN, because the two VLANs are not competing for the same traffic.

Tagged uplinks and untagged access ports

! uplink to the distribution switch - tagged members of several VLANs
configure vlan accounting add ports 1:48 tagged
configure vlan engineering add ports 1:48 tagged
configure vlan management add ports 1:48 tagged

! keep the native/untagged VLAN explicit on the uplink
configure vlan default delete ports 1:48
configure vlan management add ports 1:48 untagged

! remove a port from a VLAN later
configure vlan accounting delete ports 1:47

EXOS expects you to state tagged or untagged explicitly. There is no equivalent of Cisco's DTP negotiation: an untagged port carries exactly one VLAN, and everything else must be tagged. On multi-VLAN uplinks, this makes the configuration readable but verbose — and it means a missing tagged keyword produces a silent one-way failure rather than an obvious error.

Port auto-move, and how to control it

configure vlan untagged-ports auto-move on       ! move silently
configure vlan untagged-ports auto-move inform   ! move and log
configure vlan untagged-ports auto-move off      ! fail instead (default on many releases)

Auto-move is what produces the "Port 1 untagged has been auto-moved from VLAN Default to v2" message. In a lab it is convenient. In production, having a port silently join a different VLAN when someone mistypes a command is exactly the kind of change you want logged — set it to inform, not on.

Layer 3 on EXOS

configure vlan accounting ipaddress 10.10.10.1/24
configure vlan engineering ipaddress 10.10.20.1/24
enable ipforwarding

! give the switch a route out of one of the VLANs
configure iproute add default 10.10.10.254

Inter-VLAN routing on EXOS happens as soon as ipforwarding is enabled and each VLAN has an IP address — there is no separate SVI concept, because the VLAN interface is the L3 interface. Verify with show iproute and show ipconfig.

Verification

show vlan
show vlan accounting
show ports 1:48 information detail
show configuration vlan accounting
show ipconfig
show iproute

show ports ... information detail is where you confirm what a port is actually carrying: VLAN membership, tag state, STP state and link. When a port is not passing traffic and the VLAN looks right, this output usually shows the port still in the Default VLAN or in the wrong STP state.

Failure patterns

• Untagged port in two VLANs — impossible by design; the second command errors rather than silently winning.
• Uplink works one way only — the remote end has the VLAN tagged and the local end untagged, or vice versa. Check both ends with show vlan.
• VLAN exists, no traffic — no ports added, or all members are down. show vlan lists member ports and their state.
• Loop when adding ports — EXOS warns explicitly if the ports are EAPS ring ports; read the confirmation prompt rather than answering y reflexively.
• Configuration lost after reboot — EXOS keeps the running configuration separate from the saved one; use save configuration (or save) to persist.

Related vendor material: EXOS stacking configuration for the switch-stack side of the same platform, and Ruckus ICX stacking for the other common non-Cisco campus platform.

原文链接：https://documentation.extremenetworks.com/exos_32.1/GUID-9FC94E71-1F71-46E6-A726-416BE5D640FF.shtml