4.3 AOS-CX Interface Configuration and Port Control

4.3 AOS-CX Interface Configuration and Port Control

Configuring and controlling physical interfaces is a fundamental daily operational task for network engineers managing ArubaOS-CX campus access switches. The interface configuration model in AOS-CX provides granular control over physical link parameters, Layer 2 and Layer 3 personality, maximum frame sizing, broadcast suppression, and automated protection mechanisms. Mastering interface syntax, parameter validation, and troubleshooting commands ensures resilient host connectivity across the campus edge.

---

Interface Identification and Syntax

AOS-CX enforces a standardized hierarchical notation to uniquely identify every physical front-panel port and modular uplink across standalone switches, VSF stacks, and modular chassis.

1. Naming Syntax Breakdown

• Fixed Standalone and VSF Stacks: Interfaces follow the three-tier format:

$\text{member} / \text{slot} / \text{port}$

• On a standalone switch (or Member 1 of a VSF stack), port 24 is addressed as 1/1/24 (Member 1, Slot 1, Port 24).
• In a VSF stack, port 12 on the third physical switch is addressed as 3/1/12 (Member 3, Slot 1, Port 12).
• Modular Chassis (CX 6400 Series): Interfaces follow the format:

$\text{chassis} / \text{slot} / \text{port}$

• For example, interface 1/3/48 represents Chassis 1, line-card Slot 3, Port 48 (slots 1/1 and 1/2 hold the management modules).

2. Interface Ranges

Engineers can configure multiple interfaces simultaneously by specifying contiguous ranges or comma-separated lists from the configuration prompt:

switch# configure
switch(config)# interface 1/1/1-1/1/24
switch(config-if-<1/1/1-1/1/24>)# description Edge_Access_Ports
switch(config-if-<1/1/1-1/1/24>)# no shutdown

switch(config)# interface 1/1/48,2/1/48
switch(config-if-<1/1/48,2/1/48>)# description Core_Uplinks

Commands applied within an interface range context are applied sequentially to each individual member interface in the state database.

---

Administrative Status, Descriptions, Speed, and Duplex

Physical ports in AOS-CX are enabled or disabled using standard administrative commands:

• shutdown: Administratively disables the port, turning off the physical transmitter and setting the operational state to down (administratively down).
• no shutdown: Administratively enables the port, powering on transceivers and initiating physical layer signaling.
• description <text>: Assigns an operational label (up to 64 characters) to document connected devices (e.g., description AP-Floor2-West-AP515).

Speed and Duplex Auto-Negotiation

By default, AOS-CX interfaces operate in auto-negotiation mode (speed auto). In modern enterprise networks, auto-negotiation is mandatory for several technical reasons:

1. Gigabit Ethernet Standards (IEEE 802.3ab): The 1000BASE-T standard requires auto-negotiation to establish clock master/slave synchronization between physical transceivers. Disabling auto-negotiation on 1GbE copper links violates IEEE specifications and can cause link failures or duplex mismatches.
2. Duplex Modes: Modern switches operate in full-duplex mode (simultaneous bi-directional transmission without collisions). Half-duplex is legacy and supported only for backwards compatibility on 10/100 Mbps copper links.
3. Manual Speed Overrides: When connecting legacy equipment or specialized transceivers, speed can be manually locked:

switch(config-if)# speed 1000-full

Best Practice: Always leave interface speed set to auto unless explicitly required by a vendor-specific endpoint with defective auto-negotiation circuitry.

---

Maximum Transmission Unit (MTU) and Jumbo Frames

The Maximum Transmission Unit (MTU) defines the largest payload size (in bytes) that an interface can transmit or receive without fragmenting or dropping the frame.

+-------------------------------------------------------------------------+
|                    ETHERNET FRAME AND MTU STRUCTURE                     |
|                                                                         |
|   +-------------+--------------+-----------------------+------------+   |
|   | Dest / Src  | 802.1Q Tag   | IP / Data Payload     | FCS / CRC  |   |
|   | MAC (12B)   | (4B Optional)| (MTU: 1500 to 9198 B) | (4B)       |   |
|   +-------------+--------------+-----------------------+------------+   |
|   |<------------------- Total L2 Frame Length --------------------->|   |
+-------------------------------------------------------------------------+

1. Default vs. Jumbo Frame MTU

• Standard MTU: The default MTU across all AOS-CX interfaces is 1500 bytes (yielding a standard 1518-byte or 1522-byte tagged Layer 2 Ethernet frame).
• Jumbo Frames: AOS-CX supports frames up to 9198 bytes; the interface mtu range is 46 to 9198 (AOS-CX 10.14 CLI Guide).
• Configuration: Set the MTU per interface (routed interfaces also have ip mtu for the Layer 3 MTU):

switch(config)# interface 1/1/48
switch(config-if)# mtu 9198

2. Operational Impact of MTU Mismatches

• Storage Traffic Degradation: Network-attached storage (iSCSI, NFS) and backup replication traffic rely heavily on 9000-byte jumbo frames to maximize throughput and minimize CPU interrupt overhead. If an intermediate campus switch has a 1500-byte MTU, jumbo packets exceeding 1500 bytes are silently dropped as oversized / giant frames.
• Routing Protocol Adjacency Failures (OSPF): In OSPFv2/OSPFv3, routers exchange MTU parameters inside Database Description (DBD) packets during neighbor adjacency negotiation. If two connected router interfaces have mismatched MTU values, the OSPF adjacency becomes permanently stuck in the EXSTART / EXCHANGE state, breaking dynamic routing.

