802.1X sounds simple enough. Enable the switch ports, set up Radius and supplicants, and you're ready to go. But the reality is that common network scenarios are made vastly more difficult where 802.1x is deployed.

When I set up my test bed for my NAC testing, I designed a network that would use 802.1X and another design that would use other methods, like DHCP control. Switching from one network to another is a simple matter of moving a few configuration files and rebooting the switches. While setting up 802.1X, I ran into few issues, like not being able to use PXE boot on 802.1X-enabled ports and the common chicken-and-egg problem of trying to join a host to a domain but not being able to authenticate first.

I was talking to Kevin Koster, who is running the InteropLabs NAC demonstration, about anything he saw with 802.1X while setting up his demo. Not surprisingly, IP phones were difficult to integrate. Cisco phones on Cisco switches worked fine because Cisco's Discovery Protocol, CDP, can discover that there is a phone on the other end and move the port into the designated voice VLAN. However, when they tried to bring an Avaya phone, which doesn't support CDP, into the mix at the same time, he found they couldn't get it onto the voice VLAN. They eventually had to fall back to MAC authentication to get both phones on the same switch and VLAN simultaneously.

If you're thinking, like I am, that your other IP devices such as printers, network cameras, and VoIP phones need to support 802.1X, you're ahead of the curve compared with device vendors. But even so, there are other hurdles that have to be overcome. The most difficult hurdle is device provisioning. Back in the day when I was testing remote access gear, a few vendors had provisioning tools that were quick and simple. A remote access device could be fully configured in less than two minutes, which sped bulk deployments.

Provisioning the 802.1X is a bit more complex, but not much more. For example, credentials for the supplicant will have to be done prior to connecting the device to the network. You are probably going to want to use EAP-TLS to secure the authentication process and that means pushing your CA certificate to the IP devices. If you plan on using device certificates, you have to generate the device certificates and then manage them for the lifetime of the device. That presupposes that the device can adequately support device certificates. If you're going to use a user name-password authentication, then those have to be provisioned.

802.1X is an effective network access control mechanism, but it's not without its share of pain. IT administrators I have talked to who have deployed 802.1X have used workarounds like MAC address authentication, MAC whitelisting, or standardizing switch cabling (stating ports 1-10 are used for phones, printers, etc.) and selectively enabling or disabling 802.1X on a range of ports. Trying 802.1X in a controlled situation is critical for a successful deployment, and you can do that on your existing equipment without affecting your production network. Just be sure to test each scenario individually to ensure that the features will work solo as well as collectively to ensure you can support all simultaneous scenarios.