IOS

You are currently browsing articles tagged IOS.

If you were following my tweets over the last few days, you probably already know that I have been working on setting up a CCNA study environment using Ubuntu Linux, GNS3, and VMware Workstation. After a couple days of difficulties, I finally managed to make it work last night. Here are the steps that I took to make it work.

Before we start, there is the standard disclaimer: these are the steps that worked for me; these steps might or might not work for you, and are almost guaranteed not to work with different Linux distributions or different versions of the associated software.

Here are the software components and versions that I am using in my environment:

  • Ubuntu Linux 8.04.4 LTS, 32 bit
  • GNS3 0.6.1
  • Dynamips 0.2.8-RC2
  • Dynagen 0.10.1.090807
  • VMware Workstation 7.0.1 for Linux, 32 bit

I won’t go into great detail on setting up Ubuntu Linux as there are plenty of resources available for that portion of this environment. You will need to be at least vaguely familiar with the Linux command-line interface (CLI) and basic Linux commands, or you’ll find this process a bit difficult.

Once you have Ubuntu Linux installed and configured appropriately, the first step is to go ahead and install some dependencies using apt-get:

sudo apt-get install dynagen python-qt4

This should download and install both Dynagen and the Python-QT4 libraries. Next, you’ll need to download and install GNS3 0.6.1. There are newer versions of GNS3 available, but earlier attempts to get this environment running with the newer version of GNS3 resulted in problems. Again, your results might differ. Version 0.6.1 of GNS3 is available from the GNS3 SourceForge site.

Once you have GNS3 downloaded, extract it into the directory of your choice (I chose to use /opt/GNS3).

After you’ve downloaded and extracted GNS3, create the following directories under the directory where GNS3 is found:

<GNS3 directory>/project
<GNS3 directory>/ios
<GNS3 directory>/cache
<GNS3 directory>/tmp
<GNS3 directory>/dynamips

Use the chmod and chown commands as necessary to ensure that your user account has full read/write permissions all of these directories except the dynamips directory.

Download a copy of Dynamips (it’s generally available here), put it into the dynamips directory you created, and use the chmod command to make it executable. I also found it necessary to set the Dynamips binary’s SUID bit so that it would always run as root; I know this is not best practice but I could not find any other workaround. (Without setting it SUID, GNS3 would always report an error when trying to launch Dynamips.)

Now launch GNS3 and use the Preferences in the application to set the correct path to your project directory (<GNS3 directory>/project) and the IOS/PIX directory (<GNS3 directory>/ios), the correct path to the Dynamips binary (<GNS3 directory>/dynamips), the correct path to the working directory (<GNS3 directory>/tmp), and the working directory for capture files (set it to your project directory).

At this point you should have a working GNS3 installation. You’ll still need to locate IOS images to use; once you have valid IOS images, place them in the ios directory you created earlier and configure them within GNS3 as needed. You should then be able to create a router instance, boot it, and access the router console from within GNS3.

You could stop there and have a pretty cool environment, but I wanted to go a step further. I also installed VMware Workstation 7.0.1 (I won’t go into detail here, it’s a pretty simple process) and then used the Virtual Network Editor to create some additional host-only networks (in addition to the default vmnet1). Again, this is well-documented already, so I won’t discuss the process in any length. Where it gets interesting is in how you connect GNS3 and these host-only networks so that VMs can be incorporated into your GNS3 router topology.

Here’s how you connect GNS3 and the VMware Workstation host-only networks:

  1. In GNS3, add a cloud object to the topology.
  2. Right-click the cloud object and select Configure.
  3. On the NIO Ethernet tab in the Generic Ethernet NIO section, select one of the host-only networks (like vmnet1) and click Add. This creates a link between the cloud object and the selected host-only network.

At this point, you can attach a VM to the selected host-only network, attach a router to the cloud, and be able to pass traffic from the VM to the router. Pretty cool, huh?

What I’ve done so far is create a simple network with two VMs attached to two different host-only networks which are in turn connected to two different cloud objects and two different routers. Then I created a “serial WAN link” between the two routers (GNS3 won’t, as far as I can tell, actually simulate WAN links with bandwidth limits and latency) and configured everything so that I could pass traffic from one VM to the second VM across the “virtual WAN”. The plan is to increase the network complexity—as much as my poor little Dell laptop will allow given its limited CPU and RAM—and work through the various CCNA study guides in preparation for my exam.

