Lab version 2

Here it is! After months of rumors and non-disclosure secrets, the new CCIE W lab is anounced:
https://learningnetwork.cisco.com/thread/30228

Key takeaways:
-the new version of the lab starts from November 18th 2011

- It is built on code v7.0 MR1, which adds to the lab MSE (wIPS and CAS), CleanAir, VideoStream, OfficeExtend, bandselect, and mesh.

If you have been working on the current version of the lab, this may look like scary news, but be aware that the core knowledge remains the same, you just need to get used to a slightly different WLC and WCS interface, with a couple more options available to configure. The new items listed are not that bad.
At the time of this post, the lab details (hardware and software) is not released yet, but I would bet for Autonomous IOS code 12.4, which will add a couple of minor new possibilities, and they will probably move away from ACS 4.2 to prefer a newer version, which implies finding your way back through the new menus...
I intend to start posting videos on this new lab during the summer! In between, some advice:
- If you were already planning to take the lab before November and it is not your first attempt, keep doing it, but do not rush! People who rush to take a lab before an exam change often are not ready enough to pass... and they won't give away the old version just because there is a new one coming. Only rush if you planned to take it by mid November, take it a bit earlier.
- If you were planning to take your lab in fall, and it is your first attempt, wait for the new lab. Update your gear to 7.0 and start working on speed...
- A new lab always mean new challenges... from all sides... you may want to wait a few weeks after the lab is released, time for the scenarios to be "stabilized". At this level, it is impossible to think of anything candidates can imagine when they read questions, and I have no doubt that during the first days the lab team will receive tens of questions and will change some questions wording so as to avoid any ambiguity... passing during these first few days is difficult because you may assume things from what you read, that are not what they expect. Wait a few days so that the wording becomes "imagination proof"...

Autonomous Call Admission Control, admit-traffic?

On the autonomous APs, you can configure Call Admission Control (almost) like on the WLC. This feature allows you to decide how much bandwidth is allocated to Voice traffic on your radio.
But there are 2 places where you can set CAC (thus this article): in the QoS page and at the SSID level... so what is the difference?
To get what is going, a bit of background. You can setup Call Admission control in Services > QoS > 802.11b/g (or 802.11) Access Categories, by the bottom of the page:

This configuration adds the following line to the radio configuration:

dot11 qos class voice local
   admission-control
   admit-traffic narrowband max-channel 75 roam-channel 6

The result is that admission control is set on this radio. Voice can use up to 75% of the available bandwidth (based only on the AP dot11 traffic. To also use the noise and other APs activity, you need to get a controller and use Load based CAC). From these 75%, 6% are kept for roaming users (so that users roaming from other APs do not get disconnected when jumping to this AP).
This configuration applies to the radio, not to an SSID in particular. So any traffic matching voice classification (802.11e UP 6 and 7) on this radio for all SSIDs will be seen and controlled.
As this refers to 802.11e UP, the underlying expectation is that WMM is enabled on that radio. WMM is enabled by default, but could be disabled from Services > QoS > Advanced, for 802.11b/g or 802.11a. On the CLI, WMM is disabled with the radio command:
no dot11 qos mode

If you disable WMM, then the AP does not care anymore about the QoS field in the clients frames, and although WMM clients could still internally prioritize voice packets, the AP would not apply any admission control of any kind anymore.

Okay, but what if you do not set Call Admission Control? Could that be a problem? Well, yes. Many phones (and in particular the 7921) send TSPEC (traffic specification) information in a ADDTS QoS frame when roaming. If this is Greek to you, let's translate by saying that the phone tells the AP to which it is roaming that it wants to use a certain class of service. If CAC is not set, the AP does not really care about the type of traffic the client wants to send (as it is not going to filter the clients based on what type of traffic they send). The result is that, in the early days of this WMM adventure (in 2009!), the AP was responding to the phone reassociation request with a reassociation response that was not containing the CCKM information element, informing the phone about how fast roaming was handled (remember my default 6% bandwith left for roaming users? That's what we are talking about, the phone needs to know if there is space left on this new AP or not). Without this CCKM IE, the phone was lost and was hanging there, wondering what to do (wondering in fact if any other, better AP would be in range), before finally joining the AP anyway. This created a gap in conversations of about 1 to 1.5 seconds.
To go around this issue, you could then configure the SSID itself to say: "even though I do not set any specific call admission control or limitation on how much bandwidth can be used by this or that type of traffic, I do welcome VoIP traffic and BTW I do CCKM". This message was sent by setting the admit-traffic command under the SSID:

