Aruba AOS-CX - Troubleshooting DHCP Relay Mismatch on a VLAN

Purpose

Use this when endpoints on an Aruba AOS-CX VLAN fail to obtain DHCP even though switchport VLAN assignment, link state, and PoE appear normal.

Diagnostic pattern

A device has link and power but cannot obtain an IPv4 lease.
A Windows test endpoint connected to the same access port receives an APIPA address (169.254.0.0/16) and no default gateway.
The access port is in the expected VLAN and has no obvious physical errors.
One core or VSX peer may contain a different DHCP helper from its peer.

Diagnostic procedure

Prove the problem is not endpoint-specific. Disconnect the production endpoint and connect a known-good laptop to the same access port.
Confirm the laptop is using DHCP, then run:

ipconfig /release "Ethernet"
ipconfig /renew "Ethernet"
ipconfig /all

If the laptop receives APIPA and no gateway, treat the failure as a VLAN or DHCP-path issue rather than an endpoint issue.
On the Aruba access switch, verify the port is up and in the expected VLAN:

show interface <PORT>
show running-config interface <PORT>
show mac-address-table interface <PORT>

On both Aruba core or VSX peers, inspect the SVI:

show running-config interface vlan <VLAN_ID>

Compare the ip helper-address entries on both peers, and compare them with neighboring VLANs that use the same Windows DHCP service.

Aruba Central catch

In Aruba Central, the site-level VLAN profile may show Relay to External as disabled even while the switch running configuration contains ip helper-address commands.

When this happens, check the device-scope VLAN profile on each core switch. Imported or device-specific configuration can live at device scope and override the higher-level site profile. The actual DHCP helper can therefore be visible under the individual core device even when the site-level profile does not show it.

Do not enable DHCP relay in a broad shared site-level profile merely because the running configuration contains a helper. First determine which Central scope owns the active configuration.

Example configuration

A DHCP-enabled VLAN should have a helper that points to the intended DHCP service:

interface vlan 200
    ip address 192.0.2.2/24
    active-gateway ip 192.0.2.1
    ip helper-address 198.51.100.10

In a redundant core design, verify the intended helper is consistent on both peers.

Low-impact remediation

If the incorrect helper exists only in a device-scope VLAN profile, correct that device-level helper rather than modifying a broad access-switch or shared site profile.

If the UI allows multiple helper addresses, a cautious short-lived test can add the correct helper before removing the old one. DHCP requests will be relayed to all configured helpers during that period. Do not leave an unintended helper in place after validation.

A helper-address change does not change the VLAN ID, subnet, access-port membership, PoE state, or static IP configuration of endpoints. Static-IP cameras or appliances do not begin using DHCP simply because a helper is changed.

Validation

After the change:

show running-config interface vlan <VLAN_ID>

Confirm the intended helper is present on both peers.

Then reconnect the test laptop and renew DHCP:

ipconfig /release "Ethernet"
ipconfig /renew "Ethernet"
ipconfig /all

Validate:

The client receives an address from the expected VLAN subnet.
The default gateway is the VLAN gateway.
DHCP Server shows the intended Windows DHCP server.

Only after the laptop test succeeds should the production endpoint be reconnected and functionally tested.

Catches / gotchas

A powered, linked camera or similar IoT endpoint can still be completely unusable if DHCP relay is wrong.
DHCP snooping and LLDP-MED are separate features. Do not change them unless evidence points to them.
In a VSX or redundant-core environment, one peer being correct does not guarantee DHCP works for every client path. Configuration consistency matters.
Avoid broad shared-profile changes when a narrower device-scope correction is available.
Do not keep an unintended helper just because it has existed historically. Validate the intended DHCP architecture first.

Key lesson

Substitute a laptop on the exact production port to separate endpoint failures from network-path failures. Compare DHCP helpers across redundant core peers. Treat the switch running configuration as evidence of active state, then find the owning Central scope before editing.