#
Upgrading and Repairing Networks

# - 30 -

# Network Management and SNMP

By now, you have had a chance to learn about the many different parts and pieces that go into creating a networked environment. Management of that network is vital regardless of whether you're supporting 20 LAN users or 50 offices connected via a WAN. Good network management can save you time and help prevent the problems that occur if you currently react to network support issues in "fire-fighter" mode--killing the fire after it has started.

Networks are by nature difficult beasts to get a hold of. In the old days, when a PC or Macintosh was an island, problems could only go so far. Nowadays, we connect PCs, Macintoshes, UNIX boxes, and even mainframes together over Ethernet, token-ring, FDDI, T1s, Frame-Relay, ATM, ISDN, dial-up lines, and even wireless networks, using multiple vendors' hubs, routers, gateways, NICs, DSU/CSUs (digital service unit/channel service unit), and modems. You get the picture: a dazzling array of hardware and software that can quickly become difficult to manage. When computers were isolated, it was easy to determine why an application wasn't printing correctly. But in a networked environment, you may need to look at not only the application but also how it's loading from the file server, whether the token-ring segment it's on is beaconing, or even whether the printer's network adapter is failing. All this may be happening 20 miles from where you're located and where you may not be able to access the faulty device directly.

Indeed, you would be surprised how many companies build vast, complicated multi-vendor networks with little or no network management in place, under the thought that "We'll build that in later." If you think that you can't afford the infrastructure costs of building in network management up front, just remember that the biggest cost of a network infrastructure is not the initial hardware or software installation, but the maintenance once everything is in place. Without good network management and, as you'll see later, systems management in place, those maintenance costs can quickly devour an entire IS budget.

By the end of this chapter, you'll learn what a network-management platform should provide, some features common to all good network-management systems, and the difference between network-management and systems management. You'll also learn about how the Simple Network-Management Protocol (SNMP) works, and how to use it in TCP/IP and Novell IPX/SPX environments. We'll also talk about how to plan, choose, and set up a network-management system (NMS), including some of the challenges of multi- vendor, multiprotocol networks. Finally, we'll look at some of the issues surrounding the emerging switching technologies and how best to manage them.

## Network-Management Functions

When you begin to consider implementing a network-management strategy (NMS), it's very helpful to know what functionality you will have at your disposal. You may be asking, "Can I configure all my `Brand X' routers from a central console?" or "Can I have all my Novell servers send a message when they are experiencing excessive errors on the Ethernet that they are connected to?" In this section, we'll go into detail about what sorts of things most network-management platforms can and should provide. One thing to keep in mind throughout this discussion is that despite what you can get from a given platform, you should always keep in mind what you need for your environment. Implementing an overly complex network-management solution because it has lots of neat features is going to cost you proportionally more time than the management problem you're trying to solve is worth. A management platform should give you the basic features you need now, with the capability of being easily upgraded with additional functionality as you need it. Keep this in mind while planning a network-management strategy, and you'll always add value without adding unnecessary complexity.

NMSs typically provide functionality to a certain class of devices. If we follow the OSI seven-layer reference model described in chapter 3, "The OSI Model: Bringing Order to Chaos," then most traditional NMSs provide management up to layer three, the network layer, and sometimes four, the transport layer. If we follow this model, then network management should encompass at least the following devices:

- Layer One--Physical NICs, modems, DSU/CSUs, multiplexors, or any other device that provides physical access to a network medium
- Layer Two--Data Link Bridges, hubs, repeaters, switches, or any other device that defines the signaling of data onto the physical medium
- Layer Three--Network Routers, translational gateways, switches that implement layer three routing, or any other device that makes decisions about where data will go based on some network-addressing scheme
- Layer Four--Transport (optional) Including TCP and UDP, IPX/NCP, SPX, or any other protocol that provides connection-oriented or connectionless services between end-nodes

You will notice that the first three layers specify hardware devices, whereas layer four is expressed purely in software. Layer four information, while protocol-dependent, can provide useful information for managing a network. You may find it helpful, for example, to know whether a UNIX server running TCP/IP has a TCP connection with another host and on what port or how many UDP broadcasts that host has generated. Support for all of these layers is usually provided by some network-management protocol, which either has built-in support for these devices or provides extensibility for a vendor to add the required functionality. For example, as we'll discuss later in the chapter, the Simple Network-Management Protocol (SNMP), implemented over TCP/IP or even IPX/SPX, can provide management for many of these devices in a generic way without any additional software.

### What a Network-Management System Should Provide

When you sit down and start planning an NMS, you should think conceptually about what you want to accomplish--that is, what is your strategy for network management? Are you hoping to become more proactive in support of your systems? Are you trying to provide more centralized control? Whatever the goal, the importance of deciding this ahead of time will affect what features you look for, what devices you decide to manage, and how you implement your management system. These last two points will be discussed at length in the later section "How To Plan for a Network-Management System." Whatever the purpose, all NMS implementations should provide some basic things.

Over the past 10 years, a lot of research and development has been put into the idea of network management. The International Organization for Standardization (ISO), the same group that helped develop the OSI Model, also put together a network- management framework to support its Common Management Information Protocol (CMIP). CMIP is the OSI-standard protocol for network management. The OSI framework consists of five points that are considered imperative to a good network-management implementation. These are as follows:

- Fault Detection The ability to detect and report on faults in the network. It's also desirable if the management platform can act in some predefined way in response to a fault. For example, it could shut down a hub port that is sending excessive bad packets.
- Configuration Management The ability to remotely affect the configuration of a managed physical or logical device.
- Performance Analysis The ability to look at performance statistics on the network for the purposes of trend analysis and capacity planning.
- Security Control The ability to control access to devices on the network from the network-management platform. This would include, for instance, controlling authentication policies to routers, hubs, or other network devices to prevent unauthorized configuration.
- Accounting The ability to collect data on who's using the network, how much, and for what purpose.

What you will find is that most NMSs provide a generic set of tools that give you the ability to perform a number of key functions on elements of your network. You should always look for a core set of functionality that addresses most, if not all, of the five points.

Functionally, what you usually get when you buy an NMS is software that allows you to set up a network-management console--or simply the Network Manager. The Network Manager is the master control panel. With the Network Manager, software runs as agents on each device that you want to manage. The agents communicate with the Network Manager to provide all the information you need to manage a device. Some agents are proprietary in nature and some follow standards, but generally both serve the same purpose: to interact with the managed device to find out its status and then report back to the Network Manager. While agent software varies from vendor to vendor, most provide the following basic functionality:

- Status information about the managed device.
- Statistics about the managed device's network interface(s).
- An interface to the managed device's configuration.
- The ability to detect faults in the managed device and report on them to the Network Manager. This reporting mechanism is often referred to as a trap.
- The ability to provide authentication and security to the agent such that only a Network Manager with the correct security may access the above functions on the agent.

You'll notice that these agent features are similar to the five OSI-mandated functions for network-management systems. Indeed, it is primarily the agent's responsibility to carry out these key functions as they are implemented on the managed device.

Now that we have looked at what layers of the OSI model are involved in network management and what functions an NMS should provide, we can define what network management really is. If you take all the devices that encompass layers one through three (and optionally four) of the OSI model--for example hubs, routers, bridges, NICs and gateways--and provide the agent software on each of them that performs the above five functions--fault detection, configuration management, performance analysis, security control and accounting--you have network-management in a nutshell. The combination of managed devices, agents that run on them, and the Network Manager are common to almost every NMS, proprietary or not.

