IPv6 survival guide for CCIE Wireless candidates

Ipv6 is on the menu for CCIE W v2.0. If you have no knowledge about IPv6, fear not: there is not much you need to know to survive the exam on that topic.
I uploaded a youtube video on IPv6 configuration for the lab here, and here are the basics you need to know what you are doing:

• IPv6 format and addresses

IPv6 addresses are longer than IPv4 addresses, 128 bits (16 bytes) instead of 32 bits (4 bytes).  They are written in hex, instead of decimal format, for example 2001:0bc2:b3f0:0000:0000:dcba:0000:0021. Each group represents 2 octets, so a complete address is 8 groups of 2 octets each. Each group has 4 hex values.
To simplify the view, leading 0s are removed, so :0bc2: and :bc2: are the same.
You can also represent a group of 4 0s as "0". So :0000: and :0: are the same. You can also simplify several groups of 0s as "::", so :0000:0000: and :: are the same. This simplification can be done only once in an address. So you can simplify the address above as 2001:bc2:b3f0::dcba:0:21 or 2001:bc2:b3f0:0:0:dcba::21, but not as 2001:bc2:b3f0::dcba::21 (otherwise, there would be no way to tell how many groups of 0s does each :: represent).

• IPv6 address mask

The network mask structure is a bit more complex than for Ipv4. Theoretically, the first 48 bits (6 bytes) are the network mask, used for inter-ISP routing. The next 16 bits are used for subnets inside the ISP network. 48+16 = 64, we used half of the address for the network mask.
The rest (64 bits) is the client address.
This makes that your common mask for IPv6 networks is /64. It is written /64, not 255.255.255.255.255.255.255.255.0.0.0.0.0.0.0.0 (and you see why by the length of the standard decimal mask).
You can still find specific masks. Just like for IPv4, you can use longer masks (to a certain, limited extend) for subnetting, and shorter masks when you want to fix only a few bits in the network part of the address.

• Special addresses

Just like for IPv4, there are special addresses in IPv6, that you may want to be aware of:

