Wired and Wireless QoS translations

It has been difficult for me to locate good QoS references in the past...  So at some point, I put together the following cheat sheet which will hopefully help others as well.  It's based on my interpretation of the current Cisco best practices, and since I do not work directly for Cisco - it's a bit of conjecture on my part.  Still, it seems to line up well and has not yet steered me wrong.

So, without further ado:

Wired to Wireless QoS Mappings

Cisco AVVID 802.1p UP-Based Traffic Type	Cisco AVVID IP DSCP	Cisco AVVID 802.1p UP	IEEE 802.11e UP (WMM AC)	Notes
Network Control	-	7	-	Reserved for network control only
Inter-Network Control	54	6	7 (AC_VO)	CAPWAP control WLC: Platinum QoS profile
Voice	46 (EF)	5	6 (AC_VO)	WLC: Platinum QoS profile
Video	32 (CS4)	4	5 (AC_VI)	WLC: Gold QoS profile
Voice Control	24 (CS3)	3	4 (AC_VI)	WLC: Gold QoS profile
Best Effort	0 (BE)	0	3 (AC_BE)	WLC: Silver QoS profile
			0 (AC_BE)
Background (Cisco AVVID Gold Background)	16 (CS2)	2	2 (AC_BK)	WLC: Bronze QoS profile
Background (Cisco AVVID Silver Background)	8 (CS1)	1	1 (AC_BK)	WLC: Bronze QoS profile

CWNA

On Monday, I passed the CWNA (PW0-105) exam.

While I have decided to sit out v2 of the CCIE Wireless, I do not want my skills to atrophy completely.  I had considered focusing on CCNP Wireless, but since most of my certifications are Cisco-oriented, and since I had passed CCIE Written, it seemed to me like looking at 802.11 from a different perspective was a good idea.

CCIE Wireless is focused mostly on configuration.  This makes sense - the exam is designed to ensure you know Cisco's product inside and out, which means understanding their interpretation of the 802.11 protocol.  The best way to do demonstrate this is to prove that you know all the nuances of configuring their equipment.

CWNP has a different focus, though, since it is a vendor-neutral certification.  Their focus is more on ensuring that candidates have a solid understanding of the RF characteristics that underlie the vendor's implementation of 802.11.  I am hoping that by developing a better understanding of RF, I can gain valuable insight into understanding why Cisco approaches it from their perspective - and effectively gain a better knowledge of their product.

I still have the goal of reaching CCIE Wireless.  I'm just taking a less direct approach to it at this point.

Next on my radar - CWDP!

Wireless Timeout Settings

It's been over a year since my last blog post...  Not good.

I'm back again, however, listing some of the timeout settings that can cause issues on WLANs.  There are five infrastructure timeout values that may affect users who connect to a WLAN, depending on how and where they are connecting.  These are:

1.       Arp Time to Live

Deletes ARP entries on the WLC for the devices learned from the network.  Increasing this timeout increases the CPU load and distorts statistics for the number of simultaneous users.  The default value is 300 seconds (5 minutes).  The command applies to all WLANs on the WLC.  Configured at Controller > General > ARP Timeout.

2.      Session Timeout

When a user is idle without any communication with the LAP for the amount of time set as User Idle Timeout, the client is de-authenticated by the WLC. The client has to re-authenticate and re-associate to the WLC. It is used in situations where a client can drop out from its associated LAP without notifying the LAP. This can occur if the battery goes dead on the client or the client associates move away. Increasing the user idle timeout utilizes more RAM on the WLC and will make the WLC client database less accurate.  Default is 300 seconds (5 minutes).  The command is specified per WLAN.  Configure at WLANs > WLAN ID > Advanced > Enable Session Timeout.

3.      User Idle Timeout

This setting is the maximum time for a client session with the WLC. After this time, WLC de-authenticates the client, and the client goes through the whole authentication (re-authentication) process again. This is a part of a security precaution to rotate the encryption keys. Increasing the user idle timeout utilizes more RAM on the WLC and will make the WLC client database less accurate.  Default is 1800 seconds (30 minutes).  The command applies globally to the WLC.  Configured at Controller > General > User Idle Timeout.

4.      Broadcast Key Interval

When a user connects to the WLAN, they receive a broadcast key.  If 802.1x authentication is in place, this key allows for encryption of broadcast/multicast traffic to the client.  Increasing the timer has a slightly detrimental effect on WLAN security, as a nefarious user who manages to decrypt the key would gain access to a larger data set.  Default is 3600 seconds (1 hour).  This setting applies to all WLANs on the WLC.  Configured via CLI: config advanced eap bcast-key-interval x, where x is a value between 120 and 86400.

