A blog with tips, tricks and tutorials to help you prepare your CCIE Wireless lab exam.

Wednesday, August 19, 2009

Secure Web Authentication

When you create a Web Authentication WLAN on your controller, users authenticate (open), associate, receive an IP address, then get blocked until they open a browser. The DNS query they initiate goes through the controller, and upon receiving the DNS answer, the controller redirects the user to the Web Authentication page, were credentials have to be entered...
It is this last part that I was looking at a few days ago... how are these credentials exchanged between the controller and the client? Post? Pull?
Actually the process is a PAP! When you enter the username and password, the username and password pair is sent over the air with a PAP Access Request message.
The controller validates the username and password pair, from a local list or through a RADIUS server, and grants (or refuses) access. Of course, PAP is a very weak protocol, and you might have jumped on chair while reading this... so is this process so weak that anyone could eavesdrop and read the sent username and password?
Not really, look at this capture of such an exchange. Client is 10.1.1.57 and Virtual gateway 1.1.1.1:



As you might have guessed, the process occurs via HTTPS, so the user credentials are protected by the TLS session... not very easy to hack.
Nevertheless, you could argue that if you were to sniff the exchange, you might be able to break it offline, and that PAP is therefore bad.

Okay, not a problem. You can replace PAP with CHAP. With CHAP, the username is sent through the TLS tunnel, and then the RADIUS or the controller returns a challenge. The client browser encrypts the challenge with the password, and sends the result back. The controller (or RADIUS) does the same on its side. If both results are the same, both sides used the same password and the authentication is successful without the password having been sent.
How do you change Web authentication from PAP to CHAP? Strangely enough, in Controller > General.


The controller natively supports these three modes. If you use an external RADIUS server, make sure it supports them. ACS supports both PAP and CHAP (but not MD5-CHAP as far as I know).

Friday, August 14, 2009

802.11h Parameters

If you are used to exploring your controller features and pages, you probably know this page, under Wireless > 802.11a > DFS (802.11h). It is probably the page that generates most questions when I teach the Cisco Wireless Mesh classes, as 802.11h is often not well understood.



802.11h is part of the 802.11-2007 specification. Many airport radars use the UNII-2 and UNII-2 frequency ranges (channels 52 to 140). Any 802.11 equipment operating in this frequency range is supposed to be able to detect these airport radar signals and move away so that the radars can operate safely without our APs interference. This process is called DFS, Dynamic Frequency Selection.

I have never seen any airport radar actually using these frequencies to land planes. They have plenty of other frequencies for that. The UNII-2 and UNII-2 extended are more commonly used for weather reporting. The worst I saw was a radar reporting snow in a hot summer due to an AP interference... but the AP had an amplifier, a directional antenna and was pointing directly at the radar. This was experimental more than anything else. In most cases, your AP is too weak to disturb a radar. The 802.11h still rules that if your AP detects a radar blast, it has to move to another frequency. The process is as follows:
- Your AP, operating on any of the UNII-2 or UNII-2 extended channels, receives a blast from a radar. The AP recognizes this signal as a blast, because the AP is used to performing Radar Detection Measurements, through which it can recognize several typical "radar blast patterns", such as "pulses of identical power, 1 microsecond wide, with a frequency of 700 pulses per second, with blasts of 26 milliseconds each". This description is just an example. The 802.11h protocol actually states that has to be considered as a radar blast any signal in these frequencies stronger than -61 dBm at the Ap level, and that the AP "cannot prove not to be radar blasts". In other words, if you don't know what it is, it's a radar blast.
- From this instant, your AP has 10 seconds to move to another channel. This is called the channel move time.
- During these 10 seconds, your AP has a lot to do! It must find another channel to jump to. In a controller based solution, the controller picks up a random new channel (among the list of allowed channels) and sends it to the AP.
- The AP jumps to the new channel, and silently listens for 60 seconds. Its aim is to detect any radar blast on this new frequency (in which case the AP changes channel again). If the new frequency is quiet, the AP resumes its conversations after this 60 second period. This is called the Channel Availability Check Time.
- Radars do not always use the same frequencies. They try to detect a certain weather pattern at a certain distance, for which a specific frequency is more efficient. As the weather usually does not change every minutes, radars typically use a frequency for a little while (until they get a clear picture of the weather trends reported in this frequency), then leave the frequency. For this reason, when your AP leaves a channel, it blacklists the channel for 30 minutes. This is called Channel non-occupancy Period. After 30 minutes, if the AP has to change channel again, the previously blacklisted channel re-becomes part of the list of potential channels.

