Network Management on the Cheap update from April 2005

If The Shoe Fits, Don't Push It

You must understand the size and complexity of your management domain to know whether inexpensive, simple network management will be best. If you oversee only a portion of a large organization, within a department, you have a small management domain.

However, you must do more than count the number of devices in your domain--also consider how many FTEs work to maintain your network. If you have more than one person and make lots of changes, yours isn't a small organization. Will simple network management still work for you? Sure, if your domain consists of a few thousand devices but changes are limited to simple upgrades or community-string alterations. If your changes are more akin to rolling out 50 new sites using VPNs every day, simple and cheap won't cut it.

Inexpensive management also isn't a good fit when there's a need for strict adherence to change-management and workflow procedures, which necessitate coordination with a service desk and service-level management-maintenance windows. Many simple network-management products have SLA (service-level agreement) or maintenance-window functionality, but they don't integrate with service-desk or workflow products. Let the amount of coordination required be your guide. More coordination means more expensive network management.

If you're a departmental person who takes orders from a central IT organization, you're part of a larger, more complex domain. Yet, even if central IT monitors your department using costly network management, consider how well the higher-ups react to your needs. If failures wait beyond an acceptable point for fixes, or you can't get a notification e-mail when one of your servers has failed, consider some cheap network management in addition to what central IT provides. For example, you might want to buy monitoring software that includes e-mail notifications, such as Ipswitch's WhatsUp Small Business, and leave the long-term performance management and capacity planning to complex, centrally controlled and expensive products like Concord Communications' eHealth Suite.

If the tasks you're managing are critical, but the number of devices you're managing is small, inexpensive network management may still be a good option. How do you define small? It depends on the amount of monitoring and management data-gathering required.

Most inexpensive management products can handle 1,000 to 1,500 devices on standard, relatively beefy but not gigantic servers--a dual 600-MHz desktop with 512 KB of RAM will do just fine checking 1,500 devices every 15 minutes and gathering some CPU and memory utilization data from your servers. The frequency with which devices are checked and how they're checked (with simple pings or with detailed performance and error data) will affect your choice. The more information you gather and the more frequently you gather it, the fewer the devices you can manage from the servers. Yet, even when gathering lots of performance and error data every 15 seconds, most products on standard hardware should support at least 500 devices.

Also consider the complexity of your services. How many applications do you monitor, and what external (outside your management domain) dependencies does each app have? If your services are limited--say, you host a single app--or you've got a Web server but the DNS server is handled by your ISP, simple, cheap network management might work. But with an increasing number of external dependencies, simple becomes less of an option. If external data sources are necessary, you need automation for consistent, cost-effective processing. The more automation you require, the more it's going to cost.

The "FCAPS" model--fault, configuration, accounting, performance and security--defines the world of management. Can it be applied to cheap network management? For some time, network management has been limited to "F" and "P": Fault watches for failures, and performance tries to predict them.

Only recently have configuring network and systems devices and securing them become part of the simple network-management lexicon. Some products will grab a configuration file off a router or switch, but few will compare, catalog and archive that configuration. And if you're trying to update ACLs (access-control lists) or manage non-Cisco gear, simple network-management products won't be enough.

Security is just beginning to make its way into inexpensive products. Some can provide intrusion detection, as well as check routers and switches for weak passwords and community strings. Kiwi Enterprises and SolarWinds both offer products that do these tasks. If you need more sophisticated security, you'll pay for it. Similarly, accounting is found only in expensive management products.

Database Considerations

Some network-management products are constricted by the database used to store the performance and availability information. Typically, the database cost is included, as long as it's a flat file or free database, like Access and Jet. Most inexpensive management applications that support Oracle or Microsoft SQL won't include a licensed copy.

Any network-management application will alert you when a monitored device is unavailable. It also will tell you when a device is in trouble, reporting systems metrics like high CPU utilization, or network metrics, such as high error rates. Standard alerting methods include sending e-mail, turning an icon red, sending a message to an operator, playing a .wav file and running an executable. Advanced alerting methods include sending SMS messages and beeper support, but more sophisticated alerting options will escalate and provide rollover features.

