When wireless LAN (WLAN) users experience connectivity trouble, the problem may lie on the client side or the network side. An earlier tip discusses troubleshooting client side WLAN issues. In this tip, I discuss how to troubleshoot connectivity problems that stem from issues associated with the network side of the WLAN solution. This article will focus on potentially troublesome areas an admin will want to consider when troubleshooting WLAN connectivity: the access point (AP), the LAN, the authentication server, and routing aspects.
Access points
The network side of a WLAN solution consists of the APs to which the users connect, the controllers behind the APs (or intelligent APs), Layer 2 LAN switches the APs connect to, authentication servers, routers, and the protocols in use among all of these elements. All of the elements have to be configured properly in order for the user to connect to the WLAN infrastructure and for data to be transmitted successfully over that connection. Before continuing, I should mention that some WLAN solutions utilize controllers (boxes that control the APs), whereas others have the intelligence built into the APs themselves. These are commonly referred to as "thin client" (controller-based) and "fat client" (intelligent APs). For the purposes of this discussion, I am going to focus on general networking aspects rather than specific troubleshooting techniques associated with thin- or fat-client solutions.
Layer 2 and LAN issues
Let's start with Layer 2. Each AP must physically connect to a LAN switch and reside in a VLAN. These can be single-port connections (one VLAN) or trunk connections (multiple VLANs). Either way, this is the first place to begin troubleshooting. Log on to the switch and see whether the switch port the AP is plugged into recognizes that an AP is connected. On Cisco switches you can use the "show...
To continue reading for free, register below or login
To read more you must become a member of SearchCIO-Midmarket.com
port" or "show trunk" command to see whether the switch recognizes the AP. Another command you can use to verify that the switch sees the AP's MAC address is "show mac-address-table." The configurations on the switch must match the configurations on the AP as it relates to VLANs and trunk settings. This is a common oversight.
Routing
Secondary to the Layer 2 LAN/VLAN is the routing of the traffic. In most cases, the APs reside on one VLAN, the authentication servers reside on another, and DHCP servers reside on yet another. In order to communicate across VLANs, the traffic must be routed. In most cases, this requires adding the WLAN VLANs to the router interfaces. This is usually a virtual interface on a route processor (in Cisco's case, the MSFC). Once the interface is added, configured and enabled, you should log on to a router (preferably one that has the routes to the DNS server and the authentication server) and ping the AP from the router. If this is successful, you can assume that the route is being advertised properly.
Each time you connect to an AP you must put in an SSID. The SSID puts you into a VLAN from which IP addresses and such are assigned. For example, you may have a "guest" SSID and an "employee" SSID. These would need to be in separate VLAN's to segment the traffic. Each of the WLAN VLANs -- guest and employee -- would have a VLAN interface on the switch and the router.
Authentication
The next area to focus on is the authentication server. While authentication can be handled in a multitude of ways (including Active Directory and Windows authentication), the most common mechanism is to use a RADIUS server. The RADIUS server must contain usernames and passwords (or point to databases that store these, such as LDAP, AD and Windows) that map to the usernames and passwords configured on the client WLAN cards.
Remember that there is network association (SSID), then authentication, then encryption. If the WLAN is using 802.1x, the AP and the RADIUS server will most likely perform a network authentication. This means that a matching password must be configured on the AP and the RADIUS server. If there is a mismatch, it will not matter if the client and RADIUS server match.
That's the basics, but these common oversights lead to many WLAN communication problems. A best practice is to get the WLAN working and document everything so that changes and modifications can easily be identified and rectified. Instituting some form of change control (a process to track and institute network changes) can also be very beneficial in preventing a necessary change from affecting other areas of the network.
Robbie Harrell (CCIE#3873) is the National Practice Lead for Advanced Infrastructure Solutions for SBC Communications. He has more than 10 years of experience providing strategic, business and technical consulting services. Robbie lives in Atlanta and is a graduate of Clemson University. His background includes positions as a principal architect at International Network Services, Lucent, Frontway and Callisma.
