ArubaOS-CX Access vs Trunk Ports: Native VLAN Tagging Explained

Configuring an ArubaOS-CX interface as an access port or a trunk port is one of the first tasks every campus engineer faces, yet the native VLAN behavior trips up many people coming from ProCurve or Cisco backgrounds. This article distills the community-validated best practices from the Aruba Airheads forum: a hardened access-port template for edge hosts, a trunk-port template for inter-switch links, and a clear explanation of what vlan trunk native <id> tag actually does compared with the untagged default.

Access Port Configuration (Edge Host)

For a port (or Layer 2 VSX-LAG / Standard-LAG) connected to an edge host such as a PC or printer, the recommended configuration is:

interface 1/1/<n>
    no shutdown
    mtu 9198
    description "Link-to-Edge-Host"
    no routing
    vlan access <vlan-id>
    loop-protect
    spanning-tree bpdu-guard
    spanning-tree port-type admin-edge
    spanning-tree tcn-guard
    exit

• spanning-tree bpdu-guard — disables the interface if a BPDU is received (blocks rogue switches).
• spanning-tree port-type admin-edge — transitions the port to forwarding immediately during STP convergence.
• spanning-tree tcn-guard — stops TCN propagation to other STP ports.
• loop-protect — the default action tx-rx-disable shuts the port down on loop detection.

Trunk Port Configuration (Inter-Switch Link)

interface 1/1/<n>
    no shutdown
    no routing
    mtu 9198
    flow-control rx
    description "Link-to-Remote-Switch"
    vlan trunk native <vlan-id> tag
    vlan trunk allowed <vlan-id>
    spanning-tree link-type point-to-point
    spanning-tree ignore-pvid-inconsistency enable
    exit

• vlan trunk native <vlan-id> tag — enables tagging on the native VLAN. Without the tag keyword the native VLAN is sent untagged.
• vlan trunk allowed <vlan-id> — permits exactly that VLAN; vlan trunk allowed all permits every VLAN.
• spanning-tree link-type point-to-point — sets the STP link type for full-duplex inter-switch links (this is the default).

Tagged vs Untagged: The Rule Behind the Syntax

Everything that confuses people about native VLANs comes from one fact: an untagged frame has no VLAN information inside it, so any switch receiving it has to guess. It guesses using the port's own configuration - the untagged VLAN - and that guess must match on both ends of the link.

AOS-CX gives you exactly two ways to treat the native VLAN on a trunk:

The second row is the one that catches engineers out. vlan trunk native N tag does not mean "native VLAN, still untagged". It means "there is no untagged VLAN on this link at all - treat VLAN N exactly like every other tagged VLAN". The native keyword is retained only because the configuration model still has a PVID slot to fill.

This is why the Airheads best-practice template pairs vlan trunk native <id> tag with spanning-tree ignore-pvid-inconsistency enable: with no untagged path, a PVID mismatch between the two ends cannot create a hidden Layer 2 loop through the untagged domain, and the check is simply unnecessary overhead.

Walk-Through: Same Link, Two Configurations

Case A - untagged native (the default). Link between switch A (port 1/1/2) and switch B (port 1/1/2), both configured with native VLAN 1 and allowed 10,20:

! Switch A
interface 1/1/2
    vlan trunk native 1
    vlan trunk allowed 10,20
! Switch B - identical
interface 1/1/2
    vlan trunk native 1
    vlan trunk allowed 10,20

A broadcast tagged as VLAN 10 leaves A tagged, arrives at B tagged, lands in VLAN 10. An untagged frame (say an ARP from a device in VLAN 1) leaves A untagged, arrives at B and is assigned to VLAN 1 by B's own native VLAN setting. Consistent, and this is what "one VLAN works, everything else doesn't" faults look like when the native VLANs differ: the untagged traffic lands in different broadcast domains at each end, and Layer 3 adjacency quietly fails.

Case B - tagged native (fully tagged link). Both ends use the template, with the management VLAN 99 allowed and tagged:

interface 1/1/2
    vlan trunk native 99 tag
    vlan trunk allowed 10,20,99
    spanning-tree ignore-pvid-inconsistency enable

