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 network.
For many years, I have taught that 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 site survey and a spectrum analyzer will alleviate cover/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. In my last two blogs, we discussed how you can you use the HiveManager Client Monitor tool to troubleshoot both PSK connectivity problems and 802.1X/EAP connectively problems. 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 is transmitting two SSIDS called “Teacher” and “Student”. The Teacher SSID is mapped to VLAN 8 and the Student SSID is mapped to VLAN 10. The management interface of the Aerohive AP is mapped to VLAN 2. All three VLANs are tagged across an 802.1Q trunk between the Aerohive AP and the access switch. All three VLANs are mapped to respective subnets and all IP addresses are supplied from defined scopes on the network DHCP server.
A common support call is that a user complains that they have a Wi-Fi connection, but cannot connect to the network. In this scenario, a teacher should be getting an IP address on the 192.168.8.0/24 network. A quick check determines that the teacher is connected to the proper SSID, however the teacher receives an automatic private IP address (APIPA) in the 169.254.0.0 – 169.254.255.255 range. This would be your first indication that the problem is most likely a wired-side network problem.
HiveManager can be used to constantly monitor all clients and maintain a “client health score” which indicates the status, or health, of a client's wireless activity, network connectivity, and service support for client applications. The IP network score is based on whether a wireless client can successfully obtain its network settings from a DHCP server. As shown in Figure 2, notice that the “Radio Health” has a score of 100 points—which means the problem is not the Wi-Fi Network. However, if a client cannot obtain an IP address from a DHCP server—it receives a score of 0 points for “Network Health” which is another indicator that the problem is on the wired network.
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 8 (the Teacher VLAN) failed.
So exactly how does VLAN Probe work? As shown in Figure 4, VLAN 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 could also be a point of failure. The scopes might not be configured or the server could 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 or they might not be tagged in the 802.1Q trunk port that the Aerohive AP in which the Aerohive AP has a wired connection.
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 VLAN Probe tool, an administrator can engage any Aerohive AP at any location to 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.