One other quick note about this setup (and the reason why I chose Linux as my host platform): by setting up SSH on the Linux system (with a simple sudo apt-get install openssh-server), I can now SSH into the Linux host system and then use Telnet from there to access all the various routers. In addition, because I’m using OpenBSD as the guest OS on my VMs, I can also SSH from the Linux host to the OpenBSD VMs (assuming my GNS3 network is configured correctly). I’m also thinking that there’s a way I can leverage some VNC connectivity through Workstation to access the VMs as well, but I’ll need to research that a bit to see how it works.

I would be remiss if I did not point out a couple of sites that were extremely helpful in getting this setup up and running. First, this site provided an excellent overview of the GNS3 installation on Ubuntu. Although the walk-through was for a newer version of Ubuntu, the instructions worked perfectly on 8.04.4 LTS. Second, this site gave me the “missing link” on how to connect GNS3 and VMware Workstation’s host-only networks so that you could mix the two environments. Thank you to both sites for outstanding information!

If you are a GNS3 expert or have some additional tips or tricks to share, please add them in the comments below so that all readers can benefit. Courteous comments are always welcome.

Tags: , , , , , , ,

I had a customer contact me about scaling network throughput when using NFS datastores. Specifically, this customer was interested in knowing if it was possible to utilize more than 1 NIC with IP-based storage. The customer is currently using link aggregation (EtherChannel on a Cisco switch). I pointed the customer to my post on NIC utilization, in which I explain the prerequisites for utilizing more than 1 NIC in this sort of configuration. To refresh your memory, those prerequisites are:

  • The vSwitch must be configured for “Route based on IP hash”
  • The physical NICs connected to the vSwitch as uplinks must all be configured as active in the failover order
  • The physical switch must be configured for link aggregation
  • There must be multiple, unique source-destination IP address pairs involved

The customer responded with a question (which I’m paraphrasing here): “That’s all? It will just automatically use more than one link?”

Well…sort of.

There is one little caveat. Cisco IOS uses a hashing algorithm to determine which link a particular traffic flow between a source and destination will use. This algorithm is controlled by the port-channel load-balance command. Assuming that you’re using source-destination IP hashing, that means the Cisco switch will use a hash of the source IP address and the destination IP address to determine which link it will use. This page has more detailed information.

It’s theoretically possible, based on the number of links in the port channel, that some traffic flows between different pairs of source-destination IP addresses might end up on the same link. That means it’s not necessarily just as simple as setting up multiple NFS exports or iSCSI targets on different IP addresses—you also need to know if the IP addresses you are using will actually result in the traffic being distributed across the links.

How does one tell? Good question, and one I’m glad you asked. You can tell using this command (this command assumes you are using IP-based hashing):

switch# test etherchannel load-balance interface <Port channel interface> ip <Src IP Addr> <Dst IP Addr>

So, let’s say that you have an ESX/ESXi host with a VMkernel interface whose address is 172.16.5.10. Let’s say that you have a storage array (NetApp FAS, EMC Celerra, etc.) that supports NFS and you want to mount two different NFS exports on two different IP addresses so that traffic from this ESX/ESXi host to the storage array. You could use the test etherchannel load-balance command to help you determine which address could help ensure traffic distribution across the links:

switch# test etherchannel load-balance interface Po3 ip 172.16.5.10 172.16.5.100

For more examples of what the output would look like, take a look at this image. This was taken off a Cisco Catalyst 3560G running my test lab (and yes, the IP addresses have been changed to protect the innocent).

This would give you one way of testing whether your link aggregation configuration would actually use multiple links, or only a single link due to the IP hash calculation. Also, don’t forget that esxtop can also show you NIC utilization; here’s an example of both uplinks being used in this sort of configuration.

Unfortunately, what I can’t tell you right now is what algorithm the vSwitch itself uses to place traffic onto the uplinks. Does it follow the same sort of mechanism as the Cisco switch? I don’t know. If anyone has any information on that, it would be tremendously helpful.

If anyone has any other pertinent information or resources on this topic, please add them to the comments below.

