Michael W. Lucas - Network Flow Analysis

For Liz

PRAISE FOR ABSOLUTE FREEBSD, 2ND EDITION BY MICHAEL LUCAS

"Michael Lucas is probably the best system administration author I've read. I am amazed that he can communicate top-notch content with a sense of humor, while not offending the reader or sounding stupid. When was the last time you could physically feel yourself getting smarter while reading a book?"

Network administrators of all backgrounds share one underlying, overwhelming desire. It doesn't matter if you manage a network with 400 separate manufacturing plants connected by a global MPLS mesh or if you're responsible for three computers and an elderly printer. Network administrators all share an abiding and passionate desire for just one thing: We want our users to shut up.

Blaming the network is easy. The network touches everything. Businesses assume that the network will work perfectly and make decisions accordingly. A user can't open that 900MB Excel spreadsheet on the file server on another continent from his 20th-century PC? Network problem. A website in Farawayistan is slow? Network problem. A user can't get a faster response over a 33.6Kbps modem? Network problem. In general, users don't care about trivialities such as the cost of bandwidth, the physical layout of transcontinental fiber, or the speed of light. They want the network to work the way they think it should.

This problem is exacerbated by the network's invisibility. Routers and switches are black boxes. You feed cables to the network, and it gives connectivity back. Traditionally, servers have much better activity logging and reporting than network devices. Sysadmins can write scripts to announce when a server process fails and try to remedy the situation, but very few network administrators have equipment that can monitor or repair itself. The usage information stored on a network device shows only the last few minutes at best. When a user reports an application failure, many systems administrators check their logs and report, "I have no problems. It must be the network." More sophisticated network administrators have traffic measurement tools such as MRTG, CiscoWorks, or OpenView, but these don't prove a network has no problems. They merely show whether the network has or lacks the particular set of problems that the software can report. The lack of media errors on a switch's uplink port says nothing about TCP/IP errors or firewall issues. With such minimal logging, blaming the network becomes very easy and hard to disprove.

In addition, modern-day network administrators typically have no formal certification or training process. The days of needing a computer science degree to manage a network are long gone. What network administration certifications exist are frequently for systems administration. An "operating system vendor-certified" network administrator is actually certified in the services that the operating system offers to the network, not the network itself. When you study for a Microsoft DHCP Server certification, for example, you learn some things about networking but a whole lot more about that particular DHCP implementation. Network service management is a useful skill, mind you, but it's not the same as managing the lowest level of the network. Network administrators learn the hard wayand it's a very hard way indeed.

This is a shame, because network administrators can claim a powerful role in any organization. The network administrator can help resolve almost every technical issue. The network administrator can make himself an invaluable, indispensable, and irreplaceable component of the organization. A network administrator who masters the tools, understands the protocols, and restrains his natural contempt for the lesser minds surrounding him will not be fired until the company dissolves around him.