---

Traffic-Type Rate Limiting: Protecting the Campus Edge

In enterprise networks, broadcast radiation, multicast flooding, and unknown unicast floods caused by Layer 2 loops or malfunctioning network interface cards (NICs) can quickly saturate switch backplanes and overwhelm end-user host CPUs. AOS-CX protects against these floods with per-interface traffic-type rate limits (often called storm control on other platforms), enforced in hardware.

+-------------------------------------------------------------------------+
|                     RATE-LIMIT (STORM PROTECTION) INGRESS               |
|                                                                         |
|   Incoming Frames on Interface 1/1/1                                    |
|   +-------------------+                                                 |
|   | Broadcast / MC /  | ---> [ Hardware ASIC Rate Filter ]              |
|   | Unknown Unicast   |           |                                     |
|   +-------------------+           |                                     |
|                                   +---> Conforming Traffic: FORWARDED   |
|                                   |     (Under threshold)               |
|                                   |                                     |
|                                   +---> Excess Traffic: DROPPED         |
|                                         (Rate exceeds pps / % limit)    |
+-------------------------------------------------------------------------+

1. Filtered Traffic Types

• Broadcast: Frames addressed to FF:FF:FF:FF:FF:FF (e.g., ARP requests, DHCP discovers).
• Multicast: Frames destined for multicast MAC addresses (e.g., 01:00:5E:xx:xx:xx for IPv4 or 33:33:xx:xx:xx:xx for IPv6).
• Unknown Unicast: Unicast frames whose destination MAC address is not currently learned in the switch forwarding table (CAM table). The switch must flood these frames out all VLAN ports; a rate limit prevents this flooding from consuming total link bandwidth.
• ICMP: AOS-CX can also rate-limit ICMP (icmp ip-all, ip, or ipv6).

2. Configuration (kbps, percent, or pps)

AOS-CX syntax is rate-limit {broadcast | multicast | unknown-unicast | icmp {ip-all | ip | ipv6}} <RATE> {kbps | percent | pps} in interface context (AOS-CX 10.14 CLI Guide):

switch(config)# interface 1/1/1-1/1/24
switch(config-if-<1/1/1-1/1/24>)# rate-limit broadcast 1000 pps
switch(config-if-<1/1/1-1/1/24>)# rate-limit multicast 2000 pps
switch(config-if-<1/1/1-1/1/24>)# rate-limit unknown-unicast 500 pps

Alternatively, using a percentage of link speed:

switch(config-if)# rate-limit broadcast 5 percent

Two details are worth remembering: rate limits apply to ingress traffic and are enforced separately on each member of a LAG, and the multicast limit also counts broadcast frames and Layer 2 BPDUs, so an aggressive multicast limit can starve spanning tree.

Action: Rate limiting is non-destructive. When traffic exceeds the configured threshold, the hardware drops the excess frames while continuing to forward traffic that falls within the limit. The physical interface remains up. show interface <port> qos shows forwarded and dropped counters for each rate limit.

---

Protection Shutdowns and Recovery Timers

When a port protection mechanism detects a severe security violation or topology fault, AOS-CX disables the port (commonly called an err-disabled state on other platforms) to protect the rest of the campus infrastructure. show interface <port> reports the reason.

1. Common Shutdown Triggers

• BPDU Guard Violation: An edge port configured with Spanning Tree BPDU Guard receives a Bridge Protocol Data Unit (BPDU), indicating an unauthorized switch has been connected.
• Loop Protection Trip: The switch detects its own transmitted loop protection probe frame returning on an edge interface.
• Port Security: A client-limit violation when the violation action is shutdown.
• Transceiver Faults: An unsupported transceiver is not enabled unless allow-unsupported-transceiver is configured.
• UDLD (UniDirectional Link Detection): A fiber pair loses signal in one direction, creating a unidirectional forwarding black hole.

2. Interface Recovery Methods

Once a port enters err-disabled state, it will not forward traffic until the condition is cleared.

• Manual Recovery: An administrator investigates the fault, disconnects the unauthorized device, and manually resets the interface via CLI:

switch(config)# interface 1/1/5
switch(config-if)# shutdown
switch(config-if)# no shutdown

• Automatic Recovery: AOS-CX uses a recovery timer per feature rather than one global command (AOS-CX 10.14 CLI Guide):

switch(config)# interface 1/1/5
switch(config-if)# spanning-tree bpdu-guard timeout 300
switch(config-if)# exit
switch(config)# loop-protect re-enable-timer 300
switch(config)# interface 1/1/6
switch(config-if)# port-access security violation action shutdown auto-recovery enable
switch(config-if)# port-access security violation action shutdown recovery-timer 300

By default, a BPDU-guard port stays disabled until it is manually re-enabled, and the loop-protect re-enable timer is disabled. If the fault (such as an unauthorized switch transmitting BPDUs) is still present when a timer expires, the port is disabled again.

---

Verification and Troubleshooting Commands

switch# show interface brief
switch# show interface 1/1/1
switch# show running-config interface 1/1/1
switch# show interface 1/1/1 qos
switch# show spanning-tree inconsistent-ports
switch# show loop-protect