Configure Cisco Switches for Easy Server Deployments
Both dynamic VLANs and 802.1q auto-negotiation can enable a hands-off approach to server changes, but there are design and security tradeoffs. Are they worth the convenience?
We all struggle with the fine line between security and ease of use. Today, we offer two suggestions for making both network and server administrators’ lives easier when deploying or moving servers. Both dynamic VLANs and 802.1q auto-negotiation can enable a hands-off approach to server changes, but there are design and security issues. The question at hand is therefore, "is it worth it?"
Dynamic VLANs Explained
A switch port can be placed in "dynamic" mode, which means the switch can dynamically change the VLAN membership of the port. This works via VLAN Management Policy Server (VMPS), which defines which hosts, by MAC address, are associated with which VLANs. When a switch port comes up, the switch checks with the VMPS to determine what VLAN to put the port in, then does it. The concept is quite simple and attractive because you can manage all MAC-to-VLAN-number mapping in a central place.
There are, of course, a few minor issues to contend with. Like most Cisco features, you need to know how they work to avoid being surprised. The main issue is that when connecting a new host to the network, its MAC address must be defined in the VMPS, or else it will not get network access. Before deploying a new server, the server admins generally configure network install services (jumpstart, kickstart) that require MAC address association with the host name. Wrapping the addition of the MAC address procedure in a script to get the data in both places at once shouldn't be too difficult.
But wait: It gets more interesting. Not only will an undefined MAC showing up on a port fail to get network access, but it can also cause the port to be shut down, which requires network admin access to re-enable. If the VMPS is in secure mode, the switch port will also be shutdown if a MAC happens to be associated with a VLAN number that doesn't exist on the switch it's connected to. To prevent issues such as these, two things are required: careful network design, and user education. VLANs should exist everywhere you want them to, but in cases where the network is designed to stop, the user connecting hosts needs to be aware.
A frustrated server admin unaware of how this all works can run around trying dozens of different ports, causing each to be disabled, in a very short period of time. While this might be a bit troublesome, it also means dynamic VLANs don't present much of a security threat, on the surface. The very nature of allowing switch ports to change their VLAN access is scary, but that fear soon subsides once we learn how it all works. There is, however, the remote possibility that--and we're really reaching here--an attacker could change the MAC address of a compromised server and cause the port to flop into another VLAN. This would require that the attacker was a) a human, which is rare these days, and b) knew another MAC address from another VLAN. The attacker could flood the switch and cause spillage of other VLAN data, but the chances of this type of disruptive activity going unnoticed are slim, as are the chances an attacker would even think about dynamic VLANs.
Dynamic VLANs: Chicken and Egg?
One common reservation about switching to dynamic VLANs is that the VMPS presents a chicken-and-egg problem. If the network crashes (think power outage), the switch with the VMPS must come up first, but without the VMPS server, how will the port the VMPS uses be placed in the correct VLAN?
First, the VMPS does not need to come up first. Switches will retry until they can reach a VMPS, instead of just giving up and leaving connected hosts without a VLAN. Also, you will have multiple VMPSes, working redundantly to guard against a situation where a single crashed server can prevent other servers from getting their VLAN assignment.
Second, you will not place the VMPS on a dynamic port, so the chicken-and-egg concern is moot. You could, if you wanted, which means you probably want more than one extra VMPS, but that is just asking for trouble.
To enable dynamic ports, the switch port gets set to dynamic mode (as opposed to access or trunk modes). You will not be able to configure your entire network via the VMPS, especially inter-switch trunk ports, so keeping a few non-dynamic for the VMPS is highly recommended.
Last week we explained to server admins how they can simplify their server deployments that use two network ports, one for management and one for regular networking, by using 802.1q links. One thing we didn't mention is that some switches can automatically switch from access to trunk mode when it detects 802.1q. Do not get too excited, though. As we just mentioned above, trunk ports are unfortunately not compatible with dynamic VLAN management via the VMPS. So now that we've explained how wonderful dynamic VLANs can be, we say you can't use them? On trunk ports, yes, but that doesn't mean you should ditch the VMPS idea: Many host ports will not need 802.1q, and the time savings is still there.
There is some good news, however. In fact, with a bit of automation work, this is pretty slick. The secret is that you can configure the trunk port settings, and then set the switch port to dynamic mode, keeping the trunk settings for future use. Unfortunately, if you use auto-negotiation for 802.1q and the port is set to dynamic, it will not auto-negotiate a trunk; that only works in access mode.
When someone requests an 802.1q port, all you need to do is change the port mode with: "switchport mode trunk." To change back to a dynamic port, just leave the trunk settings in place and run, "switchport mode vlan dynamic." This, of course, could be automated so that server admins can perform this switchover themselves.
The usage of 802.1q links with servers is still rare, but becoming more popular these days. In most cases, enterprises are full of standard access ports statically assigned to a VLAN, and in those instances, dynamic VLANs are a true time saver.
Charlie Schluting is the author of Network Ninja, a must-read for every network engineer.