In these days of web interfaces, many of us rely on the built-in configuration and management interfaces in our network devices - after all, they're free and generally easy to use. The problem with these built-in management interfaces, though, is that by definition they allow you to manage only a single device at once; if you have a collection of systems on your network, you have to deal with them one-by-one.
If you have a number of similar devices (for instance, half-a-dozen, stackable switches in various data cupboards around the building) the vendor may have bundled in some proprietary software for managing multiple devices at once. This is fine in itself, but if you have multiple vendors' kit in your network, then at best you're going to have to have one management world for each vendor.
The market for generic management tools is a lucrative one for the likes of HP, whose OpenView product family is perhaps the best known of the bunch. These tools cost serious money, though, and many small and medium organisations just can't afford to use them. But in these days of open source software, has the free software community come to the rescue? Are there tools out there that will let us manage our networks for nothing (or, at least, next to nothing)?
After some scouring of the Internet, the answer appears to be: yes and no. For monitoring tools, the answer is a definitive "yes": there are plenty of useful applications out there that don't cost a packet and although some can be a bit fiddly to install, and set up, they are mostly useful. The "no" side of the answer, however, comes from the fact that we're aware of no tools that provide a simple, generic interface to actually reconfigure the devices we want to manage.
Problems with generic device configurationThis is hardly surprising, because equipment is just so darned varied that one would perhaps be over-optimistic to expect someone to write the equivalent of (say) CiscoWorks and give it away for free. After all, each vendor has put person-years into writing its configuration tools and so it would be unreasonable to expect a team of programmers to give their time for free to produce a super-set of vendors' kit.
The main issue with configuration is one of mapping the logical hardware (the low-level device and interface names) onto a physical representation of the device and catering for the proprietary idiosyncrasies of each unit. Basic routers are pretty simple, because you tend to have a collection of ports and each port has a collection of parameters - addresses, protocols, link speeds and such like. In anything other than a basic device, though, you have a plethora of inter-related features - ports might have not just link speeds and addresses but also VLAN memberships, even firewall rules. It would be unreasonable to expect a bunch of software writers who develop software for the fun of it to attempt to produce a superset of all the key vendors' management tools.
Generic monitoring toolsThe freely-available network tool market tends, therefore, to concentrate on the monitoring, information collation and alerting side of the coin. We tend to monitor networks based on devices, subnets and interfaces and these entities are largely common to all network devices - at least at the high level. So, even if we do have the most complex switching infrastructure in the world, with combined layer 2/3 switching/routing and VLANs because the whole point of "virtual" entities is that they look like physical networks at layer 3, they can be monitored using traditional layer 3 (or above) tools such as SNMP pollers and application-level probes.
Network traffic monitoringMost corporate routers provide SNMP-based interfaces to their throughput data, which can be used to analyse the usage of the various connections in the system. By far the most popular tool for plotting the ongoing loading of network links is the Multi Router Traffic Grapher, or MRTG. The fact that it uses a generic SNMP engine means that you can monitor pretty well any SNMP parameter using MRTG, but it's best known as the tool that a lot of ISPs use to show their customers ongoing graphs of the performance and loading of their network links. You can point MRTG at pretty well any device that has interfaces with throughput data available through SNMP.
Server monitoringAs well as watching the network for traffic patterns, network managers are also interested in the ongoing performance and behaviour of their various servers - both file/print and application servers. The traditional tool of choice was Big Brother, but this lacks a key property in that it's not Open Source; the alternative is Big Sister, which was written as an alternative to Big Brother but with more features, and which is available under the GNU General Public Licence, or GPL.
Big Sister, like the package from which its features are derived, has a central data collation server which polls the various machines you want to monitor. At the basic level it needs no extra software on each client machine, since basic "are you up?" monitoring can be achieved using standard network concepts such as "ping". You can also achieve application-level monitoring by writing scripts that (for instance) attempt to make an SMTP connection to each mail server to ensure that the mail server is running; scripts for a bunch of "standard" applications come as part of the package. Big Sister also has the concept of an "agent" application that sits on each monitored machine and provides the central collation server with information about CPU, RAM and disk utilisation, in order that the system manager can monitor this information on an ongoing basis.
The main screen of the package provides an overview of what's happening on each monitored server, with red/yellow/green indicators giving a basic "bad", "warning" or "OK" impression in each case. You can then drill down into each entity to see historical data and get a more quantitative analysis of what's going on.
Generic monitoringAlthough Big Sister is excellent for monitoring the basic state of systems, and for providing application-level alerting, it's not an SNMP monitoring tool. You'll therefore want to sit it next to a copy of OpenNMS, another Open Source offering that fills this gap of SNMP monitoring.
Although something of a faff to install, since it sits on a Linux machine and requires a modicum of hand-configuration using a command line, OpenNMS provides an excellent level of monitoring for all SNMP devices. Its functionality overlaps Big Sister to a certain extent, as it too is capable of providing application-level analysis of services such as DNS, DHCP or LDAP, although its user interface is more involved and it doesn't have such an idiotproof, at-a-glance system status page.
OpenNMS, like Big Sister, sits on a server somewhere and frequently probes the various devices on the network for the services you tell it to. It'll auto-discover the devices on the LAN if you tell it to, and will figure out what services it thinks are running. You can then customise the requirements for each server (you may, for instance, not wish to monitor some or all of the services it's found on your test web server).
Rather than showing you the status of all the machines on the network (as Big Sister does) OpenNMS instead worries about the machines with problems. So, although you can drill down by hand into each individual computer or network device, what you're presented with on the front screen is merely a summary of devices that have something wrong with them - the stuff that's working OK isn't shown unless you start digging. So it's very much an exception handling tool, rather than an overall network watcher.
The other difference between OpenNMS and Big Sister is that while the latter concentrates on machines (you tend to monitor "Web Server" or "Email Server 1") the former is all about interfaces. Because it's SNMP-based, OpenNMS discovers the machines using network broadcasts and pings, but then gets all SNMP-oriented and says things like "Tell me about all your interfaces". For this reason you tend to see not just a machine but all the interfaces it owns, and because SNMP interrogates the low-level information, you tend to learn a lot more about the interfaces themselves than you do with Big Sister.
Trap catchingThe next thing we need to talk about is: how do we deal with the various logging messages and alerts that are generated by the devices on the network? After all, polling devices is fine for historical reporting and trend monitoring, but if a device throws a tantrum, or experiences a serious error, you want to know about it immediately.
The Harvester Project's aim is to build a log message and SNMP trap collation tool that brings together the various reporting actions of the network devices into a central location where the appropriate alerts can be actioned. The system is designed to handle millions of alerts and log messages (which is fortunate, as even a modest server application can produce copious message logs) and in addition to handling the common message formats through in-built capabilities (SNMP, Syslog, etc) you can write your own add-ins to deal with any weird and wonderful formats you happen to use.
In addition to collating messages, Harvester will also deal with proactive alerting to email mailboxes, pagers, SMS receivers and the like, based on rules that you configure into the system.
Network analysisThe final spoke in the wheel of network monitoring is that of how to track down the actual problem when you've discovered that there's a problem. Why is your switch's traffic light permanently on? Where are the packets coming from and what are they?
The answers are provided by Ethereal, a traditional packet sniffing tool that you can use to soak up the packets from the network and decode what they mean. In addition to monitoring all traffic on a segment, you can tell it to include only a given set of source and destination hosts. The authors have been immensely kind and have written packet decoders for most of the commonly-used packet types (DNS packets, for instance, are far from trivial, but Ethereal will decode them and tell you the precise contents in human-readable form). Ethereal, like any packet sniffer, isn't something you'd run all the time, but it's an invaluable tool for figuring out the root cause of the problems that the other tools we've mentioned have helped you discover.
Vendor-specific monitoringAmid this flurry of generic tools, it's important not to forget that we do sometimes want vendor-specific tools instead of general non-specific ones. The most popular platform for networking kit, particularly in the corporate router market, is of course Cisco, and projects such as COSI (The Cisco-centric Open Source Exchange community). Leaving aside the fact that the acronym doesn't match the words, COSI exists as a distribution centre for assorted tools that people have written for managing Cisco equipment. COSI holds a vast collection of assorted scripts for Cisco routers, from everyday tools such as an access control list (ACL) manipulator to weird and wonderful stuff such as low-level PPP/L2TP packet decoders.
Most of the stuff you find in the COSI archive is rather hard to comprehend, but it's a useful reminder that Open Source tools can be vendor-specific as well as generic.
Honourable mentionsWe reckon that for a general installation, the bulk of what you need is provided by a combination of OpenNMS, Big Sister, Harvester and MRTG. We've come across a few other tools as we've looked around the Internet, though.
- Cheops-NG: An X-Windows-based tool for Linux that provides some useful auto-discovery and basic system information interrogation for networks.
- GxSNMP: An SNMP tool for Linux machines running the Gnome window manager which, although not updated for a couple of years now, has some useful functions such as a generic SNMP MIB browser.
- Mon: Another Linux-based package that has some commonality of functionality with OpenNMS and Big Sister, but whose GUI doesn't look as nice.
SummaryAlthough there's no such thing as an Open Source tool for cross-platform network device configuration, this is no surprise. At the end of the day, most network devices come with sufficient in-built configuration tools, be they command-line or Web-based (or even a separate Windows/Java GUI-based program), to enable the system manager to configure them appropriately. Given that one spends far more time monitoring networks than reconfiguring them, it's not a great problem that our Open Source friends have concentrated on the monitoring and notification aspects of network management.
In this monitoring/notification realm, the Open Source chaps (and chapettes) have come up trumps. With just a modest armoury of tools and no cash at all you can build a network and system monitoring suite whose facilities are as good as many of the commercial ones. Okay, they may not be as attractive, and you're certain to have a harder time installing the Open Source ones than you would a commercial one (it took us about three hours to do all the back-end mucking about with database software to get OpenNMS working, for instance) but at this price, you can't knock it.
PackagesThe various packages mentioned in this feature can be found at the URLs listed below.
|Multi Router Traffic Grapher (MRTG)||http://people.ee.ethz.ch/~oetiker/webtools/mrtg/|
|SNMP Trap Collector||http://sourceforge.net/projects/trapcollector/|