RedWarriorNet

One of the toughest things to wrap your head around when dealing with wireless is the sheer number of interfaces involved!  It can get really confusing trying to understand what interfaces are used for what, which are logical and which are physical, which are dynamic and which are static…yikes!

It’s important to remember that a wireless Access Point works as a bridge between the wired and wireless networks.  This inherently means that you will have at least 2 interfaces, one for each network, a radio interface for the wireless network and an ethernet interface for the wired network.  Most AP’s, however, actually have 2 radios built in to them, so that adds another radio interface right off the bat.  These are the physical interfaces and they are also static, meaning that you really can’t get rid of them.  You can disable them, but they are still there.

Ok, here is where things can get tricky.  Each SSID is actually considered an interface on the WLAN.  On the AP itself these are each tied to a subinterface on a radio and on the wired LAN, they correspond to a VLAN interface.  Here is an example.  Say I want to create an SSID called GuestAccess.  I would need to define that SSID on the AP along with security parameters for it, then I would have to create a subinterface for the radio I would want to use for that SSID.  It’s not necessary to choose a particular number for that SSID, but it is considered good practice to use the same number that you plan on using for the VLAN on the wired network that will correspond to that WLAN.  (Using a separate VLAN for each SSID on the wired network helps keep traffic from each SSID separate from other traffic, which is particularly nice when you configure an SSID for guest access.)  So, if I plan on using vlan 84 for GuestAccess, I would probably configure a subinterface on interface dot11radio0 of dot11radio0.84.   It just makes it easier to find.

I still have to configure a bridge interface that will allow me to be able to connect to the AP and allow bridging between the wired and wireless networks.  This is called a BVI interface and I give it whatever IP address I would like to use to manage the AP.  It is important to note that my ethernet interface and all the subinterfaces (there will be one for each SSID to match the subinterfaces on the radio interface) don’t get IP addresses.  My bridge interface is my only interface that needs an IP.

As I mentioned, I will need a subinterface on my ethernet interface to match the subinterfaces I have created on the wireless side.  Without this, all my wireless frames will not have a way to go out to the wired network.  For me, it helps to think of this as similar to a “router on a stick” configuration where you create virtual subinterfaces on a router to route VLAN’s.  In the case of my example, to keep things neat and tidy, I’d create a subineterface on my ethernet0 interface of ethernet0.84.  The actual numbering of the interfaces does matter in that the subinterface for the radio interface and the ethernet interface do have to match.  My AP is configured now!  I’d still have to make sure that vlan 84 is on my wired network and has a route point configured with a vlan interface for it.  I’d also have to set up a dhcp server for that network and configure security and authentication.

All that was for an autonomous AP.  If I have a lightweight infrastructure, all this can be done either from the WLAN controller or from WCS.  In this case, I define the SSID and WLAN on the controller or in WCS then I can choose which AP’s will be able to offer this SSID.  This is nice because I only have to go through the configuration of the VLAN and the SSID and I only have to do it once.  Once I choose which AP’s will be allowed to have this SSID, the controller or WCS configures all the associated interfaces on the AP’s for me!   Sweet!

As you can see, a wireless network has a whole lot of interfaces in play.  It becomes very important, particularly when troubleshooting, to know what each is and how to use them!

Roaming…it’s a huge reason to deploy a wireless network and it’s also the part you spend troubleshooting the most.  As I’ve said before, it’s easy to just set up an Access Point to serve a small area like a conference room.  Setting it up so users can walk from that conference room through the building and never lose connection?  Not so easy.  Making them able to do that?  Priceless.  Roaming is how we do that and in larger environments, say a hospital with 5 or 6 buildings in its campus, layer 3 roaming is even necessary.

CCNA-Wireless only seems to cover lightweight infrastructure deployments…at least so far in my studies.  Where I work we have both autonomous and lightweight deployments and we’re working to upgrade and transition them all to lightweight.  The differences between the way the two are set up are huge and almost seem to be more than what they have in common.  The biggest and most important difference is that in an autonomous infrastructure, much more work is done on the Access Point itself.  For roaming in this kind of environment, we’re dependent on a device called a WLSM, which is a blade in our 6509 switches.  This serves as a Wireless Domain Manager.  Wireless domains exist in both autonomous and lightweight infrastructures and are similar in concept to any other domain…they are a logical grouping within which clients can roam.  In the case of lightweight, a wireless domain is called a mobility domain and is a logical group of WLAN controllers that may or may not be in the same mobility group.  In the case of autonomous, this logical group is comprised of AP’s which may or may not be in the same subnet.