In addition to the earlier five points, there are some other important elements that a good NMS should provide and that you should seriously consider when looking at functionality:

- A graphical user interface, with the ability to visually map elements of the network
- Support for third-party plug-ins
- Operating system independence--that is, you should have the choice of which OS you run your NMS on
- Support (if possible) of industry-standard protocols and management information (for example, SNMP and MIB-I or MIB-II)

An NMS can serve many other functions; however, as previously mentioned, it's important to keep the goal of your system in mind before being wooed by some vendor proclaiming absolute control over every aspect of your environment. Make a checklist that includes the preceding five points of network management, add to it the previous four important elements and then add any needs specific to your environment. Submit that to each vendor for response, and you'll be able to compare apples to apples when making your NMS decision. The "Criteria for Choosing a Network-Management System" section later in this chapter is devoted entirely to the decision-making process.

### Network Management versus Systems Management

We have talked about network management in the context of layers one through four of the OSI model. Now consider the situation where you not only want to provide configuration, fault detection, performance analysis, security control, and accounting to network devices but you also want to be able to add users to a Novell NetWare 4.x directory tree or check on the progress of a software distribution job from Microsoft's Systems Management Server to your 200 Windows 3.1 workstations across a nationwide WAN. Suddenly the lines of functionality between normal network-management functions as earlier described and what we'll call systems-management functions become less clear. For example, if in the previous example, your SMS distribution job fails, you may need to look to the network--your hubs and routers--to determine why. As we'll see, this blurring of functionality is a difficult challenge to meet, and one that all network administrators must deal with.

What Is Systems Management? If you talk to four different NMS vendors, they will each give you a different definition of what network management is and what systems management is. What we'll call traditional network management usually includes managing only those devices that make up the network-infrastructure--those devices in layers one through three (and sometimes layer four). Systems management, however, is huge, nebulous, and at best can be defined as the management of hosts, workstations, service providers, and the protocols and services that they use to communicate with each other. What this translates to in reality can best be described with an example. Imagine you had an NMS that provided a view of the routers in your Novell network. You can view the configurations on the routers, and even change them. This would be a classic network-management function.

Now suppose you had a button on the Network Manager that allowed you to run Syscon, Novell's utility for server and user configuration. Maybe you would click an icon of the Novell server you want to manage, and then click on the Syscon button. You are authenticated to that server and provided with an option to add users to that server's bindery. This is systems management, albeit a simple example. More likely, you may want to manage a more complicated task, like inventorying all the PCs on your network and using that information to create a database from which you can build a network map, a graphical picture of what and how devices like PCs and servers are laid out on your network. There are a number of functions that are traditionally deemed systems management, and as such, are usually not included in traditional network-management software. Some of these are

- Inventory and Asset Management Usually a database of all the devices on your network, with information about what hardware they have, what their configuration files contain, and what software is loaded on them.
- Operating System Configuration and Tuning This may include functions like the Syscon example; modifying Novell Server `set` variables; or loading, stopping, or starting new services on a Windows NT server.
- Software Distribution This includes functions like copying a new application to a group of workstations or servers, such as that provided by Microsoft SMS software, and the mechanisms to verify delivery and version.
- Remote Control/Administration This includes the ability to take over a user's desktop for purposes of support, or just the ability to "touch" a remote workstation or server to restart a service, reload a NetWare Loadable Module (NLM), or kill a rogue process.

While you will find many of these systems-management functions in stand-alone software packages, you may find it useful to implement some of them as an integrated part of your network-management platform, especially if you are in a small organization, where the same group provides both network and systems support. In that case, make sure the network-management platform supports some of these stand-alone packages as plug-ins. Most network-management software provides an Application Programming Interface (API) that allows software vendors to take their stand-alone systems-management application and make it an integrated part of the Network Manager. For example, Intel's LANDESK software is a plug-in for Novell's ManageWise. Landesk's functionality is fully integrated with ManageWise's such that Landesk tools can interface directly with devices managed by ManageWise. This is an example of a fully integrated plug-in. On the other hand, some vendors may say they plug into an NMS but may only provide an icon that allows you to launch it from the Network Manager. So it is desirable to find an NMS that supports as many plug-in applications as possible if you see the need to do both network and systems management from the same Network Manager.

Deciding What To Manage. If you are faced with deciding how much systems management you will implement on your network-management platform, the best thing to do is look at how you support your network and systems now. If you work in a small shop, administering a few Novell or Windows NT servers, your needs for complex network management will probably be small in comparison to system-management needs, and you are likely responsible for both. In that case, look for a management platform with strong systems support, and the ability to plug in better network-management tools as your network grows. The reason for this is that when your network infrastructure is small, maybe two or three segments in one or two buildings, it's probably just as efficient to physically visit each site as it is to set up a complex network-management platform. However, as your network infrastructure grows, you will need to be in more geographically diverse places at the same time, and that's where good network management really helps.

If you're working for a large organization and planning for a network- or systems- management platform, the task becomes more difficult. Chances are that there are different groups doing systems management and network management. You may have one group that troubleshoots workstations, file servers, and printers. Another group may be responsible for hubs and routers, and another still for software distribution. In this case, the roles of systems and network management are less clear. This is especially true because the higher-end platforms for systems and network management tend to be more complex and therefore more difficult to integrate with each other. Many people will be tempted to try and integrate all of their network and systems management needs under one "super-console," with all functionality available on a single screen.

The advantages of integrating all these systems is that information from a system inventory database, for example, could be used to populate a network map or identify who is using a machine that is generating large amounts of network traffic. You can also use systems-management information in conjunction with network alerting and reporting to automate your trouble-ticketing system. But, be warned, such an integration task is by no means trivial. Trying to get one vendor's inventory database to feed information to another's network-management map or trouble-ticketing system will take a lot of development resources. It really only makes sense for very large organizations. And, even then, this sort of project is not for the faint of heart. More importantly, integrating all systems may not make sense organizationally if you have decentralized support staff that each support different areas. To create a synergistic management platform should be the goal of any IS organization. But don't lose sight of the real goal, which is to provide a useful management platform for the support staff doing the actual work.

## Common Network-Management System Features

In this section, we'll look at some features that most NMSs support. Generally, each of these features is implemented using either industry-standard protocols, such as SNMP, or proprietary methods. Regardless of implementation, they serve the same purpose, which is to allow a network-management console to collect data about the devices it is managing and generate information from that data.

### Polling

Polling is a key feature of all NMSs. It is also where you need to do a lot of planning before implementing your system. A Network Manager periodically queries all devices that it manages to determine their status, which is called polling. There are a couple of ways to implement polling. Usually, you configure how often a Network Manager polls. This is important because on larger networks, where a Network Manager has to keep track of thousands of devices, the traffic generated by this polling function can be quite significant and can adversely affect network performance. The challenge is to configure the polling interval to be long enough so that it doesn't generate a large amount of traffic, but not be so long that, if a device fails, you don't find out about it in a timely manner.

An alternative to this is a process called trap-based polling. In this scenario, when, for example, an interface on a router fails, a message or trap is sent to the Network Manager indicating a problem. The Network Manager can then poll the device in question to determine the extent of the problem. This is a more desirable approach than periodic polling because it is event-driven and only generates traffic as needed. Of course, some NMSs may not support this. In that case, the best way to tune polling is simply to start with a fairly infrequent polling interval, maybe 15 minutes or 1/2 hour, and then adjust it downward as you find your response time requires it. In a fairly stable network, where your response to a problem is not measured in seconds or even minutes, this should be sufficient.

