ArubaOS-CX Access vs Trunk Ports: VLAN Scenario with LAGs

The cleanest way to understand ArubaOS-CX access and trunk ports is to build the small multi-switch scenario from the official HPE Layer-2 Bridging Guide and watch the verification output. The example uses VLANs to isolate computers, switches and a server, and it exercises every concept that trips engineers up: untagged native VLANs, tagged native VLANs, allowed lists and LAG membership. This article walks the entire configuration and explains what each command changes - and then goes further, because the interesting failures only appear once the uplinks are aggregated: LAG members that disagree, an LACP session that never comes up, and native VLAN settings that are correct on the LAG but wrong on a member.

Scenario Design and VLAN Plan

• VLAN 25 — tagged and untagged traffic from computers on switch B (native on the A-B link).
• VLAN 4 — tagged traffic from computers on switch B.
• VLAN 6 — tagged and untagged traffic from switch C (native on the A-C link, but explicitly tagged).
• VLAN 17 — tagged traffic from computers on switch C.
• VLAN 100 — server VLAN on a plain access port.

Switches A and B are connected over LAG 1; switches A and C over LAG 3.

Two design decisions in this plan are worth naming because they drive everything that follows. First, the aggregate - not the physical port - is the unit of VLAN configuration. Second, the two uplinks deliberately use different native VLAN behaviour so the same switch exercises both the untagged and the tagged case. VLAN 100 stays on a single physical access port because end devices have no reason to be VLAN aware, and putting a server behind an aggregate would only add LACP as a variable during a server-side fault.

Why LAGs Change the Access versus Trunk Calculation

An aggregate interface in AOS-CX behaves like a port for every Layer 2 purpose: it has a mode, an untagged VLAN, an allowed list and a MAC address table role. Physical members do not carry VLAN configuration of their own; they inherit it from the LAG. That inheritance is the feature that keeps a four-member uplink consistent, and it is also the reason a mistaken vlan access typed on a member is either rejected or silently irrelevant. Practical consequences:

• Configure VLANs on the LAG, never on the members, and keep the members free of VLAN statements.
• Every member must be in the same LAG and must be administratively up, or capacity silently drops.
• An show vlan view reports the VLAN as present on the LAG, not on each member - the members will not appear as separate ports in that output.
• Because the LAG has one native VLAN, you cannot mix an untagged member and a tagged member inside one aggregate.

Configuring Trunk VLANs on the A-B Link (LAG 1)

switch# config
switch(config)# vlan 4,25
switch(config)# interface lag 1
switch(config-lag-if)# no shutdown
switch(config-lag-if)# lacp mode active
switch(config-lag-if)# vlan trunk native 25
switch(config-lag-if)# vlan trunk allowed 4,25
switch(config-lag-if)# exit
switch(config)# interface 1/1/1
switch(config-if)# no shutdown
switch(config-if)# lag 1
switch(config-if)# interface 1/2/1
switch(config-if)# no shutdown
switch(config-if)# lag 1

vlan trunk native 25 assigns the untagged native VLAN while vlan trunk allowed 4,25 defines the complete allowed list. If the native VLAN is missing from the allowed list, untagged frames on that trunk are dropped. Read our native VLAN and tagging deep dive for the underlying rules.

lacp mode active makes the switch offer LACP rather than rely on the static assumption that the peer agrees. Use active on at least one end of every inter-switch aggregate; active on both ends is the normal design. Static aggregates remove LACP as a variable, but they also remove the check that stops you from cabling the wrong ports together.

Optional but useful on uplinks that carry a mix of server and switch traffic is a hash policy, so that traffic to a busy destination is spread across members rather than pinned to one:

switch(config-lag-if)# hash l3-src-dst
switch# show lag 1

Hash selection is not a VLAN topic, but it is the reason a healthy LAG can still look congested: if every flow in VLAN 4 hashes to one member, the aggregate is up and correct while one member saturates.

Tagging the Native VLAN on the A-C Link (LAG 3)

On the link to switch C the native VLAN must also be carried tagged, which is done by appending the tag keyword. Only packets tagged with the matching VLAN ID are then accepted; untagged packets are dropped except BPDUs, and egress packets are tagged.

switch(config)# vlan 6,17
switch(config)# interface lag 3
switch(config-lag-if)# no shutdown
switch(config-lag-if)# lacp mode active
switch(config-lag-if)# vlan trunk native 6 tag
switch(config-lag-if)# vlan trunk allowed 6,17
switch(config-lag-if)# exit
switch(config)# interface 1/1/13
switch(config-if)# no shutdown
switch(config-if)# lag 3
switch(config-if)# interface 1/2/13
switch(config-if)# no shutdown
switch(config-if)# no routing
switch(config-if)# lag 3

Notice the asymmetry: switch A tags VLAN 6 on this link, so switch C must expect it tagged. A single mismatch here produces the classic half-working path - the tagged VLANs cross, the traffic you expected on the native VLAN is dropped, and the only clue is that BPDUs still flow because they bypass the rule.

Aggregates Can Carry Access Ports Too

Not every LAG is a trunk. When two links need to behave as one access port - for example a hypervisor with two NICs in a single VLAN, or a downstream switch that should sit inside one broadcast domain - you configure the aggregate exactly like a physical access port:

switch(config)# interface lag 20
switch(config-lag-if)# no shutdown
switch(config-lag-if)# lacp mode active
switch(config-lag-if)# vlan access 100
switch(config-lag-if)# exit
switch(config)# interface 1/1/20
switch(config-if)# no shutdown
switch(config-if)# lag 20

