Setup an IPv6 Tunnel through Hurricane Electric on a Cisco Router

I've setup my home network with an IPv6 tunnel through Hurricane Electric. The process is pretty straight forward and I'll share my learnings with you in this post.

How a Manual IPv6-in-IPv4 Tunnel Works
Using an IPv6-in-IPv4 tunnel through Hurricane Electric is useful when your current ISP doesn't offer native IPv6 service or tunneled 6rd service yet. In this case, you need to tunnel IPv6 traffic across an intermediate IPv4-only network (or the Internet). I setup my tunnel broker account through HE as an initial step in learning IPv6 prior to switching to the IPv6 service offered from my current ISP (CenturyLink). In a future post, I'll describe setting up the CenturyLink 6rd tunneling service, which will be slightly different.

The HE tunnel broker service uses a manually configured IPv6-in-IPv4 tunnel. It's pretty straightforward to understand how this works. You will define an IPv4 tunnel source (your local dual-stack router's WAN interface), an IPv4 tunnel destination (the HE dual-stack router), and a default route on your local router that directs all IPv6 traffic across the tunnel. All IPv6 traffic will be encapsulated inside an IPv4 packet and sent across the IPv4-only network. When the frame reaches the tunnel destination router the outer IPv4 header is stripped off and the IPv6 packet is forwarded to it's destination.

Manual IPv6-in-IPv4 Tunnel

There are a few things you'll need before you get started:

• A static IPv4 address from your ISP - preferred for a manual IPv6-in-IPv4 tunnel so the tunnel destination router can encapsulate return traffic back to your local router. You can use a dynamic IPv4 address, but it requires updating the tunnel definition every time it changes (see this FAQ).
  
• A dual-stack capable router - in my case, I'm using a Cisco router. 

Setting Up the Tunnel Broker Service
There are a few steps involved in setting up the tunnel broker service.

1. Create an account at http://tunnelbroker.net
   Enter a username and password in the login box and click the "Register" button. Fill in your information to complete the process.
   
   
2. Create a new tunnel
   Click the "Create Regular Tunnel" link in the User Functions section. You'll need to enter the IPv4 address of your local router's WAN interface, which must be a publicly routable Internet address (not a private RFC 1918 address). Then select a tunnel server from the list below. This will be the tunnel destination router that Hurricane Electric provides to terminate your tunnel service. I recommend selecting the closest server to your location for lowest latency performance. Click the "Create Tunnel" button on the bottom of the form.
   
   

   

   Hurricane Electric Regular Tunnel Creation

3. View your tunnel details
   You will need to take note of a few items that will be used when configuring your local router:
   - Server IPv4 Address - will be used as the IPv4 tunnel destination.
   - Server IPv6 Address - for reference only as the IPv6 tunnel endpoint.
   - Client IPv4 Address - will be used on your local router's WAN interface as the tunnel source.
   - Client IPv6 Address - will be used on your local router's tunnel interface to establish a neighbor relationship with the server's IPv6 address on the other end of the tunnel.
   - Routed /64 - this is the /64 network prefix that you can use internally on your local network for IPv6 capable hosts.
   - Available DNS Resolvers - you can use these ISP provided IPv6 DNS capable servers to lookup IPv6 resources on the Internet (such as web servers, mail servers, etc.). Or you could alternatively use any public IPv6 DNS servers (such as OpenDNS or Google).
   
   

   

   Hurricane Electric Tunnel Details

4. Optionally - assign a /48 prefix to your local network
   If you need more than one IPv6 routed prefix on your local network, Hurricane Electric can assign you an entire /48 prefix, which will be routed across the tunnel. You can then break into smaller network prefixes for use on multiple links in your local network. To assign a /48 prefix, click the "Assign /48" link.

Setting Up Your Cisco Router for IPv6
Next, we'll need to configure your local Cisco router.

First, enable IPv6 routing and Cisco Express Forwarding (CEF):

ipv6 unicast-routing
ipv6 cef

Second, you'll want to create a tunnel interface for the link to the Hurricane Electric tunnel broker service.

interface Tunnel0
 description Hurricane Electric IPv6 Tunnel Broker

 # No IPv4 address will be on the tunnel interface
 no ip address

 # Enable IPv6 on the interface
 ipv6 enable

 # Assign a Global Unicast Address to the Tunnel interface.
 # Use the Client IPv6 Address assigned to you by Hurricane
 # Electric. This will allow your router to establish a neighbor
 # relationship with the other tunnel endpoint router,
 # referenced as Server IPv6 Address.
 ipv6 address 2001:470:XXXX:XXXX::2/64

 # Set an IPv6 MTU that adjusts for the 20-byte IPv4
 # encapsulation caused by the tunnel. This prevents
 # dropping packets and sending back an ICMP 
 # Packet-too-Big error. I have a PPPoE link and reduce
 # the MTU another 8-bytes. 1500-20(IPv4)-8(PPPoE) = 1472.
 ipv6 mtu 1472

 # You may want to secure your local network using an
 # IPv6 ACL and traffic inspection. I'll cover these in 
 # a subsequent post.
 ipv6 inspect v6firewall in
 ipv6 inspect v6firewall out
 ipv6 traffic-filter v6Outside_ACL in

 # Configure the tunnel mode as a manual IPv6-in-IPv4 tunnel.
 tunnel mode ipv6ip

 # Configure the tunnel source and destination IPv4 endpoints.
 # The tunnel source is the IPv4 address on your local router's
 # WAN interface. The tunnel destination is Server IPv4 Address
 # provided by Hurricane Electric.
 tunnel source 63.224.XXX.XXX
 tunnel destination 184.105.253.14

Next, install a default route for all IPv6 traffic originating from your local network to traverse the tunnel.

ipv6 route ::/0 Tunnel0

Configure a stateless DHCPv6 server to assign IPv6 DNS servers and a domain suffix to clients so they can resolve hostnames to IP addresses. A stateless DHCPv6 server does not hand out IPv6 addresses to clients or maintain a binding database. In my setup, I'll be using SLAAC to allow clients to autoconfigure addresses on the local link based on the prefix(es) advertised by the router in ICMP Router Advertisements. You can use the ISP provided DNS servers or any public server as mentioned previously.

ipv6 dhcp pool DHCPv6
 dns-server 2001:470:20::2
 domain-name yourdomain.com

Configure a local LAN interface with the routed IPv6 network assigned to you by Hurricane Electric. This may be the /64 prefix originally assigned to your network or a smaller portion of a /48 if you requested one (break the /48 into smaller /64 prefixes for multiple internal network links). This interface is typically a dual-stack interface, meaning it will support both IPv4 and IPv6 clients. This is important to allow clients to continue to use IPv4 to access services which are not yet available over IPv6.