### Auto Discovery

Auto discovery is one of those functions that sounds good on paper, and most NMS software will boast but in practice has been problematic to implement. Basically, the idea behind auto discovery is that you can install a Network Manager package, plug it into the network, choose an icon that says Discover and it will send out a query packet to all devices on your network and build a graphical map or database of all your devices based on the responses. The mechanisms to accomplish this vary, depending on your networking protocol, but what you will usually find is that many NMS packages' auto-discovery functions don't work flawlessly or even at all. Especially on the low-end PC-based packages, this functionality seems to have been given less attention by the developers. It's a feature most vendors include because everyone expects it, but they put varying levels of attention into getting it right.

In most cases, you should expect to provide at least some information to the Network Manager regarding what devices to look for. For example, in a TCP/IP environment, some Network Managers will ask that you build a "seed" file of subnets to send a query. In a Novell environment, you may be asked to enter a range of IPX network addresses or even server names. Then the Network Manager will query an attached server's bindery to find out how to get to the other devices. In any case, don't depend on an auto-discovery process to correctly discover all devices in your network. It's best to use it as a starting point, with a list in hand of all the devices you want to manage to fill in the blanks.

### Device Configuration

Device configuration is a feature that all network-management and many system- management platforms should support. Some implement it using industry-standard protocols like SNMP, and some will use proprietary agents and protocols, but regardless of the mechanism, you should have some way of affecting the configuration of large numbers of devices from your management console. This may be anything from shutting down the number one token-ring interface on your router in another state to setting up a SAP filter on your Novell router next door. The important thing is that regardless of location, you can modify configurations as if you were at the device. What you will find is that due to the multi-vendor nature of most networks, a given NMS will provide generic configuration control, using a protocol like SNMP, and then a vendor will often plug in a module specific to their devices. For instance, you can do some rudimentary configuration of a Cisco router using any number of network-management platforms, but if you plug in CiscoWorks, you get many more features specific to these routers like advanced configuration control of many devices or the ability to script and track configuration changes.

### Graphical Mapping

As mentioned earlier in the chapter, a GUI is one of those "nice-to-have" features. In this day of GUI-based everything, suffice it to say that an NMS system without a GUI is not long for this world. Not only is it easier to visualize network problems when they are displayed graphically, but you can use features like color-coding and blinking to visually alert you to different levels of problems on your network. There are some Network Managers that even let you build physical maps of your environment and then let you overlay managed devices. For instance, you could draw a layout of your computer room and place all managed routers, hubs, and servers where they actually sit. This makes troubleshooting for someone not familiar with all your systems very easy and provides excellent documentation of your network as well. Novell's ManageWise product is a good example of an NMS that provides this feature.

### Trapping Events

As alluded to earlier, traps are an important way an agent, running on a managed device, can let a Network Manager know about unusual events. Traps are, in fact, exception reports. They let a Network Manager know that an interface is down or has come back up or that someone has tried to access a device without the correct authorization. Traps, like polling can quickly generate large amounts of traffic if not managed correctly. Because traps are implemented on the agent software running on the managed device, they can take up valuable resources on that device if they happen frequently. This is especially true if a trap is configured against a given threshold. In this case, the agent has to do some work every time the device does to determine if the threshold was exceeded. In a busy network, where all devices are doing a lot of work, this may take up valuable CPU cycles. So it is just as important to tune trap generation on an agent as it is to tune polling on a Network Manager. Ideally, an agent should generate a single packet of data when a trap event occurs. Then as previously mentioned, a Network Manager can poll that agent for more information as required. A good rule when considering trapping and polling is that you should let the Network Manager do as much of the work as possible and the agent as little as possible.

### Event Logging

Event logging is a Network Manager function where all the results of polling and trapping are collected in logs, which can be viewed then or saved for later analysis. You can also log events like who used the Network Manager last, what configuration changes were made to a given device, or any number of other auditing functions. Your NMS should give a lot of options for events that can be captured. Since a large network is likely to generate a lot of events, make sure that your event logs are configured, which prevents them from growing to epic proportions in a short period of time. Many logging facilities give you the ability to save logs up to a certain size or time and then will roll over the events in the log. If you plan to use the logs for future analysis, make sure that if you roll over the log file, you have a way to archive the log information you need, preferably in an automated fashion.

### Protocol Analysis

Protocol analysis may be the single most powerful tool an NMS can provide. What this amounts to is having a Protocol Analyzer, offering functionality like the Network General Sniffer or Novell's LANalyzer, available to you from a Network Manager console on each segment of interest throughout your network. If you support a geographically diverse environment, you can quickly benefit from the power of this tool. Imagine getting a call from a user two states away who is experiencing slow response on their PC. After checking your Network Manager for unusual activity, you might want to install a protocol analyzer on the wire to get more detailed information about the problem. Instead of catching a plane to the remote site, it's much easier to click the segment in question on your NMS console, select a menu item for protocol analysis, and see all the packets that were going across the wire at that remote site. This feature is implemented by various vendors in many different ways. Some vendors provide special software agents that run on a device attached to a given segment. You can then access the agent using a special network monitoring package and can capture packets at varying levels of detail. Some provide a high-level view of who is talking to whom, what protocols they're using, and a breakdown of the class of packets. Others provide full packet decoding.

Examples of these agents are Novell's LANalyzer agent for ManageWise, which is an NLM that runs on a NetWare server and provides packet decoding for all the segments connected to that server. Also available is Microsoft's Network Monitor Agent, which is part of Systems Management Server (SMS) and runs as a service on a Windows NT server or workstation. Then there are hardware devices dedicated to packet capture and decoding, which connect to multiple segments and provide information back to a central network monitor. Examples of this are Network General's Distributed Sniffer or any of the various RMON probes that are available. (We'll take a look at RMON later.)

There are two things to be aware of when implementing remote protocol analyzers. First, remember that if you are capturing network data in real time from a remote segment, then you are generating extra traffic on the network between your remote agent and the Network Manager. This may or may not actually affect the data you're capturing, depending on the severity of your problem. The second issue is related to the software agents. All of these agents rely on capturing data through the NIC on the device that they're installed in. All of these agents require the NIC to support something called promiscuous mode, which means that the NIC has the ability to collect and open packets that aren't specifically addressed to it. Not all NICs support this. For example, IBM's original 16/4 Token Ring NICs don't, nor do many older Ethernet NICs. Make sure you check with your NIC vendor before deciding to use the software agent approach. It's also important to realize that the software agent will impose some resource requirements on the server and NIC that may not be acceptable on a very busy system. Finally, any solution, agent or dedicated hardware, will quickly become costly if you try and monitor every segment in your network. Pick the most heavily utilized segments first and then add as needed.

## Network-Management Protocols

Depending on your platform, you may be able to implement any number of network-management protocols to support your network. The network-management protocol is the method by which your agents and network managers exchange information. The protocol will define what transport mechanisms can be used, what information exists on an agent, and in what format that information is arranged. By far, the most popular protocol for managing networks is the Simple Network-Management Protocol (SNMP). Originally designed for the TCP/IP-based Internet, it has been implemented on other protocols, including Novell's IPX/SPX, Digital's DECNet, and AppleTalk. Since it is based on widely accepted Internet standards, it has a great many advantages and is supported by most, if not all, serious network-management vendors. Because of this role, it is highly recommended that if you are planning a network-management strategy, you focus on SNMP as your protocol of choice. In the long run, it will give you the most flexibility, extensibility, and vendor and end-user support.

