Network management can be confusing to newcomers. By its nature, the field involves a daunting list of tasks. Figure 13-1 outlines the range of chores performed by the typical network management team.
Figure 13-1: Network management tasks follow an intensive cycle
Internetworks must be planned, modeled, budgeted, designed, configured, purchased, installed, tested, mapped, documented, operated, monitored, analyzed, optimized, adjusted, expanded, updated, and fixed. That's a lot. No single tool can do all these things, at least not yet. Suffice it to say that network management products and services is an industry unto itself, composed of a complex array of technologies, products, and vendors providing everything from simple protocol analyzers that measure a single link to worldwide network command centers.
You may have noticed that the term "network management" is used in connection with internetworks. (Almost nobody manages just one LAN anymore.) The term has held on since the rise of internetworking and is still in universal use. There is no real difference between network management and internetwork management.
Historically, the problem with computer management tools has been delivering true multivendor support. In other words, it's hard to find a single tool that can handle equipment from different manufacturers equally well. Multivendor configurations-the norm in virtually all enterprise IT (information technology) infrastructures today-are tough to manage using a single tool because of subtle differences in each manufacturer's equipment.
Computer management tools have evolved from opposite poles of the computing industry: systems and networks. The goal is to bring all computing assets under the management control of a single tool, and the prevalence of placing host systems on networks is driving existing system and network management tools into one another's arms.
Sophisticated computing management systems called system consoles have been around for decades. These consoles were generally hooked up to mainframes sitting in a data center and used to schedule jobs, perform backups, and fix problems. Over time, they developed more and more capabilities, such as managing remote computers.
The best-known product from the datacenter mold is Unicenter from Computer Associates (CA). Unicenter is actually an amalgamation of products that CA has woven into a single management solution. Unicenter evolved from a sophisticated console for managing IBM mainframes and disk farms to an integrated management system with support for all the important hardware and software platforms. Most Unicenter product growth has been achieved by acquisition, understandable given the product scope.
The key to Unicenter and other system consoles is the ability to handle the various computer architectures that enterprises are likely to put into a configuration.
Over the past decade, a second breed of management tool emerged in the form of network management systems. These tools focus on network infrastructure instead of the datacenter. They use the networks they manage as the platform for monitoring events and are controlled from a console referred to as the network management station (NMS).
The leading NMS is OpenView from Hewlett-Packard (HP). There's a bit of history as to how HP ended up in this enviable position. HP had committed to UNIX as its strategic operating system in the mid-1980s-years earlier than other enterprise platform vendors. (Don't give HP too much credit; they did so out of desperation because their proprietary 16-bit operating system had run out of gas.) By that time, UNIX and IP had become closely linked in the market, mostly because IBM and other big system vendors were still pushing their proprietary networking schemes. Around 1990, HP seized the moment, and OpenView rode the UNIX bandwagon to become the predominant network management tool. There are now over 100,000 OpenView installations.
As with Unicenter, the key to OpenView's success is its ability to work with devices from various manufacturers, but HP had a built-in design advantage in the form of a then-new IP network management standard called SNMP (Simple Network Management Protocol). Instead of having to design to dozens of proprietary interfaces, HP was able to let the network equipment vendors design products to the SNMP standard. OpenView was the first major management product to implement SNMP.
The defining difference between system and network consoles is the level at which they operate. System management tools focus on operating systems, transactions, data files, and databases as they exist across servers, storage controllers, and disks. Network management tools focus on packets and connections as they exist over network devices, interfaces, and transmission links.
System and network consoles are now converging into a single technology class some call enterprise system management (ESM) tools. Convergence into ESM is inevitable as the line between network and computer blurs and enterprises complete the shift to client-server architectures that move resources from the datacenter out into their internetwork topologies.
The focus of this book is internetworking, so we'll cover only the networking components of ESM.
It has proven to be quite difficult to manage an internetwork using a single tool. The problem has been the inability to collect consistent data from the variety of devices that exist in most enterprise IT infrastructures. The problem isn't so much old versus new equipment, although that's part of it. The major hang-up is that most network management systems are shallow in their implementations; in other words, they can manage only a few aspects of device operation and leave some devices unmanaged altogether.
This is so despite the fact that all major network equipment makers bundle SNMP into their device operating systems. The base SNMP infrastructure is there, but device manufacturers seldom implement it fully in their products. There are a variety of reasons for this:
Consumption of resources by network management Every CPU cycle spent gathering a measurement or sending an SNMP message is a cycle not used for payload traffic. Network management extracts a cost either in slower performance or extra hardware.
Spotty standards support by manufacturers It would be expensive for device makers to build complete compliance into their products. Device hardware would need to be beefed up to handle the additional SNMP work, pushing up prices in the process. In addition, some manufacturers prefer a dash of SNMP incompatibility to steer customers toward standardizing on their product line, because implementing SNMP from one manufacturer is easier than bringing devices of different manufacturers under the same management regime.
Labor A lot of time and attention is required for enterprises to implement and operate a network management system. Management teams are hard-pressed just to keep up with network growth. Few have the manpower to make greater use of SNMP-based systems.
Price-conscious customers Customers are fixated on low price points. The network half of IT shops is regarded as infrastructure, and managers demand commodity pricing. The relentless focus on driving down the cost per port looks good on paper, but incurs hidden costs in the form of poorly utilized assets.
For these reasons, most SNMP implementations gather only high-level information. Fewer processes-called objects-are monitored, samples are smaller, polling cycles are less frequent, and so on.
Often, even when an enterprise does want more network management controls, blind spots are still created by noncompliant devices. Blind spots occur when a policy cannot be enforced in part of a network because a device doesn't support it. Blind spots often occur at backbone entryways, especially to switched backbones. Take the scenario depicted in Figure 13-2. The part of the topology on the bottom has implemented a policy to manage traffic usage between a pair of communicating hosts. But the switch in the middle is not configured to monitor that, leaving that SNMP policy unenforced beyond the switch.
Figure 13-2: Partial SNMP management causes network management blind spots
The IETF (Internet Engineering Task Force) is responsible for the SNMP standard, and it has a tough job. The implementation of any standard requires coordinated acceptance from both manufacturers and users. This is difficult to pull off, because manufacturers are wary of market acceptance and the potential loss of competitive advantage. Understandably, then, standards-setting is always a tricky process. Yet the goal of an integrated NMS console has proved to be particularly elusive for these reasons:
Hardware dependencies Any computer standard must contend with various architectures used for CPUs, buses, device interfaces, drivers, and the like. This both complicates the standards-setting process and makes it more expensive for manufacturers to comply with. The problem is exacerbated by the internetworking industry's habit of using so many different parts in their product lines. Remember all the different CPU architectures that go into Cisco's router line?
Converging technology Until recently, telecommunications, data networking, and computing were viewed as separate and distinct industries. Each had its own industry bodies, standards, and so on. But nowadays, all this equipment has fallen under the purview of network managers. This has increased the scope of the standards and brought together different engineering fields, which creates increasingly more complex work environments for network managers.
Technology onslaught Relentless technology advances in all quarters of computing (telecommunications, operating systems, CPUs, cabling, and so on) have presented the IETF with a constantly moving target, and a manufacturer that has won a hard-earned advantage is often reluctant to fall into line with standards and make life easier for competitors.
Progress has been slow. Yet the lack of integrated management hasn't impeded the explosive growth in the size and use of networks. To accommodate this conflict, management teams use several products to track different parts of their internetworks. Most big enterprises have an ESM, but they augment it with dedicated tools to manage critical parts of internetworks. Figure 13-3 illustrates a typical scenario, with OpenView used to watch the overall network and manufacturer-specific tools to manage critical assets.
Figure 13-3: Most network teams use several tools to manage their networks
The most significant manufacturer-specific tool is CiscoWorks, with broad enough functionality to be considered an ESM unto itself-but only as long as you're strictly running Cisco gear. For that reason, CiscoWorks is usually snapped into an ESM suite like OpenView or NetView.
Management standards aren't just a problem in internetworking. An industry group called the Distributed Management Task Force (DMTF) has been trying for years to get a standard called the Desktop Management Interface (DMI) implemented. The purpose of DMI, aimed at distributed PCs and small servers, is to let consoles monitor inventory-disks, drivers, BIOS versions, memory configurations, and so on-and to perform remote upgrades. DMI 2.0 products include Compaq's Insight Manager, IBM's Universal Management Agent, Intel's LANDesk Manager, HP's TopTools, and others. Trouble is, these products pretty much work only with platforms of their own manufacture. Microsoft has weighed in with an open standard called WBEM (Web-Based Enterprise Management), now under the auspices of the DMTF. Intel is working on a complementary standard at the hardware level called WfM (Wired for Management). For now, you either restrict the number of vendor product lines you use or use individual tools to manage each of them. Sound familiar?
ESM tools have been criticized as difficult to implement, labor-intensive, expensive, slow, and ineffective. They're priced at up to $250,000 and cost at least that much again to implement. As far as specialized management hardware, RMON probes can cost over $10,000 each. The expense has left most smallto medium-sized internetworks relying on multiple tools, each usually specific to the major equipment manufacturers used in the configuration. A second result is that fewer things are monitored, diminishing proactive network management.
The market for tools is robust anyway because the potential for savings from NMS tools is enormous. Some estimate that during a typical IT infrastructure's lifecycle, 75 percent or more of all costs are spent on operations. There is a double benefit of enabling network administration personnel to be more productive and getting better results in available bandwidth. NMS tools help enterprises reduce costs and boost service at the same time.
There are now many major NMS tools. In addition to OpenView, other notables are IBM's Tivoli NetView (IBM acquired Tivoli Systems several years ago), CA Spectrum, Nortel Networks' Enterprise Network Management Portfolio, and Evidian's OpenMaster.
Microsoft entered the fray with the introduction of Microsoft Management Console (MMC) in its Windows 2000 release. Ever expanding, MMC is a key management interface in Windows Server 2003. It's not only used for Microsoft management tools, either. Third-party vendors have been creating their own snap-ins for the MMC as well. See Figure 13-4 to chart how different management tools interrelate.
Figure 13-4: There are a number of network management tools and applications at the network administrator's disposal
The cast of contenders comes from three sources: computer platform makers, such as HP and IBM; network device manufacturers, like Cisco and Nortel Networks; and software companies in the form of Microsoft, Castle Rock, and others. Who prevails will tell which is most important: the wire, the desktop, or the mainframe. Regardless of vendor, NMS technology is headed toward these goals:
More coverage As greater management control is placed on devices and network processes, faster device hardware will be required and more data will be available.
Simplicity As internetworking has exploded in popularity among smalland medium-sized enterprises, more networks are being operated by nonexperts.
Automation As underlying network management technologies improve, more management tasks are being automated to improve Quality of Service (QoS).
Proactive management A new breed of tools helps isolate emerging problems and avert major network problems by taking early corrective action.
Nearly all progress in computing results directly or indirectly from industry standards. Internetworking ushered in the era of open computing with the help of several standards: the seven-layer OSI reference model, IP, Ethernet, UNIX, HTTP, SQL, and others. Now it's time to bring it all under control with integrated management technology driven by SNMP.