All this is well, but what about the clients? If the AP suddenly moves to another channel, clients will be disconnected!... and 60 seconds of Channel Availability Check Time? This is going to kill all sessions!
Well, there is another solution. The AP could check new channels... before blasts occur. In this mode, the AP leaves the main channel every now and then, and scan new channels. To avoid losing client frames while the AP is away, the AP can send a Channel Quiet 802.11 "action message", which is a beacon telling the clients in the cell not to send anything for a while (the while is defined in another beacon) while the AP is away. With this method, the AP would know about the new channels when the problem occurs, could jump to a new channel and immediately resume its conversations. This was the original mechanism, called In Service Monitoring (the AP scans while serving an active channel). But if you think about it, this may not be the most efficient method. First of all, the AP still needs to scan any new channel for a total of 60 seconds before being able to use it. How many times would this AP have to jump from its original channel to get 60 seconds worth of information on any new channel? Secondly, what guarantee does this mechanism offer? Even if a channel was seen as "free", a blast could occur any time (the channel on which the AP was previously transmitting was also "free" until it got a sudden blast). So this method might not be that better after all.

Verifying the new channel availability when needing to jump is probably more efficient, even if UDP connections might probably drop. TCP connections will probably just have their window slide down while asking for missing packets retransmission. This if the stations know that the AP is jumping, and to which channel! This is where the screenshot above plays its role. During the channel move time (the 10 second window), the AP is supposed to stop all communications, but this is not realistic. What about beacons, client frames, probes, etc.? The 802.11h mechanism allow a certain number of transmissions: 260 milliseconds. In other words, whatever the AP transmits during these 10 seconds, the total duration all these frames added together must not exceed 260 milliseconds worth of channel utilization. This is called the Channel Closing Transmission Time. Don't get it wrong. It is not one long message. The AP can send a few milliseconds worth of traffic, then stop, then send something else, etc. At the end of the 10 second window, the transmitted amount must be less than 260 milliseconds worth of channel utilization. So the AP is going to look carefully at what it can send. It is actually going to continue sending beacons (so that clients still detect the AP), and also answer probe requests (with probe responses). All other transmission is stopped: no data packet, no ACK. All wireless packets reaching the AP are silently dropped.
Wow, that's rough: clients send packets, never get any ACK, and after 10 seconds the AP disappears to a new, unknown, channel... and when they scan to find the AP, they won't hear anything from this AP for another 60 seconds! To make the all process smoother, you can check the Channel Announcement box. This makes that when the AP jumps to the new channel, it first sends an 802.11h Channel Announcement message, telling its client that it is jumping to another channel, and giving them the channel frequency. This allows the clients to jump along with the AP. They know that the AP has to stay silent for 60 seconds when getting to the new channel, but they can jump and wait (to a new, silent channel) for the AP to resume its communications. At least they know where the AP is, even if they do not hear it.
To be even nicer, you can check the Channel Quiet Mode box. This makes that the AP, upon entering the Channel Move Time window, sends a "Quiet Message" to its clients, in which it says "do not communicate". The clients know that they don't have the right to communicate, so you avoid this situation where they send packets that are never acknowledged (therefore retransmitted again and again in vain).