### Understanding SNMP History

SNMP was actually not the first management protocol defined for use on the Internet. Back in 1987, the Simple Gateway Monitoring Protocol (SGMP) was defined by a Request for Comment (RFC) to manage the ever-expanding router network on the Internet.

> How the RFC Process Works
> The group that requests and defines the standards for the Internet, called the Internet Engineering Task Force (IETF), established a "working group" to develop a Request for Comment (RFC). RFC's are, in effect, the written specifications for a given Internet standard. As a working group begins to work on a standard, it is given a number and is given Draft status, indicating it is still a work in progress. When a standard has been agreed upon by all parties involved, it is given Recommended status and becomes the official specification for that standard.

In 1989, the first RFC on SNMP received Recommended status, having been built on the experience learned from the short life of SGMP, and the need to manage devices other than just routers. Currently, RFC 1157, written in 1990, is the most recent update to SNMP version 1. Related to the SNMP standards are the associated Management Information Base-I and -II (MIB-I and MIB-II, respectively) standards, which define the contents of the agent software. If we refer back to our discussions of agents, then the MIB is a specification for what items are managed by the agent software. The MIB attempts to provide a generic list of functions that many network devices have in common. For vendor-specific features, the MIB provides a way for vendors to add on their own.

To better understand the relationship between the MIB standards and SNMP, think of the MIB as the agent software, running on the managed device, and SNMP as the vehicle by which information is shuttled between the MIB and the Network Manager. Both the MIB and SNMP in concert provide an Internet standards-based way to manage your network. This vehicle is described in more detail later in this section.

There has been a lot of work in the last couple of years on SNMP version 2, which among other things, seeks to enhance how SNMP implements security. Unfortunately, as of this writing, there hasn't been a consensus among the involved parties, and some parts of this standard have yet to be solidified.

How SNMP Works. SNMP got its name from its goal to provide simple network management. To do this, its creators decided to take as much intelligence out of the agent as possible, and place it squarely on the shoulders of the Network Manager, assuming that while the Network Manager was destined only to manage, MIB agent software would run on devices that were responsible for other tasks like bridging, routing, or repeating. As a result, SNMP performs only four basic functions on the MIB agent. These are

- Getting a specific value in an agent (get)
- Getting the next value in an agent (get-next)
- Setting a specific value in an agent (set)
- Allowing an agent to send a trap to the Network Manager (trap)

When we speak of values above, we are referring to elements in the MIB that provide information about a specific function on the managed device. For instance, the value of "percent bandwidth utilization on router interface one." These four functions, working in conjunction with the MIB agents, provide all the functionality most NMSs need. This elegant solution allows a manager to query an MIB agent for its current status or configuration (get), traverse or "walk" the MIB from element to element (get-next), make configuration changes on an agent (set), and receive exception reports from an agent in trouble (trap).

A trap is generated by an MIB agent as a result of a predefined set of occurrences in that device. When a trap is sent, it is accompanied by the network address of the sending device, the type of trap, a trap code, the time the device has been up, and any other "interesting" information. The possible types of traps are

- ColdStart Indicates that the device is reinitializing itself and that the device's configuration may change as a result. For example, this trap might be sent by a router that has just been reconfigured and requires a restart for the changes to take effect.
- WarmStart Indicates that the device is reinitializing but that no configuration change will occur as a result.
- LinkDown Indicates that the device has encountered a failure in one of its interfaces. This may include, for example, a router interface that has gone down or a file server with a failed NIC.
- LinkUp Indicates that one of the interfaces on a device has just started. This may be an initial startup, as in the case of a newly defined interface, or a restarted interface that had previously registered a LinkDown.
- AuthenticationFailure Indicates that someone tried to access the SNMP information on the device without the proper security authority (described later in the "Security and Communities" section).
- EGPNeighborLoss This trap is used when a router utilizing an exterior gateway protocol experiences a peer that has gone down.
- EnterpriseSpecific Identifies that the agent has encountered an enterprise-specific event. This would result from a vendor who has made custom additions to the MIB in the enterprise-specific area. The trap code field will be used to detail what the exact nature of the trap is.

Because network-management information was viewed as a necessary but not critical piece of network traffic, SNMP is implemented in TCP/IP over the User Datagram Protocol (UDP), which is the connectionless protocol for use in IP networks. Because it is connectionless, there are no guarantees of delivery as in TCP. SNMP uses UDP port number 161 for requests and port number 162 for SNMP traps. Ports are the service points that an IP-based device uses to uniquely identify the protocol being sent or received. Because UDP is connectionless, if an SNMP packet fails to reach a Network Manager or agent due to a bad link or congested network, the intended party will not try to retransmit but will simply resubmit the request at the next interval. This is desirable because you don't want network-management traffic to take away bandwidth from "production" applications doing important work, by retrying the request until the packet has been delivered, as it would do using TCP.

Since its initial development, SNMP has been defined over a number of different transport protocols in addition to TCP/IP. In 1993, RFCs 1419 and 1420 defined SNMP over both AppleTalk and Novell's IPX protocols, respectively. Particularly in the Novell environment, this has been useful in providing standards-based network-management services to IPX-based services.

MIBs and Agents. MIBs (versions I and II) define the objects that are contained within agent software. When the standards for SNMP were written, it was determined that there needed to be a standard format for information within an agent that interfaced with the network-management protocol. This standard format was defined as the Structure of Management Information (SMI). If you think about an MIB as a database of items to be managed, then the SMI is the structure, or schema, of that database. The MIB is a hierarchical tree that contains definitions for a standard list of functions or characteristics to be managed on the device. These functions or characteristics are referred to as objects. If we follow the database example, they can also be thought of as fields in the database. Each object, or field can then take a value, depending on the state of that object in the managed device. For example, the "IP address of router Ethernet interface number one" would be an object that would have a given value depending on how it is configured on the managed device.

Each object in the MIB has a number of characteristics that allow it to work with SNMP to provide its four basic functions (get, get-next, set, and trap). Characteristics that are common to every object are

- `ACCESS`, which defines the access rights to the MIB object.
- `DESCRIPTION`, which describes what this object provides--for example, an object that lists a managed device's name might have a description that says "Host Name of Managed Device."
- `STATUS`, which indicates whether this object must be implemented in this MIB agent. This is primarily used by the IETF to let vendors who write MIBs know whether a given object is absolutely required, perhaps optional, or no longer relevant.
- `SYNTAX`, which describes what the proper format for the value of this object should be. For instance, if the object defines how long this router has been up, the syntax may say that "how long" should be defined in seconds.

`ACCESS`, for instance, can take one of four possible values:

- `read-only` That object can only be read
- `read-write` That object can be read or set
- `write-only` That object can be set but not read
- `not-accessible` That object cannot be set or read

Keep the `ACCESS` item in mind as we talk about security and communities in the upcoming section.

As mentioned above, `STATUS` indicates whether this object must be implemented by the MIB agent--that is, whether or not an agent must track a particular item on the device it's monitoring. This item takes the following values:

- `mandatory` The agent must implement the object
- `optional` The agent can implement the object
- `obsolete` The object is no longer required