interface FastEthernet0/0
 ip address 192.168.1.1 255.255.255.0
 ip nat inside
 ip virtual-reassembly in

 # Enable IPv6 on the interface
 ipv6 enable

 # Configure the assigned /64 prefix from Hurricane Electric
 # on the local LAN interface.
 ipv6 address 2001:470:XXXX:XXXX::1/64

 # Advertise a smaller IPv6 MTU than the default 1500 bytes
 # in order to account for tunnel overhead. The minimum IPv6
 # MTU is 1280 bytes and is a safe bet. This prevents dropping
 # packets due to IPv6 tunneling mechanisms.
 ipv6 mtu 1280

 # Advertise the ability for clients to configure other
 # parameters such as DNS by setting the other-config-flag
 # in Router Advertisements.
 ipv6 nd other-config-flag

 # Assign the previously defined DHCPv6 server to this interface.
 ipv6 dhcp server DHCPv6

The configuration of the IPv6 MTU on the local LAN interface is important because Path MTU discovery often does not work across the Internet when stateful security devices block ICMP Packet-too-Big error messages. Even if your tunnel supports a higher MTU than the minimum 1280 bytes, such as 1472 bytes, you may run into situations where some IPv6 Internet resources still require a smaller MTU because tunneling occurs elsewhere along the route.

Testing It All Out
Once you've got your tunnel established and local LAN configured, let's test it out.

Ping from your WAN interface across the tunnel. This will verify IPv6 reachability across the tunnel between the two tunnel endpoints.

cisco-router#ping 2001:470:XXXX:XXXX::1   
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2001:470:XXXX:XXXX::1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 32/32/32 ms

Connect a client to your local LAN. This will verify that a client is properly receiving an IPv6 address from your router. Here is an example using an Apple MacBook Pro connected to an IPv6 network over Wi-Fi:

Apple MacBook Pro IPv6 Network Connection

You will notice that the Cisco router sends Router Advertisements (RA) using it's link-local address in the fe80::/16 address block. Embedded in the RA is information about the network prefixes configured for the link, whether or not clients should use auto-configuration (SLAAC) to obtain an address, and the other-config-flag related to stateless DHCPv6 for DNS and domain suffix assignment. Most modern clients will auto-configure two global IPv6 addresses: one using the EUI-64 format based on the Ethernet MAC address on their interface, and one using the auto-generated random method for security and privacy. Hosts will typically prefer the random address when initiating sessions with other hosts.

vonNagyMBP13:~ andrewvonnagy$ ifconfig en1
en1: flags=8863 mtu 1500
ether 68:xx:xx:xx:1b:f0 
inet6 fe80::6axx:xxff:fexx:1bf0%en1 prefixlen 64 scopeid 0x5 
inet6 2001:470:XXXX:XXXX:6axx:xxff:fexx:1bf0 prefixlen 64 autoconf 
inet6 2001:470:XXXX:XXXX:4d2f:7cb8:221c:f6a1 prefixlen 64 autoconf temporary 
inet 192.168.1.100 netmask 0xffffff00 broadcast 192.168.1.255
media: autoselect
status: active

You can also check the DNS settings on the host to ensure stateless DHCPv6 worked properly.

Apple MacBook Pro IPv6 DNS Server(s) and Domain Suffix

Next, ping the remote tunnel endpoint from the local LAN host across the tunnel. This will verify the routing for your assigned network prefix is working properly across the tunnel. Tip: be sure to use the correct ping6 command on Mac OS X!

vonNagyMBP13:~ andrewvonnagy$ ping6 2001:470:XXXX:XXXX::1
PING6(56=40+8+8 bytes) 2001:470:XXXX:XXXX:4d2f:7cb8:221c:f6a1 --> 2001:470:XXXX:XXXX::1
16 bytes from 2001:470:XXXX:XXXX::1, icmp_seq=0 hlim=63 time=35.977 ms
16 bytes from 2001:470:XXXX:XXXX::1, icmp_seq=1 hlim=63 time=33.656 ms
16 bytes from 2001:470:XXXX:XXXX::1, icmp_seq=2 hlim=63 time=32.902 ms
16 bytes from 2001:470:XXXX:XXXX::1, icmp_seq=3 hlim=63 time=35.838 ms
16 bytes from 2001:470:XXXX:XXXX::1, icmp_seq=4 hlim=63 time=35.926 ms
^C
--- 2001:470:1F10:36::1 ping6 statistics ---
5 packets transmitted, 5 packets received, 0.0% packet loss
round-trip min/avg/max/std-dev = 32.902/34.860/35.977/1.313 ms

You might want to try resolving a AAAA DNS record:

vonNagyMBP13:~ andrewvonnagy$ dig @2001:470:20::2 www.google.com AAAA

; <<>> DiG 9.8.1-P1 <<>> @2001:470:20::2 www.google.com AAAA
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- 14297="" font="" id:="" noerror="" opcode:="" query="" status:="">
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;www.google.com. IN AAAA

;; ANSWER SECTION:
www.google.com. 52 IN AAAA 2607:f8b0:4009:802::1010

;; Query time: 38 msec
;; SERVER: 2001:470:20::2#53(2001:470:20::2)
;; WHEN: Tue Aug 13 15:24:33 2013
;; MSG SIZE  rcvd: 60

Finally, try hitting an IPv6 test website. A good one for North America is the North American IPv6 Task Force website. Look for the image of a turtle in the right sidebar along with detection of the IPv6 address being used by your host. You can also try hitting the Google IPv6 test webpage or http://test-ipv6.com/.


Cheers,
Andrew



Additional IPv6 posts you might be interested in:

• IPv6 Refresher: The Need for IPv6 and Address Format
• IPv6 Refresher: Unicast Addressing
• IPv6 Unicast Address Allocation

My IPv6 Mission

I've decided that I've procrastinated long enough. Therefore, over the next few months I'm on a mission, an IPv6 mission. I'll be reading as much material as I can get my hands on, deploying native IPv6 on my home network (including WLAN), and connecting to Hurricane Electric's tunnel broker service for native IPv6 Internet access.

To help me get started, I've acquired the following resources:

Cisco 871W Router This router is a bit older, but it was easy to acquire, can run dual-stack IPv4 and IPv6 which gives me support for both protocols in my home (because not all of my clients support IPv6, like my Roku and Wii), and it is still receiving software upgrades from Cisco. I won't be using the integrated radio in this unit since it's ancient by fast-moving Wi-Fi standards (802.11g only; when this unit first came out it didn't even support AES-CCMP... so yeah, the radio hardware is a bit old).

Aerohive AP 330 (x2, and one AP 170) Let's not overlook IPv6 for our Wi-Fi clients! I already have an Aerohive WLAN at home, and it supports IPv6 client access. The AP 330s have two 3x3:3 MIMO radios, full enterprise-class features, and mesh networking which I've extended out to my garage (hey, the man garage cave needs streaming Internet radio while I'm working on my motorcycle)!

IPv6 Essentials, 2nd Edition

Deploying IPv6 Networks

IPv6 for Enterprise Networks

I'll be posting what I learn as I go on this blog. I'll also be tweeting what I learn and my progress using the #IPv6Mission hashtag on Twitter. 

Follow along if you're new to IPv6, and I hope you enjoy! Even if you are familiar with IPv6, I'll be covering specific implementation details for Wi-Fi networks, which can be a bit different animal than wired IPv6 (there are a few gotchas that you'll need to be aware of - but let's save those for another post). And for those IPv6 experts out there, I may just need some help from time to time :)

Cheers,
Andrew

Cisco H-REAP Local Authentication Improvements

A while back I wrote about Cisco H-REAP, how it works, and some considerations and feature limitations.

As a follow-up, I'd like to briefly cover some recent changes in how H-REAP access points perform client authentication, specifically with the H-REAP Local Authentication features since this topic is confusing for most engineers (in-part because of the name).

H-REAP Local Authentication in code version 7.0.116.0 encompasses three distinct options for authentication of clients when "connected" to a WLC or "standalone".

Backup RADIUS Servers (AP as NAS)
This is the long-standing H-REAP feature that allows the AP to source RADIUS authentication to external 'backup' RADIUS servers when in standalone mode and the WLC in unreachable. In this scenario, the AP is the authenticator which forwards requests to the authentication server (RADIUS server). The authentication server must have the APs defined as a NAS.

This permits the APs to accept new clients and successfully complete authentication without reliance on the WLC. This is really a high availability feature for the WLAN to prevent an outage if one or multiple controllers fail.

Define the H-REAP backup RADIUS servers from the H-REAP Group:

H-REAP Backup RADIUS Servers

Update - Based on feedback in the comments, it should be pointed out that the AP and RADIUS server must use the same shared secret as configured on the wireless LAN controller. The AP inherits the RADIUS server definition and configuration from the controller, and it cannot be configured separately. This applies to both AP as a NAS situations.

Local Authentication (AP as RADIUS)
This feature allows the H-REAP access point to assume the role of both the authenticator and the authentication server (RADIUS server). The AP is required to have local users defined and only support a few EAP types, notably EAP-FAST and LEAP.

This feature is what most engineers describe this feature as meaning, without knowledge of the 3rd option below. Having locally defined users and restricted EAP types makes this option not all that attractive for most organizations, but there are some who have obviously requested it from Cisco. It beats static pre-shared keys for security, but creates administrative burden on network administrators to define and manage local users on the H-REAP APs.

Many organizations already have user accounts stored in corporate directory systems such as Active Directory, and definition of users in an alternate database is not preferred or allowed. That said, this feature doesn't make a lot of sense for user accounts tied to real people since corporate security policies usually dictate that passwords are rotated regularly and support personnel don't have access to those passwords, preventing them from being replicated on H-REAP APs. However, it may make sense for non-user IDs attached to embedded devices such as IP phones, Vocera badges, or handheld scanners.

Enable H-REAP Local Authentication (AP as RADIUS) in the H-REAP Group:

Enable H-REAP Local Authentication by the AP

Additionally, define local users and configure EAP-FAST and LEAP:

H-REAP Local Auth User Definition

Local Authentication (AP as NAS)
Historically, when the H-REAP AP was connected to a WLC, all authentication flowed through the controller. In code version 7.0.116.0 this changed. Now administrators can configure H-REAP APs to source client authentication and bypass the WLC, even in connected mode. This is beneficial when the AP is logically closer to the RADIUS server than the WLC and should source authentication itself to improve performance. A remote site that contains both H-REAP APs and a RADIUS server, with a centralized controller across the WAN is one example.

Enable H-REAP Local Authentication (AP as NAS) in each WLAN:

Enable H-REAP Local Authentication in the WLAN

When this option is enabled, the AP sends client authentication requests to servers in this order:

1. WLAN AAA Servers
2. H-REAP Group Backup RADIUS Servers (primary/secondary)
3. AP Local Authentication (local users on the AP)

One other quick note is that the H-REAP APs also support RADIUS fallback. So if a primary RADIUS server fails and subsequently comes back online, the AP will recognize this and begin sending client authentications back to the preferred server.

Hopefully this clarifies some of these new features that aid both high availability and performance.

Cheers,
Andrew

Cisco Sunsets 1250 Series Wireless APs and the CSSC Supplicant

The Nasty Smell of a Cisco 1250 Series AP

Ah, the smell of dying product. It's quite distinct, as "once promising" products that were shiny and new not that long ago are quietly sent off to into the sunset, never to ship again. It's a fond time to look back and remember all the marketing material and product hype that pre-sales teams attempted to sell to customers. While some products hold true to their hype and live a long healthy lifespan, others, well... just don't quite ever live up to the expectations and the benefits never quite materialize.

The end of sale / end of life announcements for the Cisco 1250 series APs (Aug. 1, 2011) and Cisco Secure Services Client (CSSC) (July 30, 2011) are examples of the latter; products that never quite fulfilled the vision they were sent out to market with.

The 1250 series APs were released in early 2008 prior to the official ratification of the IEEE 802.11n amendment. At that time, the Wi-Fi Alliance was already certifying 802.11n Draft 2.0 equipment but fear remained (to a certain extent) in the industry around compatibility with the final ratified standard. To that end, Cisco released the 1250 series as a modular dual-radio 11n AP that offered field-upgradability by customers should the final standard prove to be incompatible. Those fears were largely unfounded, as the final amendment was released in Sep. 2009 and proved to be fully backwards compatible.

While the 1250 series excelled as a rugged business-class 802.11n access point providing MIMO, high throughput data rates, better signal quality, and flexible antenna options, it failed spectacularly in product vision. The need for modular hardware never materialized, and Cisco never released upgraded radios as there was never a need to do so. Additionally, product design choices required additional investment by customers to realize the full capabilities of the device. First, higher power draw of 18.5W is required in order to support both radios operating with two spatial streams. Customers without a Cisco proprietary POE+ switch were forced to make a trade-off: power the APs using power injectors or a local power supply, or operate without full 11n MIMO capabilities. Second, the product weighed in at a very hefty 5.1 pounds which created a safety risk if not installed and mounted with proper strain relief. This further increased solution expense for customers requiring additional parts, time, and labor to properly install this husky AP.



The final nail in the coffin came with the removal of the 1250 series from the CCIE Wireless version 2.0 blueprints this past May.

The Cisco Secure Services Client (CSSC) was born out of the 2006 acquisition of security vendor Meetinghouse and their AAA software product line, which included the Aegis SecureConnect wireless supplicant. This was in direct response to Juniper's acquisition of Funk and their Odyssey client package, which was at the time the Cisco recommended solution for clients.

The CSSC client was late to market and wasn't formally unveiled until 2007, but by then the market had matured and customers had found adequate alternatives elsewhere. This was Cisco's first attempt at a unifed software package to provide an 802.1X authentication framework for both wired and wireless networks, as well as VPN connectivity.

However, CSSC never took hold with customers and made minimal market impact. The software was burdened with poor end-user usability and difficult administration and maintenance, requiring administrators to use a separate management utility to pre-define configurations, create packages, and bundle license keys for enterprise deployments. In addition, 802.1X timer settings within the software often caused usability and support issues post deployment if administrators were not careful to modify default values. Common problems included the pre-mature failover to secondary or subsequent network profiles if authentication and DHCP did not complete within default strict timer settings.

The CSSC Was Not Particularly "User-Friendly"

So, it's long past due that Cisco sunset these products, retire them to pasture, and move forward with alternative solutions. The emergence of the ruggedized Cisco 1260 series APs and the Cisco AnyConnect client have superseded the need for these products. The quality of native operating system supplicants within Windows 7 and Mac OS X also obviate the need for 3rd party supplicants to a large extent.

I bid adieu, willingly and gratefully!

Cheers,
Andrew

Cisco Live! 2011 Wireless & Security Recap, and an Apple Rumor

Last week at Cisco Live! 2011 I attended several sessions related to wireless LAN products and would like to provide a review of the major technical announcements that I took away from these presentations. Due to the overwhelming amount of technical content provided over the course of the 6 days, I won't be providing detailed recaps of each session. However, there were several major announcements that could impact customer roadmaps that I would like to discuss.

You can also read my article on value of live events on professional development and networking on the Cisco Mobility Blog.

CCIE Wireless Version 2 - On Sunday, several of my peers attended a CCIE-W techtorial which discussed the changes to expect in v2 of the written and lab exams. I did not attend this session, but you can find excellent recaps of the information presented by Jason Boyers (IPExpert), George Stefanick (my80211.com), and Blake Krone (Digital Lifestyle). You can also find my previous review of the v2 blueprint changes.

Some of the interesting facts that I caught from other included the relative scarcity of CCIE Wireless engineers - only 45 total worldwide, and only 27 outside of Cisco. Small numbers indeed!

ISE / TrustSec Overview - Several salient details of the new ISE platform include:

• ISE bundles multiple systems under one product, including ACS, NAC Manager, NAC Server, NAC Profiler, NAC Collector, and NAC Guest Server. These roles can all be installed on a single ISE instance or split between multiple ISE instances.
• ISE is out of band and provides central policy definition and enforcement.
• ISE focused on determing both device and user identity for complete contextual policy definition and enforcement. It supports a myriad of EAP types, similar to the Cisco ACS product.
• ISE also provides policy management for non-802.1X capable clients via MAC Auth Bypass (MAB) and/or web-authentication, which is important for wired network security. 802.1X timeouts will need to be tuned much shorter than the default of 90 seconds to allow MAC Auth Bypass and DHCP processes for non-802.1X clients to continue un-interupted, prior to device profiling and policy enforcement. Pre-auth ACLs can also be defined to limit access until device profiling and policy assignment can occur (PXE boot is one scenario to consider).
• Flex-Auth aims to allow a single port-configuration to accommodate client devices of all types (802.1X, MAB, web-auth) to ease switch port management. Failover behavior betweent authentication types can be defined to meet customer requirements.
• ISE supports device profiling using many different methods, including 802.1X authentication parameters, MAC address OUI lookups, DHCP options via SPAN port / IP helper / proxy, reverse DNS lookups, HTTP user-agent via SPAN port / captive web portal on ISE, NetFlow v5/v9, and SNMP queries & traps.
• Device profiling is hierarchical, can define generic categories then drill into more detailed profiles if desired to apply more specific policies. (Example: IP Phones > Cisco IP Phones > Cisco 7960 Series).
• Device profiles can be created using combinations of gathered information from the previous bullet point to provide a more educated interpretation of what the device is. This should help reduce false positives and false negatives as well as make it difficult for someone to spoof multiple device capabilities.
• ISE fully supports RADIUS Change of Authorization (COA) which allows dynamic policy changes in the middle of client sessions if the environment changes. Previously, only support for initial policy assignment upon the initial network access attempt was supported. COA can include client disconnection, re-authentication, port bouncing, or port shutdown. Note that the WLCs support COA as of version 7.0.116.0 code.
• It supports authorization & policy management via dynamic VLAN assignment, dynamic ACL assignment, downloadable ACLs, and Security Group ACLs.
• ISE provides a new security paradigm based on Security Group Access (SGA). SGA relies on Security Group Tagging (SGT) which is hardware ASIC dependent. SGTs are assigned based on successful RADIUS authentication and attribute assignment back to the network access device.
• Older equipment such as the 3750 switches do not support full Security Group Tagging. Such platforms will rely on a software upgrade to support the SGT eXchange Protocol (SXP) which will relay IP address to SGT mappings to neighboring equipment which do support SGT. This allows end-to-end network-wide support for the Security Group Access model and a migration path without forklifting existing equipment. Note that the wireless LAN controllers will support SXP with code version 7.0.116.0 and later. For a full list of hardware and software compatibility, see the Cisco TrustSec SGA Solution Config Guide.
• SGA simplifies network security policy enforcment with ingress SGA tagging, and egress SGA enforcement based on both the source and destination SGT combinations. This reduces the need to distribute policy definition throughout the entire network, simply enforce security for central servers and data stores once at egress. See the solution guide linked above for more information.
• It currently does Not Support TACACS+, only RADIUS (focused on client authentication, not admin).
• ISE logging is much more detailed than the current ACS product, providing more information to troubleshoot authentication and policy management for clients.
• ISE and NCS management platforms are tightly integrated. The GUI looks very similar to provide consistency, and client reporting in NCS provides ISE specific authentication and profiling information for easier monitoring and troubleshooting.

See my previous posts for a review of Wireless Network Segmentation Options and Dynamic VLAN Assignment.

WLC Code Support - The legacy WiSM-1 and 4400 series controllers will not be supported on code versions 7.2 and later. The latest supported code version will be 7.0. Customers should plan accordingly and prepare for hardware upgrades in the near future if they intent on deploying new features. Note that sotware maintenance for bug fixes and security patches will continue on the 4400 platform until 2014 according to the EoL notice.

ELM aWIPS Limited HW Support - Enhanced Local Mode (ELM) WIPS will only be supported on 802.11n access points. I am not sure if this is due to hardware limitations or not, but this is a huge issue for existing customers looking to support this feature. ELM was designed for highly distributed environments where the cost of an overlay solution was prohibitive. In lieu of that target market, I would have to say that Cisco seems unwise to limit support to new 11n access points. I would venture that most retail or other distributed environments already have deployed wireless network, many with older 11a/b/g hardware. The whole value proposition of ELM to reduce hardware deployment costs gets thrown out the window with this move and really invites customers to evaluate the entire WIPS market which includes other overlay solutions. This can only be a bad move for Cisco!

RRM Modifications - Significant changes to the RRM algorithm have been made between WLC versions 4.2 to 7.0. These include fixes to eliminate pinning (the worst APs cannot improve and prevent other APs in the same RF group from being changed) and cascading (propagation of a single channel change across all APs in the RF group). For example, an AP channel change event can only cause subsequent changes to first-hop APs which are direct RF neighbors of the original AP modified. RRM is preferred over static channel and power assignments becuase most RF environments are dynamic and change over time. Cisco recommends that customers who had issues on older code versions re-evaluate the use of RRM in their environments with these enhancements.

RRM First-Hop Neighbors (purple) Are Allowed
To Change Channels, But Not 2nd-Hop Neighbors (blue)

Also, most RF designs using RRM should be designed to allow APs to operate at medium power levels (values 3-5) so that RRM can adjust power levels up or down as necessary. If the network is designed with minimal overlap and APs operate at maximum power level 1 all the time, then RRM can adjust power higher to compensate for coverage holes or AP failures.

BandSelect Recommendations In-Flux - The historical official recommendation from Cisco documentation, TAC, TMEs and other support personnel has been to disable BandSelect on voice WLANs to prevent roaming delays. Since BandSelect delays probe responses on the 2.4GHz radio, it can cause roaming delays that may impact performance of an active voice call. However, we heard from a few sources during multiple presentations that voice engineers within Cisco may have validated minimal impact to voice calls and recommending customers to turn it on the voice WLANs. No official change has been made to formal recommendations at this point, but may be an interesting topic to watch for changes in the future.

Cisco Stadium Wi-Fi - The new 3500p access point and 25137NP (36⁰ spot-beam dual-polarization antenna) provide focused coverage for stadium seating sections. This solution also incorporates changes to the RRM algorithm and Wi-Fi Clear-Channel Assessment (CCA) specific to supporting a high-density environment. Read more about it here.

Cisco Narrow Beamwidth Antenna Focuses on
Individual Stadium Seating Sections

Layer 3 Roaming Enhancement - New in code version 7.0.116.0 is support for layer 3 client roaming when clients have static IP addresses configured.

Redundant Controller Licensing - Cisco WNBU (Wireless Networking Business Unit) has heard customer requests for backup controller licensing instead of having to purchase redundant units with full licensing for the intended AP capacity required. However, this change has not yet been committed to by WNBU. If you are a Cisco wireless customer and deploy N+1 or N+N redundancy, you should contact your Cisco account team to formally request s this change and throw added pressure on the pile!

Multiple LAG Groups on WLCs - Cisco WNBU is also considering adding support for multiple link aggregation (LAG) groups on the controllers. This would allow more flexible deployment in scenarios where controllers need to connect to separate physical networks, most common in DMZ anchor controller deployments I would imagine. For instance one LAG group connects to physical switches that lead into the core and another LAG group leads to a different set of physical switches that lead to the Internet. Currently, the only way to do this is to not use LAG at all and use a single physical interface for each side of the connection. This limits throughput to 1Gbps maximum. Multiple LAG support is not yet committed to by WNBU, so once again, call your account team to formally request support if it's important to you as a customer.

Rumor Apple will Support Fast Roaming in iOS 5 - There was also a very interesting rumor that was brought up in Wednesday's "Design and Deployment of Enterprise WLANs" that Apple may support 802.11r Fast BSS Transition (fast roaming) in it's upcoming release of iOS5. If this turns out to be true it will be a major improvement for support of Apple mobile devices including the iPhone, iPod Touch, and iPad in an enterprise environment. In a corporate setting these devices are much more likely to be leveraged as a converged devices supporting voice and video integration with corporate PBXs and video collaboration systems which require fast roaming for uninterrupted sessions.

Support for 802.11r should also officially come in Cisco WLC code version 7.2, although hooks have been in the WLC since the first 7.0 train release of 7.0.98.0.

Cheers,
Andrew

Cisco Live! Brings Virtual Communities Together

Last week Cisco Live! 2011 took place in Las Vegas, NV. This year was my first time attending the conference, and I am a bit amazed at my experiences looking back on the event now that it is over. In addition to the deep technical content the conference is best known for, I found more valuable benefits are afforded to attendees willing to take a more active role in the technical community.

Arguably, the most valuable aspect of the conference is the opportunity for professional development through interaction with influential members of the industry, both internal and external to Cisco. Professional networking provides a foundation for growth and success by drawing on the energy of a collective group of friends and associates who share similar ambitions and have a drive to be successful, enabling the group to move forward as a whole. Building communities within the industry is when the magic starts to happen. Joining these communities can provide access to shared knowledge, creation of new and exciting opportunities, leveraging of broader connections throughout the community, and promotion of valuable content, products, or services created by trusted members within the community.

Many of these communities begin as virtual communities, built on social media platforms such as Twitter, LinkedIn, Facebook, and the rapidly growing Google+. These platforms enable greater access to members within the community, but must be used appropriately to be effective. Individuals trying to join the community must provide value to the larger collective and interaction must be genuine. A quote from a widely successful writer and blogger comes to mind…

Networking is always important when it’s real, and it’s always a useless distraction when it’s fake. – Seth Godin

Industry events, such as the Cisco Live! conference, bring the virtual community together allowing attendees to build on existing relations formed online and expand on them by providing more personal interaction, helping to form more meaningful relationships.

The conference provides organized formal opportunities for attendees to have direct access to internal Cisco resources who present many of the sessions, the ability to meet Cisco Press authors, interaction with experts one-on-one, and casual discussion during planned social events such as one of the many welcome receptions or the customer appreciation event.

The event also provides a great forum for informal virtual communities to self-organize and enhance the value of the event by networking with peers, discussing session content, exchanging unique perspectives, and gathering insight from experts across numerous technical fields. A large group of networkers that are active on Twitter organized ad-hoc ‘tweetups’ to do just that. Having been a member of this virtual community for some time, the opportunity to meet many of them face to face was invaluable and solidifies my trust and reliance on them, and on the broader community, as a valuable resource in my professional network. The ability to interact in more relaxed social settings after conference activities concluded during many of the days provided deeper friendship among many, and I would like to think that we have formed more lasting relationships among one another.

Our Twitter Networkers Group at Cisco Live! 2011

In fact, our group was so active in the event that we garnered the attention of a few conference organizers and even established an un-official tweetup table outside the registration area. We coined the table “Tom’s Corner” due to the most active organizer among us (Tom is in the Collaboration User’s Group, which is probably not a coincidence). By Wednesday night we had even garnered an exclusive tweetup section at the Customer Appreciation Event!

The use of social media during the event also allowed attendees to provide live session updates to the broader virtual community and incorporate real-time discussion and feedback during sessions Q&A periods. The feedback that I received was one of genuine gratitude for providing content to the broader community and the ability for others to be involved in the event even if they could not attend.  In addition, social interaction between attendees at the conference was frequent, allowing live discussions within many sessions as well as access to content in alternate sessions occurring at the same time.

Cisco Live! provides a wealth of opportunities for individuals to grow their professional networks through personal interaction and to make networking ‘real’. Join the community and we’ll see you next year!

Cheers,

Andrew vonNagy 

Note - This post originally appeared on the Cisco Blog on Mobility. Thank you to Scott Simkin for providing the opportunity to share my experiences with the broader Cisco audience!

Wi-Fi Article Round-Up: 2011/06/02

A recap of Wi-Fi related articles from around the interwebs. As always, for a complete list of articles check out my shared article feed from Google Reader.

My Stuff:

• I continued my series on Wi-Fi protocol analysis with a discussion of Wireshark WLAN Traffic Statistics and I/O Graphs, which follows previous posts on Wireshark Coloring Rules. Keep an eye out for some posts on professional grade tools which can automate some of these (tedious) tasks!
  
• Wi-Fi Direct is gaining momentum, as expected, with several products hitting the consumer market.
  
• I ran an admittedly unscientific survey about WLAN Vendor Selection Criteria and decided to giveaway a CWDP Study Guide in the process. Although the response period is over, I am compiling the survey responses and will post the results soon - stay tuned!
  
• I gave the low-down on what customers need to know about the Cisco Flex 7500 Cloud Wireless Controller (and lamented at the use of the term "cloud", ugh). Greg, over at EtherealMind.com, appears to agree with me!
  
• The CCIE Wireless Lab Exam Version 2.0 was announced. See what I think are the important changes to focus on.
  
• I absolutely love TED Talks, and share some of my favorites every now and then, like this one by Kathryn Schulz on "Being Wrong". If you're looking for another great talk, check out Jason Fried's TEDx talk on "Why Work Doesn't Happen at Work".
  
• Small market Wi-Fi vendors like Aerohive have a knack for pushing the industry forward. They are willing to take a fresh approach and are much more agile at adapting to market demands than larger vendors. I think their Credential Caching capability is a feature that provides a great value for customers and makes other vendors look out of touch with true branch environment needs. Abby at Aerohive also seems to agree (imagine that)!
• PowerCloud announced CloudCommand Hotspot Edition, which promises to ease deployment, management, and revenue generation for Wi-Fi hotspots for small customers and managed service providers. Also see their blog post on the release and its benefits.

Industry Wi-Fi Articles:

• The World Health Organization (WHO) and International Agency for Research on Cancer (IARC) released a report classifying electromagnetic fields as "possibly carcinogenic (Group 2B)", which will undoubtedly create mass confusion among the media and spawn quite a few sensationalist journalist articles. The finding is definitely not conclusive (see the definition of Group 2B in the Preamble to the IARC Monographs) and more applicable to cellular phones which are held close to a person's body. However, I'm sure we'll see these findings reported across all RF related technologies, including Wi-Fi. Here is another article on the report from InformationWeek.
  
  Update - IEEE Spectrum published a great analysis of the report, "What the WHO's Cellphone-Cancer Statement Really Means"
  
  
• Reed Hastings, CEO of Netflix, spoke at D9: All Things Digital conference and listed Wi-Fi enabled TVs and fiber optic bandwidth as the two most important tech revolutions for the company's future growth. I couldn't agree more!
• Stephen Foskett covered Apple's new AirDrop feature which is forthcoming with Mac OS X 10.7 "Lion", and broke the unfortunate news that once-again, they are relying on proprietary protocols to accomplish their goals. Why, oh why, can't they just use Wi-Fi Direct?
  
• Qualcomm completed its acquisition of Atheros, expanding its portfolio and strengthening the company's position in the mobile industry with solutions spanning cellular and Wi-Fi now.
• Qualcomm and Atheros released a tri-band chipset that enables Wi-Fi on 2.4GHz and 5GHz, plus 60GHz WiGig for in-room high bandwidth data transfers. This could explode the in-home video streaming market. Here are additional articles from DailyWireless and GigaOm on the announcement.
  
• Wi-Fi traffic is forecasted to overtake wired network traffic by 2015. Yeah, we're growing by leaps and bounds folks, where have you been!
  
• The Enterprise Mobility Foundation posted a great interview on enterprise mobility management, MDM, and the state of the market with Todd Delaughter, CEO of Mformation. There is some great insight and practical advice for organizations looking to define a strategy to support mobile devices more extensively. A must read in my opinion!
• The Packets Never Lie, at least according to Douglas Haider. This was a fun little video that Kevin Sandlin at CWNP, Inc. put together from the CWAP beta class attendees.

Techie Wi-Fi Articles:

• Sam Clements busted out some Linux kung-fu on Cisco networking equipment to resurrect an NM-AIR-WLC6 from death. He reminds us just how useful some basic Linux skills can be as a swiss-army knife for many occasions as an IT professional. And that "dd" is our friend :)
  
