We're migrating from UniFi switches to an Aruba Instant On design. The network includes stacks of 1960 switches, several 1930 switches, and fiber uplinks between parts of the building. Some links use 10 Gb connections, while others use standard Ethernet uplinks. The physical layout is intended to mirror the existing design, except for the 10 Gb switches in certain areas.
The Aruba switches work normally for days when staged on a separate management LAN. A laptop connected directly to them receives an address and can reach the Internet. However, whenever we begin moving production connections from the UniFi switches to the Aruba switches, the Aruba cloud health status deteriorates and connectivity falls apart. Clients may fail to obtain DHCP addresses, and even when they do receive one, DNS lookups fail. Basic sites such as Google become unreachable.
We've tried several migration approaches, including removing the firewall uplink from the UniFi switches and connecting it only to the Aruba network. The symptoms make me suspect a Layer 2 problem, possibly involving VLAN tagging, native or untagged VLANs, spanning tree, or a switching loop. What would be the best way to isolate the fault and verify the Aruba uplinks, VLANs, and topology before attempting another full cutover?
4 Answers
Strip the design down to the smallest working path: firewall, one 1960 stack, one 1930, and a laptop. Confirm that DHCP, DNS, and Internet access work there. Then add the remaining switches and uplinks one at a time, testing after each change. The first connection that causes the failure should identify the problem segment much faster than troubleshooting the whole topology at once.
If wireless access points are connected to any of these stacks, temporarily disconnect or disable them during testing. A device or AP that is still bridging through the old switching path can create a loop when the Aruba path is connected. Test with only one known-good wired laptop, then reconnect APs and other edge devices after the switching path is stable.
This sounds more like a Layer 2 failure than a DNS problem. Start with RSTP and check which switch is becoming the root bridge, along with the topology-change counters. If those counters climb rapidly as production links come online, you likely have a loop or an unexpected redundant path.
Also verify every uplink in both directions: allowed VLANs, tagged VLANs, native or untagged VLAN, and the management VLAN. A mismatch on just one 1960-to-1930 link can make DHCP and DNS appear broken even though the switches themselves look healthy.
Double-check that the VLAN definitions and default VLAN behavior are identical on both platforms. Don’t assume that a VLAN being present on one side means it is tagged correctly on the other. Pay particular attention to the untagged or native VLAN on trunks and to the VLAN used for management.
VLAN tagging was one of my main suspicions too. I’ll compare the tagged and untagged settings on every uplink instead of only checking that the VLAN exists.