Each object in the MIB is uniquely identified by a kind of addressing, called the Object Identifier (OID). The OID is a convenient notation for locating a MIB object, and you will often see it referred to on Network Managers when you query a device's configuration or status. When the IETF defined the MIB, they attempted to build a "tree" that includes not just information on the MIB standard, but information about other kinds of information, including definitions for other organizations besides the IETF, and other types of information other than network management. While this may seem like a lot of information, the MIB-II standard represents just one "branch" on the tree. In figure 30.1, you see the whole tree, starting at the root of the tree and presenting all of the relevant "leaf objects" that lead to where the MIB-II definitions are. The reason we need to follow the tree from the root to the MIB-II part is that the OID refers to the MIB starting from the root. Within the MIB-II tree, each standard object that defines an element on a managed device is referred to by a unique OID.

Figure 30.1
This is a look at the path to the MIB-II "branch" of the IETF Object Tree.

To define the OID for the start of MIB-II, for example, you use the notation 1.3.6.1.2.1, which refers to the numeric value of each branch leading to the MIB-II branch. In fact, every OID for elements within the MIB starts with this same dotted decimal notation (1.3.6.1.2.1). You might also see the OID represented in terms of the branch names, instead of the decimal notation. In this case, the OID for MIB-II starts at iso.org.dod.internet.mgmt.mib-II. Each element within the MIB can be identified in this way. When using the get-next SNMP command, you have the ability to move from OID to OID, retrieving the value of each object. This is especially useful when you are trying to obtain values in MIB tables.

Tables are basically a set of OIDs that represent the columns and rows of a table. For example, a router's routing table is in an MIB table--where each row/column element of the table has its own OID--and benefits from the use of the get-next command to collect all the routing entries available. Additionally, there is a place in the MIB tree for vendors to put MIBs specific to their products, allowing their management software to address them. This place in the MIB is designated by the OID 1.3.6.1.4.1 or iso.org.dod.internet.private.enterprises. Under this OID, vendors can implement additional objects that are specific to their product line.

You may be wondering if you have to memorize the OIDs for every object you want to manage! Don't worry, most Network Managers shield you from ever having to look at OIDs. They translate that long dotted notation OID into plain old English like "router at interface one, number of Ethernet collisions since the router has been up." The only time you need to know about OIDs is if there is a value in an MIB object that your Network Manager doesn't know about. In this instance, you have to manually adjust it. Most Network Managers provide this kind of manual interface with the MIB for this purpose.

Security and Communities. The creators of SNMP sought to provide some rudimentary level of security, such that any user with an SNMP manager could not issue, for example, a set command to change a router's interface IP address. To support this security need, the concept of communities was developed. You can very easily think of communities as user IDs of a sort. When an SNMP agent is configured on a device, you can assign access-levels based on a community name. As mentioned above, each MIB object can have four `ACCESS` types: `read-only`, `read-write`, `write-only`, and `not-accessible`. Generally, when you configure an agent, you provide it with a community name for `read-only` and `read-write` access. In effect, this is your password to attain that level of access. When configuring a Network Manager, you provide a community name for each device you want to manage. When the Network Manager sends, for instance, a get packet to a given OID on a device, it sends along the configured community name. The device's agent receives the community name and, based on its community name configuration and the access-level for the OID, provides a community profile. The profile indicates your effective rights to the requested object.

For instance, suppose your Network Manager provides a community name to an agent. The agent has been configured to allow that community name, `read-only` access to the MIB. If the Network Manager is trying to issue a set command on an MIB object with an access type of `read-write`, the set command is disallowed because the only operations that the Network Manager can perform are get and get-next (read operations only). In this way, the community profile provides a restricted view of the MIB to the Network Manager.

It's important to be aware that community security is only a rudimentary form of authentication. Community names are sent in the "clear," or unencrypted, as part of an SNMP packet and are therefore easy to discover. And any community name implementation is also only going to be as secure as the security on the Network Manager console, which generally hard-codes community access into its configuration.

Implementing SNMP in IP and Novell Environments. Most major NOSs today come with support for SNMP. What this means is that they provide agent software running on both client and server. In the TCP/IP environment, this may come in the form of the snmpd daemon on a UNIX system or the SNMP Service on a Windows NT workstation or server. In the Novell environment, you can implement the SNMP NLM over either IP or IPX. Figure 30.2 shows the SNMP configuration options for Windows NT.

Figure 30.2
Configuring Windows NT's SNMP service installation options.

If you have TCP/IP configured on your Novell server, you can also configure it with SNMP support. Novell provides an SNMP NLM that provides an MIB agent for your server. You can configure the NLM with community-based security and specify the network address of your Network Manager for purposes of sending traps.

Generally, each vendor will implement some relevant subset of the MIB specification as part of their SNMP agent. For example, Novell's SNMP NLM allows you to configure all the elements of the Systems group, indicating Name of Server, Location, Contact Name , UpTime, and so on. From any SNMP Manager, you can then add the server as an object on your map and get this basic information. You can also color-code the map so that you know if the server goes down or maybe even have it page you when an outage occurs, depending on the features available to the Network Manager. As an example, I used Cabletron's Remote LanView product, primarily for managing its hubs via SNMP, to map a large number of Novell servers in order to find out about outages in a timely manner. This same basic functionality is available for accessing Windows NT's SNMP service.

If you are interested in managing workstations as well as servers, you have a number of options. In the Novell client environment, Novell's VLM architecture includes an SNMP module, implemented as a software driver, that allows you to manage a workstation to get `system` information as well as packet data flowing through the NIC. Additionally, many NIC vendors implement SNMP agents on the hardware. For example, 3Com Corporation's Ethernet NICs let you configure an SNMP agent implemented in hardware on the NIC. Using the NIC's configuration utility, you can enter in the System Name, Location or Contact Name, and manage the NIC from a central SNMP Manager.

### RMON

RMON stands for Remote Network Monitoring. The RMON MIB extension was first defined in RFC 1271 in 1991 and recently updated in RFC 1757. The purpose of RMON is to extend the MIB-II standard so that it could provide a mechanism for the unattended capture of more detailed data than that provided by the standard MIB-II groups. You can retrieve that data later and use it to determine characteristics like utilization, error rates, and so on.

The RMON MIB fits in the MIB tree, shown in figure 30.1, at the same level as the other MIB-II objects, like `System`, and `Interfaces`. The RMON objects begin at OIDs 1.3.6.1.2.1.16, which if you refer to «B_Ref343929807», is under the MIB-II branch. Within the RMON MIB are nine groups of statistics that can be implemented. If a vendor chooses to provide support for a given RMON group within an agent, then the standard requires them to support all objects within that group. However, not all groups need to be implemented. Indeed, many vendors choose to implement only a subset of the groups to conserve valuable resources on the device running the RMON agent. Because the nature of RMON is to capture and hold data until needed, the more groups that an agent supports, the more memory and processor resources are required to maintain it.

How RMON Works. When implementing RMON, hardware-based "probes" or software-based agents are placed at various points of interest on the network. These probes or agents' sole function is to capture data of a number of types or "groups" into the RMON tables. At a later time, one or more management stations can then access the probes or agents to get a variety of statistics, generate graphs, and do trend analysis. The probes and agents also prove useful when trying to troubleshoot problems. Since they can run all the time, they can capture events leading up to network trouble and allow you to go back and determine where and why the problems occurred.

Hardware-based RMON probes are usually small boxes, which contain nothing more than an NIC and a lot of memory to store data. Depending on the configuration, sample intervals, and number of statistics collected, some probes can capture one or more month's worth of data. This can be very valuable if you are trying to baseline a network for future capacity planning. There are a number of vendors that either build RMON probes or install software-based RMON capabilities into their network devices. For example, HP's LAN Probe can work in conjunction with an application called Netmetrix to configure and analyze remote probe data. Many hub vendors also include at least some of the nine RMON groups in software on their management modules to provide more complete data about the packets going through the hub.