• The guys at MetaGeek give practical advice on building a spectrum analysis report with their Chanalyzer Pro Report Builder. Remember, include only the appropriate amount of data and graphs to get your point across. Too much data can be self-destructive!
  
• Aerohive released HiveOS 4.0, which includes enhanced support for Mobile Internet Devices (MIDs), spectrum analysis based on the Atheros chipsets, and Partner Admin which enables managed service provider cloud NMS control for customer deployments. See reviews by Chris Lyttle and Marcus Burton.
  
• PC Pro (a UK based magazine) researched What's Killing Your Wi-Fi? This article is full of so many mistakes, mis-conceptions, and flat-out wrong advice, that I would caution anyone reading it to dismiss most of what it says. From getting the unlicensed frequency ranges wrong, describing co-channel interference of other Wi-Fi networks minimal compared to non-Wi-Fi interference, to coming dangerously close to advising users to leave their networks unsecured for performance gains, PC Pro shows very poor journalism. I also would like to know what "wireless industry experts" they "canvassed", because they don't site any sources (other than generically) and their facts are incomplete or wrong in many cases.

Other IT Related Articles:

• Riverbed unleashes the fury on competitors paying for so-called "independent lab testing", which is arguably skewed to shed favorable light on the sponsoring vendor's products. I think we've all read these types of reports, and most of us are smart enough to see through them. However, it's unfortunate that some customers will never know better, and take these reports at face value. Matthew Norwood also recently called out the need to study vendor solutions and be careful who you trust prior to making decisions. Bravo Riverbed and Matthew!
  