UPDATE: Duncan Epping pointed out an article by Ken Cline from earlier this year provides the mechanism VMware uses to determine which uplink on a vSwitch will be used. This algorithm performs an XOR operation on the Least Significant Byte (LSB) of the source and destination IP addresses, then finds the modulus of that result and the number of uplinks. Thanks, Duncan and Ken!

Tags: , , , ,

For all you data storage guys and gals out there, CDP here means “Cisco Discovery Protocol”, not “Continuous Data Protection.” Sorry.

It seems that interest in VMware ESX’s support for CDP is gaining interest and attention; fellow blogger Rich Brambley of VM /ETC recently covered the topic as well.

To help summarize some of the content that I’ve generated around VMware ESX and CDP, here is a list of the articles available on this site:

  • Identifying ESX Server NICs in Blades – Although written for the blade server environment, the information presented in this article on how to use CDP to identify NICs works just as well for rack mount servers.
  • Next-Gen Stuff: Enabling CDP in ESX/ESXi – This article describes how to enable CDP on a standard vSwitch (on both VMware ESX and VMware ESXi) as well as on a vNetwork Distributed Switch (officially abbreviated as vDS but I like to call them a dvSwitch).
  • Viewing CDP Data on VMware ESX – Using the esxcfg-info command will actually show you the CDP data that’s been collected by VMware ESX. This command is different from the command that Rich showed; I think I like Rich’s command (also shared by wharlie in the comments to my article) better.

Enjoy!

Tags: , , , , ,

A couple of weeks ago I wrote about enabling Cisco Discovery Protocol (CDP) on next-gen ESX/ESXi and made the comment that I hadn’t yet found a way to view CDP data from the ESX side. One of the great things about writing a blog is that insightful and knowledgeable readers share some great information with you, and you learn a lot! That’s the situation here.

Viewing CDP data from the Cisco switch is easy. From the switch’s command prompt, use this command:

show cdp neighbors

This will display the CDP information that the switch has gathered. When CDP is enabled on ESX/ESXi, that will include information on which VMnics are attached to which switch ports.

From the ESX side, you can use this command:

esxcfg-info | more +/CDP\ Summary

This searches for the string “CDP Summary” in the output of the esxcfg-info command. The output from that command will include information about the switch to which the ESX host is connected, the ports to which the NICs are connected, and associated VLANs. The screenshot below shows some of the output from this command.

esxcfg-info-cdp.png

Thanks go to reader Larry for the information on this command. Other readers, feel free to continue to share information here. It is helpful!

Tags: , , , , ,

Earlier this year, I wrote an article about NIC utilization in VMware ESX in which I discussed some of the details around how VMware ESX uses NICs in various configurations. The testing that prompted that article was primarily centered around IP-based storage (software-based iSCSI and NFS), so naturally the discussion primarily centered around IP-based storage as well.

As a follow up to that article, I’ve been running some additional tests with a focus this time on the behavior of virtual machines (VMs) in configurations both with and without link aggregation. The results are very consistent with the findings from the previous set of tests, but with a few key items to keep in consideration when applied specifically to VMs.

Without Link Aggregation

As stated in the earlier article, using NIC teaming without link aggregation means the vSwitch is configured with one of these three load balancing settings:

  1. Route based on the originating virtual port ID
  2. Route based on source MAC hash
  3. Use explicit failover order

The primary focus here is “Route based on the originating virtual port ID,” since that’s the default vSwitch setting and the recommended setting from VMware when not using link aggregation.

Just as all the VMware docs explain, the tests show that a VM will use only one uplink, regardless of how many different connections are involved, and it will stay on that uplink until the uplink fails, at which time the VM will be moved to a different uplink according to the NIC failover order configured for that port group or vSwitch.

There are, however, a few other things to consider:

  • There is no guarantee that the VMs will be evenly distributed across the uplinks on a vSwitch or port group. Although I’ve seen references in the VMware documentation to indicate that VMs are balanced in some fashion (I could not find those references, however), real-world experience seems to indicate otherwise. In my tests, I had instances where four VMs were all “linked” (via their virtual port ID) to the same uplink.
  • It’s unclear at what point VMware ESX creates the link between the virtual port ID and the uplink. In my tests, I rebooted the guest OS and power cycled the VM only to have it come back on the same uplink again. Only a VMotion off the server and back again caused a VM to move to a new uplink. I’ve been trying to track down more information on the timing of the association between the virtual port ID and the uplink, but have thus far been unsuccessful.
  • There is no control over the placement of VMs onto uplinks without the use of multiple port groups. (Keep in mind that you can have multiple port groups corresponding to a single VLAN.)
  • Because multiple VMs could be assigned to the same uplink, and because users have no control over the placement of VMs onto uplinks, it’s quite possible for multiple VMs to be assigned to the same uplink, or for VMs to distributed unevenly across the uplinks. Organizations that will have multiple “network heavy hitters” on the same host and vSwitch may run into situations where those systems are all sharing the same network bandwidth.