A good real-world example would be that hospital again.  In this case, all the buildings would belong to the same mobility domain while each individual building could be in its own mobility group.  A user walking from one floor in the same building to another would most likely just perform layer 2 roaming, which takes 10ms or less.  They may remain on the same WLAN controller or might move to another controller, but from the user’s perspective, nothing happens.  They simply walk along from AP to AP without having to reauthenticate and without having to change IP address because the controllers keep track of them and are aware they are already authenticated.  In the case of an autonomous infrastructure, it is the WLSM that keeps track of clients in a mobility table.  The WLSM depends on the AP’s to tell it of clients that associate with them.  It puts the client’s MAC address and the MAC address of the AP in its mobility table.  Then things get complicated…the WLSM has no way of knowing layer 3 information *except* by overhearing it.  In our case, the switch the WLSM is installed in uses something called “dhcp snooping” to listen in to dhcp messages going to and from the wireless clients.  It uses this information to keep track of IP addresses given to the clients and adds those addresses to the mobility table.

As I said, things get interesting when clients do layer 3 roaming.  In our example, this would happen when our user decides to leave their building, but need to keep connection as they move from one building to another.  Say that user is on a wireless VoIP phone and they are walking from one building to another.  The same SSID exists on the AP’s in each building, but in each building that SSID is tied to a different subnet since the buildings are in different networks.  In both lightweight and autonomous infrastructures, the preparation for them to roam was made the moment they connected to their first AP back in the building they began in.  For lightweight, the controller that they first registered with marked their entry as an “anchor” entry and then informed all other controllers about it.  The other controllers, including those in the other buildings, mark this entry as “foreign,” but are aware of it.  In an autonomous implementation, an entry was made for them in the WLSM’s mobility table with their MAC address, the MAC address of the AP they connected to, and the IP address they were given which was learned via dhcp snooping.  The client is ready to roam just as soon as they have connected.

*When* the client roams to another building, in a lightweight infrastructure, the controllers note that the client has moved and all traffic to and from that client is sent by the controller of the building they have roamed to back to their anchor controller to be tunneled to the client.  The client keeps their same IP address even though they are physically on a different network and it works similar to a GRE tunnel, with traffic routed to that original IP regardless of where the client roams to.  You can even force clients to be anchored to a specific network if you like.  Things aren’t quite as nice and neat in an autonomous infrastructure.  There, the client does have to get a new IP address, but they do not have to re-authenticate.  The WLSM keeps track of the client and knows that the client is authenticated.  The client does lose connection for a couple of pings while they get a new dhcp address, but the process is a lot quicker than it would be without the WLSM.  Generally, only VoIP clients notice the loss of pings, while laptop users may not even notice that they are obtaining a new IP address.  Once the client has roamed, the mobility table is updated with their new information.  In the lightweight scenario, there is no new information to update as the client remains tied to their anchor entry on the controller they are anchored to.

If all this sounds complicated…that’s because it is.  Roaming allows wireless clients mobility and is the goal of a wireless LAN.  It is also the most frequent thing to break on a wireless network.  Most of the work I have done as a WLAN administrator has been to troubleshoot issues with layer 3 roaming.  A big part of the problem is that so many different problems on the infrastructure side can show up with the same symptom on the client side.  For a user, they either connect or they don’t.  Wireless either works or it doesn’t.  They don’t realize there are so many stages they have to go through in order to connect and then in order to roam and that a problem can happen at any one of those stages.  This can make troubleshooting a WLAN challenging since you may not get much more information than “user can’t connect” or “user keeps disconnecting.”  Even worse, no matter how many problems you fix, the users will have the impression that you haven’t done anything until you have fixed everything.  When it all works, though…it is golden.