The Nine Groups of RMON. As previously mentioned, the RMON specification provides nine different categories or groups of data that can be captured. It's broken down this way so that the RMON vendor has the option of providing only the most vital groups necessary or all the functionality available. These groups are implemented on the RMON probe or software agent. The following lists the nine RMON groups, their Object Identifier to indicate their place in the MIB hierarchy, and a description of their function:

- Statistics (OID: 1.3.6.1.2.1.16.1) This group provides basic statistics for the given network interface type on the probe. For example, it will collect a breakdown of packet sizes on the segment over time.
- History (OID: 1.3.6.1.2.1.16.2) The history group is responsible for storing periodic samples of the segment for later analysis. The size and sample interval of the history group can be configured on the probe.
- Alarm (OID: 1.3.6.1.2.1.16.3) Using preconfigured thresholds on the probe, this group can generate alarm events when a parameter surpasses a threshold. This group requires implementation of the Event group to generate alarm events.
- Hosts (OID: 1.3.6.1.2.1.16.4) This group keeps track of the MAC addresses of the devices that are communicating on this segment. It keeps track of both source and destination addresses to determine who is talking to whom.
- HostTopN (OID: 1.3.6.1.2.1.16.5) This group is used to store data regarding the top "talkers" based on some criteria provided by the management station. Basically, this group forms a holding area when a management station requests a report of the most active devices.
- Matrix (OID: 1.3.6.1.2.1.16.6) This group holds a table that defines pairs of devices who are talking to one another. While it is similar to the Hosts group, the Matrix group is really only concerned with providing a table of "conversations."
- Filter (OID: 1.3.6.1.2.1.16.7) This group allows a Network Manager to define one or more filters, based on a value and offset, for packets that want to be captured. The definition of that filter(s) exists in this group. This group depends on the Capture group to actually do something with the filtered packets.
- Capture Packets (OID: 1.3.6.1.2.1.16.8) This group requires the presence of the Filter group and provides a means of capturing packet flowing through the network interface for later review. This group actually stores the contents of each packet flowing into the interface and meeting the filter criteria. This data can then be utilized by an application similar to a protocol analyzer to view the contents of the packets.
- Event (OID: 1.3.6.1.2.1.16.9) This group provides the mechanism for the device to generate events and alarms. It is basically the holding table for any events that occur on the device, either through configuration or exception.

Once you have installed RMON probes or software agents onto your network, you can use the data they collect to perform many functions. Depending on which groups the probe or agents implement, you can configure them to collect, for example, collision and utilization statistics on a given network segment. You could have the probe capture this data for a month; then utilizing software like Netmetrix, you could graph this information over the month to determine peak utilization and peak collisions and make decisions about whether you should further segment your network or even provide more bandwidth.

Using the Alarm group, you could set thresholds on these two statistics, and each time the thresholds are reached, the probe or agent would report it to the Event group's table to be viewed later. Finally, if you had Packet Capture and Filter capabilities, you could store the packets during times of heavy utilization and view them later to determine which devices were doing the most talking. The biggest advantage that RMON provides over the standard MIB-II object set is the ability to capture and store historical data for later review. The values contained in standard MIB-II objects represent only what is going on at any given moment, providing an instantaneous view of the managed device.

Advantages and Limitations. As mentioned earlier, RMON devices can be a great tool for gathering network statistics without having to constantly monitor a given segment via a Network Manager. They are basically designed to plug in and be forgotten. However, there are several issues to consider before running out to buy probes for every segment in your network.

First, if you are considering implementing RMON in an existing hub, router, or other network device whose primary function is not RMON, then remember that this kind of remote monitoring is resource-intensive. Don't go out and implement a RMON agent that supports all nine groups on all your hubs if you don't need all nine groups. Similarly, if you are considering implementing stand-alone RMON probes, you will find that they are pricy little investments, costing as much as $1,500 to $2,000 each. Sit down with a map of your network and decide what segments really need probes. Consider starting out by putting them on busy server and user segments or remote segments that are geographically difficult to access. And make sure that you purchase them with enough memory to store a sufficient amount of data in case you don't get to check them for a few days.

## Planning, Choosing, and Setting Up a Network-Management System

Now that we've discussed the various mechanisms available to you for managing networks and systems, we'll go over the process of building a network-management infrastructure in your organization. This process involves planning a strategy for your NMS, choosing a vendor or vendors to provide the hardware and software, and setting these systems up in your environment in a way that provides robust, easily accessible network-management resources.

Just as a warning, implementing network management is an evolutionary process, especially in today's growing distributed environment. Don't expect instant results. Most network administrators are "brought up" as fire fighters, responding to problems as they arise. Installing network-management promises to make them proactive, but it will take education and time before a network-management tool can enable your network administrators to provide the kind of support needed to grow with your organization and its networking needs.

### How To Plan for a Network-Management System

Installing an NMS differs from other types of software installations you may have performed. Unlike basic applications such as word processors or spreadsheets, NMS software requires some forethought, some planning, and some real analysis of what you are trying to accomplish. As mentioned at the beginning of this chapter, it's easy to build a very complex NMS that doesn't address what you really need to manage. Following are some steps you can take to ensure that before you actually choose a software vendor, you have thought about what you want to do with your NMS.

Defining Needs. The first step in planning an NMS is to determine what it is you need to manage. We covered in an earlier section the differences between network and systems management. The first decision you need to make is: Are you going to do some elements of both? If so, do you plan on integrating both on the same platform from the very start? If so, then this may guide your decision from the very beginning.

When you define your needs, think about what devices you want to manage first. Start small, choosing only those network devices in OSI layers one through three. This means hubs, routers, bridges, and maybe NICs in servers. I say maybe on NICs because in a large environment this may mean making software changes on a large number of servers to accommodate SNMP, or whatever network-management protocol you choose. Most hubs and routers have SNMP support built-in, and it's simply a matter of defining community names and setting up your NMS console, and away you go.

Also, think about which of the functions you want to have right off the bat. To start with, you may want to consider sticking to the basics like fault detection, configuration management, and performance analysis. This can be implemented without a lot of changes in your infrastructure. If you decide you need to have protocol analysis, historical reporting, or even systems management, then this will likely have a greater impact on your infrastructure, require more time and money to implement, and introduce greater complexity. There may also be significant time and resources required if you are planning on building your NMS based on an OS you don't have experience with. For instance, if you support Novell and Windows on Intel platforms and are considering implementing NMS on UNIX (a common NMS platform), you may require additional time to get up to speed on administering the OS before you can get up to speed on the NMS.

Infrastructure Costs To Consider. Speaking of money, you will need to consider what costs, both hidden and obvious, you will incur when building your NMS. The obvious ones are hardware and software. You will need at least the following:

- Some kind of workstation to serve as the NMS console (you may want to buy several for different locations). These workstations will need to be quite powerful, including lots of RAM and disk space to manipulate and store the management database.
- Depending on the vendor, you may need to add a management module to each of your hubs, routers, or bridges to support network management.
- You will need software for each management console you build. Depending on the company, they may license you based on how many network devices you are going to manage. Additionally, you may incur separate costs for agent software if you are using a proprietary-management protocol.
- If you are implementing some kind of remote protocol analysis solution like RMON or software agents, you will need to purchase hardware or software for every segment you want to analyze. Then you may need to purchase separate console software to read the data from the agents.
- Finally, don't forget the soft costs of setting up the console, building your network map, and setting up any event reporting, alarms, and so on. Also, you may have to make some network protocol changes to accommodate the NMS. For instance, in a TCP/IP environment, you may find it useful to use a service like DNS to refer to all your hubs, routers, and other IP devices that are being managed. This may require building such an infrastructure if it's not already in place. If you estimate man-hours to complete this phase, double it to be on the safe side. This is by far the most challenging portion of the process.

