In-Depth

6 Steps to a Simpler Network

There's a saying in IT that "complexity is the enemy of security." It's also the enemy of efficiency, troubleshooting and other critical network functions. Here are six ways to untangle that crowded web you've weaved.

• By Bill Heldman
• 05/01/2005

Has your single LAN of the '90s evolved into a gargantuan enterprise? If your shop is like most, it started out with a handful of Windows NT, Unix and Novell servers on a little network. Now you're awash in a sea of servers (for which you might have little solid software and hardware inventory information); you're reasonably certain some percentage of your equipment has little to no fault-tolerance or redundancy protection associated with it; bandwidth usage is out of control; you're nowhere near level-set in terms of your end-user computers' OSes, Office and miscellaneous application installations, not to mention BIOS versions; and you're vulnerable to the virus du jour. On top of it all, your mobile and wireless users are increasing at an astronomical rate.

Sound familiar? If so, you're probably wondering how to make sense of it all—or if that's even possible at this point. Well, here are some practical steps you can take to simplify your network.

Figure 1. This building has an unwieldy and overly complex subnet structure, with multiple subnets per floor and limited IP addresses per subnet. This will eventually lead to problems. (Click image to view larger version.)

Start with the Subnets
First, take a look at your subnet structure, because nowhere can things get more kludged than a poorly engineered subnet plan. It can start with a wonderful idea like the 10-dot private addressing scheme. Then you add a bizarre subnet mask to it, assign a subnet to each little handful of users in various corners of the building, and

wind up with a rat's nest. To top it off, you associate the whole thing with switched VLANs. Poorly engineered TCP/IP subnet plans are difficult to understand (especially at 3:00 a.m. when you're trying to figure out the problem with your network), and might needlessly stress network switch and routing gear. If this is you, re-invent your subnet plan. Use standard subnet masks, and break things out into logical divisions. The subnets will fall right out at you.

Take a look at Figure 1, and note that Floors 1 and 3 (we can presume the other floors as well) have a 255.255.128.0 subnet mask, meaning that each subnet has half the available IP addresses that it normally would. (For simplification and clarity, avoid using anything other than a straight Class A, B or C mask.) Further, the second octet is incremented, and the third octet is the same in all subnets. While this works, it's messy and confusing because there are eight subnets per floor. As you go up the floors, you have to remember which grouping of subnets belongs to which floor.

Figure 2. The re-engineered subnet plan is less confusing, more logical and simpler. As you can see, there is one subnet per floor, and double the number of IP addresses available per subnet. (Click image to view larger version.)

Now look at the revamped subnet structure in Figure 2, in which the first floor's eight subnets are isolated with a normal Class C subnet mask. It's much easier to tell at a glance which floor you're dealing with now, and you don't run the risk of running out of IP addresses for a given subnet. Whether you keep the VLANs is a networking decision, but in either case you'll have to go in and tweak the closet switches on each floor to reflect the new addressing scheme.

Simplify Your Name Resolution
A big offender in adding unnecessary complexity to the network is the proliferation of WINS and DNS boxes. By keeping a multitude of name servers in your environment, you run the risk of an amateur administrator keying a static record into the database, preventing Windows from automatically discovering and creating records for the device (which happened to me in one of my jobs). Also, you increase the chance of errors due to replication latency, and the complexity of the installation confuses people that have to follow your lead. Besides all that, you simply don't need a bunch of name servers on your network.

A well-architected name server implementation requires only a handful of servers for even the largest of enterprises. In the case of name server quantities, less equals more. Here are some of the most important considerations:

• If you have to maintain WINS, no more than three WINS servers is a pretty good rule of thumb, regardless of the size of the organization.
• If you can avoid it, do not use the LMHOSTS file on the local client computer or on servers, as this creates even more complexity and difficulty in troubleshooting.
• If you use an image to install clients, disable LMHOSTS lookup in your client network configuration. In cases like this, LMHOSTS is blank. If a computer tries to find a host and resorts to LMHOSTS, the LMHOSTS lookup will fail, of course, but the computer wasted time performing a useless exercise.
• If you can get by without WINS, do so, sticking strictly with DNS for name resolution. However, realize that unless everything is up-to-date—all applications, servers and users—it may be tough to dispense with WINS, at least for the next several years.
• Try to keep your internal DNS environment to three servers.

I'm not a fan of forest administrators keeping a secondary DNS server, as this, too, adds complexity. However, I understand why an admin would want to maintain his own DNS server. The trick here is to have one or two top people (keepers of the root) architect and manage the DNS deployment, and communicate on a routine basis what's happening, so that it's understood how DNS will roll out. Otherwise, the servers will procreate like rabbits and no one will be able to resolve a name. It is vital that someone own the DNS implementation, lock, stock and barrel.