The upper section of the screen is about the second feature, TPC, Transmit Power Control. The 802.11h protocol states that the AP (and the wireless clients!) must be able to reduce its power level to the minimum value needed for its operation. In other words, if you are an access point, do not shout! You may disturb a neighboring radar. Reduce your power to be just loud enough to be heard by your clients, no more. The fine line is that the 802.11h protocol states that the AP must “be able to” reduce its power, not that it “has to” reduce its power. So most vendors implement the ability without forcing the behavior. But Cisco APs do implement it. The AP sends in its beacons a 802.11d value that sets the max power value for the local regulatory domain, and the 802.11h Power Constraint value tells the client (the other mesh APs in this case) by how much they should try to reduce their power below the local regulatory max. The controller can reduce the client -mesh-AP power with 802.11h (this is called Transmit Power Control, TPC, not to get mixed with Dynamic Transmit Power Control, which is a CCX feature by which an AP can as a client to be louder or quieter to improve the communication quality). To actually use the TPC, check the Power Constraint box. A new field allows you to set “how quieter” the client is expected to try to be. Keep in mind that - 3 dB is half the power, so every 3 dB allows the AP-client to reduce its power by half. A common value is 9 dB, allowing the AP-client to divide its power level by a factor of 8 (3 dB + 3 dB + 3 dB, which is power level divided by 2, then divided by 2 again, and divided by 2 another time). This starts from the local regulatory domain max value (not from the AP max value), and any value below the target is okay. So for example, if regulatory max is 30 dBm, and you set 9 dB in this field, your AP tells its clients to not go above 21 dBm, even if (still 'for example') your AP max power is 24 dBm.

Monday, August 10, 2009

Controller Admin password

When you create a WLC Management User, you define a password. What if you want to change this password later on? From the controller Web interface, the answer is... you can't. There is no option to "change" a local management user's password. You can delete the user, and re-create it with another password. Not always very handy.



From the CLI on the other hand, there is an easy command to change your management user password:
config mgmtuser password username new_password
For example:
config mgmtuser password admin2 mynewpass.
Easy and useful...

.

Sunday, August 9, 2009

Configure your LWAPP AP from the AP CLI