• My good friend, Nate Lee, covered ARP Spoofing / Man-in-the-Middle attacks, DHCP Snooping, and Dynamic ARP Inspection security controls on wired switches. This is a great intro to these network security features that all organizations should consider implementing on edge access switches. This must be his way of showing me how secure his network can be after I've heckled him for years about how my Wi-Fi network was much more secure than his wired network :)
  
• Stephen Foskett gave the low-down on what Tech Field Day is all about, and I am super jealous about the Fenway Park visit during Tech Field Day 6 in Boston next week. I know it's virtualization focused, but I soooo want to be there!
  
• FCC Commissioner Mignon Clyburn visited my hometown of Omaha, NE and spoke about broadband availability being so much more than just access to the Internet. The Internet is already a necessity for almost everyone to function in today's society. She spoke of the issues of physical broadband availability, adoption, and important access provided by local libraries, schools, employers, friends and families. Also of critical importance, especially in rural America, is access to distance learning programs for children and students (something which I am proud to have worked on at my time early in my career with a local NE school district).

Comic for the Week:
Take a break, with a Geek Meditation Session (courtesy of AllThingsD, via @travis_schlafke)

Cheers (and happy reading!),
Andrew

Cisco Live 2011 Schedule - Focusing on Wi-Fi Security, Performance, & Mobile Devices