These considerations are not significant, but they are not insignificant, either. The workaround for the potential problems outlined above involves using multiple port groups with different NIC failover orders so as to have more fine-grained control over the placement of VMs on uplinks. In larger environments, however, this quickly becomes unwieldy. The final release of the Distributed vSwitch will help ease configuration management in this sort of situation, but that’s still out in the future yet.

VM Networking with Link Aggregation

Using NIC teaming with link aggregation means that the vSwitch is configured with “Route based on ip hash” and that the physical switch has been configured for EtherChannel or static 802.3ad/LACP.

<aside>By the way, static 802.3ad/LACP in the Cisco IOS world means the use of the “channel-group X mode on” command as opposed to “channel-group X mode active”; the first command uses static link aggregation whereas the second uses dynamic link aggregation. Static is supported; dynamic is not.</aside>

In this environment, the tests showed exactly what we expected; traffic from VMs was distributed across the uplinks in a dynamic fashion based upon the source and destination IP addresses. While some of these things may be common sense, there are a few things to consider:

  • Depending upon the number of uplinks, it’s certainly possible that some traffic streams may end up getting hashed onto the same uplink. One a traffic stream is placed onto an uplink, it won’t move off that uplink until the flow is complete.
  • The way in which outbound traffic from the VMs will be placed onto the uplinks won’t necessarily be the same as the way the physical switch places inbound traffic onto the uplinks. A good resource on how Cisco handles placing traffic onto members of an EtherChannel bundle is this page.
  • Multiple connections to or from a VM might utilize multiple uplinks but aren’t necessarily guaranteed to use multiple uplinks.

Again, some of the points above are simple common sense, but they should be kept in mind nevertheless. If the workloads that are being hosted on VMware ESX are such that having more aggregate bandwidth would be beneficial, then using link aggregation is really the only way to do it. I suppose it would be possible to use NIC teaming inside the guest OS, assuming the VM was configured to use e1000 NICs, but I’ve never tested this configuration. (Anyone else tested it?)

Tags: , , , , , ,

Back on March 5 blogger extraordinaire Alessandro Perilli of virtualization.info revealed that Cisco had chosen KVM as the virtualization platform for IOS-XE, the new Linux-based version of IOS that runs on the recently introduced ASR series of routers.

If you were like me, you may have been wondering exactly how Cisco was putting KVM to use. No need to wonder any longer! Colleague and fellow blogger Colin McNamara has written up a detailed and in-depth discussion of the ASR1000 and how it uses KVM to provide virtualized instances of IOS-XE. Colin also discusses the role of the QuantumFlow processor and, believe it or not, the role of Popeye and Spinach. (Go read the article. It will make sense when you’re done.) Nice work, Colin!

Tags: , , , ,

As a follow-up to my earlier post about using VLANs with VMotion, I wanted to also share a brief configuration snippet (based on a Cisco IOS-based switch) that aligns with the recommendations in that article. This is nothing new to those who are familiar with IOS, but for those readers who are not it may provide some helpful information.

For the purposes of this configuration, I’m making the following assumptions:

  • VLANs 100 and 200 are the VMotion VLAN and some other production VLAN, respectively (perhaps a VLAN carrying virtual machine traffic, or a VLAN carrying Service Console traffic)
  • VLAN 4094 is the “ESX Trunk” VLAN, which isn’t used anywhere else in the network for any purpose

Here’s the recommended port configuration for ports connecting to an ESX Server:

interface g0/1
switchport trunk encapsulation dot1q
switchport trunk native vlan 4094
switchport mode trunk
switchport trunk allowed vlan 100,200,4094
switchport noneg
spanning-tree portfast-trunk