Regardless of the cost or complexity of the networking equipment to be managed, all the devices, systems and applications to be monitored must be defined to the management application. All network-management products will let you add one device at a time. If you've got fewer than 50 devices, this isn't going to be a challenge--as long as the changes in the network aren't too frequent and the relationships between the devices aren't overly complex.

The inventories of monitored devices are IT assets and have many relationships--regarding how they're physically and logically connected, who is responsible for them, what applications they run and support, and their importance to the business. In networking terms, these relationships are topologies that represent various layers of provided IT services. Network-management applications can document some or all of these topologies, but simpler tools are less likely to show much more than TCP/IP Layers 3 and 4.

Most simple, cheap network-management apps have some automated methods for learning and mapping these topologies. Most often they'll use ping, SNMP, ARP (Address Resolution Protocol) and host files for discovery; LDAP, Network Neighborhood and Active Directory queries are sometimes available. Ipswitch's WhatsUp Professional and Neon Software's LANsurveyor have expanded discovery options. These are usually scheduled, recurring jobs the management software runs, first searching for devices and then querying them to understand what they do and where they belong in the supported topologies.

Depicting Layer 2 connectivity is much more difficult because there is no standard for it. Cisco Systems, Extreme Networks, Enterasys Networks, Hewlett-Packard, Nortel Networks and others offer proprietary Layer 2 discovery protocols. But without a standard for Layer 2 discovery, management vendors are left with the imperfect SNMP Bridge MIB and the task of reverse-engineering each network device. The IEEE is working on 802.1ab, a standard for Layer 2 discovery that will be gradually implemented this year (see "Layer 2 Discovery Digs Deep," at ID# 1423ws1).

Most management applications can scan for IP services like telnet, SMTP and DNS, but don't assume that all protocols are supported, especially if you've got custom applications. Sometimes the flexibility to add and define IP service monitoring is not included.

Being able to group devices by like attributes, organizational hierarchies or business applications supported is useful, but such groupings are only sometimes supported by simple management applications. It's common to group devices by IP subnet and less common to group devices with IP service ports. Some network-management programs let you create arbitrarily named groups that mirror organizational and lines-of-business hierarchies, but you must manually add devices into these groups. In structured networks, it's useful if the discovery process places switches and routers into groups based on SNMP OIDs (object identifiers). This allows for the automatic grouping of access and distribution switches. Simple, inexpensive management applications are unlikely to have this level of sophistication.

Web site monitoring has both cheap and expensive approaches. The simple method checks that a Web page--or, more precisely, a URL--is answering with the appropriate HTTP response. Some inexpensive management products, like those from Empirix and ProactiveNet, can even show the round-trip time for that HTTP response on average, at a minimum or a maximum.

Reporting is always important. It's how status, historical capacity and diagnostics are distributed and analyzed. Most simple network-management products will provide some static, or canned, reports that are output to screen and printer, and as HTML. Only some inexpensive network-management tools include features like e-mail reports and ad hoc report writing.

The Big Easy

Products must be easy to use. But easy means more than having a simple interface. Training, documentation, personalization, automation and support are all ease-of-use factors. Simpler, less expensive network- and systems-management products tend to have fewer features and, consequently, fewer knobs to turn. This usually makes them easier to use.

Most management applications have some sort of Explorer-like interface and are Web-based. Listed hierarchies generally are faster to traverse than topological maps, but maps can require less from the user. Maps can help visualize problem determination and impact of failures. The trade-off is that more complex networks don't usually fit onto a single screen at a usable resolution.

Bruce Boardman, executive editor of Network Computing, tests and writes about network and systems management. He has 12 years' experience managing networks and distributed computing for a financial service provider.

1) Assess your management domain. Larger, more complex domains require more sophisticated management features.

2) A small IT staff doesn't need fancy maps as much as good event management.

3) All automatic inventory features fail to some degree. Audit your network regularly.

4) If you know your network is going to grow, get a product that supports a database.

For details and prices on specific systems, use our Interactive Buyer's Guide charts