I will be attending Cisco Live! 2011 in Las Vegas, NV between July 8-15th. This will be my first ever trip to Networkers / Live and I am excited to see what the event has to offer. Working for a customer has typically limited how many individual seats we are able to send to the event due to staffing requirements back at the office and funding for travel and expenses. I've heard many good things over the years, along with some cautionary tales, tips, and tricks to get the most out of the event.

Here is my schedule for the event (emphasis on topics added by me):

Friday / Saturday

• Fly into Las Vegas on Friday (time TBD), get settled into the hotel, and network with other peers that may be travelling in early.
  
  If anyone is available on Friday or Saturday to network, hit me up via email or twitter (@revolutionwifi).

Sunday

• 08:00 - 17:00
  TECSEC-2041 Identity and Security Group Access with 802.1X and TrustSec
  
  This session is a deep dive on 802.1X and the technologies that make up Cisco’s TrustSec solution. This includes the functions of access control and the application of policy derived from end-point profiling, Security Group Tags (SGTs), Network Device Admission Control (NDAC), guest access, change of authorization, and MACSec. With these technologies businesses can address many existing and emerging network access control issues, such as regulatory compliance, virtualization, and guest services. A basic knowledge of 802.1X is assumed.

I decided to go with the ISE / TrustSec technical session on Sunday, instead of the CCIE Wireless session. With the growing explosion of mobile devices in corporate environments, understanding the latest context-aware security architectures is a must in my current position. I've already acquired my CCIE digits, so real-world applications of ISE / TrustSec take priority over an exam refresher.