Defining the Scope of Implementation. When you define the scope of your NMS implementation, make sure you plan to install critical elements in phases. For example, start small by deciding that in the first phase, you will install the NMS software and populate the network map with all the hubs and routers in your local location. Then maybe the next phase includes adding devices across one or more WAN connections to the picture. A third phase may include integrating one part of a systems-management solution. Don't try to do everything at once, and do take time between phases to work out the bugs of the previous phase.

Defining the Method of Implementation. How you implement your NMS solution is mostly a function of your organization's environment. But there are a few things to be aware of before you dive right in. Count on any changes you make to managed devices, like hubs, routers, and so on to be disruptive. That is, even if a vendor says adding SNMP support is Plug and Play, plan for it not to be and schedule work accordingly. Also, any new software agents you install on any systems, especially file servers, should be tested thoroughly before installing them in production environments. This includes looking for memory leaks that may slowly cripple a server or other obvious anomalies. The best advice is to test, test, test any new hardware and software before implementing it. While this may seem obvious, you'd be surprised how many organizations don't do this, only to discover that the seemingly benign NMS software cripples their network.

### Criteria for Choosing a Network-Management System

In an earlier section, we talked about the features and functions of a good NMS. Depending on your environment, however, you may be constricted in your choice of available systems. If that is the case, the best advice is to build in extra time to implement any nonstandard solution. Otherwise, the choices for standards-based NMSs are quite complete, and you should have no problem choosing a vendor solution that meets your needs.

Industry Standards Compliance. In some situations, adhering to industry standards can sign the death knell for a piece of software or hardware. In the case of network management, however, SNMP has become the standard for managing a variety of network types. This is evidenced by the majority of vendors that provide SNMP solutions. Suffice it to say that unless you have a very small environment with very specialized needs, your best bet is to implement a management system based on SNMP. By doing so, you will give yourself the flexibility of having the widest choice of vendors and products, and the protocol with which most network administrators are experienced. This recommendation applies not just to TCP/IP environments, but also to Novell, Apple, and any other platforms that support SNMP.

Availability of Third-Party Add-Ons. No matter which network-management vendor's software you buy, it is unlikely that it will have everything you need. So it is important that the vendor supports add-ins of other companies' products. This generally comes in the form of an API that they provide to allow developers to write additional modules. Examples of products that support this are HP's Openview platform and Novell's ManageWise software.

> NOTE: No matter what other features a given NMS touts, make sure it supports plug-in modules for other nonstandard network components, and make sure there are vendors who actually write these plug-ins. This cannot be emphasized enough. Make sure that the modules you need actually exist, and that there are at least some well-known vendors supporting and writing software for the platform.

Distributed Database Support. Most NMS platforms keep all the information they have learned about your network in some kind of database. Some use industry-standard database engines from Sybase, Oracle, or Microsoft's SQL Server. Other systems use a proprietary format. There are arguments to be made for choosing an NMS that supports one of these popular engines because it makes any future development utilizing the database engine simpler. Perhaps more importantly, however, is that the platform supports a distributed database model. In reality, very few do support this model. The reason this is useful is that, if you have support staff located in different locations, who need access to resources on the NMS, it would be useful to provide them with their own NMS console without having them build their own map and corresponding database. Without distributed database support, each NMS console you build requires you to build the network map and corresponding database from scratch each time. This process is time-consuming enough without having to do it for each console.

Unfortunately, many NMS vendors don't yet provide this support, so you have to weigh the costs of having this feature against other features a particular vendor may have. If you don't mind having to do a little extra work up front and on an ongoing basis and have good backups, you may not need this feature.

Some Well-Known Management Platforms. While there is no one vendor's platform that meets all needs, there are a number of companies who have large percentages of market share because their applications are "open," standards-based applications that many vendors write add-ins for. Generally, most high-end NMS software runs on some flavor of UNIX. This is generally due to the inherent robustness of UNIX as a 32-bit multitasking OS. What you will also find, is that recently, many vendors have been announcing ports of their NMS applications to Windows NT because they have the same 32-bit features as UNIX. If you are more familiar and comfortable with setting up and administering Windows-based systems, this may be a good alternative. For these same reasons, Windows 3.1 makes a poor network-management OS platform for any but the most basic types of management. The following are some examples of the more popular NMS systems, with their attendant OSs:

- Hewlett Packard's Openview platform (UNIX, Windows 3.1 version also available)
- Cabletron's Spectrum (UNIX)
- IBM's Netview and Netview-6000 (SNA & UNIX)
- SunSoft's Sun NetManager (UNIX)
- Novell's ManageWise (Windows 3.1)

This is by no means a complete list but gives you an idea of the "big" players in the network-management world.

### Setting Up and Maintaining a Network-Management System

Once you have planned your NMS and chosen a vendor, you will then need to set it up in your network environment. This involves not just populating your network map and configuring alarms and thresholds, but also finding a place for the console to sit and providing the most reliable path to the rest of the network.

Where To Put It? You might think that deciding where to put your NMS system is a trivial issue, but realize that its connection to the network is the only way it can keep track of devices going up or down and gather statistics. If something happens on this local segment, the rest of your network may be fine, but your NMS console will never know about it. It will light up like a Christmas tree and you'll think the whole network has failed. So when you're placing your system, make sure that you have redundant paths to the rest of your network. As an example, you could connect two routers to the segment such that you have two paths to the other segments in your environment. This is illustrated in figure 30.3.

Figure 30.3
How to place a Network Manager Console on your network for fault-tolerance.

Baselining and Setting Thresholds. After you have installed the system, installed the software, and populated your network map through either a manual or auto-discovery process, you will want to start capturing statistics on your network for purposes of providing a baseline for network activity. The baseline is the level at which your network is normally operating. This relates to utilization on the various segments, response times to various parts of the network, and levels of resource utilization on your network devices. You should capture statistics for a good representative period of time to allow your network to reach an equilibrium point. This may be one day or one week, depending upon the stability of your network.

Once this baselining process is complete, take a look at your data to figure out where your network is normally operating. You can look at things like utilization, collisions, and errors on various key segments. Now you can begin to set thresholds. Thresholds are "high-water" marks that you can set on various network attributes. When statistics exceed these marks, an alert is generated and sent to your console. If you are using RMON, these alarms can be set on the RMON agent and picked up by your RMON Manager. If you don't have an RMON-like mechanism, most network-management platforms themselves support alarms based on thresholds you configure. Once the thresholds are set, go back every so often and rebenchmark your network to determine if your baselines have changed.

Setting Up Event Notification. Many systems support various mechanisms for notifying you in the case of a network problem. Visual alarms are the simplest way. These are usually pop-up windows that appear on your screen when alarms are reported. Since you may not always be sitting in front of the NMS console, it's useful (but perhaps not desirable!) to have mechanism to notify you wherever you are. Many NMS packages and third-party add-ins support mechanisms to page you, send you e-mail, or even flash a message on the screen of any system you're logged on to! If your required response times to a problem are quick, you may want to consider one of these technologies.

