When you visualize alarms in WCS, by clicking the Alarm dashboard or through Monitor > Alarms, you have a couple of choices that look the same but are different. Options are (from the WCS help page):
- Assign to me—Assign the selected alarm(s) to the current user.
- Unassign—Unassign the selected alarm(s).
- Delete—Delete the selected alarm(s).
- Clear—Clear the selected alarm(s).
- Acknowledge—You can acknowledge the alarm to prevent it from showing up in the Alarm Summary window. The alarm remains in WCS and you can search for all Acknowledged alarms using the alarm search functionality.
- Unacknowledge—You can choose to unacknowledge an already acknowledged alarm.
- Email Notification—Takes you to the All Alarms > Email Notification page to view and configure email notifications.
Assign and Unassign are simple, they determine who is supposed to deal with the alarm. But what about the others? Crystal clear isn't it? "Clear" clears, "delete" deletes and so on... okay, so what are the differences? You need to know them, because on the day of your CCIE Wireless lab, you may be asked to complete a task for which only one of these options is the right answer.
- Clear basically says "remove this alarm from this list". The alarm is removed from the list, but stays in the WCS database. If the event triggering the alarm occurs again, WCS will be able to tell you "here it happens AGAIN". If you run a report, you will see the alarm having occurred in the past. You would clear an alarm if the cause of the event disappeared and you still want to remember that it happened.
- Delete basically says "forget about this alarm". The alarm is removed from the list and from the WCS database. If the event triggering the alarm occurs again, WCS will discover it as if for the first time and tell you "oh, something new happens".
- Acknowledge basically says "Don't bother me with this anymore". The alarm is removed from the list, and WCS will not tell you if the event triggering the alarm occurs again.
When do you use them? Few examples:
- Your colleague brings his home AP and plugs it to the network. ALARM! ROGUE! You go to your colleague's desk, explain why he has been a bad boy, and remove the AP. As you are a nice guy, you tell him that you won't report him... so you CLEAR the alarm. As you removed the AP, you don't need that alarm anymore... but you want to keep track that it happened. If the guy brings the AP again, you want to get an alarm and know that it is not the first time. This time, you'll get him fired... :-) Why don't you delete or acknowledge? Because if you acknowledged, the alarm would not show anymore, even if the guy brings it back to the network (acknowledge says "don't bother me with this alarm anymore"). If you deleted, the alarm would re-appear the next time the guy brings the AP, but you would not be able to see if it was the first time or not...
- Your neighbour AP keeps showing up as a rogue. You get an alarm. You cannot remove this AP. So you ACKNOWLEDGE the alarm. This makes that the alarm will not show up anymore, regardless of your neighbour keeping the AP, changing its configuration or removing it. Basically, you know this AP, you cannot control it, so you just don't want to have warnings about something you cannot control and that is outside of your network anyway. Why don't you clear or delete it? Because then the alarm would show up again next time your neighbour plays with his AP...
- You remove an AP from the wall and put it in a box. AP status turns red on WCS and you get an alarm (AP status is down!). You remove the AP from WCS (monitor APs > Remove AP), and then DELETE the alarm. Why don't you clear it instead? Because if you re-plug the AP elsewhere, then remove it for another reason, you do not want the WCS to tell you: "Oh no, AP went down a second time!" It is not really a "second time" for you, as the AP was plugged elsewhere. To you, it is the AP second life, whereas for WCS it is still the same AP as the first time. So as these events are really distinct, you want to re-start from scratch, and this is why you delete the alarm. Why don't you Acknowledge the alarm? because if you re-plug the AP elsewhere, then remove it a second time, the AP status on the map will stay green! (with Acknowledge, you told WCS not to bother you with this AP status anymore, so it does it).
So watch what you are asked, these 3 actions are very different.
As a side note, WCS has a feature to hide Acknowledged or Cleared alarms automatically. To configure (or unconfigure) these features, go to Administration > Settings > Alarm and check (or uncheck) the corresponding boxes.
Thursday, July 30, 2009
Wednesday, July 29, 2009
RRM tuning
RRM, Radio Resources Management, is the ability that a controller has to control APs Power level and Channel values. An AP needs to be surrounded by at least 3 other APs hearing this first AP at -70dBm or better, for the RRM algorithm to be triggered on the controller. In other words, if any of your AP has only 2 other APs in its neighbourhood (or at least 2 APs heard at -70 dBm or better), the WLC will not change the AP power level.
To determine the number of neighbouring APs and their power level, the system relies on RRM neighbour messages, sent by all APs every 60 seconds by default, at max power and lowest mandatory rate. All other APs hearing the RRM message forward it to their controller. As each RRM neighbour message is signed, each controller can recognize if it was sent by a known AP in the RF Group and identify the AP along with which APs reported (= heard) the message, with what power level. Smart, he?
Now what can we tune here? 2 things:
- How often the RRM neighbour messages are sent.
- What is the threshold that triggers the RRM algorithm.
Remember the defaults? RRM messages are sent every 60 seconds, and you need 3 neighbouring APs hearing this AP at -70 dBm to trigger the algorithm. You cannot change this "3 APs" value.
To change how often the RRM neighbour messages are sent, from your controller GUI, navigate to Wireless > 82.11a > RRM > General. Change the Neighbor Packet Frequency from 60 to the new interval you want to use. As you can guess, this is done on a per radio basis, do the same for 82.11b/g if you want to.
That's for the RRM neighbour message frequency. The RRM algorithm threshold cannot be changed from the GUI, but from the CLI. In your controller CLI, type:
(Cisco Controller) >config advanced 802.11a tx-power-control-threshold ?
Enter a value between (-50) and (-80)
And change the value to what is best. For example:
Cisco Controller) >config advanced 802.11a tx-power-control-threshold -79
You can of course use the "show advanced 82.11a tx-power-control-threshold" command to verify the current value. This changes the threshold for 82.11a, you need the same command for 82.11b/g if required.
You can see the value of this threshold from the GUI, under Wireless > 82.11a > RRM TPC.
Before:
After!
To determine the number of neighbouring APs and their power level, the system relies on RRM neighbour messages, sent by all APs every 60 seconds by default, at max power and lowest mandatory rate. All other APs hearing the RRM message forward it to their controller. As each RRM neighbour message is signed, each controller can recognize if it was sent by a known AP in the RF Group and identify the AP along with which APs reported (= heard) the message, with what power level. Smart, he?
Now what can we tune here? 2 things:
- How often the RRM neighbour messages are sent.
- What is the threshold that triggers the RRM algorithm.
Remember the defaults? RRM messages are sent every 60 seconds, and you need 3 neighbouring APs hearing this AP at -70 dBm to trigger the algorithm. You cannot change this "3 APs" value.
To change how often the RRM neighbour messages are sent, from your controller GUI, navigate to Wireless > 82.11a > RRM > General. Change the Neighbor Packet Frequency from 60 to the new interval you want to use. As you can guess, this is done on a per radio basis, do the same for 82.11b/g if you want to.
That's for the RRM neighbour message frequency. The RRM algorithm threshold cannot be changed from the GUI, but from the CLI. In your controller CLI, type:
(Cisco Controller) >config advanced 802.11a tx-power-control-threshold ?
Enter a value between (-50) and (-80)
And change the value to what is best. For example:
Cisco Controller) >config advanced 802.11a tx-power-control-threshold -79
You can of course use the "show advanced 82.11a tx-power-control-threshold" command to verify the current value. This changes the threshold for 82.11a, you need the same command for 82.11b/g if required.
You can see the value of this threshold from the GUI, under Wireless > 82.11a > RRM TPC.
Before:
After!
Tuesday, July 28, 2009
OTAP - Over the Air Provisioning
You probably know OTAP, over the air provisioning of APs. When an access point boots, it can listen to the Air and receive information about controllers from the other APs. Do you want to know what does an OTAP message look like? How to read your controller IP address from a capture?
Watch here: http://www.youtube.com/watch?v=dZHiY_1p_d0
Imagine... you are in a lab, and the scenario says "your controller blahblah Management IP address was lost. Use the OTAP capture to find it. And basically if you can't find it, you can't get to it and configure it and this means the end of the journey for your lab..." you'd better be able to decipher OTAP messages, just in case!
Disclaimer: I DON'T know if this scenario is part of an actual lab or not! I just feel that at CCIE level, you are probably expected to understand OTAP well enough to know how to use it!
:-)
Watch here: http://www.youtube.com/watch?v=dZHiY_1p_d0
Imagine... you are in a lab, and the scenario says "your controller blahblah Management IP address was lost. Use the OTAP capture to find it. And basically if you can't find it, you can't get to it and configure it and this means the end of the journey for your lab..." you'd better be able to decipher OTAP messages, just in case!
Disclaimer: I DON'T know if this scenario is part of an actual lab or not! I just feel that at CCIE level, you are probably expected to understand OTAP well enough to know how to use it!
:-)
Monday, July 27, 2009
Hide that LED
In some environments the nice blinking LEDs on our controller based access points are not welcome: in some hospital environments they are said to create panic related reaction with some patients, in some school they are said to attract too much attention... well, you may be asked to make sure that this AP LEDs are disabled.
This is a controller CLI command. To disable the LEDs for an AP called AP5 (check your AP names with show ap summary):
(Cisco Controller) >config ap led-state disable AP5
To disable LEDs on all APs:
(Cisco Controller) >config ap led-state disable all.
Nice and easy. As you can guess, use the config ap led-state enable to revert the command.
This is a controller CLI command. To disable the LEDs for an AP called AP5 (check your AP names with show ap summary):
(Cisco Controller) >config ap led-state disable AP5
To disable LEDs on all APs:
(Cisco Controller) >config ap led-state disable all.
Nice and easy. As you can guess, use the config ap led-state enable to revert the command.
Sunday, July 26, 2009
Wired Guest
You know the wireless guest feature, where users get a Web authentication page, enter username and password (or just enter their email address if it is a Pass Through config) to access the Internet.
The Wireless Business Unit has had the request for year to do the same for wired users... why? Well, juts because you always get that guy who does not have wireless, wants to plug somewhere just to check emails. Over the years, as the wireless guest access has become "the guest networks", we wireless guys are usually asked to take care of this "wired exception" along with the wireless standard guest users.
So now, the controller can also take care of these guys. It is easy to configure and very close to the wireless guest config. You can do it on one controller, or with 2 controllers, which is more interesting.
So imagine, you have a Switch, with a VLAN 50, which is the "Wired guest" VLAN. Whenever a wired guest wants access to the internet, plug the laptop to a port on that switch, in VLAN 50. This VLAN 50 guest to the trunk where you have your controller, called WLC1, waiting. WLC1 is your internal controller. It has quite a few WLANs and VLANs. It also receives the requests for wired (and wireless maybe) guest users, and sends them to the DMZ controller, DMZWLC.
So here is the process. Configuring Wired Guest Access is done is 5 steps:
1. Configure a dynamic interface (VLAN) for wired guest user access
2. Create a wired LAN for guest user access
3. Configure the Foreign controller (Main Office)
4. Configure the anchor controller (the DMZ controller)
5. Fine tune the guest LAN
1. On WLC1, create a dynamic interface VLAN50. In the interface configuration page, check the "Guest LAN" box. As soon as you check that box, fields such as IP address or gateway disappear. The only thing your WLC needs to know about this interface is that "there will be client traffic coming from VLAN 50. These clients are wired guests".
2. On a controller, an Interface is used when associated to a WLAN. The second step is therefore to create a WLAN on your Main Office controllers. Navigate to WLANs and click New.
In WLAN Type, choose Guest LAN.
In profile Name and WLAN SSID, enter a name that identifies what this WLAN is about. These names can be different, but cannot contain any space. The term WLAN is used, but this network profile has nothing to do with wireless.
The General tab offers 2 drop down list: one "Ingress" and one "Egress". Ingress is the VLAN users come from (VLAN 50), Egress is the VLAN you want to send them to.
For Ingress, choose VLAN50. Easy. For Egress, things are a little more interesting. If you had only one controller, you would create another dynamic interface, a "standard" one this time (i.e. NOT guest LAN), and you would send your wired users to this interface. In this case, we send them to the DMZ controller. So for the Egress interface, choose the Management Interface.
The Security mode for this Guest LAN "WLAN" is Web Auth, which is fine. Click Ok to validate.
3. From the WLAN list, click Mobility Anchor at the end of the Guest LAN line, and choose your DMZ controller. I am supposing here that both controllers know each others. If they do not know each other yet, go to Controller > Mobility Management > Mobility group, and add DMZWLC on WLC1, and similarly add WLC1 on DMZ. Both controllers do NOT need to be in the same mobility group (actually they'd better NOT be! Otherwise you would be breaking basic security rules here).
4. Your Main Office controller is ready. You now need to prepare your DMZ controller. Open a Web browser session to your DMZ controller and navigate to WLANs.
Create a new WLAN.
Just like on the Main Office controllers, in WLAN Type, choose Guest LAN.
In profile Name and WLAN SSID, enter a name that identifies what this WLAN is about. Use the same values as on the Main Office controller.
The Ingress interface here is None... It actually does not matter, as the traffic will be received through the EoIP tunnel, so this is why you do not need to specify any ingress interface.
The egress interface is the one on which the clients are supposed to be sent. Let's say that the DMZ VLAN is VLAN9. Create a standard dynamic interface for VLAN 9 on your DMZWLC, then choose VLAN 9 as the egress interface.
You need to configure the end of the Mobility Anchor tunnel. From the WLAN list, choose Mobility Anchor for Guest LAN. Send the traffic to the local controller, DMZWLC.
Both ends are now ready.
5. You can also fine tune the WLAN settings on both ends. Be careful, settings are to be exactly the same on both ends. For example, if you choose to click, in the WLAN Advanced tab, "Allow AAA override" on WLC1, you need to check the same box on DMZWLC. Any difference in settings in the WLAN on either side will make that the tunnel will break (DMZWLC will refuse the traffic, you can see that by running debug mobility).
Keep in mind that all values will actually be obtained from DMZWLC: IP addresses, VLAN values, etc. You configure the WLC1 side identically just for it to relay the request to the WLCDMZ...
Give it a try, and post here if it does not work.. :-)
The Wireless Business Unit has had the request for year to do the same for wired users... why? Well, juts because you always get that guy who does not have wireless, wants to plug somewhere just to check emails. Over the years, as the wireless guest access has become "the guest networks", we wireless guys are usually asked to take care of this "wired exception" along with the wireless standard guest users.
So now, the controller can also take care of these guys. It is easy to configure and very close to the wireless guest config. You can do it on one controller, or with 2 controllers, which is more interesting.
So imagine, you have a Switch, with a VLAN 50, which is the "Wired guest" VLAN. Whenever a wired guest wants access to the internet, plug the laptop to a port on that switch, in VLAN 50. This VLAN 50 guest to the trunk where you have your controller, called WLC1, waiting. WLC1 is your internal controller. It has quite a few WLANs and VLANs. It also receives the requests for wired (and wireless maybe) guest users, and sends them to the DMZ controller, DMZWLC.
So here is the process. Configuring Wired Guest Access is done is 5 steps:
1. Configure a dynamic interface (VLAN) for wired guest user access
2. Create a wired LAN for guest user access
3. Configure the Foreign controller (Main Office)
4. Configure the anchor controller (the DMZ controller)
5. Fine tune the guest LAN
1. On WLC1, create a dynamic interface VLAN50. In the interface configuration page, check the "Guest LAN" box. As soon as you check that box, fields such as IP address or gateway disappear. The only thing your WLC needs to know about this interface is that "there will be client traffic coming from VLAN 50. These clients are wired guests".
2. On a controller, an Interface is used when associated to a WLAN. The second step is therefore to create a WLAN on your Main Office controllers. Navigate to WLANs and click New.
In WLAN Type, choose Guest LAN.
In profile Name and WLAN SSID, enter a name that identifies what this WLAN is about. These names can be different, but cannot contain any space. The term WLAN is used, but this network profile has nothing to do with wireless.
The General tab offers 2 drop down list: one "Ingress" and one "Egress". Ingress is the VLAN users come from (VLAN 50), Egress is the VLAN you want to send them to.
For Ingress, choose VLAN50. Easy. For Egress, things are a little more interesting. If you had only one controller, you would create another dynamic interface, a "standard" one this time (i.e. NOT guest LAN), and you would send your wired users to this interface. In this case, we send them to the DMZ controller. So for the Egress interface, choose the Management Interface.
The Security mode for this Guest LAN "WLAN" is Web Auth, which is fine. Click Ok to validate.
3. From the WLAN list, click Mobility Anchor at the end of the Guest LAN line, and choose your DMZ controller. I am supposing here that both controllers know each others. If they do not know each other yet, go to Controller > Mobility Management > Mobility group, and add DMZWLC on WLC1, and similarly add WLC1 on DMZ. Both controllers do NOT need to be in the same mobility group (actually they'd better NOT be! Otherwise you would be breaking basic security rules here).
4. Your Main Office controller is ready. You now need to prepare your DMZ controller. Open a Web browser session to your DMZ controller and navigate to WLANs.
Create a new WLAN.
Just like on the Main Office controllers, in WLAN Type, choose Guest LAN.
In profile Name and WLAN SSID, enter a name that identifies what this WLAN is about. Use the same values as on the Main Office controller.
The Ingress interface here is None... It actually does not matter, as the traffic will be received through the EoIP tunnel, so this is why you do not need to specify any ingress interface.
The egress interface is the one on which the clients are supposed to be sent. Let's say that the DMZ VLAN is VLAN9. Create a standard dynamic interface for VLAN 9 on your DMZWLC, then choose VLAN 9 as the egress interface.
You need to configure the end of the Mobility Anchor tunnel. From the WLAN list, choose Mobility Anchor for Guest LAN. Send the traffic to the local controller, DMZWLC.
Both ends are now ready.
5. You can also fine tune the WLAN settings on both ends. Be careful, settings are to be exactly the same on both ends. For example, if you choose to click, in the WLAN Advanced tab, "Allow AAA override" on WLC1, you need to check the same box on DMZWLC. Any difference in settings in the WLAN on either side will make that the tunnel will break (DMZWLC will refuse the traffic, you can see that by running debug mobility).
Keep in mind that all values will actually be obtained from DMZWLC: IP addresses, VLAN values, etc. You configure the WLC1 side identically just for it to relay the request to the WLCDMZ...
Give it a try, and post here if it does not work.. :-)
Saturday, July 25, 2009
TPC vs DTPC vs World mode
Have you heard about TPC (Transmit Power Control), DTPC (Dynamic Transmit Power Control), and World Mode? They look the same, but do not actually do the same things... let's have a quick look at each of them:
- World Mode is probably the oldest one. It is a feature you can configure on the Autonomous (OIS) access points, and by which a client in World Mode receives its " radio parameters" from the access point. If you look a bit closer, you might read that "parameters" are actually channels and power levels. But don't take it wrong. "Channels" has an "s". It is not the channel on which the client should be! To hear the access point, the client has ANYWAY to be on the right channel. So what World Mode is about is "the list of allowed channels in this country" and "the power level ranges allowed in this country".
World mode is actually a Cisco implementation of the 802.11d protocol... but wait, why do we need that stuff? You are already on the right channel anyway! Well, for 2 reasons:
. Your client is going to scan for other APs offering the same SSID. You do not want your client to scan channel 13 if there is no AP on that channel because this channel is not allowed in your country... and you do not want your client to send a probe request on that channel if using it is forbidden...
. Your client power level might be too high for the country, thus creating issues for the other clients around it... what issues? Well, if you client is too powerful, it is going to associate at high speeds in areas where it should not even be able to associate, thus creating interference and hidden nodes issues for the other clients...
So the 802.11d protocol allows you to send the regulatory domain information to you client, which is going to adapt to them. Cool isn't it? The 802.11d protocol was integrated into the 802.11-2007 standard, thus allowing the possibility to send this information, without stating exactly how it could be sent. In a Cisco network, this can be contained in the Vendor Specific fields of the beacons. So where is that feature in the Autonomous APs? In the radio (802.11b / 802.11a) configuration page.
And in the Unified solution? Nowhere... what? did they forget it? Naahh, can't believe that... read further....
-TPC, Transmit Power Control, is actually a feature of 802.11h... You know 802.11h? This protocol that prevents your APs working outdoor on the 5 Ghz spectrum from interfering with airport radars... this protocol has two sides:
. DFS, Dynamic Frequency Selection, that makes that if your AP hears a radar blast on its current frequency, it sends a "changing channel" 802.11h message and jumps to another channel.
. TPC, Transmit Power Control, by which 2 devices initiating a communication in the 5 Ghz spectrum will negotiate so that their respective power level is as low as possible, just loud enough to hear each other (so that your noisy 50 mW access point does not disturb the poor 60 WATTS radar sitting next door!!).
Where do you configure TPC? Well, you don't really configure it. It is part of 802.11h, and your 802.11a device has to be compliant with it, and implements it automatically.
-DTPC, that's Dynamic Transmit Power Control, looks close to TPC hey? But this is Cisco stuff, not 802.11 something anymore. With DTPC, your Cisco access point transmits to your Cisco CCX compliant client information about which power level to use... looks somehow close to World mode, don't you think?
Yes, it's close... but do you know what caused the death of World mode and why you don't find this feature in a controller? Think about it... what does it exactly do? If (yes, "if"), you enable it, your clients will receive a pack of allowed channels and power levels from your AP. This information format is proprietary, so your client needs to be a CCX guy to understand it. And what does it do with that information? You don't know... your client may use it, if it is also configured for World mode. It may understand it but not use it, if it is CCX but not configured for World mode, it may not be able to use it if its drivers is not per-set for this regulatory domain, or it may not even understand it if the client CCX version is too old or if the client is not CCX... Whoa, what a result... so let's think about another approach.
If your client is CCX, you can actually do more: influence it. very often, your AP has a good 9 dBi patch antenna and your client has a poor rubber duck 2.2 dBi antenna. Your client hears the AP well, but the client signal is lost in the surrounding noise and your AP does not hear it well. Your client should increase its power level, but it does not know that the AP does not hear it well... all it knows is that it (the client) hears the AP well, and from this received signal deduces its own power level. If you client is CCX, the AP can tell to your client "I don't hear you well, increase your power to 20 mW", or "hey no need to shout! reduce your power to 5 mW, that will save your battery". In this information, the AP can communicate maximums ("increase your power again, but don't go beyond 50 mW"). Isn't that better than World mode? That's what DTPC is about. You can enable it in your controller from the Main radio menu (Wireless > 802.11a > Network, in the General field).
But what about the channels? Well, there is also another CCX feature by which an AP can tell a CCX client "don't scan, you are in my cell in a comfort zone, stay quiet and save battery". Or "your signal strength is decreasing, you should start scanning", and there are a lot of variation from there, from "scan channels 1,6,11" or "check channel 6, Ap aa:bb:cc:dd:ee:ff should be there"... isn't that even better?
Yes, but what about the non-CCX clients? Well, they would not have understood the World mode messages anyway, this is why CCX is cool...
- World Mode is probably the oldest one. It is a feature you can configure on the Autonomous (OIS) access points, and by which a client in World Mode receives its " radio parameters" from the access point. If you look a bit closer, you might read that "parameters" are actually channels and power levels. But don't take it wrong. "Channels" has an "s". It is not the channel on which the client should be! To hear the access point, the client has ANYWAY to be on the right channel. So what World Mode is about is "the list of allowed channels in this country" and "the power level ranges allowed in this country".
World mode is actually a Cisco implementation of the 802.11d protocol... but wait, why do we need that stuff? You are already on the right channel anyway! Well, for 2 reasons:
. Your client is going to scan for other APs offering the same SSID. You do not want your client to scan channel 13 if there is no AP on that channel because this channel is not allowed in your country... and you do not want your client to send a probe request on that channel if using it is forbidden...
. Your client power level might be too high for the country, thus creating issues for the other clients around it... what issues? Well, if you client is too powerful, it is going to associate at high speeds in areas where it should not even be able to associate, thus creating interference and hidden nodes issues for the other clients...
So the 802.11d protocol allows you to send the regulatory domain information to you client, which is going to adapt to them. Cool isn't it? The 802.11d protocol was integrated into the 802.11-2007 standard, thus allowing the possibility to send this information, without stating exactly how it could be sent. In a Cisco network, this can be contained in the Vendor Specific fields of the beacons. So where is that feature in the Autonomous APs? In the radio (802.11b / 802.11a) configuration page.
And in the Unified solution? Nowhere... what? did they forget it? Naahh, can't believe that... read further....
-TPC, Transmit Power Control, is actually a feature of 802.11h... You know 802.11h? This protocol that prevents your APs working outdoor on the 5 Ghz spectrum from interfering with airport radars... this protocol has two sides:
. DFS, Dynamic Frequency Selection, that makes that if your AP hears a radar blast on its current frequency, it sends a "changing channel" 802.11h message and jumps to another channel.
. TPC, Transmit Power Control, by which 2 devices initiating a communication in the 5 Ghz spectrum will negotiate so that their respective power level is as low as possible, just loud enough to hear each other (so that your noisy 50 mW access point does not disturb the poor 60 WATTS radar sitting next door!!).
Where do you configure TPC? Well, you don't really configure it. It is part of 802.11h, and your 802.11a device has to be compliant with it, and implements it automatically.
-DTPC, that's Dynamic Transmit Power Control, looks close to TPC hey? But this is Cisco stuff, not 802.11 something anymore. With DTPC, your Cisco access point transmits to your Cisco CCX compliant client information about which power level to use... looks somehow close to World mode, don't you think?
Yes, it's close... but do you know what caused the death of World mode and why you don't find this feature in a controller? Think about it... what does it exactly do? If (yes, "if"), you enable it, your clients will receive a pack of allowed channels and power levels from your AP. This information format is proprietary, so your client needs to be a CCX guy to understand it. And what does it do with that information? You don't know... your client may use it, if it is also configured for World mode. It may understand it but not use it, if it is CCX but not configured for World mode, it may not be able to use it if its drivers is not per-set for this regulatory domain, or it may not even understand it if the client CCX version is too old or if the client is not CCX... Whoa, what a result... so let's think about another approach.
If your client is CCX, you can actually do more: influence it. very often, your AP has a good 9 dBi patch antenna and your client has a poor rubber duck 2.2 dBi antenna. Your client hears the AP well, but the client signal is lost in the surrounding noise and your AP does not hear it well. Your client should increase its power level, but it does not know that the AP does not hear it well... all it knows is that it (the client) hears the AP well, and from this received signal deduces its own power level. If you client is CCX, the AP can tell to your client "I don't hear you well, increase your power to 20 mW", or "hey no need to shout! reduce your power to 5 mW, that will save your battery". In this information, the AP can communicate maximums ("increase your power again, but don't go beyond 50 mW"). Isn't that better than World mode? That's what DTPC is about. You can enable it in your controller from the Main radio menu (Wireless > 802.11a > Network, in the General field).
But what about the channels? Well, there is also another CCX feature by which an AP can tell a CCX client "don't scan, you are in my cell in a comfort zone, stay quiet and save battery". Or "your signal strength is decreasing, you should start scanning", and there are a lot of variation from there, from "scan channels 1,6,11" or "check channel 6, Ap aa:bb:cc:dd:ee:ff should be there"... isn't that even better?
Yes, but what about the non-CCX clients? Well, they would not have understood the World mode messages anyway, this is why CCX is cool...
Get a Pass
I took my CCIE Wireless lab a few weeks ago and got a pass.
After seeing many friends struggling for their studies and seeing quite a few people I highly respect for their technical level fail badly on their attempts, I decided to create this blog to exchange tips about the exam and how to prepare for it.
The CCIE Wireless exam is hard, but not infeasible if you know where you are going. A few tips:
1. Get yourself a CCNP wireless level. This does not mean actually pass the CCNP Wireless exams, but work the topics. There is no official resource (student guide or such) for the CCIE preparation, apart from bootcamps like the one from Fast Lane. Although you will definitely learn a lot from these bootcamps, you will only take full benefits of them if you come prepared with a level good enough level, so that you will only have to learn the few tips you miss and work your configuration speed. For the CCNP Wireless though, there are student guides and self prep books out there, so it's easy to go through them and make sure you master what they contain. Without breaking any NDA, if you look at the CCIE blueprint, you will see a lot of topics that look just likes the one listed in the CCNP Wireless courses...
2. Learn how to read minds... yes, you read that one right. You know, it is a CCIE exam, so they won't tell you "Hey, we would like you to configure this weird feature, you know the one that sits at the bottom of that page". They will more likely say "Configure your network to achieve this or that result". You will stop and think: "Okay, I know at least 3 ways to achieve what they want". Now, you can be sure that 2 of these 3 will be considered as the wrong answer... and you won't know until you get your "failed"....
How to figure out which solution they want? Well, there are a few ways:
- check if any of your possible answers breaks something else... it can be something they asked before, or something they will ask later on in the lab. Nothing magic here, and nothing you really care about during the initial "prepare" phase of your journey. Just be aware of the consequences of each configuration item. For example if they say "optimize your cell for voice" and if you think "hey, I should set the minimum speed to 24 Mbps", and if they say somewhere that 802.11b clients are in the same cell, you obviously can't remove any 802.11b speed... easy in an example, harder during the lab itself... so be aware of what side effect each configuration item has...
- check the exact phrasing... and that's where you get closer to mind reading. It could be things they say or things they don't say. An example: "most of your APs work fine, except one in that room that disconnects its clients because its power level is too weak. Solve the issue". You can easily guess that this is about setting the power level manually to a higher value. You can do it globally for all APs, and set them all to "1", or just for that AP. If most of the APs work fine, there is no way that they will accept the global solution, it has to be only for the problematic AP...
- Know what they think a CCIE should be... to you, it's a title, to them, it is a role, a position, a level of expertize that will guarantee that you will know the main problems of the real world and how to solve them. These problems obviously won't be newbie issues, but weird ones... so check the places where people talk about these issues... 2 main places I would recommend:
Cisco Forum : http://forums.cisco.com/eforum/servlet/NetProf?page=Wireless_-_Mobility_discussion
Cisco TAC Solution database for Wireless: http://www.ciscotaccc.com/wireless/home
Be sure you would be able to answer most questions and issues you see there. Not necessarily new questions about new issues you never heard about, but the ones already solved and documented, learn how they solved them...
3. Train on speed: during the lab, you don't have time to learn on how to configure stuff... you do have access to Cisco Documentation CD, but if you start looking in there, it's better be for a detail or a small item, otherwise you will run out of time. So during your training, configure stuff, learn to configure all variants, and know how to do it quick. If I tell you: "Configure ACM for Voice on 802.11a", your brain has to do: "ACM? That's Access Control management, in Wireless > 802.11a > Voice, but I first need to shut the 802.11a network". 2 clicks, done. You may not know about ACM yet (well, now you do!), but the main point is that, as soon as you do know about it, what it is and what it does, you have to know immediately where it is and what conditions exist to make it work (network has to be disabled first). Nothing magic here again, just pure practice, configure VoWLAN 2 times and you'll have done it 2 times!
4. Be curious. Do not limit yourself to the "Oh, I know how to configure a VoWLAN" (for example). Also look around. You'll notice small things... an example: oh, what is that "Web Radius Authentication" authentication feature in the Controller > General menu?... and BTW, why is it in the General menu if it is about RADIUS?... if you keep doing the same things and do not look around, you might be surprised when they ask you for a feature you never heard of... if you keep your eyes open, you will at elast have heard or read about what they ask...
One last thing... they can't really ask you magic things beyond what a controller or an Access Point can do. So it is a difficult exam, but if you learn your controller menus, know them all and know them well, do the same on an access point, you are close to the point where they can' t really surprise you anymore. All you need then is speed...
Good luck. It may be a long journey, but it is worth it...
After seeing many friends struggling for their studies and seeing quite a few people I highly respect for their technical level fail badly on their attempts, I decided to create this blog to exchange tips about the exam and how to prepare for it.
The CCIE Wireless exam is hard, but not infeasible if you know where you are going. A few tips:
1. Get yourself a CCNP wireless level. This does not mean actually pass the CCNP Wireless exams, but work the topics. There is no official resource (student guide or such) for the CCIE preparation, apart from bootcamps like the one from Fast Lane. Although you will definitely learn a lot from these bootcamps, you will only take full benefits of them if you come prepared with a level good enough level, so that you will only have to learn the few tips you miss and work your configuration speed. For the CCNP Wireless though, there are student guides and self prep books out there, so it's easy to go through them and make sure you master what they contain. Without breaking any NDA, if you look at the CCIE blueprint, you will see a lot of topics that look just likes the one listed in the CCNP Wireless courses...
2. Learn how to read minds... yes, you read that one right. You know, it is a CCIE exam, so they won't tell you "Hey, we would like you to configure this weird feature, you know the one that sits at the bottom of that page". They will more likely say "Configure your network to achieve this or that result". You will stop and think: "Okay, I know at least 3 ways to achieve what they want". Now, you can be sure that 2 of these 3 will be considered as the wrong answer... and you won't know until you get your "failed"....
How to figure out which solution they want? Well, there are a few ways:
- check if any of your possible answers breaks something else... it can be something they asked before, or something they will ask later on in the lab. Nothing magic here, and nothing you really care about during the initial "prepare" phase of your journey. Just be aware of the consequences of each configuration item. For example if they say "optimize your cell for voice" and if you think "hey, I should set the minimum speed to 24 Mbps", and if they say somewhere that 802.11b clients are in the same cell, you obviously can't remove any 802.11b speed... easy in an example, harder during the lab itself... so be aware of what side effect each configuration item has...
- check the exact phrasing... and that's where you get closer to mind reading. It could be things they say or things they don't say. An example: "most of your APs work fine, except one in that room that disconnects its clients because its power level is too weak. Solve the issue". You can easily guess that this is about setting the power level manually to a higher value. You can do it globally for all APs, and set them all to "1", or just for that AP. If most of the APs work fine, there is no way that they will accept the global solution, it has to be only for the problematic AP...
- Know what they think a CCIE should be... to you, it's a title, to them, it is a role, a position, a level of expertize that will guarantee that you will know the main problems of the real world and how to solve them. These problems obviously won't be newbie issues, but weird ones... so check the places where people talk about these issues... 2 main places I would recommend:
Cisco Forum : http://forums.cisco.com/eforum/servlet/NetProf?page=Wireless_-_Mobility_discussion
Cisco TAC Solution database for Wireless: http://www.ciscotaccc.com/wireless/home
Be sure you would be able to answer most questions and issues you see there. Not necessarily new questions about new issues you never heard about, but the ones already solved and documented, learn how they solved them...
3. Train on speed: during the lab, you don't have time to learn on how to configure stuff... you do have access to Cisco Documentation CD, but if you start looking in there, it's better be for a detail or a small item, otherwise you will run out of time. So during your training, configure stuff, learn to configure all variants, and know how to do it quick. If I tell you: "Configure ACM for Voice on 802.11a", your brain has to do: "ACM? That's Access Control management, in Wireless > 802.11a > Voice, but I first need to shut the 802.11a network". 2 clicks, done. You may not know about ACM yet (well, now you do!), but the main point is that, as soon as you do know about it, what it is and what it does, you have to know immediately where it is and what conditions exist to make it work (network has to be disabled first). Nothing magic here again, just pure practice, configure VoWLAN 2 times and you'll have done it 2 times!
4. Be curious. Do not limit yourself to the "Oh, I know how to configure a VoWLAN" (for example). Also look around. You'll notice small things... an example: oh, what is that "Web Radius Authentication" authentication feature in the Controller > General menu?... and BTW, why is it in the General menu if it is about RADIUS?... if you keep doing the same things and do not look around, you might be surprised when they ask you for a feature you never heard of... if you keep your eyes open, you will at elast have heard or read about what they ask...
One last thing... they can't really ask you magic things beyond what a controller or an Access Point can do. So it is a difficult exam, but if you learn your controller menus, know them all and know them well, do the same on an access point, you are close to the point where they can' t really surprise you anymore. All you need then is speed...
Good luck. It may be a long journey, but it is worth it...
Subscribe to:
Posts (Atom)
Posts