• 18:30 - 20:30
  GENCOL-1002 Collaboration Welcome Reception - WAITING LIST

I am registering for the event a bit later than I would have liked, so I'm on the waiting list for this reception. I don't hold out much real hope of getting on the list.

Monday

• 08:00 - 17:00
  TECEWN-3002 Advanced Enterprise WLAN Deployment with Centralized Controllers
  
  Attendees will be given a comprehensive walk through on the technology and design that enables Cisco’s WLAN solution to support tablets and other mobile devices while still providing appropriate performance, security and quality of service for the user. The session starts with an exploration of 802.11n and CleanAir, highlighting deployment best practices and an exploration of the client capabilities in tablets today. Second, the topic of strong authentication will be discussed along with advanced policy capabilities leveraging device fingerprinting to identify who and what is accessing the network with an example from a real-world customer case study. Next, the topic of multicast best practices over wired and wireless networks will be explored as a means of delivering high-quality video to many users. Lastly, the session will culminate with quality of service implementation guidelines for the end to end solution to properly meet the demands of challenging applications like voice and video while contending with the ever present needs of reliable data service.

This session should provide a nice transition from the previous day session on ISE / TrustSec with real-world application of the solution to support a large enterprise WLAN environment. Additional topics include multicast and QoS considerations, which are typically very difficult solutions to architect for large customers and require extensive planning and expertise. As a bonus, my local wireless CSE, Alex, is one of the presenters!

Tuesday

• 08:00 - 09:30
  BRKEWN-2019 Managing the Mobile Device Wave: Best Practices
  
  Learn how to plan, evaluate, and implement wireless in demanding high density environments such as lecture halls, classrooms, and auditoriums. Learn how to evaluate end user throughput requirements and translate this into the number of channels required. Learn how to manage cell size, co-channel interference, and successfully apply these principles using Cisco's Unified Wireless Network.
  
  
• 10:00 - 11:00
  GENKEY-4700 Welcome and Keynote Address
  
  Come hear John Chambers paint a compelling picture of the future of networking and communication technology and the ways it will transform business practices, education, and social relationships. He will help you put your week of learning and training into the broader context of the industry’s evolving future.
  
  
