RedWarriorNet

I was very, very sick for about a week, which threw my exam preparations into disarray, but now I’m back to studying and I have scheduled my exam for next monday morning.  I’m feeling pretty confident about the material and I’m thinking it will be a great feeling to be 75% done with my CCNP and ready to move on to routing with my last exam, BSCI.  I hope to have my CCNP all wrapped up by the end of the summer and be ready to refocus my studies back on wireless.

I am thinking that, for me, next year will be the year of wireless.  I hope to face again my nemesis, the CCNA Wireless, and defeat it, and then probably move on to the new professional level wireless certification that Cisco is rolling out this summer.  I am considering also trying to work in one or two of the CWNP vendor-neutral wireless certifications along the way.  Wireless is a big part of my current job and I support both autonomous and lightweight Cisco networks and we have the possibility of adding another network made up of a third party vendor’s gear later this year.  That is a lot of wireless to take care of and there are only 2 engineers in our company specializing in wireless, which is a big deal in our particular market, particularly as RFID applications grow.

There’s just so much to learn and so little time.

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.  

I can just barely remember in High School Physics class learning about the “Wave-Particle Duality of Nature” and thinking how cool it would be to calculate my own frequency and wavelength.  Studying RF is a lot like that.  There is a whole world around us that makes much of what we do possible that we never see or even think about.  Waves.  Without them, we wouldn’t see, our muscles would not move, we would not hear, and we certainly would not be able to nuke some Mac n’ Cheese.  Waves, whether electrical, radiation, sound, or light, waves make it all possible.

I find it somewhat amusing whenever people talk about worrying about the amount of RF that people are now being exposed to by wireless.  When you look at the entire amount of waveforms that our bodies are subjected to on a daily basis even if we run out into the wilderness away from all technology in a cellular dead zone where we can’t get TV signals or a decent radio station, the amount of RF that we are exposed to by wireless networks seems pretty small.  Much more dangerous are the light waves, particularly in the Ultra-violet spectrum, that we so willingly subject ourselves to in pursuit of a tan or the concentrated sound waves that we ram into our eardrums when we plug our earbuds into our ipods for the latest track from our favorite artist.

One of the things you quickly learn dealing with RF as it pertains to wireless networks, is how easily these waves are actually disrupted.  Basically anything that could muffle sound waves will absorb RF waves as well, wreaking havoc with the coverage you are trying to achieve.  Even worse, since the frequencies used for wireless networks are unlicensed, there’s already many, many devices that transmit in those frequencies and they will interfere with your signals.  Bluetooth interferes…microwaves…cordless phones…the goodyear blimp, even.  (It interferes with b/g frequencies, in case you’re curious.)  It’s like there are enemies to your signals lurking behind every corner.  Then there’s the building itself.  Carpet and walls absorb the signals, glass, mirrors, and shiny floors reflect the signals, even dust and humidity can and do wreak havoc.  It’s just not a friendly world for wireless.

Considering how wimpy these RF waves are and how easily they are blocked, absorbed, and reflected, I don’t think we’ll see much harm come from having them around…particularly since we have been using the same unlicensed frequencies for other uses pretty much since they were opened up for use.

Back to the books I go!  I bought a cool new tea infuser for work which came with 5 free little tins of different types of tea, so I’ve had my own little zen cube thing going this week.  Sipping green tea or chamomile certainly helps take the edge off studying and working!