I had this case a couple of times and thought it might be useful for all of us... you know that the AP, upon booting, will try hard to discover a controller, using broadcast, pre-configuration (AP priming as they say) DHCP option 43, DNS, OTAP, etc.
Now my friend has an AP at home, and wants to use it to connect to its corporate network over his VPN link (my friend's router to the company VPN concentrator).
The AP is new, so there is no controller IP address the AP could remember from a previous life (AP priming).
There is no other AP around, so forget about OTAP.
My friend's network is small, so no option 43 or DNS that you can dream of.
Okay. Time to be creative... but Cisco thought about this case!
You can configure your AP directly from the CLI to provide information to it... boot the AP, get yourself a console connection, and try:
AP0023.0410.4aea#lwapp ap ?
controller lwapp primary controller
hostname Configure ap hostname
ip lwapp ap ip command
log-server Configure the syslog server where all LWAPP errors will be logged

As you can see, you can give your AP, in LWAPP mode, information about a controller:

AP0023.0410.4aea#lwapp ap controller ?
ip lwapp primary controller ip
AP0023.0410.4aea#lwapp ap controller ip
AP0023.0410.4aea#lwapp ap controller ip ?
address Configure primary Controller IP address
AP0023.0410.4aea#lwapp ap controller ip add
AP0023.0410.4aea#lwapp ap controller ip address ?
A.B.C.D Controller IP address
AP0023.0410.4aea#lwapp ap controller ip address 10.1.1.10

Done. You AP knows how to get to a controller (careful, if your AP is already connected to a controller, using this command does not make any sense anymore, and you get a nice "ERROR!!! Command is disabled" when you issue it).

You can also give some other information to your AP, such as AP hostname, or syslog IP address where to dump all issues that the AP might encounter while trying to get to your controller. A useful one is the AP IP address:

AP0023.0410.4aea#lwapp ap ip ?
address Configure ap static IP address
default-gateway Configure Default-gateway IP address

Configure both! The AP needs both to get out of the local network.

Once the AP is configured, you can use the show lwapp family of commands to check what is going on, such as the show lwapp ip config to check your AP IP details, or the show lwapp client config to check controller config and friends:

AP0023.0410.4aea#show lwapp client config
configMagicMark 0xF1E2D3C4
chkSumV2 46073
chkSumV1 17487
swVer 4.2.130.0
adminState ADMIN_ENABLED(1)
name AP0023.0410.4aea
location default location
group name
mwarName
mwarName
mwarName (these are the primary, secondary, tertiary controllers)
<.../...>
ApMode Local
Discovery Timer 10 secs
Heart Beat Timer 30 secs
Led State Enabled 1
<.../...>
Configured Switch 1 Addr 10.1.1.10
<.../...>

With this command, no more AP lost in the dark, far from its controller!

Thursday, August 6, 2009

Wireless Guest Access common issues

You probably know the Wireless Guest Access feature, by which wireless clients use a Web interface to enter credentials before being allowed to access the network. There are several common issues that you may be facing, and here a re a few suggested solutions...
First, let's verify the process:
Client detects the guest SSID, sends a Authentication request and receives an authentication success reply (authentication is typically open in this type of network).
Client sends an association request, and receives the association reply with AID, nothing special here.
At this stage, the client is associated and can send two types of traffic: DHCP and DNS (warning: except if you setup a preauthentication ACL! In this case, make sure that your ACL does allow DNS and DHCP traffic!). So the client can get an IP address, obtain DNS server information, open a Web browser and try to open an URL. Upon doing so, the DNS server is queried to resolve the URL IP address. Upon seeing the DNS answer, the controller redirects the browser to the authentication page.

In a real or lab network, you may face several issues:

1. No DNS server. Your network is internal, and not DNS server is available to resolve the URLs. Of course, if no DNS server can be queried by your client, the process stops and the Web browser returns a "Cannot open page" message, as the browser does not know how to get to the URL you ask.
Two solutions here:
- Ask your clients to open directly the Web authentication page, typically in the form https://1.1.1.1/login.html.
- Play with your client hosts file! If your client is a Windows client, this file is located under %windir%\system32\drivers\etc\. In Linux, it is typically under /etc. The hosts files contains the DNS entries that your client can know without asking an external DNS server. Insert a line in this file in the form "1.1.1.1 https://mynicepage.com", then ask your clients to use mynicepage.com/login.html as their default page.

2. Special port: you want to authenticate your clients on your WLC, but not on the default port 80. By default, the controller redirects queries on port 80 to the Web Authentication page, but all other ports (apart from DNS and DHCP) are blocked. What if you need to redirect them when they open, say, port 5000?
Go to your controller CLI, and enter: config network web-auth-port 5000.
Then ask your clients to open their browser with the relevant port, in the form http://www.cisco.com:5000 (this supposes of course that you solved the "no DNS" issue).

3. Default proxy: this is a classic one. Many clients say "hey, all of my clients are configured to use the proxy 10.10.10.10. When I open the browser, they are redirected to the proxy, no matter what, and they never get the Web Authentication page.
Just configure their browser not to proxy for 1.1.1.1... this configuration is commonly under the options of the browser, in the section where you configure proxy settings. There is often an "Exceptions" or "Advanced" button where you can say that when the address is 1.1.1.1, do not use the default proxy.

Feel free to add other issues you see in your deployments/labs!

Wednesday, August 5, 2009

7921 Web interface

You can configure the 7921 phone using the phone keypad, or use a comfortable Web interface...
You can get a USB cable that connects your 7921 to your local PC. Installing the driver on your PC creates a virtual network interface on your PC. Give it any address in the 192.168.1.0/24 network (except 192.168.1.100), and you are ready to open an https session to your 7921, which is listening at https://192.168.1.100. Check here for more details on how to install the USB driver, install with Windows is sometimes... interesting...
http://www.cisco.com/en/US/docs/voice_ip_comm/cuipph/7921g/6_0/english/administration/guide/7921cfgu.html

From the Web interface, you can monitor your phone and configure many items such as WLANs and anything else you would configure using the phone keypad... this is "if" you have write access to your phone via the Web interface... how does that work? This is where it gets easy:

1. If the phone is set to factory default, you can access with Read/Write rights without restriction. Use the credentials admin/Cisco to access the phone configuration pages.

2. If the phone has already registered to a Communications Manager (CUCM), the possibility to Write depends on what configuration was sent from the CUCM to your phone. The CUCM admin may have allowed the Read/Write access... or not! The default is not to allow it, because why would your average user access this interface anyway, hey? They are supposed to USE the phone, not to PLAY with its configuration.
On your phone interface, you can verify if you have Web Read/Write access by going to Settings > Device Configuration > Security Configuration, check if Web Access is set to Full, Readonly or Disabled. You can also try to https to the phone, and see how far you go...

Now, what if you do not have the USB cable... and still want to use the Web interface? Well, that's kind of easy too... create a basic cisco WLAN on your controller (open authentication, no encryption), and reset your phone to factory default (go to Settings > phone settings > type **2 > Click yes to accept the reset to factory default)... the phone reboots, looks for the cisco SSID (that's the default behaviour), associates, and gets an IP address through DHCP. Just HTTPS to that IP address and you are on the phone Web Interface, with full read/Write access.