Now every frame on the wire carries an 802.1Q tag. There is no VLAN 1 traffic at all, no untagged domain to match up, and BPDUs travel per-VLAN as usual. Two operational consequences:

• A third-party device that expects an untagged management VLAN on the same link will see its frames dropped. That is the most common interop complaint against this template.
• Tools that assume VLAN 1 is the management VLAN must be re-pointed at VLAN 99.

The PVID, and Why "Native VLAN Mismatch" Is Such a Common Fault

On AOS-CX each port has an internal port VLAN ID (PVID) derived from its untagged/native VLAN setting. The PVID is what makes untagged traffic work at all. Its value on both ends of a link must be identical, and when it is not, four classic symptoms appear:

Two habits prevent all four. First, change the native VLAN everywhere, in the same change window, and record it. Second, prefer vlan trunk native <id> tag on uplinks so there is no untagged domain to mismatch - this is the direction HPE's own guidance pushes and why the template above is recommended for inter-switch links.

Verifying Tagging State on AOS-CX

switch# show vlan
switch# show vlan port 1/1/2
switch# show interface 1/1/2 trunk
switch# show running-config interface 1/1/2
switch# show mac-address-table vlan 99
switch# show spanning-tree interface 1/1/2

• show vlan port <port> prints the VLANs on the port and flags each one as tagged or untagged - the single most useful command for native VLAN disputes.
• show interface <port> trunk summarises trunk mode, native VLAN, and the allowed list in one screen.
• show mac-address-table vlan 99 proves the VLAN is actually carrying traffic; if the expected MAC is absent, tagging is wrong even when the config looks correct.
• show running-config interface is the tie-breaker: it shows the commands that are actually in effect, including anything inherited from a range or a template.

Working through these in order is a five-minute exercise and eliminates guesswork; the same sequence with expected sample output is laid out in our access vs trunk verification guide.

Troubleshooting Flow for Untagged-Traffic Faults

1. Confirm the port type. show interface <port> trunk. If it is not a trunk on either end, an untagged VLAN is expected and the conversation changes entirely.
2. Compare native VLANs. If either side shows a native VLAN other than the one you believe, you have found the fault. Fix in a change window, not by adding an interim workaround.
3. Check the allowed list. A VLAN absent from vlan trunk allowed is dropped even when it is the native VLAN on one side. Allowances and tagging are independent settings.
4. Look for tag mismatches at the peer. With vlan trunk native N tag on one end and plain vlan trunk native N on the other, the tagged side's frames are accepted but the untagged side's egress is untagged and dropped. This asymmetric case is the hardest to spot from the CLI and the easiest to spot from a packet capture.
5. Capture. An AOS-CX packet capture on the trunk shows immediately whether egress frames carry an 802.1Q header and which VID they carry.
6. Only then look at STP and routing. Many native VLAN tickets turn out to be a routed-side issue once tagging has been proven correct.

Interop Notes: Cisco, ProCurve, Arista

AOS-CX's access/trunk model is deliberately simpler than the ProVision and Comware "per-VLAN membership" models. That simplicity removes a class of mistakes, but it also means an AOS-CX port cannot serve one untagged VLAN and a tagged VLAN on the same edge port the way a Comware hybrid port can. If you need that behaviour, you need two ports or a design change.

Summary Checklist

• Edge hosts: access port, plus bpdu-guard, port-type admin-edge, tcn-guard and loop-protect.
• Inter-switch links: trunk with an explicit vlan trunk allowed list, never all unless designed.
• Prefer vlan trunk native <id> tag on uplinks to remove the untagged domain entirely.
• Keep native VLANs identical if you do use an untagged native VLAN, and change them network-wide in one window.
• Verify with show vlan port, show interface ... trunk and the MAC table - not by reading the config and hoping.

Related Articles on This Site

For the basic comparison, see ArubaOS-CX access vs trunk port comparison and ArubaOS-CX access/trunk interface best practices, or learn how VLANs route traffic in our inter-VLAN routing guide. For untagged traffic specifically, see ArubaOS-CX native VLAN on trunks: untagged traffic explained and the cross-vendor view in Arista EOS native VLAN and trunk troubleshooting.

原文链接：https://airheads.hpe.com/discussion/arubaos-cx-accesstrunk-interface-configuration-commongood-practices