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

Sunday, December 18, 2011

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

Friday, December 2, 2011

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