5.      DHCP Lease Time

The DHCP lease specifies the amount of time a given client may utilize a dynamically assigned IP address.  Increasing the value can create DHCP scope depletion, where all IP addresses in the scope are assigned to clients even though those clients are no longer active on the network.   Default on Cisco routers/switches is 1 day.  This applies to all clients on the scope.

In addition, other timeouts need to be considered:

6.      Device Timeout

All WLAN client devices have their own settings for determining when and how to disassociate from a WLAN or disable their wNIC.  This is normally done to conserve battery power and/or increase device security.  These default values are device-dependent.

7.      Other Timeouts

There are many other timeout values that can affect the wireless user experience.  Among these are VPN timers, RADIUS timeout values (when utilizing 802.1x), and various client application settings (browser timeouts, sleep settings, power settings, etc.).  Determining the exact cause of a timeout for a specific group of users may require consideration of these values.

CCIE Wireless v2

I had made 5 attempts and spent 2 years studying for CCIE Wireless v1.  On November 17, 2011 Cisco retired this version of the lab and moved on to v2.

I needed a break to determine where I was, both on a personal and professional level.  It's very disappointing to have spent 4+ hours a day in study and not bear the fruit of that effort.  A lot in my life has changed since I began this journey and I was not quite sure that I was ready to put myself through all of the challenges again.  Things are starting to come together again for me though, and I sense an attempt at CCIE Wireless v2 in the future.

Here's a list of things I have done to help myself prepare for a possible shot at the new test:

First, I wanted to gather some training material.  I had used material from both Fast Lane and IP Expert in studying for v1.  They both are excellent sources of what to study for the exam, but I like the pedagogical approach from Fast Lane better so I started with purchasing their program for v2 (I plan to buy IP Expert as well when $ permits):

CCIEW-MENT
CCIEW-WBP1

For more information on either of these, visit the Fast Lane website:

 www.fastlaneus.com

With the new workbook in hand, I started building out my lab.  At this point, my lab consists mainly of my equipment from v1 - although I have a new PC for running ACS 5.2.  I spent literally 50% of my time studying for v1 troubleshooting my virtual ACS (running in VMWare Server on a Win 2000 box) so I am hoping to have better luck this time around...  Having an independent computer shouldn't hurt.

So here's my current setup for the ACS 5.2 box:

Dell Latitude E6400 running Ubuntu 11.10, VMWare Player v 4.0.2

Installing VMWare Player was a bit onerous - the following website provided the instructions I couldn't find elsewhere:

http://askubuntu.com/questions/101139/how-to-install-vmware-player-4-0-2

Next, I used this blog as a guideline for installing ACS 5.2:

http://blog.sudonetworks.com/2010/10/installing-cisco-acs-52-on-a-laptop.html

That's it for now - I'm off to upgrade the IOS on all my equipment.

Kara Muessig Passes CCIE Wireless!!!

Just a quick note that on July 7th one of my study partners passed the CCIE Wireless Lab.  Kara Muessig was the first female to pass the CCIE Wireless, and one of the first 50 people to have achieved the certification.

Great job, Kara!

Mobility

Settings that must be configured identically to allow wireless mobility between controllers:

LWAPP Transport Mode (layer 2 or layer 3)
config switchconfig mode {L2|L3}

Virtual IP
config interface address virtual 1.1.1.1

Mobility Tunneling Mode (symmetric or asymmetric)
config mobility symmetric-tunneling {enable|disable}

Mobility Security Mode
config mobility secure-mode {enable|disable}

DHCP Proxy
config dhcp proxy {enable|disable}

WLAN
All parameters for the WLAN should be identical (other than security settings), including the WLAN numbering on the WLCs in the mobility group.

Beacon Period commands on Autonomous APs

Time for another post!

I'm hard at work looking at some more autonomous AP commands.  This time it's beacon periods!  So, on an AAP, how would you configure the beacon period to 100 milliseconds?

One would be tempted to look under the radio interface:

"ap#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
ap(config)#int d0
ap(config-if)#beac ?
  dtim-period  dtim period
  period       beacon period

ap(config-if)#beac per ?
  <20-4000>  Kusec (or msec)"


What's that, you've never heard of Kusec before?!  Where have you been?


I looked it up, and apparently Kusec is a kilomicrosecond...  And what, exactly, is that?  1.024 ms.  So now, to set your AP beacon period to 100 milliseconds you are forced to do a bit of math:


100 ms / 1.024 = 97.66 Kusec.


What about the DTIM period?  That's a bit easier - just the number of beacons to wait before multicast traffic is transmitted.