Technically, the “switchport noneg” command won’t really do anything; it disables DTP (Dynamic Trunking Protocol) but DTP isn’t supported by ESX Server anyway.

A couple of notes about this configuration:

  • Refer back to my article on the native VLAN with ESX Server; by setting the native VLAN to 4094 (the “ESX Trunk” VLAN), you won’t carry that traffic into the ESX Server. If used on a vSwitch that also carried Service Console traffic, then it could impact automated build scripts.
  • If you needed to combine this configuration with EtherChannel, refer back to my original article on ESX Server, NIC teaming, and VLAN trunking.

Keep in mind the other recommendations as well: explicitly control trunking to other devices and explicitly control the transmission of VLANs across trunks to control “VLAN leakage”.

CCIEs and other experts, I’d welcome any other suggestions as well as recommended commands to use in the switch configuration to help maximize security and minimize exposure to VLAN-based attacks.

Tags: , , , , , , , ,

In my previous article about using NetApp multi-mode VIFs with Cisco switches, I mentioned that you could—at that time—only use 802.3ad static link aggregation:

Be aware that Data ONTAP’s multi-mode VIFs are only compatible with static 802.3ad link aggregation; you can’t use PAgP (Cisco proprietary protocol). I would assume dynamic LACP is also incompatible. For this reason we used the “channel-group 1 mode on” statement instead of something like “channel-group 1 mode desirable”.

I recently got some feedback from a NetApp SE in my area; this SE informed me that Link Aggregation Control Protocol (LACP, part of the IEEE 802.3ad specification) is indeed supported with Data ONTAP version 7.2. This KB article on the NetApp NOW site (login required) indicates that ONTAP 7.2.1 is required in order to use a LACP VIF.

There are a couple important requirements to note; these are laid out in the referenced KB article:

  1. Dynamic multimode VIFs should use IP address-based load balancing. This means that the Cisco switch or the channel group must also use IP address-based load balancing.
  2. Dynamic multimode VIFs must be first-level VIFs. This makes sense; LACP is a Layer 2 protocol, so layering a LACP VIF on top of other VIFs just doesn’t work.

To create the dynamic multimode VIF on the Data ONTAP side, the command is pretty simple:

vif create lacp <vif name> -b ip {interface list}

On the Cisco side, the commands are very similar:

s3(config)#int port-channel1
s3(config-if)#description LACP multimode VIF for netapp1
s3(config-if)#int gi0/23
s3(config-if)#channel-protocol lacp
s3(config-if)#channel-group 1 mode active

These commands would be repeated for all physical ports that should be included in the LACP bundle. Note the differences from the earlier commands in the previous article; here we use “channel-group 1 mode active” instead of “channel-group 1 mode on“. We also added the “channel-protocol lacp” command.

Together, these commands will establish a LACP-based link aggregate between a NetApp storage system running Data ONTAP version 7.2.1 or higher and a Cisco IOS-based switch.

Thanks to Jeff, our NetApp SE, for providing the updated information.

Tags: , , , , ,

It’s common in blade deployments to use multiple Ethernet switches in the blade chassis to provide network redundancy (I’ll refer to these as “in-chassis switches” moving forward). For example, in both the IBM BladeCenter H and the HP BladeSystem c-Class, we can provision multiple in-chassis switches so that half of the NICs on the blades connect to one in-chassis switch and the other half connect to the other switch. Within the OS, we load NIC teaming software to provide automatic failover if one of the links goes down. In this scenario, if one of the in-chassis switches fails then traffic will automatically fail over to the other switch.

In cases like this, everything works as advertised. But what about when the in-chassis switch stays up, but the uplink from that switch to the outside world goes down (perhaps the upstream switch went down or the link was unplugged)? In that case, the link from the in-chassis switch to the blade’s NIC is still up, and therefore the NIC teaming software in the OS does not know that a problem has occurred and will not move the traffic to the other link. In situations like this, we need to implement link state tracking.

<aside>Astute readers will recognize that link state tracking is actually applicable in any server deployment—not just a blade server deployment—where the servers connect to a distribution switch and not the core. I’m just going to focus on blade server deployments here, but the configuration would be much the same, if not exactly the same, in non-blade server deployments.</aside>

