Switch field guide: Huawei and HP Aruba, side by side

Most switching references are written from documentation. This one is written from outages.

I run two CLI dialects daily: Huawei VRP on S5735 access switches and HP ProVision on Aruba switches. Switching between them is a small tax paid every single time. display versus show. save versus write memory. Tagged versus trunk, which mean almost opposite things depending on whose manual you're holding.

So this is the reference I wanted and couldn't find: the same task, both dialects, next to each other. Plus the troubleshooting workflow I've refined across a lot of production VLAN migrations, and one failure that taught me more than any of the successes.

The two dialects#

The single most useful table in this article. Same intent, different words.

Two things that catch me out constantly:

Interface naming. Huawei wants the full name, GigabitEthernet1/0/24, or GE1/0/24 for short. HP just wants the number: 24. Muscle memory from one platform produces syntax errors on the other for the first ten minutes of every session.

MAC address format. Huawei groups in fours, HP groups in sixes:

Same address, different punctuation. Paste one into the other and you get "no such MAC" rather than a helpful error, which sends you chasing a device that was there the whole time.

Interfaces#

Naming ports properly is the cheapest documentation you will ever write. Do it while you're already in the interface.

Huawei

system-view
interface GigabitEthernet1/0/1
 description Reception-PC
 undo shutdown
quit

HP

configure terminal
interface 1
 name "Reception-PC"
 enable
exit

To disable a port, Huawei uses shutdown and HP uses disable. To bring it back, undo shutdown and enable respectively. That undo prefix is VRP's universal negation, the equivalent of no on most other platforms.

VLANs#

Where the vocabulary diverges most, and where migrations go wrong.

Huawei: create and assign

system-view
vlan batch 20
interface GigabitEthernet1/0/1
 port link-type access
 port default vlan 20
quit

HP: create and assign

configure terminal
vlan 20
 name "OFFICE"
 untagged 1
exit

Note the model difference. Huawei configures VLAN membership from the interface. HP configures it from the VLAN, listing which ports are untagged or tagged members. Neither is wrong; they're just inverted, and thinking in the wrong direction wastes time.

The terminology trap:

"Trunk" means two different things. On Huawei it's a port carrying multiple tagged VLANs. On HP it's a link aggregation group, several physical ports bonded together, and carrying multiple VLANs is called tagging. Say "trunk" in a mixed-vendor conversation and confirm which one you mean.

Trunks and tagging#

Huawei: allow VLANs on a trunk port

interface GigabitEthernet1/0/24
 port link-type trunk
 port trunk allow-pass vlan 10 20 30

HP: tag a VLAN onto an aggregated trunk

vlan 20
 tagged trk1
exit

Verifying, on both:

# Huawei
display current-configuration interface GigabitEthernet1/0/24
display interface brief

# HP
show trunks
show running-config interface trk1
show vlan port trk1

Finding where a device actually is#

Two tools, used together. LLDP tells you what's on the other end of an uplink; the MAC table tells you which port an end device lives on.

LLDP: what is this cable connected to?

# Huawei
display lldp neighbor brief
display lldp neighbor interface GigabitEthernet1/0/24

# HP
show lldp info remote-device
show lldp info remote-device 24
show lldp info remote-device 24 detail

MAC table: which port is this device on?

# Huawei
display mac-address 00e0-fc12-3456
display mac-address interface GigabitEthernet1/0/24

# HP
show mac-address 00e0fc-123456
show mac-address vlan 20

Tracing an unlabelled cable across a stack of switches is just these two commands in a loop: LLDP to find the next switch, MAC table to find the port, repeat until you reach an access port.

When a device gets 169.254.x.x#

The most common failure during a VLAN migration, and the one worth having a fixed routine for. An APIPA address means exactly one thing: the client broadcast a DHCP request and nothing answered.

That's useful, because it's a path problem. The client is fine. Work the path.

flowchart TD
  A[Client shows 169.254.x.x] --> B{VLAN exists on<br/>the access switch?}
  B -- no --> B1[Create the VLAN]
  B -- yes --> C{Access port in<br/>the right VLAN?}
  C -- no --> C1[Fix port membership]
  C -- yes --> D{MAC learned on<br/>that port?}
  D -- no --> D1[Cable, NIC, or port disabled]
  D -- yes --> E{Every trunk in the path<br/>carrying the VLAN?}
  E -- no --> E1[The usual culprit]
  E -- yes --> F{Gateway + DHCP scope<br/>configured?}
  F -- no --> F1[Firewall / router side]
  F -- yes --> G{STP forwarding,<br/>not blocking?}
  G -- yes --> H[Look at firewall policy]

The checklist in order, because order saves time:

1. VLAN exists on the access switch: display vlan / show vlan
2. Access port assigned: display current-configuration interface … / show vlan port 1
3. MAC learned on that port. If not it's physical, so stop looking at VLANs
4. Every trunk in the path carries the VLAN, access to distribution to core, all of them
5. Gateway exists for the subnet, so check the router or firewall interface
6. DHCP scope is configured and not exhausted
7. STP forwarding, not blocking: display stp brief / show spanning-tree
8. Firewall policy permits the new segment

