How to convince your boss to buy technology
As with a major military campaign, the first order of business is gathering intelligence. Guessing doesn't cut it when you're asking for big bucks--you need solid statistics on network utilization from the backbone, server farms, local segments, wide area links, and Internet feeds. Get some RMON or SNMP probes such as Shomiti's Surveyor and deploy them on critical areas of the network. Make certain you attach the probes to switches that support port mirroring, so that you are able to monitor all network traffic. If the hardware doesn't support port mirroring, you'll need to install an optical splitter (if it's a fiber link) or insert a cheap repeater between the network segment and the backbone feed.
If you don't have the budget for commercial traffic analysis tools, check out my column on low-cost network traffic analysis.
Monitoring wide-area links or an Internet connection can be a bit more difficult--it's not always possible to get a probe in the link between you and your ISP, and CSU/DSUs that provide traffic statistics for wide-area circuits are prohibitively expensive. What can you do? Install Multi Router Traffic Grapher, a free application that provides daily, weekly, monthly, and yearly statistics on router interface traffic. If you're not already running MRTG, download a copy and start gathering data on those WAN links.
Besides helping you prepare a case for upgrading your technology, keeping stats on your router interfaces provides an additional benefit: you'll have hard data to support your case if you have to decline requests for bandwidth boosts. Case in point: at our university we recently received a request from an offsite department to upgrade its connection from a T-1 to a 10Mbps Ethernet-over-ATM circuit. All WAN circuits are centrally funded, and upgrading this link would have put an additional $1,100-per-month drain on our IT budget. A quick glance at our MRTG statistics showed that the existing link was averaging 5 percent utilization--hardly enough of a load to justify an upgrade. Without the statistics provided by MRTG, it would have been difficult for us to deny the request.
Be careful how you interpret the numbers, however, because there's a big difference between average and peak utilization. Bursts of traffic can slip under the radar of statistical monitoring tools like MRTG if the polling interval is set for a long period of time. Just because a network segment averages 5 percent utilization doesn't mean that all is well--a seemingly quiet segment might be the next place someone deploys a massive bandwidth-gobbling application.
Network probes and MRTG statistics can only provide you with information about what's happened on the network--they can't predict the future. To get a grip on future growth, you need to talk with the users and the application developers.
Application developers and network staff are usually the last to know about application deployments, but their input is crucial to your proposal. So how do you get them to talk to you? A non-confrontational approach, such as offering to buy lunch, works much better than a finger-pointing fest. ("You're going to deploy a bandwidth-gobbling application in two weeks? Did you think about telling the network crew?")
The same technique works for gauging what users will do when a new application rolls out: take them to lunch, or offer to do a chalk-talk over a brown-bag lunch. Tell them about your plans for the network, and they'll be more willing to tell you what they're going to do with it. You know you've succeeded in getting the feedback you need when your inbox starts filling up with messages like this: "We're thinking about putting an image-based resume system on the human resources network segment. Would this put a big load on the routers?"
Now that you've collected data from the network monitoring tools and feedback from the application developers and end-users, it's time to build your case for a technology upgrade. In my next column I'll show you how to put all of the information you've gathered into a signature-securing presentation for upper management.
Robert Currier has been in data networking for more than 15 years, the last five as Director of Data Communications at Duke University. Currier is an accomplished writer, public speaker, and photographer. His credits include product reviews in Network World, features in PC Computing and photographs in the Chronicle of Higher Education. He can be reached at robert.currier@duke.edu.