Link state tracking is pretty easy to configure; you define one or more upstream ports and one or more downstream ports. The upstream port(s) are the ports that uplink to the rest of the network; in a blade server deployment, this would be the ports (or port groups) that connect to the network backbone. The downstream port(s) are the ports that connect back to the servers.

Here’s an example. We have a Cisco in-chassis switch that has a GigabitEtherChannel port group defined as an uplink out to the outside world:

interface Port-Channel1
description Uplink to network backbone
switchport trunk encapsulation dot1q
switchport trunk native vlan 2
switchport trunk allowed vlan 2-4094
switchport mode trunk
link state group 1 upstream

Note the “link state group 1 upstream” command, which marks this port channel as an upstream port. If all the links in this port channel go down (thus making the port channel itself go down), then the switch will notify downstream ports in the same group to mark themselves as down also.

The member ports of this port channel would not have the “link state” command present:

interface GigabitEthernet0/18
description Port group member for uplink to network
switchport trunk encapsulation dot1q
switchport trunk native vlan 2
switchport trunk allowed vlan 2-4094
switchport mode trunk
channel-group 1 mode on

So for the ports on the same in-chassis switch that are connecting to the servers in the chassis, we have this configuration:

interface GigabitEthernet0/10
description Web server NIC
switchport access vlan 2
switchport mode access
link state group 1 downstream
spanning-tree portfast

Note the “link state group 1 downstream” command, which marks this port as a downstream port from the Port-Channel1 interface. If Port-Channel1 goes down (because all the member links in Port-Channel1 also went down), then GigabitEthernet0/10 will also go down. Because GigabitEthernet0/10 went down, the NIC teaming software running in the OS on the blade will fail the traffic over to a different NIC, presumably a NIC that connects to the redundant in-chassis switch.

You’ll also need the global “link state track 1″ global command to enable link state tracking (thanks for the clarification, Matt!).

Because of the nature of blade deployments, this sort of configuration is particularly applicable in blade deployments, but also applies in other situations as well (as mentioned earlier). I hope this is useful!

UPDATE: I’ve changed from using “chassis switch” to “in-chassis switch” to help avoid confusion with products like the Cisco Catalyst 6500 series, which are commonly referred to as chassis switches. Thanks, James!

Tags: , , , , ,

The idea behind 802.1x is to provide Layer 2 authentication; that is, to authenticate LAN clients at the Ethernet layer. (This is before the client gets a DHCP lease or anything of that nature.) With 802.1x in place, rogue users can’t just tap into a physical connection on the network. In order to gain network connectivity, the device must authenticate before network traffic is allowed.

The idea here is to configure 802.1x authentication on a network switch in such a way as to leverage the existing authentication infrastructure provided by Active Directory. Like it or not, Active Directory is a widely deployed directory service and leveraging it where we can will certainly provide an advantage. This process uses RADIUS to provide an interface between a Cisco Catalyst 3560G switch (the 802.1x authenticator in this scenario) and Active Directory. I could only test Mac OS X as the client (or 802.1x supplicant), but I’m confident that the configuration will work equally well with Windows XP Professional.

Configuring the Cisco Catalyst 3560G

The Catalyst switch I used in this configuration was running IOS 12.2(25); please note that the commands listed here may be different in different versions of IOS.

To configure the switch for 802.1x authentication, three steps are involved:

  1. Enable 802.1x authentication on the switch (global configuration).
  2. Configure the RADIUS server(s) to which the switch will communicate for authentication requests.
  3. Enable 802.1x authentication on the individual ports.

(This document from the Cisco web site was tremendously helpful in configuring 802.1x.)

First, to enable 802.1x authentication on the switch, use the following commands in global configuration mode:

aaa new-model
aaa authentication dot1x default group radius
aaa authorization network default group radius
dot1x system-auth-control

This enables 802.1x globally on the switch, but none of the interfaces are enabled for 802.1x authentication. Next, we configure the RADIUS server(s) to which the switch will pass the 802.1x authentication traffic. That’s handled with these commands in global configuration mode:

radius-server host 10.1.1.254 auth-port 1645
acct-port 1646 key Password