Backups. Methods for backing up your networked systems were discussed at length in chapter 17, "Backup Technology: Programs and Data." However, backups of your NMS are very important, especially if you don't have distributed database support, and each NMS console's database exists as a stand-alone. Losing a stand-alone database could take days to rebuild, not to mention the lost baseline data, threshold, and alarm configurations.

When backing up most SQL-based database engines, you usually need to take the database offline, do a dump of the data, back up the dump, and bring the database back online. Refer to chapter 17 for more information on backup strategies.

## Managing Emerging Networking Technologies

Most networks today consist of Ethernet, Token Ring, FDDI, and maybe some Local- Talk segments. These segments contain any number of workstations and servers, on a "shared-media." That is, whatever their network topology, they must share resources on their wire with other devices, limiting their access to the full bandwidth available for that technology. Many of these segments are connected together by routers, which provide network-layer packet forwarding to shuttle traffic from one segment to the other. Additionally, routers keep certain types of traffic from leaving the local segment, such as broadcasts, and topology-specific problems, like collisions. However, they also introduce latency into the network, as a packet traveling from one segment to another has to undergo some routing calculation to determine its destination at the router. As a result of these and other issues, switching has emerged in the last couple of years as the next generation network technology. Perhaps spurred on by the increasing popularity of Asynchronous Transfer Mode (ATM) technology, which is inherently switch-based, Ethernet, Token Ring and FDDI switching is fast becoming the preferred method of networking technology.

Basically, switches do what bridges used to do before routers became fashionable. That is, a switch gets a packet in and, based on its data link layer source and destination addresses, makes a decision to forward it to the port of its destination device. Since no network layer decisions are made, switches move packets very quickly, on the order of up to a million packets per second for the faster switches. In contrast, most routers don't forward packets at rates much higher than a couple hundred thousand packets per second. Additionally, a single device, such as a server, plugged into a switch port, effectively has the full data transfer rate available to it during each packet transmission. So a server attached to a 10 M/sec Ethernet switch has a full 10 M/sec available all the time. In contrast, depending on the number of devices connected to a share media 10BaseT hub, each device may get only about 10-30 percent of the 10 M/sec rate, due to collisions and contention. So you can see the lure of switching technology. However, what this means is that, as switched networks grow, networks become flatter, or less segmented. Additionally, broadcasts that were originally blocked by routers suddenly get forwarded to all devices within a switched environment. Therefore, the need to effectively manage traffic in a switched environment becomes very important.

### Managing a Switched Network

Management of the switched environment definitely presents new challenges. Most vendors today have network-management software to cope with these changes, but it's important to recognize how switching changes the way you think about troubleshooting your network. What you will find is that most switch vendors implement the same kind of support that they had for their shared-media hubs, including a management module containing SNMP support and even some number of RMON groups. But they will also include support for the new switched paradigm, including ATM support, virtual LANs, and new ways to monitor switched traffic.

What Changes? Most importantly, moving your network to a switched environment presents the opportunity, as mentioned earlier, to build a flatter, less segmented network. As great as this may sound, it has several implications. First, if your environment is primarily TCP/IP, you may have a fixed IP address space that you have chosen to subnet to provide maximum segmentation for the routed environment. Now you install some switches, flatten out your user segments, and suddenly, instead of having 50 IP hosts per subnet, you have 200. You either have to re-address all your workstations to support the flatter network or do some magic on the routers you have left to accommodate multiple IP subnets on one segment. Management of either solution is challenging to say the least.

More importantly perhaps, is what implementing a switched network does to your ability to troubleshoot problems. If we remember the discussion of the different tools available to most NMSs, protocol analysis, and especially remote protocol analysis through distributed RMON agents, presented a powerful way to capture packets on the network remotely and decode them to determine where a problem lies. With switches, things get tricky. If you have a switch with 12 ports, and five of the ports have, for example, a Windows NT server plugged into them, where do you plug in your RMON probe, or even your network-monitoring agent software? If you plug them into any old switch port, they will never see the packets going from one device to another because the switch receives a packet from server A, destined for server B, and forwards it right to server B's port!

Protocol Analysis Options. Now faced with the above problem, how do we do effective protocol capture and analysis in a switched environment. Different vendors have different solutions, depending upon the switch. On some switches, the vendor has implemented, usually in a combination of hardware and software, all nine RMON groups on each port in the switch. This allows the RMON agent to capture packets, alarms, events, and so on from each port and store them in some area of memory to be analyzed later by a Network Manager.

The limitation of this solution, of course, is related to the inherent performance advantages of switches. Switches forward so many packets at a time, that a large switch would spend all its processor and memory resources trying to keep up with populating the RMON tables with statistics. For larger switching solutions, most vendors implement some kind of special port on the switch, where you can install either a protocol analyzer or dedicated RMON probe. Through the switch's management software, you can then configure the switch to take all packets that come into it from any of its ports, and copy them also to the port connected to the analyzer or probe. In some cases, the probe or analyzer will be on the same switch that it's gathering data from. In other cases, you can actually configure the switch to copy all its packets to some remote port, maybe on another switch, where the probe/analyzer is connected. In this latter case, be aware that you will then be sending additional traffic, in the form of copied packets, along whatever path leads to the probe.

### Virtual LANs

Virtual LANs (VLAN) were developed in conjunction with today's switching technology to aid managing switched networks. What VLANs do, in the simplest case, is provide some functionality to segment devices within or between switches--similar to what a router did. This is done through the management software supporting the switch. Essentially, you can assign one or more ports on a switch or across switches to form a VLAN. All packets from devices in the VLAN will only be forwarded by the switch to other members of the VLAN. This includes broadcasts and has the effect of providing a means of controlling who gets broadcast traffic in a switched environment. Depending on the vendor solution, you can either assign VLANs based on a given set of switch ports or by a given MAC address on a device connected to the switch. Currently there is no one standards-based way to implement VLANs. Therefore, one vendor's VLAN may not talk to another's. Additionally, each vendor implements management of VLANs slightly different. Some allow you to graphically drag and drop ports from one VLAN to the other. Some allow you to define complex rules for the flow of traffic among VLAN members and to other VLANs. Regardless of the implementation, switching in general and VLANs in particular, will add additional challenges, require quite a bit more planning, and demand a new set of skills to manage them properly.

## Summary

In this chapter, we've discussed what kinds of features and functions you should expect to find in today's NMSs. A good NMS should have features like fault detection, configuration management, performance analysis, security control, and accounting. Systems management features like asset management, remote control, and software distribution were discussed as optional elements to your network-management strategy but ones that add complexity to your management strategy. Additionally, we talked about the industry standard SNMP protocol, and its attendant MIBs, for keeping information about network devices. SNMP is the protocol of choice for network management in today's networks. We also discussed the RMON portion of the MIB. RMON provides a mechanism to capture historical statistics, errors, and packets remotely for more complete management of distant sites. Next, we talked about the issues of planning, installing and setting up an NMS, including the idea of starting with a simple plan to manage a base set of network devices, building on that as the system stabilizes. Once the NMS is built, we talked about the need to baseline the system in order to set thresholds for notifying the network support staff of problems. Finally, we talked about how network management, and especially protocol analysis, change in the new switched environments, and how VLANs add complexity to the network-management picture.

Regardless of your environment, it's important to realize the need for good network management. The underlying goal is to build a management system that enables you to see problems before they become epidemic and to better plan for growth in your network. If you're able to accomplish either of these goals, you're on the way to building a better network. If you accomplish both, congratulations, you have done something that most organizations can only dream of!

© Copyright, Macmillan Computer Publishing. All rights reserved.