I have to keep reminding myself that Extreme employees, customers, and partners might not be familiar with some of the legacy capabilities of ExtremeCloud™ IQ that I have long taken for granted. One prime example is the VLAN Probe diagnostic utility that I have been using for almost ten years. As with communications network, problems with Wi-Fi networks arise that might require attention from an administrator. Wi-Fi operates at layers 1 and 2 of the OSI model, and therefore, a network administrator should concentrate on those two layers when troubleshooting Wi-Fi problems. If you can determine the problem does not exist at layers 1 nor 2, then the problem is not a Wi-Fi problem. Therefore, upper-layer troubleshooting may still be a necessity.
Wireless networks very often get blamed for causing problems that exist in the wired network at higher layers. If an employee cannot connect to the corporate Wi-Fi network, the employee blames the Wi-Fi even though the actual problem is somewhere else on the corporate network. If you validate that the problem is not a layer 1 or layer 2 problem, then the problem is usually a networking issue or problems with an application.
A typical support call is that a user calls and complains that they have a Wi-Fi connection but cannot connect to the network. If you have already determined that the problem is not a Wi-Fi problem, move up the OSI stack to layer 3 to check for IP connectivity.
Consider the diagram of a school WLAN shown in Figure 1. An AP is deployed in a school and is transmitting three SSIDS, one each for teachers, students, and guests. The student SSID is mapped to VLAN 2; the teacher SSID is mapped to VLAN 4, and the guest SSID is mapped to VLAN 5. The management interface of the AP is mapped to VLAN 1. All four VLANs are tagged across an 802.1Q trunk between the 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.
As previously mentioned, a common support call is that a user complains 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 10.104.56.0/24 network. A quick check-in the Client 360 view in ExtremeCloud™ IQ determines that the student connected to the proper SSID; however, the student received an automatic private IP address (APIPA) in the 169.254.0.0–169.254.255.255 range, or no IP address at all (0.0.0.0). As shown in Figure 2, this would be your first indication that the problem is most likely a wired-side network problem.
The next step is to employ the VLAN Probe diagnostic tool available in ExtremeCloud™ IQ. VLAN Probe reports if VLANs are operational on the wired network as well as the subnet of each VLAN. As shown in Figure 3, an administrator can select an AP to perform a probe across a designated range of VLANs. Please note that VLAN 4 (the student VLAN) failed.
VLAN Probe leverages the ability of the management interface of any access point to send out DHCP requests, as shown in Figure 4. Once the probe starts, the management interface of the AP sends 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 AP. The management interface of the AP does not need another IP address; therefore, a NAK is sent back to the DHCP server. If the DHCP lease offer reaches the AP, then there is not an issue with the wired network. However, if the DHCP lease offer does not reach the AP, then there is absolutely a wired-side problem, and the diagnostic probe displays a negative result.
As shown in Figure 5, two common points of failure are the upstream router and 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 are improperly 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 90 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 might have been misconfigured as an access port.
VLAN Probe is wildly popular with both Extreme customers and partners alike. Using the ExtremeCloud™ IQ VLAN Probe tool, an administrator can manage any 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.