• 12:30 - 14:30
  BRKEWN-2010 Design and Deployment of Enterprise WLANs
  
  This session focuses on design and deployment concepts for enterprise and branch office WLAN deployments, i.e. the core technologies that drive and enable mobility services. Topics covered include protocol comparisons between LWAPP and CAPWAP, deep-dives into new controller features, mobility protocols and design recommendations, and the latest in design and deployment recommendations for new WLAN controllers, including centralized and distributed deployments.
  
  
• 16:00 - 18:00
  PNLUCC-4004 The Workforce of the Future
  
  Today’s younger generations are technically savvy by default. Video and social networking are how they collaborate. As this new talent enters the work force, what will they expect? In what ways are you calibrating your global IT infrastructure to accommodate for changing work patterns and demands for any device on the network from anywhere? Follow-the-sun, 24-by- 7 work time is upon us now. With talent pools spread across the globe, what architectural strategies will work best for your enterprise to ensure employees can collaborate, innovate and execute with the highest levels of productivity? This panel of experts will discuss how to approach these questions, touching upon security, video, collaboration tools, and more.
  
• 20:00 - 24:00
  Private CCIE Party!!!
  
  I'll cap off the day by attending the private CCIE party. I can't wait to network with other brilliant minds. I wonder what I should wear?

On Tuesday, I will be focusing on wireless network performance with the onslaught of mobile devices, both personal and corporate liable. Managing high density network performance is critical given the growth of enterprise and public WLAN deployments needing to support smartphones, tablets, netbooks, notebooks, and other consumer electronics. In addition, the method by which we work and collaborate at work is merging with how we conduct our personal lives. Technology solutions are blurring the line, and the it is important to understand how to enable younger generations of workers that integrate technology much more deeply into their lifestyle.

Wednesday

• 08:00 - 10:00
  BRKEWN-2016 Architect Networks for Branch Offices Using Cisco Wireless
  
  This session focuses on the architecture concepts of the branch office WLAN deployments, emphasising the core technologies that drive and enable mobility in retail, banking, education, entreprise or managed wlan services. Topics covered include in-depth protocol description of H-REAP (FlexConnect), all deployment options in practice, and are based on customer case studies for their application into the branch environment.
  
  
• 10:30 - 11:30
  GENKEY-4701 Cisco Technology Keynote
  
  
• 12:30 - 14:30
  BRKEWN-2011 Managing an Enterprise WLAN with Wireless Control System (WCS)
  
  This session focuses on Wireless Control System (WCS) as a deployment, management, and troubleshooting tool for Cisco Unified Wireless Networks.
  
  
• 16:00 - 18:00
  BRKEWN-3013 Wireless LAN Radio Spectrum Management Best Practices
  
  Managing the Radio Frequency and Spectrum is a critical challenge for modern WLAN networks, especially with advanced applications like VoWLAN. This session looks at the theory of operations and best practices for taking advantage of Radio Resource Management and usage of several tools included or available from Cisco like 'Planning Mode' and 'Cisco Spectrum Expert'. This session is updated to reflect new advances contained in release 7.0 of CUWN, and is of an advanced level.

On Wednesday, I will be focusing on branch office WLANs, a topic near and dear to my heart working for a large retail organization. I will be interested to hear the latest information on the Flex 7500 controller platform and applications in branch environments. Second, I'll be interested to hear about network management with the WCS platform, and hopefully, a healthy amount of detail surrounding the new Cisco Prime NCS platform that will replace WCS (despite not being listed in the session description). Finally, I'll wrap up with some more RF performance considerations, including spectrum analysis.

Thursday

• 09:00 - 10:00
  BRKCDN-1111 Evolution of the CCX Program and Services Solutions
  
  Cisco has driven Enterprise WiFi thought leadership since 2001 and offered the Cisco Compatible Extension (CCX) program as a pre-standard innovation program to certify that Cisco and third party WiFi devices are “Cisco Compatible” (CCX Certified) and take advantage of Cisco innovation in the WLAN Infrastructure and the extension to Wireless Carriers (Hotspot 2.0).  If your company makes WiFi enabled devices, attend this session to learn more about the latest innovation and schedules of the CCX Program and how Cisco continues to lead with pre-standards innovation in laptops, tablets, dual mode phones, digital media players, medical devices and anything WiFi.  Also, learn about how the Cisco Developer Network (CDN) Program is evolving include application solutions from partners from the "client to the cloud".
  
  
• 10:30 - 11:30
  GENRST-4640 Town Hall: Borderless Networks
  
  
• 12:00 - 14:00
  BRKSEC-3005 Advanced IEEE 802.1X for Wired Networks
  
  This session builds on the concepts introduced in BRKSEC-2005, with a focus on design optimization and troubleshooting IEEE 802.1X. Drawing on real-world examples, we examine complex system interactions that can occur when deploying IEEE 802.1X and how to prepare for those situations. We take another look at the three deployment models introduced in BRKSEC-2005 (Monitor Mode, Low Impact Mode, and High Security Mode), focusing on best practices, benefits, limitations, and advanced features such as MACSec and NEAT. The session will also address how to troubleshoot common problems in each model, including authentication failures, authorization failures, IP telephony failures, and other complex system interactions. Understanding of IEEE 802.1X is required, BRKSEC-2005 is recommended.
  
  
• 14:30 - 15:30
  GENKEY-4702 Closing Keynote: William Shatner
  
  
• 16:00 - 17:30
  BRKEWN-2018 Secure Mobility in the Cisco Unified WLAN Networks
  
  The proliferation of Wi-fi enabled devices creates important challenges for IT, perhaps the chief challenge being security and scalable, efficient, secure roaming. This session will cover the state-of-the-art technologies for proper authentication and encryption and fast, secure roaming. Topics include 802.11i/WPA/WPAv2, TKIP/AES & Fast roaming with CCKM, PKC, and the emerging 802.11r standard. Different EAP types like PEAP, PEAP-GTC, EAP-TLS, EAP-TTLS, EAP-FAST will be covered in this session. The session will include best practices for implementing latest WLAN security techniques and design and deployment recommendations for device roaming.

On Thursday, the final event day, I'll be focusing on wireless client performance optimization with the CCX program and secure fast roaming. Sandwiched in-between, I'll dip into a session on wired 802.1X, which is gaining momentum in large organizations that are finally realizing their physical controls are insufficient and need to place more controls around enterprise wired switch ports. Perhaps organizations are also realizing just how secure the wireless network has become and are jealous!

I'm excited to be going to the event for the first time! See you networking nerds at the event! (yes Tom, this means you).

Cheers,
Andrew