fe80::/10: this is what is called the link-local address. Notice the /10 mask. Fe80 hex is 11111110 10000000 in binary, any address that has the first ten bits set to 11111110 10 is link local. So link-local ranges from fe80:: (all the other bits are 0s) to febf:ffff:ffff:ffff:ffff:ffff:ffff:ffff (11111110 1011111111... etc all ones to the end of the address). IPv6 generates a link local address immediately for any interface that has IPv6 enabled. It is only used on that link (not routed). You can configure it manually. If you don't, IPv6 uses the interface MAC address as the host part of the address. You can use this address to test the link (ping the device on the other end of the link), but you can't use it beyond the local link (you can't ping fe80:: addresses beyond a router). In IPv4, this address would be the equivalent to 169.254.0.0 APIPA addresses.

fc00::/7: this is the Unique Local Address (ULA is the little name). You will see that one often, because it is an address reserved for local, private space. It can be routed, but not to the internet. This is the equivalent to the RFC 1918 IPv4 address space (10.0.0.0/8, 172.16.0.0/12 and 192.168.0.0/16). Only the first 7 bits are fixed, so this space ranges from fc00:: (1111 1100 in the first byte) to  fdff (1111 1101 in the first byte, all the rest to 1s).
2000::/3: this is  a global unicast. This would be the equivalent to the IPv4 public address (but it works a bit differently).

ff00::8: this is  an IPv6 multicast address. Just like for IPv4, there are several well known IPv6 multicast addresses. This is the address that would be used if you were asked to forward IPv6 multicast traffic throughout your network alond with IPv4 multicast.

2001:: addresses: there are quite a few of them (2001:0000::/32 (Teredo), 2001:0002::/48 (benchmarking), 2001:0010::/28 (Orchid), 2001:db8::/32 (documentation)). They are used to translate IPv4 into IPv6 addresses (Teredo) for NAT, or for documentation and examples. They may be the ones used in your lab.

::ffff/96: this is another possible address you may be given. It is called the IPv4-mapped address, because it allows you to represent an IPv6 by using an IPv4 structure. For example, you can use ::fffff:192.0.2.7. As you can see, if your IPv4 address is 192.0.2.7, using an IPv6 address that is just the same with leading ffff makes it very easy for lab work.

You probably do not need to know much about these addresses for the IE wireless exam. You will probably be given a range of IPv6 addresses, and will just be asked to work your wireless gear to support them. Knowing the basic IPv6 address format will help you understand what was the reasoning behind the choice of the IPv6 block given to you: multicast, private address, etc.

• Testing IPv6

In the lab, you can expect to be asked to support Ipv6 connectivity, not to be asked to be an IPv6 guru and configure complex Ipv6 routing parameters, or even IPv6 to Ipv4 translation mechanisms.
If you want to test basic IPv6 connectivity to get a better grasp at how it works, you need a simple router, a basic switch and a laptop. Your windows 7 laptop already supports IPv6 on its interfaces:

You just need to keep it set to DHCP, and configure an IPv6 IP address and DHCP server on your router, just like in the video. You should see the client get an IPv6 address. The switch is layer 2, so it does not care about the IP address format above the Ethernet layer.
On your router, you need to enable Ipv6:

Router#conf t

Router (config)# ipv6 unicast-routing

Once IPv6 is enabled, you can create a DHCP scope for IPv6. For example, suppose that you want to create a DHCP scope for subnet FC0:6::/64. You first create the scope:
Router (config)# ipv6 dhcp pool vlan6
Router (config-dhcp)# prefix-delegation FC0:6::/64 64

Depending on your router IOS, the command used to provide the subnet information is prefix-delegation, followed by the subnet (fc00:6::/64 here) and an identifier (64 here), or the command addres-range followed by the subnet (which is the command we use in the demo video).
You do not need to add anything else (the router is going to announce the scope, and announce itself as the gateway), although there are some options you can add. But for wireless, the scope is the bare minimum you need to make it work.

Then, on the router interface to the switch, you need to create a subinterface, so that the switch can send tagged frames with VLAN 6 tag to the router. You then need to give your router an IPv6 address in VLAN 6 (you can also give an IPv4 address, if you want a point of reference to something you know), and you need to call for the DHCP scope, so the router starts providing addresses from that scope to DHCPv6 requests received on that interface:
Router (config)# interface FastEthernet0/0.6
Router (config-if)# encapsulation dot1Q 6
Router (config-if)# ipv6 address FC0:6::15/64
Router (config-if)# ipv6 dhcp server vlan6

Done, you can now plug your laptop to the switch, in an interface set for VLAN 6, and your laptop should get an IPv6 address from the router.


This is of course on the wired interface. The logic is the same for the wireless interface, except that the laptop would go through an AP and a WLC before getting to the VLAN6 dynamic interface on your controller, then to the switch and the router. The rest... is about wireless...

WLAN controller Local EAP profile vs external RADIUS server

You probably know that the the local EAP profile you can configure on a controller is a backup... it will be used only if no external RADIUS is defined for user authentication on the controller, or if the defined RADIUS cannot be reached. In other words, when you define a Local EAP profile on a controller that also has RADIUS servers, the order is as follows:
1. Try to use the RADIUS server defined in the WLAN
2. Try to use any RADIUS server defined in Security > AAA > RADIUS > Authentication.
3. If all this fails, try to use the local EAP profile.

Let's play with this idea:

With this WLAN configuration, am I going to use the 10.100.1.30 RADIUS server or the local EAP profile?
Did you answer the 10.100.1.30 RADIUS server? Well, almost right... but I first need to check that server:

Oops, Network User is NOT checked for 10.100.1.30. This supposedly means that I cannot use this RADIUS server for wireless client authentication (only for management users authentication)... but I called that server from the WLAN, so this global "Network User unchecked" parameter does not matter (thanks Stoef and Anonymous for this comment): because the RADIUS is called directly from the WLAN, the WLAN is going to try to use it anyway. But because Network User is unchecked globally, any other WLAN trying to use the global RADIUS server list (i.e. not having the RADIUS called directly from the WLAN) is going to skip that one RADIUS.
Things would be different if the RADIUS was disabled:

In this case (regardless of Network User being checked or not), I may be calling 10.100.1.30 from the WLAN, but the RADIUS is disabled, and cannot be used, and will be ignored.
Okay, so my controller is going to revert to plan 2, try to use any RADIUS server configured for Network User authentication in Security > AAA > RADIUS > Authentication.
Cool, there is one there (172.29.129.156), matching my criteria (Network User is checked, and the RADIUS server is enabled).
So, my controller is going to use it... or is it? If I look into Management > SNMP > Trap Logs:

Ooh, this is not my lucky day, 172.29.129.156 is not responding, so the controller removed it from the active server list (172.29.129.156 still has the "enabled" status in the RADIUS > Authentication page, this "enabled" status just means that you, the admin, intended to use this RADIUS, not that the controller can actually talk to it successfully).
Ok, then the controller is going to use the local EAP profile. I can see that by running the debug aaa local-auth db enable command:
*aaaQueueReader: Dec 02 16:21:49.385: LOCAL_AUTH: EAP: Received an auth request
*aaaQueueReader: Dec 02 16:21:49.386: LOCAL_AUTH: Creating new context
*aaaQueueReader: Dec 02 16:21:49.386: LOCAL_AUTH: Created new context eap session handle 94000011
*aaaQueueReader: Dec 02 16:21:49.386: LOCAL_AUTH: (EAP:18) Sending the Rxd EAP packet (id 1) to EAP subsys
*EAP Framework: Dec 02 16:21:49.386: LOCAL_AUTH: Found matching context for id - 18
*EAP Framework: Dec 02 16:21:49.386: LOCAL_AUTH: (EAP) Sending user credential request username 'cisco' to FILE
*aaaQueueReader: Dec 02 16:21:49.386: User cisco information retrieved
*aaaQueueReader: Dec 02 16:21:49.386: AuthorizationResponse: 0x2c190b9c

A lot of "LOCAL_AUTH" stuff is happening here, I am definitely using the controller local EAP.
Would have this happened anyway, even with a RADIUS server?
Nope, as soon as I re-enable my RADIUS server:

The authentication occurs on the RADIUS server, and I can see the result on my ACS server (if authentication was local to the controller, I would not see any hit on the ACS... you can try at home, the best way to try is to create one user on the controller, and another on the ACS, and see which one works depending on your configuration changes):

So, in summary, do not get caught by the appearences. Your controller will always ("always", that is on code 7.0.x) prefer an external RADIUS server to the internal local EAP profile, whatever your WLAN configuration looks like.
The WLC will revert to the local EAP profile ONLY if no external RADIUS can be used (external RADIUSes are not configured for network user authentication, or no external RADIUS answers). Always verify "the rest" (RADIUS servers configuration and reachability)  before trusting the WLAN configuration nicely displayed before your candid eyes... :-D

Stay tuned and sister blog

This blog has been very silent for the past few months. I did not want to post entries that would be too early for the CCIEW v2.0, and too late for the ones rushing to take the exam before the change.
But stay tuned! I will soon start re-posting new entries, this time entirely focused on CCIEW v2.0. With the zillions of questions I received so far, there seem to be tons of gotchas in this new exam.
I will also restart posting videos on the youtube channel soon.
Also, I received over the last few months many questions related to wireless, but not directly to the CCIE exam. To make things simple, I created a sister blog, where  I will post entries that will give you the background you may need to understand the "why" (and not the "how") of some configuration items present on the Cisco wireless solution. This sister blog is here: http://expertwireless2be.blogspot.com/

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... :-)