| Downloads |
|---|
| 20805.zip |
The software-development company for which I work divides many of its projects into separate class C subnets to heighten security and preserve bandwidth. Many employees move from project to project. Such moves often result in a physical move to a different office and an electronic move to a different subnet. Keeping subnets up-to-date in this environment can be challenging.
When I first joined the company's network administration staff, the network had concentrators (i.e., hubs). When employees moved to different subnets, the other network administrators and I had to rewire the users' connections on the patch panel. You can imagine how that panel looked after about 6 months. To remedy this problem, we installed four Cisco switches and used Virtual LANs (VLANs) to create subnets. A VLAN is a group of ports on a switch. These ports can talk with one another without going through a router. We used one VLAN for every class C subnet deployed and connected every computer directly to a port. To change a user's subnet, we used Telnet to connect to the switch, then manually configured the port's VLAN.
Although manually configuring VLANs was much better than rewiring patch panels, the manual configuration was time-consuming. Thus, we enabled VLAN Management Policy Server (VMPS) on the switches. VMPS automatically assigns a computer to a particular subnet based on the computer's media access control (MAC) address (i.e., the unique number assigned to the network card). Central to VMPS is a database-configuration text file that maps MAC addresses to VLANs. When a user turns a computer on or plugs it into a port, the switch automatically reads the computer's MAC address. The switch then checks for that MAC address in the database-configuration file. When the switch finds a match, it uses the mapped VLAN to connect to the correct subnet.
We set up the VMPS system so that users could plug into just about any port in the building and still connect to the correct subnet. To maintain this system, all we needed to do was keep the database-configuration file up-to-date—a simple task, or so we thought. We quickly realized that updating the database-configuration file and the switches wasn't as easy as it seemed. We discovered the hard way that just one syntax error in the database-configuration file can cause the switch to stop reading the MAC addresses. Everyone with a MAC address below the syntax error then gets knocked off the network. After we updated the database-configuration file, we discovered we had to update the switches by prompting the switches to reread the database-configuration file. To prompt the switches, we had to use Telnet to connect to each switch and run a command—a cumbersome task when many switches exist.
To reduce the risk of syntax errors and make updating the switches easier, we decided to automate the entire update process. We used Active Server Pages (ASP) to create an internal Web site on our network that was running Windows NT Server 4.0 and Microsoft Internet Information Server (IIS) 4.0. This Web site uses two scripts—updatevmpsline.asp and telnet.asp—that I wrote in VBScript.
Updatevmpsline.asp automatically updates the database-configuration file. As the excerpt in Listing 4 shows, I used the FileSystemObject object to read and write to that file. (You can find the entire updatevmpsline.asp script as well as the telnet.asp script in the Code Library on the Windows Scripting Solutions Web site at http://www.winscriptinsolutions.com.)
Telnet.asp automatically updates the switches. To create this script, I used Dimac's w3 Sockets utility. With this utility, you can easily write code that uses Telnet to connect and pass commands to a switch. You can download a free trial version of w3 Sockets from http://www.dimac.net.
We now have a solution that makes managing subnets a breeze. When we want to update the database-configuration file, we just specify the MAC address or VLAN we want to change or add. When we want to update all the switches, we just click a link.
