A New Home

I’ve staked a claim to a new domain name for my blog and a new hosting service to host it.  You can now find my latest posts at www.redwarriornet.com, where I will be adding more content.

Thank you for visiting!

Cisco Says, “No PBR for You, We’re Going with Miller Lite…”

I just found out through working with a TAC Engineer on an issue where our brand spanking new Catalyst 4900M won’t accept the command to place a Policy Based Route map on a vlan interface that PBR will not be supported until an upcoming IOS release, most likely in June.   Ugh.  This is not the first weirdness we’ve had with our 4900M’s.  The first was with one of the 4900M’s we have deployed in our new datacenter core.  This switch displayed some weird behavior when we were troubleshooting what appeared to be an issue with a fiber uplink in a twingig module we had plugged into one of the ten-gigabit ports.  We shuffled around some known-good GBICs in these twingigs and next thing we knew, the ports had error-disabled due a Cisco “feature” that keeps you from using illegal hardware, giving us an error of “Unapproved GBIC” in the output of a show interface status.  A reboot got us our ports back, but to this day one of the ports still shows that error even though it works and TAC hasn’t been able to help us be rid of it.  Apparently, on most of the higher-end switches, the database that keeps track of GBIC serial numbers times out entries after a certain period so that you can reuse a GBIC from one module in the switch to another without much trouble…in the 4900M’s they have yet to perfect this.

Don’t get me wrong, the 4900M’s are definitely good hardware and allow you to double your port density in modules you don’t want to use TenGigabit in by using the twingig modules that give you 2 1Gig ports instead, while still giving you the option down the road of using half as many tengigabit ports.  That can be a very handy feature when combined with the port density they already have and is the reason we have 4 of them in the core of our datacenter.  I just wish Cisco had worked out a few more kinks before releasing them.

But enough complaining…it’s good to have job security in these uncertain times!  My BCMSN studies are coming along well and I’m up to chapter 8 in the self-study guide.  That doesn’t sound like much, but the self-study guide’s chapters are all pretty meaty.  I also managed to watch 4 hours straight of CBT Nuggets this weekend before needing a nap.  My lab setup is almost finished and I hope to get it accessible from my desk as soon as there is a lull in the datacenter cabling.  Until then, I hope to keep pushing on my reading.  I’ve already really enjoyed some of the information on MST, which allows you to combine multiple instances of spanning tree into one instance, saving resources and allowing you to more easily use redundant links for load-balancing instead of just leaving them in blocking.  I’ve also really enjoyed the section on etherchannel, particularly doing more sophisticated load-balancing over multiple etherchannel links.

Back to BCMSN!

Well, I have survived both the first part of the data center move as well as the first game of the softball season, so I am ready for a new exam to study for.  I am going next for the BCMSN and I received my copy of the BCMSN self-study guide from Cisco Press.  It’s definitely the heftiest of my Cisco books right now, even outweighing Routing TCP/IP vol 1.  I’ve just started digging into the first chapter and already, from judging the table of contents, I’m wishing I’d read this one about 6 months ago!  There is an entire chapter on dhcp snooping, something which was giving me fits at one of our autonomous wireless sites a few months ago.  It would have been easier then if I’d been familiar with the concept of dhcp snooping.  Oh well!  I always feel like I’m 1 exam behind what I’m doing at work.

This ought to be a great exam for me to study for right now.  We don’t have many routers in our enterprise, but mostly rely on big layer 3 switches.  We use HSRP heavily and have rapid-spanning tree implemented.  These are all things I’ve worked with in practice but never had the time to dig deeper into how they actually work.  My studies for the CCNA-Wireless ought to also make the wireless portion of this exam a little easier to handle and I’m thinking that having already taken the ONT will help with the QoS portion.  There really is a good amount of overlap in some sections of these exams, which might be why everyone thinks their last 1 or 2 CCNP exams are the easiest of the bunch.

This weekend is all about resting up and relaxing.  I’m planning to do some reading, some grilling, and maybe playing catch with the family, but nothing hardcore.  The past 2 weeks have involved a lot of physical work in the datacenter installing switches, running cables, and labeling the heck out of everything.  The payoff is a brand new datacenter with a 10 gig backbone which hopefully will lead to fewer calls of “application slowness” when I’m on call!

Where Have I been?

I’ve been in a data center…climbing racks, crawling under the floor and generally getting good and messy.  The company I work for is rolling out a brand new, 80-rack data center.  It’s  a pretty exciting…and exhausting project to be a part of.  So far I’ve learned a ton of tricks to dressing cables, labeled more cables than I care to remember, and gotten to install and configure ten gigabit interfaces.

I will be uploading my CCNA-Wireless study guide this week and I will be starting my BCMSN studies this weekend.  I’m excited to dig into some rapid-spanning tree after installing all these switches!  

Wireless Interface Madness!!!

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!

Oh Give Me a Home, Where the Wireless Clients Roam…

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.  

Waves, Waves, everywhere there’s Waves!

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!