Troubleshooting Connectivity Problems With VLAN Probe (Pro Tip: It’s not always the Wi-Fi)
Five years ago, I wrote a blog about about VLAN Probe, one of the most popular troubleshooting tools available in HiveManger Classic. I am extremely pleased to announce that VLAN Probe now also exists in the HiveManager NG cloud management solution for enterprise mobility.
Because it has been five years since I last blogged about VLAN Probe, I realized that many of our partners and customers may not fully comprehend the awesomeness of this outstanding troubleshooting tool.
Because Wi-Fi is an access technology, if something goes wrong, the knee-jerk reaction of the user is to blame the wireless network. From the user’s viewpoint, they cannot access the Internet or corporate servers via the WLAN and therefore the problem must be the Wi-Fi network.
However, more often than not, the actual cause of the problem is not the Wi-Fi network and is actually an issue on the wired networkBecause Wi-Fi is an access technology, if something goes wrong, the knee-jerk reaction of the user is to blame the wireless network .
The exact same methodology that is used to troubleshoot a wired network should also be used to troubleshoot a wireless network. A bottoms-up approach to analyzing the OSI reference model layers also applies to wireless networking.
A wireless networking administrator should always try to first determine whether problems exist at layer 1 and layer 2.
All 802.11 mechanisms operate at layer 1 and layer 2. Most layer 1 problems revolve around RF interference, improper WLAN coverage/capacity design, or client driver issues. A proper WLAN design followed by a validation site survey will alleviate coverage/capacity and interference issues.
Because client drivers often cause problems, Wi-Fi troubleshooting 101 dictates that the end-user should always disable and re-enable the WLAN network adapter. This ensures that the WLAN NIC driver is talking properly to operating system.
Once you establish that the problem is not a layer 1 issue, move up the OSI stack and investigate layer 2. The HiveManager Client Monitor tool can be used to troubleshoot both PSK connectivity problems and 802.1X/EAP connectively problems from the cloud. Client Monitor is the perfect tool to diagnose layer 2 connection problems.
If you can determine that no problems exist at either layer 1 or layer 2, then the Wi-Fi network is not the culprit. The problem is most likely a higher layer networking problem or an application issue on the wired network.
Luckily, Aerohive offers a fantastic tool called VLAN Probe to determine if the problem exists on the wired network.
Please look at the diagram in Figure 1; an Aerohive AP deployed in a school is transmitting three SSIDS for teachers, students and guests. The Teacher SSID is mapped to VLAN 2, the Student SSID is mapped to VLAN 5 and the Guest SSID is mapped to VLAN 8. The management interface of the Aerohive AP is mapped to VLAN 1. All four VLANs are tagged across an 802.1Q trunk between the Aerohive AP and the access switch. All four VLANs are mapped to respective subnets and all IP addresses are supplied from defined scopes on the network DHCP server.
At this point, it is time to use the HiveManager VLAN probe tool. As shown in Figure 3, an administrator can select an Aerohive AP to perform a VLAN probe across a designated range of VLANs. The tool will report back if the VLANs are operational on the wired network as well as the subnet of each VLAN. Please note that VLAN 5 (the Teacher VLAN) failed.
So exactly how does VLAN Probe work? As shown in Figure 4, VLAN Probe leverages the ability of the management interface of any access point to send out DHCP requests. Once the VLAN probe starts, the management interface of the Aerohive AP will send out multiple DHCP requests across all the designated VLANs. Each DHCP request is sent up the 802.1Q trunk and onto the wired network. Once the DHCP request finally reaches the DHCP server, a lease offer is sent back to the Aerohive AP.
The management interface of the Aerohive AP does not need another IP address, therefore a NAK is sent back to the DHCP server. If the DHCP lease offer reaches the Aerohive AP, then there is not an issue with the wired network. But if the DHCP lease offer does not reach the Aerohive AP, then there is absolutely a wired-side problem and the VLAN probe will show a negative result.
As shown in Figure 5, two common points of failure are the upstream router or the DHCP server. DHCP requests use a broadcast address and therefore an IP Helper (DHCP-Relay) address needs to be configured on the upstream router to convert the DHCP request into a unicast packet. If the router does not have the correct IP Helper address, then the DHCP request never makes it to the DHCP server. The DHCP server is more likely to be a point of failure. The DHCP server may have crashed, the scopes might not be configured correctly or the server could simply be out of leases.
Although these two points of failure are certainly possible, the most likely culprit is the access switch as shown in Figure 6. Almost ninety percent of the time the problem is an improperly configured access switch. The VLANs might not be configured on the switch, the VLANs might not be tagged on the 802.1Q trunk port or the port has been misconfigured as an access port.
Once the wired side problem has been located and fixed, a VLAN Probe can once again be run to verify all is well as shown in Figure 7.
VLAN Probe is wildly popular with both Aerohive customers and partners alike. Using the HiveManager NG VLAN Probe tool, an administrator can manage any Aerohive AP at any location and begin the troubleshooting process of the wired network. VLAN Probe is the perfect tool to prove that the problem is not a Wi-Fi problem. Stay tuned for more updates about VLAN Probe as we we have more advanced troubleshooting capabilities planned in the near future for VLAN Probe.
Slow Wi-Fi? These articles might explain why