* Save time and improve network performance--without spending a dime! * Outstanding open source tools for management, monitoring, optimization, and troubleshooting * In-depth coverage: retrieval, compilation, installation, configuration, and usage--with extensive examples * An indispensable resource for every network administrator and troubleshooter Save time and improve performance with free, open source netadmin tools!In this book, MIT netadmin James M. Kretchmar presents an extraordinary collection of open source tools for streamlining and improving virtually every facet of network administration. Regardless of your experience or your network's size, these flexible tools can help with everything from management and monitoring to optimization and troubleshooting. Every tool is described in detail, with easy instructions for retrieval, installation from source, configuration, and real-world usage. Coverage includes: * SNMP: Remotely administer diverse network devices with a single protocol * MRTG: Graph bandwidth and other router and network statistics * Neo: Unify the administration of SNMP switches, routers, and other devices * Flow-Tools: Collect and process crucial interface-level Cisco NetFlow traffic data * Oak: Collect and distill syslog messages from servers and network equipment, and automatically send trouble alerts * Sysmon and Nagios: Monitor network hardware and servers and notify administrators of problems * Tcpdump: Analyze network traffic at the packet level * Basic Netadmin Tools: Make the most of ping, telnet, netcat, traceroute, MTR, and netstat * Build your own tools with the Bourne shell and Perl scripting language These tools will save you time and help improve network performance-today, tomorrow, and for years to come. Until now, you'd have to discover most of them through word of mouth. Now, one book is all you need: Open Source Network Administration.
Foreword
When I graduated from MIT in 1990, I joined the MIT Network OperationsGroup. It was there that, among other things, I started workingon the Linux kernel as recreational programming. During my time withthe Network Operations Group, I learned what it was like to have operationalresponsibilities. This is a valuable perspective that all developersshould be exposed to, if only briefly.
During my first year or two with the Network Group, we evaluateda commercial network management system. Out of charity, I will notreveal the name of the product nor its vendor, but suffice it to say, it wasa very complicated beast, which required huge amounts of disk spaceand computing power. It would display a picture of the campus, whichwhen you clicked on a building, would zoom in and allow you to selecta floor and display a floor plan, at which point you could click on aroom, and finally, select a piece of network equipment. When selected,a picture of the device would appear, complete with flashing LEDs,which were emulated via SNMP monitoring. If there was a problemwith a router, it would cause an alarm to ring and, on the campus mapview, the building containing the bad network device would flash. Ifthe building map was displayed, the floor with the problem would flash,and so on, until the faulty router was identified.
Unfortunately for the vendor of this very complicated, proprietary,network-management system, an experienced network engineer couldlocalize the problem faster using simple tools like ping, traceroute, andan ASCII terminal. This was advantageous to us because we could alsouse them when we dialed in from home at 3 a.m.
Even implementers of this product realized how outrageous theentire interface was; rumor had it that by setting a certain magicconfiguration variable, the interface would display a picture of the MilkyWay, and you could zoom into our local group of galaxies, pick our homegalaxy, the star system on the edge of that galaxy, and so on, beforefinally zooming into the campus map level. No doubt it was the implementers'private protest against the set of requirements handed to themby some fuzzy-cheeked product manager who, obviously, had never con-figured a router or repaired a malfunctioning network in the middle ofthe night.
Not surprisingly, we decided to skip purchasing this very expensive,very unnecessary network management system. Instead, we stuck toour own collection of tools; some of which were freely downloaded fromthe Internet, and some of which we developed ourselves.My personal contribution to this set of tools was the "ninit" program,a very simple tool. It watched over the named program, andrestarted it if the need arose. It also collected periodic statistics, andtested the named program every 15 seconds to make sure it was stillfunctioning correctly and responding to queries. If not, ninit would killoff the named process and restart it.
The ninit program was made famous in the Unix Haters Handbook(IDG Books, 1994), where it was lampooned as a demonstration of howunreliable Unix software is -- or perhaps all software from BSD; orperhaps just Named -- because it needed a watcher process. The UnixHaters may have had a point, but the ninit program was short, and itwas sweet, and it restarted the name service on our servers at 3 a.m.so I didn't have to be awakened by a pager after our mail queues hadexploded due to a lack of name service.
Many other people have advanced other explanations for the superiorityof Open Source software, such as Linus Torvalds' observationthat "with enough eyeballs, all bugs are shallow." While this is true,I think it is the last point which is the most important for explainingwhy Open Source network management tools work as well as they do:When the person to be aroused from bed to fix an operational problemis the person writing the tools, the very tight accountability loop meansthat they might not be architecturally beautiful (although often theyare), nor have fancy graphical interfaces (very often not necessary), butthey will certainly solve the problem at hand.
This book is a wonderful survey of a wide range of Open Sourcenetwork management tools. Some of these tools may be well knownto you already; others may be entirely new to you. All of them areextremely useful to a network operations team. I hope you enjoy goingthrough these tools, and I encourage you to try them out in your ownwork. If you haven't tried some of these tools yet, you will be in for avery pleasant surprise.
--Theodore Ts'o, Linux Kernel Developer