dot11 ssid XYZ

admit-traffic

On the Web interface, this is done at the bottom of the SSID page:

In other words, the admit-traffic SSID command allows you to improve your CCKM clients roaming performances, without the need to limit the bandwidth allocated to voice users (local voice users or roaming voice users).
Now, what if you do have CAC enabled?... do you still need to set admit-traffic under the SSID? The answer depends on the IOS code and the associated AP hardware. The short answer is: if the admit-traffic (Call Admission Control) command is available under the SSID, always set it. Otherwise, you may have CAC set at the radio level, but the SSID blocking the TSPEC SCCP messages, in other words not answering with the CCKM IE anyway.

In a pure lab mindset, the prerequisite is that your AP runs a code where this feature is possible. The second requirement is that roaming is involved. If there is no roaming, you may want to set CAC to limit the VoIP bandwidth consumption, or you may not care about CAC. In all cases, a 1 to 1.5 second initial delay does not mater. It is an issue only when roaming is involved. So... read your lab scenario carefully.

Last tip: the default rate for TSPEC on the 7921/7925 is 12 Mbps, which should be enabled on the AP.  Make sure that 12 Mbps is always allowed on the radio that those phones use, otherwise your will be missing those messages, and you would be back to the voice gap issue.

Wired QoS for Voice control: AF31 (DSCP 26) or CS3 (DSCP 24)?

This is a question I get quite often, so I thought it might be useful to write a quick summary about it: Voice traffic is divided into the voice flow itself and some control traffic (mainly statistics). Voice traffic is usually (in the Cisco world) tagged CoS 5 (802.1p), or DSCP 46, AKA Expedited Forwarding (EF). This is 802.11 AC_VO priority level 6. But what about Voice control? You will read in some places that it should be tagged DSCP 26, and in other places that it should be tagged DSCP 24... so what should we do in the wireless world?

First of all, the easy part. Voice control is less time sensitive than the voice flow, because it does not carry voice sound, just statistical information about the voice flow. So you can miss a packet or 2, no big deal. But if you miss too many of them, the phones won't be able to interpret the quality of the line anymore, and your call will drop. So this information is "critical" but "less urgent" than the voice flow. It is tagged 802.1p 3, and belongs to the AC_VI tag 4 for the wireless side.

Now the more delicate part: what DSCP should it have? So here is the story behind it, as I remember it (am I that old?): Cisco used to recommend setting voice signaling to AF 31 (DSCP 26). They thought that tagging voice control this way was appropriate, because it allowed for the same class 3 as the 802.1p value, while still setting a drop precedence (1), which is what the strength of DSCP is about.
But they were criticized because people were saying that systems using IP precedence instead of DSCP could not really use the drop precedence (value 1) and just the IP precedence PHB part (3), so using AF31 was not the best choice ever.
After years of hearing that complaint, Cisco released new good practices and new tables showing that in fact voice signaling should slowly be changed to DSCP 24, which is CS3 (so there is no drop precedence and a complete match between the DSCP value, the IP precedence value and the 802.1p priority level). That was a couple of years ago. But of course in between the same complaining customers had already implemented the AF31 tag, and started complaining again, this time about migration issues, stating that if the systems were fully DSCP it didn't really matter, etc.
So today, the new recommendation is DSCP 24 for voice control, DSCP 26 being still largely accepted for migrated implementations.
So which one should we use in a training scenario?
The bottom line is that in a lab environment, 24 is better but both 24 and 26 are fine.
If you know the story, you can decide that this is a new implementation and you set 24, or this is a migrated implementation and you keep 26, or you can ask which one is preferred to your dear proctor... but he may then remind you that this is the CCIE Wireless, not Voice, and that it does not really matter to judge your wireless skills... :-)

Workgroup Bridge (WGB) CLI commands

Workgroup bridges (WGB) are IOS access points configured as clients to the wireless infrastructure. They can associate to Aironet IOS APs or LWAPP/CAPWAP APs. They usually are used to relay traffic from non-802.11 clients, acting as a sort of common wireless NIC for those clients.

Beyond the simple WGB configuration, there are several "optional" parameters that you may need to configure.


