VLAN trunking (802.1q) allows multihoming to function without the need for multiple physical network adaptors and the additional infrastructure required to connect them. I’m going to show you how to implement this technology using VLAN trunking on a combination of Cisco switches and routers and Windows systems.
Figure A shows a network diagram of the lab environment used for this article.
I first introduced this technology in “Use VLAN trunking and Gigabit Ethernet for smarter multihoming,” in which I showed how VLAN trunking is revolutionizing the way network topologies are being designed and interconnected.
Cisco switch configurations
Cisco switches primarily come in two flavors: Catalyst OS (CatOS) and Internetworking OS (IOS). I’m going to look at VLAN trunking on both of them.
Although Cisco is trying to migrate almost everything to the IOS, there is still a large installed base for CatOS switches. Cisco’s flagship 6500 series switches can run CatOS or IOS, but most people I know run CatOS on the 6500s. Smaller switches, such as the 2950 and the 3550, all run IOS (the 2948g-L3 is an exception; that switch is really more of a router and you should refer to the section below on routers for its configuration).
In many ways, I prefer the CatOS over IOS because I feel that the CatOS user interface is superior for entering system configurations. For example, if you ever need to apply a common configuration to 48 Ethernet ports on module 4, you simply need to apply a command to “4/1-48.” On the IOS, you would need to enter each interface for all 48 ports and apply 96 individual commands versus one command on the CatOS. Viewing the configuration on IOS is equally bloated.
Table A shows a breakdown of 802.1q trunking support for the various Cisco switches.
To set up the CatOS or IOS on Cisco switches, the port that needs to be trunked must be configured for the right kind of VLAN trunking. Note that not every module and interface on a switch supports trunking and this could lead to error messages and incompatibilities. This may require you look up the trunking capabilities for each port.
Before I look at configuring the switches for trunking, I need to first cover a few procedures for locking down your switches.
Lock down the switches first
Table B shows the configuration for locking down IOS switches.
Table C shows how to lock down the CatOS switches.
Although these security procedures are not mandatory in order to get trunking to function, this layer 2 security lockdown procedure should be. Although the CatOS switch has a far more streamlined UI compared to the IOS switches, it is notoriously promiscuous with its default settings on VLAN trunking.
The trunking auto-negotiation is equally alarming on both the IOS and CatOS switches, which, if left to the default settings, will automatically connect switches as fully enabled and wide open (you would be shocked to see the sloppy Layer 2 security on most networks). If left unchecked, most of these switches are not only opened to malicious hacks, but anyone could plug in a Cisco switch with a VTP (VLAN Trunking Protocol) engine and accidentally wipe out your network by altering your VLAN configuration.
Table D shows how to configure CatOS switches for trunking.
You may find it amusing that it took so much work to lock down your CatOS switch while it only took one command to enable trunking. If you didn’t bother to follow the lockdown procedure shown above, specifying the 10-15, 20 VLAN IDs would be useless because it simply adds them to the existing 1-1005 pool, which remains wide open. This behavior of the CatOS is very annoying and insecure by default.
The IOS switches, on the other hand, only permit the VLANs you enter last. Note that, on an IOS switch, if you enter 10-15,20 with your “allow VLAN” statement, it nullifies any other allowed VLAN outside of 10-15 and 20. The big plus to this is default security. In this case, if you did the IOS security steps above, then no additional steps are needed to enable trunking.
Cisco router configurations
Cisco router configuration for trunking is fundamentally different from Cisco switch configuration. A router encapsulates traffic to be carried on the switch infrastructure and behaves as a multihome node on the network. A switch works as the infrastructure to carry traffic for VLANs (for those that are allowed) on the Layer 2 infrastructure as the VLAN traffic director, while the router performs a higher layer function as a network gateway that can route Layer 3 traffic.
You can basically configure a router with the number of desired virtual interfaces (or sub-interfaces) from a single interface and designate the VLAN that you want those interfaces to be switched to. The switch determines where the traffic from that router’s virtual interface will wind up based on the VLAN ID portion of the 802.1q tag that is inserted into the Ethernet frame header by the router.
Table E shows how to configure Cisco routers for trunking (routers only use the Cisco IOS).
You can continue to add any number of subinterfaces you need. Once FastEthernet0/0 is connected to a switched port configured for 802.1q trunking, as shown in the above switch examples, all the subinterfaces of FastEthernet0/0 become a routable node (can be default gateway) on the subnets that correspond to their VLAN.
Windows configuration with Intel Pro Series adapters
Conceptually, trunking a Windows workstation or server to a switch is the same as trunking a router to a switch. The only difference is the procedure, which is a little easier for a Windows system.
The ubiquitous Intel Pro Series network adapters provide a simple-to-use graphical tool called PROSet that can help with this configuration. I’m going to walk through the procedure of configuring an Intel Pro NIC on a Windows XP system with the help of PROSet. (Note that the same Intel adapters can provide similar capabilities on Linux.)
To get started, simply invoke the Intel PROSet or PROSet II utility (assuming the PROSet software is installed). This can be done by simply double-clicking the PROSet icon in the system tray on the lower right-hand corner of the desktop. The utility in Figure B will come up.
Now you must add a VLAN interface. Simply right-click on the Intel adapter with the PCI Card icon and then click Add VLAN. Note in Figure C that the virtual interface for VLAN 100 is already there and you are adding an additional one.
The Add New VLAN window will come up. Enter the VLAN ID you want this interface to trunk in the ID field, then give it a name that describes the VLAN function. In this case, you will be adding VLAN 69 labeled the Wireless LAB (see Figure D).
Once this is completed, click OK and then simply click Apply and OK on the PROSet window to commit the changes and exit out of the PROSet utility.
The next step is to configure the virtual interfaces. Open up the Network Connections window and begin configuring the virtual interface as you would any other physical interface (see Figure E and Figure F).
Note that the interface names already correspond to the names of the VLAN interfaces you added. However, autonaming only works in Windows XP. Windows 2000 just gives them generic names, so you must add one interface at a time and rename the interface under “Network Connections” before you add another VLAN interface. If you don’t do that, it is impossible to tell which interface goes to which VLAN without some tedious trial and error.
Another very important thing to note is that the physical interface itself (“Local Area Connection”) is not bound to anything except for the “Intel Advance Network Services Protocol.” It is not used for anything else and only serves as a host for all of the virtual interfaces, and it does not have its own IP address or VLAN.
Just remember that only your primary interface is registered with internal Dynamic DNS and WINS, and it's the only interface that can have a default gateway. This is the same as when you have multiple network interfaces. In both cases, whether there are multiple physical or virtual interfaces, you must set manual routes to take advantage of the other nonprimary interfaces.
This is why, in the TCP/IP configuration in Figure F, I deliberately left the default gateway and DNS settings blank, because those settings went on to the VLAN 100 interface. If you put a default gateway on the VLAN 69 interface, it will take over and the default gateway for the VLAN 100 interface will disappear. All the default gateway means is the route for 0.0.0.0 network with mask 0.0.0.0 (which really just means any IP destination) will route to the default gateway. You can easily find this out with the Route Print command.
From this point on, you may add as many VLANs as you need using the example above. The only other thing you should be aware of when dealing with these VLAN interfaces in Windows is that you should not enable or disable them from the Network Connections folder. Doing so will cause you to encounter some strange behaviors and errors. Instead, after the initial setup, you should deal with the interfaces primarily from the PROSet tool.