Tuesday, August 4, 2009

7921 boot process

When you reset a 7921 VoIP phone to factory defaults (Toolbox > Phone Settings > **2 > Yes), the phone automatically looks upon rebooting for the SSID cisco, open authentication, no encryption.

Whatever the phone configuration is, it first behaves like a standard 802.11 client, it scans channels and looks for the SSID it is configured to use (cisco and/or any other SSIDs that you may have configured in the different profiles that may be enabled at boot time).
Once it has found a valid SSID, it tries to authenticate/associate. On the phone screen, you see "Locating Network Services".

Once this step succeeds (the phone associated successfully), the 7921 needs to get an IP address, usually through DHCP (you see "Configuring IP").
Along with the IP address, the phone should get the IP address of a TFTP server (this is called option 150 in the DHCP scope). The phone needs this TFTP server to obtain its configuration file and verify that its firmware is the right one. Usually, the TFTP server is directly the Call manager or Call Manager Express, but it could be a standard TFTP server.

Once the phone has its configuration file, it reads from it the list of Call Managers (Express or not) that it is supposed to try to reach. It contacts them one by one (you see "Configuring CM List" on the phone screen).
The nice thing about using the Call Manager (CUCM) or Call Manager Express (CME) as the TFTP is that finding the CUCM or CME is easy!

Once the phone successfully found a CME or CUCM, it registers to it (you see "Registering" on the phone). This is the step where the 7921 gets its extension number.
The phone is then ready to place and receive calls.

When you configure the 7921 from its screen, most features are locked. You unlock them by keying **#. As soon as you key these three keys, a new soft button appears, displaying "Change" or "Edit".

Monday, August 3, 2009

RRM (Radio Resource Management) deep dive

I has several questions about details on RRM mechanism, so I uploaded 5 videos on Youtube about RRM:
- The first video (http://www.youtube.com/watch?v=gwCxVwmHnRw) describes RRM principles
- The second video (http://www.youtube.com/watch?v=XhmnXeeLQBc) goes deeper into RRM and provides useful information if you are to take a Cisco exam on Wireless related topics! :-)
- The third video (http://www.youtube.com/watch?v=3EnvhxjzEWU) details how RRM controls the AP channel assignment with DCA (Dynamic Channel Assignment).
- The fourth video (http://www.youtube.com/watch?v=32YWzuXTg5M) explains how RRM dynamically reduces AP power with TPC (Transmit Power Control)
- The fifth video (http://www.youtube.com/watch?v=yot63RsKOCg) explains how the Radio Coverage Detection Algorithm works.
Each video is only a few minutes long... hope they are usuful!

Sunday, August 2, 2009

WCS Planning mode and VoWLAN

What is a good VoWLAN design?
-67 dBm RSSI at the edge of the cell, aiming for less than 1% packet loss to get a MOS (with G711 codec) of 4.1 or better. Typically speed in the cell would be set to 24 Mbps or more (lower speed disabled) for 802.11a or 802.11g, and 11 Mbps or more for 802.11b/g. This last figure makes that some people would say "12 Mbps or more for 802.11g", to have 802.11g value close to the 802.11b/g value.
The main point is that if RSSI is good at the edge of the cell, and if SNR is good at that point (25 dB or more), then call quality would be good.

Now take the WCS, in planning mode, and ask it for Voice service... the network will be designed with the following predictive RSSI at the edge of the cell:
- Aggressive = Minimum [-78 dBm (802.11a/b/g)]
- Safe = Medium [-75 dBm (802.11a/b/g)]
- Very Safe = Maximum [(-72 dBm (802.11a/b/g)]
- 7920_enabled = [(-72 dBm (802.11a); -67 dBm (802.11b/g)]
All these values are way below all Cisco recommendations... you'll need to manually tune the Planning Mode result to get an acceptable predictive coverage...