Step 4 is the one people skip. It's also the one that gets them.

The half day I lost to a trunk#

Worth writing up properly, because the symptom pointed everywhere except the cause.

Symptom. During a migration onto new segmented VLANs, clients moved to the new VLAN on an HP access switch consistently pulled 169.254.x.x. Same clients worked fine on the old VLAN. Move them back, DHCP worked. Move them forward, APIPA.

What checked out clean:

• The Huawei access switch was tagging the new VLAN correctly
• The core switch trunk allowed the new VLAN
• The firewall's interface for the new subnet was up, with a healthy DHCP scope
• The HP access ports were untagged into the right VLAN
• The client MAC was being learned on the expected port

Everything I looked at was right, which is exactly the problem. I was checking the two ends of the path repeatedly and never the middle.

Root cause. An HP link-aggregation trunk, trk1, between the access and distribution layer. It had been built years earlier and carried the legacy VLANs. Nobody had added the new VLANs to it as tagged members.

DHCP discovers are broadcasts. The client broadcast, the access switch flooded it within the VLAN, the frame hit trk1, and trk1 had no membership for that VLAN, so it was silently discarded at the trunk boundary. It never reached the firewall. Nothing logged an error anywhere, because nothing had failed. The switch did precisely what it was configured to do.

Fix. One command per VLAN:

vlan 20
 tagged trk1
exit
write memory

DHCP started working instantly for every migrated client.

Diagnostics worth knowing#

Is the cable actually good?

# HP
test cable-diagnostics 1
show cable-diagnostics 1

# Huawei
virtual-cable-test interface GigabitEthernet1/0/1

Time-domain reflectometry, built into the switch. It reports the fault type and roughly how far down the cable it is. Enormously useful before crawling into a ceiling, because it will tell you if the break is 40 metres away or the patch lead at your feet is simply bad.

Optics

# Huawei
display transceiver interface XGigabitEthernet0/0/10 verbose

# HP
show interfaces transceiver detail

Check the received power. A fibre link that's up but flapping under load is very often an SFP running at the edge of its budget, or a dirty connector.

Errors and spanning tree

# Huawei
display interface GigabitEthernet1/0/1
display stp brief
display stp interface GigabitEthernet1/0/24

# HP
show interfaces 1 counters
show spanning-tree

Rising CRC or FCS errors mean a physical problem: cable, connector, or duplex mismatch. Rising drops with clean CRCs usually means congestion or policy.

Migration runbook#

The sequence I follow now, which exists because doing it in the wrong order once caused an outage.

Build the path before you move anything onto it.

1. Create the VLAN on every switch in the path
2. Name it, because an unnamed VLAN is a mystery in six months
3. Confirm the gateway exists on the router or firewall
4. Confirm the DHCP scope exists, with a sane range and lease time
5. Add the VLAN to the core trunk
6. Add it to the distribution trunk
7. Add it to the access switch trunk
8. Only now, move one test client
9. Verify properly before touching anyone else
10. Move the rest in batches, not all at once

Step 8 is non-negotiable. One machine, fully validated, before touching production users.

What "verify" means. All four of these, not only the first:

ipconfig /all          # correct subnet, gateway, DNS - not APIPA
ping <gateway>         # layer 3 within the VLAN
ping <dns-server>      # across the firewall
nslookup fiventhree.com # DNS resolution works

Then the things users will actually complain about if you skip them: internet browsing, file shares, printing, RDP, and any line-of-business application. A client that pings the gateway but can't print is still a failed migration.

Building an access switch from scratch#

The order that avoids locking yourself out:

1. Console in first. Never start on the network you're about to reconfigure
2. Set hostname, management IP, default gateway
3. Enable SSH, disable telnet, set a real password
4. Create all VLANs before assigning any ports
5. Configure the uplink trunk before the access ports
6. Configure and name access ports
7. Enable LLDP so the next person can trace the topology
8. Enable loop protection on access ports
9. Save, then reboot and confirm it comes back as expected

Step 9 gets skipped constantly. A config that works but was never saved is a time bomb that goes off during the next power event, usually at night.

The daily drivers#

Huawei

display current-configuration
display interface brief
display vlan
display mac-address
display lldp neighbor
display arp
display ip interface brief
display stp brief
save

HP

show running-config
show interfaces brief
show vlan
show trunks
show lldp info remote-device
show mac-address
show spanning-tree
show logging
write memory

Why write this down#

Two reasons, and only one of them is about the commands.

The first is practical: I stop looking things up. Muscle memory across two dialects is genuinely hard, and a reference written in my own words sticks better than vendor documentation.

The second matters more. Writing up the trk1 failure forced me to articulate why I missed it: I'd checked both ends of the path repeatedly and never the middle, because both ends were where I'd made the changes. That's a generalisable debugging error, not a networking one. I've caught myself starting to make it in completely unrelated systems since, and recognised it in time.

Certifications teach you what a trunk is. Half a day of a production network quietly dropping broadcasts at a trunk boundary teaches you to check every hop.