I am currently preparing the Troopers network in a lab environment to ensure that we all will have a smooth Wi-Fi experience during Troopers. I wanted to spice things up a little bit for the Wi-Fi deployment (more on that in a following blogpost) and get rid of IPv4 wherever possible. Our Wi-Fi infrastructure consists of typical Cisco Access Points (1602) and a 2504 Wireless LAN Controller. Beginning with WLC image 8.0 it is finally supported to establish the CAPWAP tunnel between the AP and the WLC over IPv6, which is awesome and I wanted to implement it right away.
Before we delve into the details, a short refresher how an access point in the Cisco world learns the IP address of a controller. There’s four different variants you can implement:
- DNS (the APs try to resolve a specific DNS name)
- Multicast (when AP and WLC share the same broadcast domain)
- Manuel configuration on the AP
In the legacy world, I chose the DHCP route because it was the easiest to implement. You only have to configure DHCP option 43 in the DHCP pool and provide the IPv4 address of the WLC in hexadecimal notation like in the example below.
ip dhcp pool DHCP-TRP-NOC-v4-POOL network 172.20.40.0 255.255.255.0 domain-name troopers.net option 43 hex f104.ac14.280a default-router 172.20.40.1 lease 0 23
Pretty straight forward, and I wanted to go the same route for the IPv6 CAPWAP tunnel. For CAPWAP over IPv6 one has to provide a different DHCPv6 option (OPTION_CAPWAP_AC_V6 (52)) for the access points to find the WLC. I looked up the WLC IPv6 Deployment Guide for configuration examples, but it only provided examples for ISC and Windows Server 2008 DHCPv6 server, which was quite unfortunate and I didn’t understand the reasoning for this initially.
I proceeded to configure the DHCPv6 Pool on our ASR 1002 (running the latest code 15.5(3)S1a) and had the following configuration:
ipv6 dhcp pool TRP6-MGMT-POOL domain-name troopers.net vendor-specific 52 suboption 1 address 2A02:XXXX:F00:40::10
Again, seems pretty straight forward, but the configuration was not working as my APs did not learn the WLC address and hence couldn’t join. A quick look on the APs confirmed my assumption.
AP11#show ipv6 dhcp interface Vendor-specific Information options: Enterprise-ID: 52
After a little bit of google-fu and browsing through the Bug Tracker of Cisco I found this gem: CSCux73480. Turns out that the Cisco DHCPv6 router does not support DHCPv6 Option 52 despite the fact that you can configure it like any other DHCPv6 option. As the link to the Bug Tracker requires a Cisco login, here is an excerpt:
DHCPv6 option 52(RFC 5417) is not supported by IOS/IOS XE dhcpv6 server
Use CNR/Windows dhcp server.
As we can see, the “Enhancement” is only one month old. To be honest, I was a little bit surprised that I ran into this issue because I thought (maybe I was a little bit too optimistic or naïve) that in a homogeneous environment with latest greatest code it would just work as the DHCPv6 option was specified in 2009 (by Cisco themselves btw.). Now it makes sense that there was no configuration example in the WLC IPv6 Deployment Guide. But it didn’t mention that it isn’t supported on IOS/IOS-XE either.
Well, now I know better 😉
Sure I could use another DHCPv6 server, but I don’t want to install/configure/maintain another DCHPv6 server just for this option. Luckily, the amount of APs isn’t that large, so I will swallow the pill and may just manually configure the IPv6 address of the WLC on the APs.
Moral of the story: expect the unexpected 😉
If you want to hear more about IPv6 in Wi-Fi deployments or IPv6 in general don’t miss the IPv6 Security Summit! I’ll discuss our setup in detail there.
And if you have any suggestions or comments, please leave a message.
Everybody have a nice weekend,