- Preamble: 3 or 4 MAC addresses

To understand most of these settings, keep in mind some 802.11 basics:

 This is an 802.11 header. It has up to 4 MAC addresses. The logic is that if you send a frame from a wireless client to another wireless client via an AP, you need 3 MAC addresses: the source (the original emitter), the final destination, and the AP. Then we use the terms:

DA (destination address) for the final destination,
SA (source address) for the original source,
RA (receiver address) for the MAC address of the device supposed to receive that frame,
TA (transmitter address) for the MAC address of the device sending that frame.

So for example, if you send from a station A to a station C via an AP B, the frame goes from A to B (during which SA=TA=A, DA=C, RA=B, then from B to C (during which SA=A, DA=RA=C, but this time TA=B). You see that we do not use the fourth address, because it would always be A, B or C repeated. Instead, we just position the addresses where they make sense.
Address 1 is always the device receiving the frame, Address 2 is always the device transmitting the frame, and Address 3 gives additional information about who the original sender was or who the final destination is supposed to be.

The only case where you use 4 addresses is when you have 2 relays... for example a wireless bridge: you packet goes from station A, through AP B, is relayed to another AP C in bridge mode over a wireless link, then goes to your final client D. Between these 2 bridges, you need to tell:
Address 1 = RA = C
Address 2 = TA = B
Address 3 = DA = D
Address 4 = SA = A.
This is a case of "4 MAC address header". In all other cases, you use 3 MAC addresses and the fourth MAC address field is not used.


Why do we care for WGB? Because the big question is: is your WGB a normal client, just like a laptop, or is-it more a sort of infrastructure device?
It all depends of course on what type of non-802.11 clients (and how many) connect through that WGB, and what you try to achieve.



- Universal vs Cisco mode:

During the association request phase, the WGB signals to the AP that it is a special client through 2 special vendor specific tags by the end of the frame and IAPP (inter AP messaging). So the AP knows that this is not a normal client... and this is good! Because as soon as that WGB will complete the association phase, it will start behaving very strangely: imagine, it is going to relay traffic to and from several wired clients. This means that your WGB, MAC address aaaa.bbbb.cccc authenticates, negotiates the keys and everything, and as soon as you say "OK, client aaaa.bbbb.cccc, your are in my cell", you start seeing packets coming from other MAC addresses, 1111.2222.3333 for example, using the same keys as your aaaa.bbbb.cccc client... and you are supposed to find all this perfectly fine and normal! Cisco access points are perfectly fine with that, as long as those packets still have the special WGB tag indicating that it is all coming through the same WGB... but many other vendor APs turn to panic mode and block the traffic (actually exactly as they should, as this is not a normal behavior).

If you want your WGB to associate to a non-Cisco AP, then you may have to moderate its WGB erratic behavior. This quieter mode is called the universal mode (as opposed to the "normal" mode, which is the Cisco mode). In this mode, the AP only displays one single MAC address, exactly like a normal client. No IAPP in this mode, but you can still see the Cisco vendor specific information in the WGB messages, just in case the AP would be a Cisco. The downside of this mode of course is that you can only bridge one non-802.11 client, the one having the MAC address displayed by the WGB.

When you configure the WGB, you define the Cisco or universal mode from the radio configuration section. In the CLI, use:

interface d0 (or d1)

station-role workgroup-bridge

or
station-role workgroup-bridge universal .

The has to be the wired MAC of the non-802.11 client talking through the WGB. The WGB will become transparent, and the only MAC address you'll see in the wireless space will be the MAC of the wired client. 

Few things to keep in mind:
- This wired client must exist. If the WGB does not detect that MAC address on its Ethernet interface, it associates to the WLAN using its own MAC address, which means that you see in the wireless space the WGB BVI1 MAC address instead of the client behind.
- When the non-802.11 client appears on the wired interface, the WGB disassociates then re-associates using this time the wired client MAC address.
- Are you really limited to one device in universal mode? Well not really, you are limited to one MAC address in the wireless space. If that address is the MAC address of a router connected to the WGB, and if you have 10 devices behind that router, fine! Only 1 MAC address is seen and all is well.


- Infrastructure-client:

By default, WGB are normal clients, okay we saw that. You can configure the AP to see the WGB as an infrastructure client. This is done from the radio configuration section. In the Web interface, in the radio page, this is called "reliable multicast delivery to the WGB". In the CLI, use:

interface d0 (or d1)

infrastructure-client

What does-it do? Well, two things:
- the first one, which is the most publicised, is that if the WGB is seen as an infrastructure client (which is NOT the default), then multicast (and broadcast) packets to the WGB are acknowledged (by the WGB). The advantage is that if you have several clients behind the WGB, you send one broadcast (or one multicast), then a second copy of that broadcast/multicast encapsulated into a unicast frame to the WGB and the ACK from the WGB confirms that the frame was received and is going to be relayed to the wired clients. This increases reliability (usually, broadcasts and multicasts are never acknowledged).. The downside is that it also increases traffic on the radio, as packets that are usually not acknowledged are now acknowledged (and you send as many unicast copies as you have WGBs). So the limitation of this mode is that the AP will not allow more than 20 WGB clients.
- The second one is that if your WGB is an infrastructure client, it can associate to an infrastructure SSID. Infrastructure SSIDs are SSIDs created only to authenticate other APs (bridges, repeaters, etc.). A WGB in standard mode (Cisco or Universal) is by default a "client", not an "infrastructure client" and therefore cannot associate to an infrastructure SSID. Make your WGB an infrastructure client and voila, it can magically associate now to infrastructure SSIDs.


Last detail:

- From a pure wireless standpoint, a question I often get: who is acknowledging those frames, when you have several clients behind the WGB? One of the clients? The WGB itself? The answer is: no-one! An ACK frame does not contain any SA or TA, just a RA...




- Multicast-mode client / infrastructure:

This one is usually happily confused with the previous one, as infrastructure client talks about multicast. But they do not do the same thing.
When you configure your WGB in Cisco mode (so NOT in universal mode, which is incompatible with this feature... well, you can always try, but you won't make them work together), in infrastructure client or not, the WGB will by default use 3 MAC addresses, pretending to be whatever non-802.11 it is relaying traffic for. In the scheme shown at the beginning of this post, you will see those various clients as if they each were wireless clients. The WGB relays their frames, pretending to be each of them in turn.

One downside of course is that the WGB is just a client, and a relay. In a worst case scenario configuration, suppose your WGB has 8 wired clients, and is set as infrastructure client. Bad news, you have 15 other WGBs with the same number of clients in your cell, each with 8 clients, so 128 clients in total... one of them is a phone, that needs music on hold, sent as a multicast frame... you see where this is going? The AP sends one frame, all 8 WGBs receive it, all 16 WGBs acknowledge that frame (nice collisions in your cell!), and as it is a multicast frame, all 16 WGBs relay that frame to all your wired clients, 127 of which don't care... is that efficient? Not really.
Yeah, that's also what they thought at Cisco. Although the fact that the WGB acknowledges or not is based on its infrastructure-client configuration, you still have 127 clients getting a frame they don't care about in any case.
So they built the multicast infrastructure mode. In that mode, multicast and broadcasts sent to a WGB use 4 MAC addresses, instead of 3 MAC addresses when using the multicast client mode.

What difference does that make? Well, if you configure your WGBs as multicast infrastructure, this is what happens:
The AP sends one multicast frame. The DA is the multicast address, but this time Address 1 is RA, the WGB behind which the phone sits (Address 2 is the AP or TA, Address 3 is DA, the multicast address, and Address 4 is SA, the original sender of the multicast frame). All 16 WGB receive that frame (coz they have no choice), 15 of them drop it because RA is not their MAC address, and only one WGB takes the frame, acknowledges it or not depending on its infrastructure-client configuration, then relays it to its wired interface. 8 clients receive it, 7 that do not care, plus our phone.
This mode is more efficient... in that case.

You configure that mode from the CLI with the command:

interface d0 (or d1)

station-role workgroup-bridge multicast mode {infrastructure | client}

Notice, again, that this mode is not compatible with Universal. Using station-role workgroup-bridge  multicast mode blahblah meansh that you say "station-role workgroup-bridge", which is the default, and not "station-role workgroup bridge unversal ".
There is no mode configured by default, which means that the WGB would accept any frames, with 3 or 4 addresses. You can force the mode one way or the other (3 addresses or 4) depending on the special case you try to solve.


- Mobile-station

WGB are not good roamers. They connect to an AP and stay there until they disconnect. If you WGB is mobile (on a cart in an hospital for example), you may need it to roam better. You can imrpove its roaming behavior with the CLI global config command:

mobile-station

When you enable this setting, the workgroup bridge scans for a new parent association when the RSSI to its AP gets too poor or when it has to many retransmits. This makes that the WGB will roam when its signal to the AP degrades. When the mobile station setting is disabled (the default setting) the workgroup bridge does not search for a new AP until it loses its current association. 



Additional tricks:

These two are borderline I would say, in the sense that you would not use them everyday... but there are cases when they can be useful:


- Scanned channels:

Just like a normal client, the WGB will scan all channels to discover an AP with the right SSID. This may take time, and be a waste of time if you use the classical channels 1/6/11 scheme. In this case, you can configure your WGB to only scan the channels on which you know that you have APs, instead of scanning all channels. This is done at the radio level, with the CLI command:

int d0 (or d1)
mobile station scan 1 6 11



- CCX neighbors

This setting is related to the channel scan. When the WGB scans, it actualizes its list of available APs. This is a CCX mechanism by which the WGB can transmit to its AP the details of the others APs the WGB heard. When you statically configure which channels to scan, the logic is that you know on which channels you have APs, so you don't need the WGB to tell you. You can therefore disable the CCX neighbor list building with the CLI command:

int d0 (or d1) 

mobile station ignore neighbor-list 

Wowoo, that was a long post, sorry for that. I hope it clarifies things... comment if you have any addition or question!
:-)

Autonomous APs: Network EAP vs. Open with EAP, the right combination

When configuring an SSID with EAP/802.1X on an autonomous AP, you are given the choice between Network EAP and Open with EAP (or both).

On the CLI, you would say:
dot11 ssid whatever
   authentication open eap eap_methods
   authentication network-eap eap_methods
As Cisco documentation (for example here) is... er... not completely clear (thanks Seth for pointing me to it!), if not completely wrong, here is a quick summary of which one to choose and when.

First, background information on why this is here (skip this part if you don't care about the whys and just care about the hows).
All this started at the time when we had "nothing (Authentication set to 0 in the AP beacons)" or WEP PSK (Authentication set to 1 in the AP beacons). WEP was weak, so everybody needed a replacement for it. Cisco implemented LEAP, which implies both au authenticaion mechainsm and some encryption. So Cisco set the Authentication value to 1 in the AP beacons using LEAP, not to indicate PSK but to indicate "authentication required" (and this is also why you cannot use LEAP with no encryption). But this does not really conform to the (future, when LEAP was created) 802.11i (and WPA) specifications, so this is Cisco specific...
Later on, when WPA and 802.11i appeared, the protocol detailed that, for compatibility with the 802.1X protocol, the authentication would occur at the association phase. In other words, with 802.1X you plug your PC to a switch, and it is only when you do that that authentication occurs. Similarly in the wireless space, you go through the 802.11 authentication phase (request/response) in an open manner, and it is only when you go to the association phase, which is the "hey, plug me to your cell" message, that the AP says "wait, I need to do 802.1X authentication first", and the EAP process starts. So, Authentication is set to 0 (for its 802.11 part), and EAP/802.1X starts at the association phase.
At the same time, in 2004, ASLEAP was released, and so was 802.11i, following WPA the year before. So when Cisco replaced LEAP with EAP-FAST, the information I have is that they conformed to the WPA/802.11i specifications, and Authentication is set to 0.

So, (whatever the documentation above says) Network EAP = LEAP. Open with EAP = Any other EAP. This is something you see when checking Network EAP: the popup window clearly states that if you use EAP-FAST or any other EAP (than LEAP), you should check Open with EAP. You can of course check both when you want to allow LEAP and another EAP, but you will not be able to authenticate using EAP-FAST if you choose Network EAP only...

There is one exception though... for long, LEAP used to be the default "secure" authentication method. This makes that some old Cisco clients (for example access points!) need to be offered LEAP to get started (or turned on, name it the way you like)!
In other words, if you build a wireless link between 2 APs, for a repeater, bridge or Workgroup Bridge configuration, and if you use 802.1X on that link, you need to offer LEAP (i.e Network EAP) for the secure authentication to be used. So you can offer Network EAP, or Network EAP and Open with EAP, but you should not offer just Open with EAP.
Which one is going to be used if you offer both? Well, it all depends on how you configure your client side (non root Bridge, Workgroup Bridge, etc). If you use the "old" EAP Client (optional feature), in the SSID page:

Which is in the CLI:
dot11 ssid whatever
   authentication client username jerome password 7 104D000A0618
This is going to use LEAP only.
If you want to use another EAP, for example EAP-FAST, you need to empty that EAP Client field (it cannot be used in combination with another method), then use the AP Authentication feature.

In this page, you define credentials and method. You can pick up several methods if you want.
Then from the SSID page, you can call these methods:

In the CLI, this is:
dot11 ssid whatever
   dot1x credentials jerome
   dot1x eap profile Myfast
exit
eap profile Myfast
 method fast
dot1x credentials jerome
 username cisco
 password cisco
So you offer both LEAP and Open with EAP, and using the newer AP Authentication method allows you to to use the credentials you defined, and use the most secure method selected. In this example, we use EAP FAST only, so that's the one we'll use. Of course, the RADIUS to which you main AP points (local RADIUS on the main APor external RADIUS) needs to allow that method.
Careful when testing, it is only from the non-root AP / WGB /  repeater CLI that you will use, at authentication time, which method was used. The main AP CLI will just tell you "WPA", or "Open", etc., but not the details of the authentication method used.
If you offer just Open with EAP, as the AP expects LEAP (Network LEAP) among the possibilities, then the EAP part is discarded. Although your link may come up, if you look carefully at your non-root AP CLI, you will see that the authentication is going to be "Open" (NOT with EAP), so there is no real authentication there. As soon as you also offer Network EAP, the non-root AP is happy, being offered LEAP, btu also something stronger, and is going to use the stronger method (EAP-FAST in our example)>
Give it a try in your lab!
;-)

13 reasons to reboot your access points or your controller

Do they hire people fr Microsoft at Cisco? I don't know, but I know for sure that there are more and more features that require you to reboot your controller or your access points. It is quite difficult to keep track of them in the lab, as you do not want to waste time rebooting too often. On the other hand, if you do not reboot, some changes will not take effect, and you will not always be able to test those changes. So here is a list of the changes I found that require a reboot. If you find more, add them to the list!

Access Points: well, those are obvious.

• AP mode: every time you change the AP mode (local to monitor for example), the AP reboots to reload the firmware matching its new mode. Good thing is the AP will popup to tell you it has to reboot.
• Static IP: whenever you switch your AP IP address from static to DHCP or back, from the controller interface, a popup asks you to reboot the AP. Funny thing is that if you change the IP address from the AP CLI (using clear lwapp ap ip address, to remove a static IP address, or lwapp ap ip address a.b.c.d , you just need a shut/no shut.
• Primary, etc.: if you change the AP primary/secondary/tertiary controller and want the AP to use this information, you need to wait for the AP to unicast a discovery message to that controller. Supposedly, this happens every 30 seconds, so whithin half a minute your AP should send an LWAPP keepalive message to that controller, then join it... if AP Fallback is set to Enable (Controller > General) on the current controller to which the AP is associated... well, you may want to reboot the AP to speed up the process and make the discovery more reliable, at least on code 4.2 (on 5.2 and up, seems to work a lot better).
• Webauth WLAN: when you create your first WebAuth WLAN, you need to reboot your APs for the certificate to feature to be enabled on them. This does not seem to be consistent between code versions, on 4.2.130, failure to reboot the APs seems to cause clients to fail to get the certificate warning page, unless you refresh many times. Good practices say "reboot your APs".
• Mesh AP and MAC filter list: no mesh in the lab yet... but for the sake of listing them all... if you have Mesh APs, and check or uncheck the MAC Filter List box in the Wireless > Mesh page (this parameter forces the AP to be authenticated through a MAC address list before being allowed to join the controller), all your mesh APs have to reboot to get applied this parameter. Supposedly they are supposed to reboot automatically... well, more than often, you may want to reboot those APs that forgot that they had to reboot automatically...

Controllers:

• SNMP user/communities: on the 2106 and code 4.2.130 and 4.2.207 at least, the SNMP communities and v3 users seem to be loaded at boot time. You may discover this painfully when trying to add your WLC to you WCS and get "No response from device, check SNMP communities, version or network for issues". Reboot the controller, things should be better. An interesting detail is that this "feature" (that's how we also call the Blue Screen of Death, right?) seems to be platform and code dependant. So you may have or not have this issue... but keep it in mind if you have an SNMP issue with a newly added SNMPv1/2c community or v3 user...
• Virtual Gateway interface: whenever you make any change to the Virtual Gateway Interface (changing its address or associated DNS name), you need to reboot the controller. The Virtual Gateway parameters are loaded at boot time and not refreshed (cannot change dynamically) during the active life of you controller.
• Certificates: whenever you change a certificate on the controller, you need to reboot the controller for this certificate to be loaded in RAM and used. This is true for any certificate (https access to your controller, WebAuth WLAN certificate, local certificate for EAP/802.1X authentication, etc.).
• LAG: if you set LAG to enable or disable, the change only happens next time you reboot.
• NTP server: controllers query NTP servers at boot time, and at intervals defined by the CLI command config time ntp (or on the Controller > NTP page, Polling Interval). The default interval is 24 hours (86400 seconds), a bit too long a wait most of the time. A quick reboot forces the controller to check the NTP server (I am of course assuming a lab environment, not a production environment).
• Max user database: when you change the maximum number of users in the database (from Security > General), this parameter will only be applied upon next reboot.
• Symmetric Mobility Tunnelling: when you enable or disable this feature (from Controller > Mobility Management > Mobility Anchor Config), you need to reboot the controller for this feature to take effect.
• Code and Config download: this is obvious, but whenever you download a new code to the controller or a previously saved config, you need to reboot the controller for those to be applied.

Don't reboot:

• Short/long preambles? Cisco documentation states that you need to reboot the controller if you enable or disable short preambles (in Wireless > 802.11b/g/n > Network). This is a myth (or a leftover from ooooold times). When you change this parameter, you clearly see in the AP beacons capability field the Short Preamble Allowed parameter switching from 1 to 0, and the "long -preamble only" stations failing or succeeding to associate accordingly (tried on an old handheld scanner).

So, in the lab, should you reboot every time you change one of those, or reboot once sometime during the day (for example at lunch break)? I am not sure there is an absolute rule. I find many people saying "reboot once, this will save you time". I like to multi-task. So I would rather reboot when I change one of these parameters, do another task then come back to finish this one. This will ensure that I can test the feature if needed, and that I do not leave too many things to verify when coming back from lunch...

7921: can you do WPA2?

You may have read different stories about the 7921 phone and its support for "strong encryption", that is AES-CCMP in a WPA2 logic. This is what the issue is:
The 7921 phone, until firmware 1.3(4), does support CCKM, WPA and WPA2, but not in any combination of those!
- WPA (TKIP) and CCKM work fine
- WPA (AES) and CCKM work fine, but this is bad practice (so that's a no no, unless you are specifically asked for this awful combination, coz after all, it's a lab, not real life)
- WPA2 (TKIP) and CCKM work fine, but this too is ugly, so another no no, unless they really insist.
- WPA2 (AES) and CCKM do NOT work together. What happens is that the phone does not take the roaming process well for the AES encrypted keys, and forces a full reauthentication.
In other words, you usually want to enable CCKM with Voice, because CCKM caches the key and allows for faster roaming (which is good for voice). But this does not work with the 7921 and a firmware older than 1.3(4).

So what should you do? Use WPA (TKIP) and CCKM, or WPA2 (AES) without CCKM? Well, all pushes you to use WPA (TKIP) with CCKM. The reason is that there is no reasonably usable  attack against WPA/TKIP encryption (provided you use 802.1X authentication, and not PSK), so TKIP is rather secure, and CCKM is definitely a plus for voice.

But all this is is you use a firmware older than 1.3(4). On 1.3(4) and later, you would prefer WPA2(AES) with CCKM, which is a supported combination on 1.3(4) and later. This firmware was released in its stable form at the end of May 2010. The CCIE W lab started a year before. So unless the hardware was updated in the lab (the lab blueprint does not specify a7921 specific firmware version), you will get firmware 1.2.1 and will have to go for the WPA/CCKM combination, if you have voice, 7921s and a requirement for strong encryption... but it may be worth checking!
On your phone, press the down arrow to access the tool box, then go to "6, status", then "4.Firmware version" to check the App Load ID, which will display the firmware with a value in the form CP7921G-1.2.1.LOADS.