Simplification Through "Stream"-lining Applications
Suppose you were told you could package all of your users' apps with a simple, wizard-driven product, store them on a server as a file and send the resulting application icons to a designated set of users. When a user clicks on one, a small percentage of the app streams to the user's computer, then launches.

This is the idea behind "streaming applications." The app acts like it's running locally, but in fact nothing is installed on the user's desktop—no Registry entries, no files. That certainly simplifies your network, but it goes even further than that: the program isn't even installed on the server. The idea revolves around the packaging software watching an app install itself, then creating a file that represents the app to the server and to the user. The app thinks it's running in the regular framework for which it was written, but in reality, the user is simply utilizing a cache file on his computer.

In this scenario, the user clicks an application and part or all of it—depending on whether it's a desktop or mobile user—is streamed to his computer, as opposed to running directly from the server, as in the Citrix/Terminal Services model. The program instead runs from the app-streaming server. The app-streaming servers represent the apps to your Citrix or Terminal Services servers and they, in turn, represent them to the user. You don't even have to have a Citrix or Terminal Services box to use streaming app server software. Two major players in this space, AppStream and Softricity, both allow you to host the apps without Citrix or Terminal Services.

Simplify by Standardizing
When it comes to Total Cost of Ownership (TCO), one of the worst things you can do is maintain an installed base of every version of Windows and Office under the sun. By level-setting your users' OSes and application versions, you gain some important simplification benefits:

• You avoid having to carry around a bevy of CDs
• Support costs are greatly reduced
• Upgrades are easier ("Let's see, is it SP4 for Win2K and SP1 for XP or vice-versa?")
• Training is easier
• You don't have to cope with software glitches spread across four or five version levels.

I've seen shops with Windows 3.11, 95, 98, ME, NT, 2000 and XP—even a couple of old DOS machines. There are shops where a small percentage of the user-base insists on staying with WordPerfect instead of joining the rest of the Office crowd (or vice-versa). One time, my CFO was adamant that he would not migrate to Outlook calendar from his "Act!" program—never mind that the rest of the enterprise was scheduling meetings in Outlook he wouldn't show up for because he didn't know he was invited.

The same thing goes for servers—keep them level-set for greater efficiencies. One trend starting to take hold in the server world is the idea of "automatic provisioning." You have a rack of "bare metal" servers sitting in your data center, just waiting for loads to increase. When they do, your management software is smart enough to provision (some call it "inflate") a new server for the need, regardless of where the need is. This sort of provisioning technology might require standardization, at least in terms of the OS and associated service packs and security updates.

Simplify Automatically
Savvy administrators know how important automation is to making, or keeping, a network simple. And they get help from today's management tools like SMS/MOM, Altiris, NetIQ, LANDesk and others, which have come a long way from the days of SMS 1.0. One overlooked area of automation, though, is in configuration management. If you've ever had to go through and change the subnet mask on a couple hundred closet switches all over your company, you'll love this class of software.

Suppose, in the example above, that you have 250 network switches sitting in 25 different closets around your company and decide to re-engineer your subnets, as advised in Step 1. Without automated configuration management, you'll have to either Telnet, or HTTP, into each switch to make the configuration change, or visit each switch with a laptop and null modem cable to make the change on a per switch basis.

Configuration management software discovers the managed devices. Once it does, you set up the subnet change and issue the command to all 250 switches at once. Cool, huh?

Simplify Your Printing
Question: What procreates faster than warm, moist yeast?

Answer: Printers!

In a 12-story building of about 900 users, guess how many printers my shop supported? 900! The printer insanity has to stop.

To simplify this grotesque situation, consider leased, networked, enterprise-class Multi-Function Devices (MFDs) that can print in color and black and white, fax, scan and copy. (Some of them make espresso and heat up your morning bagels, too.) Several strong vendors play in this space including Ricoh, Canon and Xerox. These devices can be centrally managed, they're rugged and aren't subject to breakdowns like the little ink- and laser-jet units are. Users can send a variety of jobs to them—whether it's scanning a document on the platen to send to the desktop or sending a 500-page report from the desktop to hit the three-hole paper bin.

Because of the tremendous duty-cycle these MFDs can handle, you can design an implementation that strategically locates them around the building—instead of in every nook and cranny in your office. Best of all, with the right leasing plan, support is handled by the leasing company, freeing you up for more important duties.

Don't Put It Off
Many of these tips take time to implement. Some, like the subnet, require a great deal of preparation and testing. You may feel like you don't have the time and resources to undertake some of these changes, but consider the alternative: having an inefficient, needlessly complex network that slows you down every day. In the end, the extra effort you spend now will save you much effort in the future, not to mention money that you can spend on something other than aspirin.