The choice is the same one you make on a physical port: one VLAN (access) or many (trunk). The aggregate does not change the model, it only multiplies the bandwidth. A common trap is configuring an access aggregate on one side and a trunk with a matching native VLAN on the other: traffic still flows for the native VLAN, so the fault survives the first round of testing and only appears when a second VLAN is introduced months later.

Server Connection as an Access Port

End devices such as servers do not need VLAN awareness, so the port facing the server is a single-VLAN access port:

switch(config)# vlan 100
switch(config)# interface 1/2/32
switch(config-if)# no shutdown
switch(config-if)# vlan access 100
switch(config-if)# exit

If that server later grows a second NIC or a second NIC team, the migration path is to create a LAG and move vlan access 100 onto the aggregate - not to add a second access port with its own VLAN, which would put two untagged ports into the same broadcast domain without any loop protection between them.

Verification with show Commands

Confirm the VLAN-to-interface mapping first:

switch# show vlan

Output should list VLAN 4/25 on lag1, VLAN 6/17 on lag3 and VLAN 100 on 1/2/32. Then inspect the LAGs — the interesting fields are VLAN Mode, Native VLAN and Allowed VLAN List:

switch# show interface lag1
Aggregate-name lag1
VLAN Mode: native-untagged
Native VLAN: 25
Allowed VLAN List: 4,25
switch# show interface lag3
VLAN Mode: native-tagged
Native VLAN: 6
Allowed VLAN List: 6,17

VLAN Mode: native-tagged confirms the tag keyword took effect on lag3. Finally check a physical port and its counters with show interface 1/2/32 and show interface lag 1 statistics, watching the Rx/Tx counters increment to prove data is flowing. For the bigger picture of access versus trunk design, compare our ArubaOS-CX access vs trunk configuration guide and the port comparison article.

Verifying the Aggregate Itself

switch# show lacp interfaces
switch# show lacp aggregates
switch# show lag
switch# show interface lag1 brief
switch# show running-config interface lag1

Layer 2 verification and aggregate verification answer different questions, so run both. show interface lag1 proves the VLAN configuration is what you intended. show lacp interfaces proves the members are actually bundled - a member that shows "Current State" without the aggregating and synchronisation flags, or that shows a partner that does not match, is contributing no bandwidth even though the port is up. A LAG whose members are individually up but not correctly bundled carries traffic on one link and drops the rest into the bit bucket, which looks like packet loss rather than a link failure.

Troubleshooting Access and Trunk Failures That Involve LAGs

Work this order when a VLAN scenario that worked before stops working:

1. show interface lag <n> - is the VLAN Mode, Native VLAN and allowed list exactly what was designed?
2. show lacp interfaces - are all intended members bundled and synchronised?
3. show vlan - is the VLAN defined and is it mapped to the aggregate?
4. show interface 1/1/1 for each member - member up, no error counters climbing?
5. show mac-address-table - is the expected MAC learned on the aggregate, not on a single member?
6. On a VSX pair, show vsx status - is the inter-switch-link healthy before you blame the LAG?

The recurring failure patterns, and what they look like:

• Member missing from the bundle: capacity halves, VLANs are unaffected, so the fault is reported as slowness rather than outage. Fix the LACP negotiation or the cabling.
• VLAN configured on a member instead of the LAG: the LAG output shows the wrong list, or the member's configuration is simply ignored. Move the statement to the aggregate.
• Native VLAN mismatch on one member: untagged traffic crosses some members and not others, giving intermittent loss that clears and returns as flows rehash.
• Allowed list present at one end only: tagged VLANs pass one way in the lab and fail in production once the peer's list is pruned.
• Access aggregate against a trunk aggregate: works for the shared VLAN, breaks the moment a second VLAN appears.

Multi-Chassis Aggregates

The same VLAN rules apply to a VSX LAG that spans two chassis, with one addition: the two switches must agree on the LAG configuration, and the inter-switch-link must be up before the aggregate behaves as designed. Configure the VLANs identically on both peers and verify with show vsx status; a topology that is logically correct but has a down inter-switch-link will pass some traffic and drop the rest depending on which peer a flow hashes to. The ArubaOS-CX VSX configuration guide covers the peer-link side in detail.

Frequently Asked Questions

Can I set a VLAN on a physical member of a LAG? No. VLAN configuration belongs on the aggregate interface; the members carry it implicitly. Configuration typed on a member is either refused or does not take effect, depending on the platform and version, and either way it is not the place to look when the VLAN is wrong.

Do I need no routing on a LAG? You need it whenever the interface must behave as a Layer 2 port and the platform defaults to routed. Apply it to the LAG (and, as in the scenario above, to members where it is accepted) before VLAN statements, otherwise the VLAN commands are rejected.

What happens if the allowed list is empty? The trunk reverts to permitting every VLAN the switch knows, which is rarely what you want on an uplink. Keep the list explicit.

Does the native VLAN need to appear in the allowed list? Yes, if its tagged form must cross the link. The untagged form associates with the native VLAN regardless, which is precisely how a partial misconfiguration stays hidden.

原文链接：https://arubanetworking.hpe.com/techdocs/AOS-CX/10.15/HTML/l2_bridging_4100i-6000-6100-5420-6200/Content/Chp_vlans/vla-sce.htm