(This should all be on one line.) Note that the “auth-port” and “acct-port” parameters are only necessary if you are using nonstandard ports. Since Microsoft’s IAS (Internet Authentication Service, which provides the RADIUS interface to Active Directory) uses both sets of standard ports (1645/1812 and 1646/1813) you won’t need to specify these parameters. The “key” parameter is a shared secret key between the RADIUS client (the switch) and the RADIUS server. Obviously, you’ll want to use something other than “Password”.

Finally, to enable 802.1x on the applicable interfaces, you’ll use these commands in interface configuration mode:

int gi0/23 (or whatever interface you want to configure)
dot1x port-control auto

That enables 802.1x authentication on that specific port. Repeat the process for all ports that should use 802.1x authentication. Note that some ports can’t be enabled for 802.1x authentication; most notably, trunk ports can’t be used for 802.1x. Refer to the Cisco documentation (or the documentation from your particular vendor) for complete details on the limitations.

Now that the switch is configured, we move on to configuring Active Directory.

Configuring Active Directory and IAS

I suppose that saying we need to “configure Active Directory” isn’t entirely accurate, since no configuration changes and no schema extensions are necessary to make this work. All that really needs to be done is to enable reversible password encryption (which can be done on a per-user basis) and setup Internet Authentication Service (IAS).

First, regarding reversible password encryption: The configuration described here uses MD5 hashes (passwords) to authenticate clients to the network. There are other methods, such as digital certificates, to accomplish the same thing, and I’ll probably revisit this configuration again at a later date to look at using those. For now, though, the use of MD5 for authentication means that we have to enable reversible password encryption for every user that will need to authenticate via 802.1x, and those users will need to change their passwords after that change is made. A pain, yes, and a potential security concern, yes, but necessary at this point. (I won’t bother going through the details of enabling reversible password encryption here; there are plenty of resources available on the Internet, like this one, that provide that information.)

Configuring IAS is really pretty straightforward. I’ve discussed the use of IAS before (here in discussing Cisco PIX-AD integration and here regarding WatchGuard Firebox-AD integration), and I’ll refer you back to those articles for some of the basics on setting up and configuring IAS.

To configure IAS in this instance (once it has been installed and registered with Active Directory), we’ll do the following:

  • Add the Cisco Catalyst switch as a RADIUS client. We’ll need to be sure to specify the same shared secret as used in the switch configuration.
  • We’ll create a new remote access policy. The conditions on the policy should be “NAS-Port-Type” (set to Ethernet) and “Windows-Groups” (set to whatever group should be allowed to authenticate via 802.1x; I used Domain Users).
  • The profile associated with this policy should be edited to note only the EAP MD5 authentication type (under “EAP Methods” on the Authentication tab); all other authentication types should be unchecked. In addition, all encryption types on the Encryption tab should be unchecked except for “No encryption”.

At this point, the IAS configuration should be complete. Now for the final step: configuring the client to use 802.1x.

Configuring the Client (Mac OS X)

As mentioned earlier, I didn’t have a physical Windows XP Professional-based machine to test with, but I did do some testing with Mac OS X. Although the software used to configure the operating system is different, the overall configuration is similar and should work without any major hitches on Windows XP.

To configure Mac OS X, launch the Internet Connect software in the Applications folder and follow these steps:

  1. From the File menu, choose “New 802.1X Connection…”.
  2. Specify a description and choose the appropriate network port (typically “Built-in Ethernet”).
  3. Specify a username and password.
  4. For authentication types, click to enable MD5 and move it to the top of the list. Uncheck all other authentication types.
  5. Click OK to save the connection.

Once the connection has been defined, you can plug your OS X-based system into one of the 802.1x-enabled ports and click “Connect” in the Internet Connect window. If everything is configured correctly, you should be connected and be able to pass network traffic without any issues. If things don’t work, go back and check the switch configuration and the logs on the IAS/RADIUS server. In particular, the logs may indicate that an incorrect password was used, or you may be able to determine that the switch isn’t even talking to the IAS/RADIUS server (perhaps a typo in the server address?).

By the way, configuring Mac OS X to use 802.1x for wireless connections is equally easy and done the same way (using Internet Connect). I used to regularly use my MacBook Pro in an environment that used 802.1x and EAP-FAST/LEAP for wireless authentication with no problems.

Future enhancements to this configuration include switching from EAP-MD5 to something like EAP-TLS or PEAP; this will avoid the need to enable reversible password encryption on the domain.

Tags: , , , ,

« Older entries