Challenges

Network managers face many challenges. Networks often consist of thousands of heterogeneous devices connected by token ring, Ethernet, or X.25 and separated by wide expanses of geography. The size and scope of today's networks make them difficult to manage effectively.

Given the size and geographic dispersion of the typical network, it is extremely difficult for the person charged with network management to even know all of the devices that are in the network, much less the location of those devices. However, it is impossible to effectively manage networks without being aware of all of the components that must be managed. The basic maxim applied to other areas of management is valid here as well: "You can't manage it if you don't know it exists. "

Knowing that a managed object exists essentially consists of trying to keep an accurate and updated inventory--a challenge in itself when considering all of the additions, changes, and deletions from the network that may occur daily. Problem determination is more difficult, if not impossible, when the inventory of network assets is inaccurate or does not contain enough information about the failing network component.

The network manager is confronted by a myriad of devices supplied by a variety of vendors, diverse communications protocols, and complex network topologies, which adds to the difficulty. The permutations of platforms, communications protocols, application software, servers, mainframes, desktops, and databases that could be connected to the network are infinite. Attempting to sort out this tangled web can be an overwhelming task.

The complexities of the IT environments lead to another challenge for the network manager. There is an avalanche of data to sift through in order to find information that is useful for the task at hand, be it problem determination, adding a new device to an existing network, or dealing with performance issues. At times, it may seem like searching for a needle in a haystack.

It is simply impossible to manage the network environment effectively without using a sophisticated management tool. Unicenter TNG includes extensive management capabilities to address the problem. This chapter will address some of the key questions that must be answered in order to take advantage of this management resource.

Where to Begin?

The first question all new enterprise managers should ask is "What systems am I responsible for?" If they can't answer that most basic question, they ought to find the answer as the first order of business. Ignorance is not bliss for a network manager. Rogue systems are vulnerable back doors for hackers. Less dramatically, these hidden or camouflaged assets drain productivity because they are unknown quantities. Something as simple as missing important upgrades makes problems more likely to occur, diagnosis more time consuming, and remedies more difficult to administer. This degrades productivity in the long run.

Each management task described in this book starts with a good inventory of the systems and a good topology of the network. A manager needs the inventory to understand which systems should be backed up. What systems require an upgrade to Windows NT 5.0? What servers should be assigned new user accounts? Topology is necessary to figure out why all of a sudden Human Resources isn't getting email from Accounting, or where it would be best to install a faster link for improving performance.

Slipping Through the Net

The following transpired years ago in the network development group at a major New England computer company: This company once built network equipment (one of the first Ethernets ran through the building) and designed networking software. They knew they had at least one of every kind of major network software and hardware that existed at the time, save one. SNA, TCP/IP, DECnet, Netware, NetBios, and XNS were all present--but not Appletalk. They were positive that there were not any Macintoshes on the company network. It was the punchline of many jokes. When they actually looked at the results of a discovery, however, they found that a dozen Macintoshes had been happily running on their intranet for over a year.

Another company experienced an unexpected benefit of Auto-Discovery when the enterprise IT map, generated via Auto-Discovery, showed a connected network emanating from a division that the company had sold two years before.

The fact that this sold company still had a connection to the parent company's network constituted a security breach. A manual inventory of networks and networked devices would not have revealed this security breach because the resident experts were certain this network had been disconnected. This rogue network would only have been found by accident, an undue and impractical amount of checking, or a computer-driven Auto-Discovery service. The discovery of this security breach was an unexpected use and benefit of Unicenter TNG's Auto-Discovery service.

The Brave New World of Unicenter TNG Discovery

The Discovery service included with Unicenter TNG automatically detects devices on your network and populates the Unicenter TNG Common Object Repository with objects that represent your network devices and their relationships. Once created, these objects can be displayed by Unicenter TNG's GUI and monitored and controlled by the applications in the Enterprise Management layer of Unicenter TNG, such as the Security and Event Managers, as well as by third-party manager applications.

Unicenter TNG Discovery provides significant advantages over other network discovery applications. Unicenter TNG Discovery allows you to do the following:

The automated facilities provided by Discovery reduce time spent on manual network database maintenance, entry validation, network map creation, and routine network maintenance activities. This reduction lowers operating costs and provides increased network reliability.

Prerequisites for Running Discovery

Besides installing Unicenter TNG itself, there are four primary prerequisites that must be met before running Discovery:

There must be a Common Object Repository (CORE). You don't have to worry about this because the

Loading Factors

Many network managers worry that the load imposed by Discovery will bring the network to its knees. A little arithmetic can calm this fear. With ARP cache, the traffic is all in SNMP Gets. Getting a MIB variable takes about 200 bytes of network traffic. For a 100 host subnet with two routers attached to each subnet and each router having eight interfaces and five addresses, you can estimate the number of variables retrieved; assume that many interfaces are disabled. The total data for ARP cache turns out to be less than 450KB, less than 300KB for fast ARP, and less than 225KB for a Ping sweep. Furthermore, studies have found that that normal management traffic for most organizations (polling, traps, and so on) represents only 1-2 percent of available bandwidth--not considered a major impact.

Discovering a Network

Unicenter TNG gives you lots of options for discovering your network, but there are really two basic approaches: the Discovery Wizard and Advanced Discovery. In the wizard-based approach, Unicenter TNG explores the network to its heart's content. Unless you purposely limit it to your subnet, the Discovery Wizard finds everything on your network at once. You don't need to know, plan, or do much. Just start it and go get a beverage. When you come back, there will be plenty to observe.

In the Advanced Discovery method, you carefully control what has been discovered and decide for yourself where to look and what to find next. The Advanced Discovery method can obviously exercise more discretion, but it also asks for a bit more input.

The Discovery Wizard

The Discovery Wizard executes (initially) at the time of installation and is the easiest way to find all of the devices on the network and its subnets. Of course, if specified, the exploration can be limited to particular segments or subnets. It is wise to determine whether the network is connected to external networks, such as the Internet, before using the global discovery approach. If it is, it's strongly suggested that you isolate it from the external network via appropriately configured firewalls, gateways, or routers before running Discovery.

The reason it is important for the network to be isolated from the Internet is that Unicenter TNG's Discovery process is very thorough. It will discover every device on every network and subnetwork that it can reach. While this thoroughness is generally desirable and produces very interesting results on a properly configured college or corporate campus, it can also deliver surprising results. For example, if a dial-up connection (circumventing a firewall) to the Internet (via an ISP) is active during Discovery, Unicenter TNG will continue its process beyond campus boundaries and potentially map all the ISP's assets as well. That can produce a real "world view, " but it may take hours to run to conclusion. However much fun this sounds, the ISP owners may not be amused due to privacy and bandwidth issues. Of course, if the ISP owners had Unicenter TNG installed, they would have the security mechanisms to prevent such unanticipated inspections!

Running Network Discovery

A network's presence must be recognized before it can be managed. Discovery is the process by which Unicenter TNG actually probes the network and finds components to be managed. Unicenter TNG Discovery not only inventories network elements (such as routers, hubs, and NICs), it also detects systems and depicts the relationship between them in order to help you visualize the network. ...

Read a Sample Chapter

[Figures are not included in this sample chapter]

Working with Unicenter TNG

- 3 -

Basic Network Management

In this chapter:

• Challenges 
• Where to Begin? 
• The Brave New World of Unicenter TNG Discovery 
• Discovering a Network 
• Technically Speaking: How Discovery Works 
• Maps 
• The Business Process View (BPV) 
• Network Performance Management 
• Creating Reports on Network Assets 
• Distributed State Machine 
• How to Set Up a Distributed State Machine 
• Viewing Status with Node View 
• Setting Status 
• Mapping Status to Severity 
• Technically Speaking: Polling and Event Notification 

Challenges

Network managers face many challenges. Networks often consist of thousands of heterogeneous devices connected by token ring, Ethernet, or X.25 and separated by wide expanses of geography. The size and scope of today's networks make them difficult to manage effectively.

Given the size and geographic dispersion of the typical network, it is extremely difficult for the person charged with network management to even know all of the devices that are in the network, much less the location of those devices. However, it is impossible to effectively manage networks without being aware of all of the components that must be managed. The basic maxim applied to other areas of management is valid here as well: "You can't manage it if you don't know it exists."

Knowing that a managed object exists essentially consists of trying to keep an accurate and updated inventory--a challenge in itself when considering all of the additions, changes, and deletions from the network that may occur daily. Problem determination is more difficult, if not impossible, when the inventory of network assets is inaccurate or does not contain enough information about the failing network component.

The network manager is confronted by a myriad of devices supplied by a variety of vendors, diverse communications protocols, and complex network topologies, which adds to the difficulty. The permutations of platforms, communications protocols, application software, servers, mainframes, desktops, and databases that could be connected to the network are infinite. Attempting to sort out this tangled web can be an overwhelming task.

The complexities of the IT environments lead to another challenge for the network manager. There is an avalanche of data to sift through in order to find information that is useful for the task at hand, be it problem determination, adding a new device to an existing network, or dealing with performance issues. At times, it may seem like searching for a needle in a haystack.

It is simply impossible to manage the network environment effectively without using a sophisticated management tool. Unicenter TNG includes extensive management capabilities to address the problem. This chapter will address some of the key questions that must be answered in order to take advantage of this management resource.

Where to Begin?

The first question all new enterprise managers should ask is "What systems am I responsible for?" If they can't answer that most basic question, they ought to find the answer as the first order of business. Ignorance is not bliss for a network manager. Rogue systems are vulnerable back doors for hackers. Less dramatically, these hidden or camouflaged assets drain productivity because they are unknown quantities. Something as simple as missing important upgrades makes problems more likely to occur, diagnosis more time consuming, and remedies more difficult to administer. This degrades productivity in the long run.

Each management task described in this book starts with a good inventory of the systems and a good topology of the network. A manager needs the inventory to understand which systems should be backed up. What systems require an upgrade to Windows NT 5.0? What servers should be assigned new user accounts? Topology is necessary to figure out why all of a sudden Human Resources isn't getting email from Accounting, or where it would be best to install a faster link for improving performance.

Slipping Through the Net

The following transpired years ago in the network development group at a major New England computer company: This company once built network equipment (one of the first Ethernets ran through the building) and designed networking software. They knew they had at least one of every kind of major network software and hardware that existed at the time, save one. SNA, TCP/IP, DECnet, Netware, NetBios, and XNS were all present--but not Appletalk. They were positive that there were not any Macintoshes on the company network. It was the punchline of many jokes. When they actually looked at the results of a discovery, however, they found that a dozen Macintoshes had been happily running on their intranet for over a year.

Another company experienced an unexpected benefit of Auto-Discovery when the enterprise IT map, generated via Auto-Discovery, showed a connected network emanating from a division that the company had sold two years before.

The fact that this sold company still had a connection to the parent company's network constituted a security breach. A manual inventory of networks and networked devices would not have revealed this security breach because the resident experts were certain this network had been disconnected. This rogue network would only have been found by accident, an undue and impractical amount of checking, or a computer-driven Auto-Discovery service. The discovery of this security breach was an unexpected use and benefit of Unicenter TNG's Auto-Discovery service.

The Brave New World of Unicenter TNG Discovery

The Discovery service included with Unicenter TNG automatically detects devices on your network and populates the Unicenter TNG Common Object Repository with objects that represent your network devices and their relationships. Once created, these objects can be displayed by Unicenter TNG's GUI and monitored and controlled by the applications in the Enterprise Management layer of Unicenter TNG, such as the Security and Event Managers, as well as by third-party manager applications.

Unicenter TNG Discovery provides significant advantages over other network discovery applications. Unicenter TNG Discovery allows you to do the following:

• Run multiple instances of Discovery on multiple machines at the same time.
  
  
• Run Discovery as a service, allowing you to perform other work on your machine.
  
  
• Define granularity. You can discover all devices in a subnet or specific elements connected to a specific segment.
  
  
• Start Discovery automatically or manually.

The automated facilities provided by Discovery reduce time spent on manual network database maintenance, entry validation, network map creation, and routine network maintenance activities. This reduction lowers operating costs and provides increased network reliability.

Prerequisites for Running Discovery

Besides installing Unicenter TNG itself, there are four primary prerequisites that must be met before running Discovery:

• There must be a Common Object Repository (CORE). You don't have to worry about this because the CORE is created as a result of the installation process so that Discovery can be run automatically.
  
  
• The Real World Interface should be installed. This also occurs automatically during Unicenter TNG's initial installation, although technically the Real World Interface is not a prerequisite to run Discovery. (See Chapter 2, "The Unicenter TNG Framework," for information about installing this component.)
  
  
• The machine from which Discovery is run must be connected to the network and have valid IP and gateway addresses, as well as subnet masks. It is possible to discover from any network connection all of the other devices and subnets that are connected to the network on which it is located. However, there are more time-efficient ways to discover large networks. Multiple instances of Auto-Discovery can be run simultaneously, populating a single common repository. For example, in a one-router network connecting four geographic regions (North, South, East, and West), it would make sense to run Discovery in each of the locations simultaneously in order to save time and (by reducing cross-router traffic) bandwidth. Running multiple threads per Discovery instance will also speed execution.

---

TIP: Depending upon server size, it is typically impractical to run more than nine simultaneous discoveries against a single repository.

---

• Both TCP/IP and SNMP service must be installed and configured properly on target devices, whether they are network, computing, or non-IT devices.

Loading Factors

Many network managers worry that the load imposed by Discovery will bring the network to its knees. A little arithmetic can calm this fear. With ARP cache, the traffic is all in SNMP Gets. Getting a MIB variable takes about 200 bytes of network traffic. For a 100 host subnet with two routers attached to each subnet and each router having eight interfaces and five addresses, you can estimate the number of variables retrieved; assume that many interfaces are disabled. The total data for ARP cache turns out to be less than 450KB, less than 300KB for fast ARP, and less than 225KB for a Ping sweep. Furthermore, studies have found that that normal management traffic for most organizations (polling, traps, and so on) represents only 1-2 percent of available bandwidth--not considered a major impact.

Discovering a Network

Unicenter TNG gives you lots of options for discovering your network, but there are really two basic approaches: the Discovery Wizard and Advanced Discovery. In the wizard-based approach, Unicenter TNG explores the network to its heart's content. Unless you purposely limit it to your subnet, the Discovery Wizard finds everything on your network at once. You don't need to know, plan, or do much. Just start it and go get a beverage. When you come back, there will be plenty to observe.

In the Advanced Discovery method, you carefully control what has been discovered and decide for yourself where to look and what to find next. The Advanced Discovery method can obviously exercise more discretion, but it also asks for a bit more input.

The Discovery Wizard

The Discovery Wizard executes (initially) at the time of installation and is the easiest way to find all of the devices on the network and its subnets. Of course, if specified, the exploration can be limited to particular segments or subnets. It is wise to determine whether the network is connected to external networks, such as the Internet, before using the global discovery approach. If it is, it's strongly suggested that you isolate it from the external network via appropriately configured firewalls, gateways, or routers before running Discovery.

The reason it is important for the network to be isolated from the Internet is that Unicenter TNG's Discovery process is very thorough. It will discover every device on every network and subnetwork that it can reach. While this thoroughness is generally desirable and produces very interesting results on a properly configured college or corporate campus, it can also deliver surprising results. For example, if a dial-up connection (circumventing a firewall) to the Internet (via an ISP) is active during Discovery, Unicenter TNG will continue its process beyond campus boundaries and potentially map all the ISP's assets as well. That can produce a real "world view," but it may take hours to run to conclusion. However much fun this sounds, the ISP owners may not be amused due to privacy and bandwidth issues. Of course, if the ISP owners had Unicenter TNG installed, they would have the security mechanisms to prevent such unanticipated inspections!

Running Network Discovery

A network's presence must be recognized before it can be managed. Discovery is the process by which Unicenter TNG actually probes the network and finds components to be managed. Unicenter TNG Discovery not only inventories network elements (such as routers, hubs, and NICs), it also detects systems and depicts the relationship between them in order to help you visualize the network.

---

TIP: Your results may be more complete if you run Discovery during the day. Devices are often powered down during the off hours; if so, a late-night Discovery can miss them. Also, the ARP cache mechanism uses temporary storage in the routers, so a system that has not sent or received traffic lately will be discarded from the cache. As a consequence, if a device is not found in the ARP cache, it will not be targeted for the confirming Ping that actually locates devices at their addresses.

---

To run Network Discovery, click the Start menu, Programs, TNG WorldView, Auto Discovery; alternatively, you can double-click the Auto-Discovery icon in the TNG WorldView folder.

The first window you see is Discovery's Distributed Services window, shown in Figure 3.1. This lists the servers where copies of Discovery are running. You will see only your machine listed immediately after initial installation. Of course, additional servers could be introduced. Jot down at this point the name of your local server and repository for later reference.

FIGURE 3.1 Discovery's Distributed Services window.

From this window you can see the status of the Discovery servers, start and stop the servers, or begin configuring the servers. Notice that Discovery can be run on both TCP/IP and IPX-based networks. The default selection will be for discovery of an IP network. If you are running on Novell NetWare, it might be appropriate to select CA-IPXDiscovery by clicking that server instead. For this example you accept the default selection TCP/IP.

Next, click the Setup button (shown at the bottom of the screen in Figure 3.1) to start customizing the Discovery Wizard. Figure 3.2 displays the Discovery Wizard's opening screen.

FIGURE 3.2 The Unicenter TNG Discovery Wizard.

Note that the Unicenter TNG Discovery Wizard automatically retrieves your gateway and host IP addresses. Discovery always starts with the subnet your server is in. It figures out the host IP address and the address of a router in the subnet (the gateway address) from the system.

Now allow the wizard to walk you through the steps required for launching Auto-Discovery.

You can tune the discovery parameters more precisely by selecting the Advanced button on the bottom right of the Unicenter TNG Discovery Greetings window. Experienced network administrators may want to jump ahead to the "Advanced Discovery" section in this chapter if parts of the network have already been mapped. In the vast majority of circumstances, however, the Unicenter TNG Discovery Wizard will suit the purposes at hand. If there's any doubt, readers should choose Next, which brings up the Unicenter TNG Repository Selection window (see Figure 3.3).

FIGURE 3.3 The Discovery Wizard's Repository Selection window.

Repository Page 

The repository is the central storehouse for all your managed objects. Stored information about each of those objects is in this repository. There are many classes of objects attached to your network (routers, servers, databases, applications, and so on). Within each class, there will normally be many individual objects. Information about each class and each object within it is stored in Unicenter TNG's central repository. It is the discovery process that populates the repository with information about your enterprise's managed objects.

The Discovery setup's Repository Selection window (shown in Figure 3.3) allows you to change the repository where Discovery will store the objects that it finds. The Repository Selection panel allows you to send the results of the search to any repository, including remote repositories. This is useful for accelerating the discovery of large networks. Multiple discovery engines can run simultaneously and the information consolidated to a central point. Assuming this is your first discovery, you should select a new repository name for population.

Selecting the Next button will take you to Discovery Wizard's Scope window (see Figure 3.4).

FIGURE 3.4 The Discovery Wizard's Scope window.

The Unicenter TNG Discovery Scope window allows you to choose between two search modes. You indicate how much of the network will be discovered. It is possible to limit yourself to the immediate subnet, of course, but in the interest of simplicity, the default is accepted here and the entire network is canvassed. Select the Next button to get to the Methodology window (see Figure 3.5).

FIGURE 3.5 The Discovery Wizard's Methodology window.

Most network elements can be located quickly and efficiently by inspecting data contained in devices' ARP cache. However, thoroughness requires an exhaustive Ping sweep, which tests all the network addresses in a given range by querying them each at least once. Here you accept the default setting again (Detailed Discovery) and simply click the Next button to reach the Unicenter TNG Discovery DHCP Configuration window (see Figure 3.6).

Dynamic Host Configuration Protocol (DHCP) is a dynamic IP address assignment protocol. DHCP specifies the use of pooled addresses that are assigned to systems on an as-needed basis and includes recommendations for guaranteeing unique IP addresses among nodes in local and wide area networks. It is particularly useful for handling mobile devices such as laptops. Unicenter TNG's Discovery simplifies network management in a DHCP environment:

• Providing screens for system managers to identify IP address ranges for DHCP subnets (see Figure 3.6).
  
  
• Enabling periodic reruns for subnets and devices identified as DHCP based.
  
  
• Automatically updates the object information for DHCP devices.
  
  
• If a device's subnet or address within a subnet has changed, Discovery moves the objects into the correct subnets and switches IP addresses to keep the subnet as static as possible, making management easier.
  
  
• Deletes unclassified DHCP devices if other devices are using their IP addresses.
  
  
• Updates the status of a classified device if its IP address conflicts with others.

FIGURE 3.6 Discovery Wizard's DHCP Configuration window.

This is a binary selection, depending upon whether your network addresses are assigned dynamically or statically. If your network uses DHCP, simply check that option and assign one or more address ranges to be searched in the DHCP Range Set area. An address range has been entered for a subnet that does employ DHCP. Some networks in an organization may be using DHCP, while others are not; check with your network administrator if you're uncertain. Click the Next button to reach the Unicenter TNG Discovery Multiple Instances window (see Figure 3.7).

FIGURE 3.7 The Discovery Wizard's Multiple Instances window allows you to set speed adjustments.

The Unicenter TNG Discovery Multiple Instances window provides two parameters that can impact the speed of the discovery process, although with potential tradeoffs. Starting multiple instances of the discovery engine will leverage additional memory, network bandwidth, and (on SMP machines) processors. This may come at the expense of other processes or applications running on the Discovery host machine.

Likewise, reducing the SNMP/ICMP query time-out value offers a potential tradeoff that hastens the discovery process. The lower the time-out value is set, the more likely that a busy agent will not have the opportunity to respond while the discovery engine is listening and therefore remain (temporarily) anonymous. The discovery process will commence when you click the Finish button. You don't have to be a networking guru to discover a network with the Unicenter TNG Discovery Wizard.

This raises the question "How long will it take to discover my network?" This is difficult to estimate. The time required is dependent upon several factors:

• Speed of the system on which Unicenter TNG is running
  
  
• Speed of the networks across which the discovery traffic must travel
  
  
• Number of devices to be discovered
  
  
• Number of discovery engines simultaneously executing
  
  
• Number of threads running per discovery engine

However, the main limiting factor is the speed with which the engines can write their results to the repository. A secondary factor is the network bandwidth available to carry the discovery traffic (although a large or dense network could slow Discovery). Discovery of just one subnet, especially if it is a small subnet, is typically measured in minutes. Watching the Discovery Monitor is reassuring because it helps meter the rate of progress.

Discovery Monitor 

The Discovery Monitor lets you watch over Network Discovery's shoulder as it searches the network. Observing its progress is usually fun. To run it, either click the Discovery Monitor icon or select the Start menu, Programs, Unicenter TNG WorldView, Discovery Monitor.

You will see the CA-TNG Discovery Monitor window (see Figure 3.8). The counts will increase as objects are added to the repository. The counts will move in fits because Discovery, in the interest of efficiency, waits awhile before writing them to the repository.

FIGURE 3.8 The Discovery Monitor window. Click the OK button and then start the Discovery Monitor.

Advanced Discovery

Advanced Discovery gives you more control by letting you limit how far the discovery process explores. The basic plan is to run through multiple passes of Discovery. Each pass searches through a few subnets at a time. This way, you slowly build a picture of the network outward from your local network.

Subnet Management 

You can display the results of your discovery when the Discovery Monitor or trace console indicates that Discovery is complete. There are two display methods: the Discovery Subnet Management window and the 2D map.

The Discovery Subnet Management window (see Figure 3.9) displays all of the subnets that were discovered. The window displays two panes. The right pane displays subnets that will be discovered on the next pass, while the left pane lists subnets that have already been discovered or were bypassed. The left pane subnets will not need to be rediscovered on the next pass.

FIGURE 3.9 The Discovery Subnet Management window.

Click the subnet and then click the Add or Remove button (whichever is active) to move the subnet from one side to the other. You can see more information about a subnet by double-clicking it in either pane. You will see the Modify Subnet window, as is shown in Figure 3.10.

FIGURE 3.10 The Modify Subnet window.

---

TIP: You can see more information about a listed subnet by double-clicking it.

---

The subnets you choose to discover determine the direction in which Discovery proceeds. Before running an Advanced Discovery pass, be sure the subnets that have already been discovered, as well as those subnets you do not want to discover, are displayed in the left panel of the Subnet Management window. The right panel of the Subnet Management window should list all the subnets that you want to discover. Discovery will only discover the subnets listed on the right panel of the screen.

What if Something Isn't Found?

It is quite possible that the first pass of Discovery will not find all of the devices on your network. There are a number of factors that can account for this. Portions of the network may be down, devices may not respond to SNMP queries (if so, check on the community name), ARP caches may be stale, or devices may be turned off or disconnected from the network. This does not reflect a problem with Unicenter TNG. Instead, it is simply the result of the limitations of an automated discovery process. A management system can no more discover devices attached to a network that is down than a person could manually inventory supplies in a warehouse without entering it. If you do encounter this situation, you will want to make additional Discovery passes on your network. It is also wise to run Discovery periodically to ensure that any changes have been detected and reflected in the repository. Rediscovery incrementally adds new systems, new networks, and new subnets to your existing repository.

Periodic Rediscovery

It is inevitable that over time the network will change. New systems and new networks will be added. Old ones will be removed. The first discovery is unlikely to find everything. You will want to rediscover your network a few times at the start using different methods, and periodically thereafter.

Removing old systems is a more difficult task. It's hard to tell the difference between a system that has been removed from the network and one that is down right now. The removal of systems and networks is best accomplished in conjunction with event and fault-management policies.

Backing It Up: TNG Repository Import/Export Exchange Facility (TRIX)

After putting this much effort into building a repository, it would be a shame to lose it all. Like any database, it's important that you back up the repository. The repository can be backed up using the underlying database's backup services (such as Microsoft SQL), an enterprise backup solution like the Unicenter TNG Advanced Storage option (also known as ARCserve), or the Save Demo utility provided on the TNG CD-ROM. However, there is a backup utility specifically designed for the repository; it's known as TRIX (Unicenter TNG Repository Import/Export Exchange).

TRIX takes the contents of the repository and turns them into a TRIX script--a text file that can be easily backed up and exported for safe storage. TRIX can also be used to transfer objects from one repository to another. You export them from one repository, copy the script to the other system, edit it, and import the script again later. TRIX has many other uses in customizing Unicenter TNG, but most of those are beyond the scope of this book.

Technically Speaking: How Discovery Works

Discovery starts at the local Discovery server and explores outward from there. It proceeds through the network in steps, looking for hosts, routers, and subnets. Discovery starts with just one subnet: the subnet local to the Discovery server. The steps it follows for each subnet are as follows:

1. Discovery for network devices does its work based on the method selected in the Discovery Setup window. It searches a subnet for assigned addresses in the subnet using one of three techniques: ARP cache, fast ARP, or Ping sweep.

• ARP cache--The ARP cache method starts at the gateway address (the nearest router's address) for the current subnet and uses the gateway's ARP cache to discover information about the devices. An SNMP request (GET) is initiated for each device found in the ARP cache. If the device does not respond, it is a TCP device; otherwise, the information on the device is added to the CORE.
  
  
• Fast ARP--The fast ARP method saves time by checking only the ARP cache of routers. Fast ARP is the best choice when updating the database between the more intensive services initiated by Ping sweep and ARP cache.
  
  
• Ping sweep--The Ping sweep method sends ICMP pings to all of the devices on the network based on the subnet mask. The discovery engine then retrieves SNMP information. If there's no SNMP information available, it is assumed that the device is a non-SNMP device. Discovery then receives the attributes from the device's MIB and adds the information to the Common Object Repository.
  
  

Each of the discovery methods has advantages and disadvantages. The Ping sweep option gives you more complete quantitative information--meaning it finds more devices--because every address in the range selected (potentially the entire network) is pinged. Even if a device type is not recognized, its presence will be known. The same device quite possibly would not be discovered at all through the ARP cache method.
On the other hand, ARP cache provides the MAC address information on all the devices that are found in the ARP cache in the router. Ping sweep, however, generates additional network traffic and is thus more time consuming than ARP cache. A combination of Ping sweep and ARP cache is sometimes required to discover every device in the network.

2. For each address it finds, Discovery tries to figure out what type of system it is (host, router, and the like) using SNMP and DNS. If it is a new system, it creates an object in the repository for it.

• Classified objects--Objects having an SNMP-compliant agent and a matching Unicenter TNG class definition are classified objects. Typical examples are a UNIX workstation or Windows NT server. By default, any classified object is visible on the 2D and 3D maps.
  
  
• Unclassified objects--Non-SNMP devices might have IP or MAC address conflicts, or they might be of a model that does not match any Unicenter TNG class. Unclassified objects are placed in the Unclassified_TCP class, which is a subclass of unclassified objects. Unclassified objects is a subclass of the Managed Objects class.
  
  

3. SNMP is used to find out what interfaces and addresses are in each system, and they're added to the repository. Each address is checked to see what subnet it resides in. If the device is found in a new subnet (that matches the subnet filter), it too is added to the repository.

Classifying an IP System

Once Discovery finds a new IP address, it uses SNMP to get information from MIB-II to classify the system in the repository. MIB-II (Management Information Base II) provides basic information about TCP/IP and is supported by nearly all TCP/IP implementations. MIB-II provides a description of the system, a contact person, the location of the system, and the system's vendor and equipment type.

Discovery can find the name of the system in one of two ways. It looks in DNS to find the name corresponding to the address. If that fails, it uses SNMP to ask the system what it thinks its name is.

Finding New Interfaces and Subnets

Information in the SNMP MIB (MIB-II) tells Discovery what interfaces are in the system, what IP addresses are assigned to those interfaces, and what subnet masks are used for those addresses. From all that, Discovery adds interfaces to the repository for the systems and figures out what subnets are attached to the system. Discovery classifies the interface based on its type and uses that to create LAN segments in the subnets. If any new subnets show up, they are compared with the subnet mask to see if they should be added to the repository and discovered.

Armed with a list of new subnets, Discovery can now go on and discover what they contain. Discovery rolls outward like the ripples on a still pond until it finds everything.

Maps

Network Discovery generates a map of the network, but that map is driven by the topology of the IP network. Much of TNG's power comes from your ability to customize its display. The maps can be customized in two main ways. You can also customize TNG to reflect more closely the physical structure of your environment. You can customize TNG to reflect the logical structure of your environment through Business Process Views, but that is covered later in this chapter.

Customizing Topological Representation (Maps)

Maps are topological representations. Customizing your maps is accomplished through the Real World Interface 2D map (see Figure 3.11). Chapter 2 discusses navigating through the 2D view in more detail. If you have not already read Chapter 2 or are not already familiar with navigating through the 2D view, you may want to review that section before proceeding with this chapter.

FIGURE 3.11 A 2D map

You can change the location of an icon on a 2D map with the following steps:

1. In the WorldView folder, double-click the 2D Map icon.

2. Click OK in the Unicenter TNG dialog box. The information from the repository will be loaded and the 2D window should appear.

3. Click Modes on the menu bar located at the top of the 2D window.

4. Select Design to bring up Design mode. You must be in Design mode to create new objects, define new relationships between objects, and do any detailed customization of the 2D map. The Toolbox menu will appear when you select Design mode. The Toolbox menu displays all of the managed object class definitions, as well as the classes for the map-only objects. The Toolbox menu displays in icon format, a hierarchical list format, or a tree format. You are now ready to customize your display.

To move, copy, or rearrange any managed object (devices and systems, for instance) on your topology map, do the following in Design mode:

1. Open the source and destination folders on the 2D map.

2. Select the object that you want to copy or move in the source folder, left-click it, and drag it to a blank section in the destination folder.

---

TIP:
The shortcut for copying and moving multiple objects simultaneously is to click the first object and then hold down the Shift key while clicking the second and each additional object. Once all objects are selected, release the Shift key (without releasing the mouse button) and drag the dotted-lined rectangle to the destination folder.

---

3. The Select Operation dialog box will appear after you drag and drop the object.

4. Select one of the following options:

• Create New Parent--Creates a copy of the object in the destination folder without changing the original object in the source folder. The links in the source folder are not retained automatically (a basic copy function).
  
  
• Move Selected Devices--Deletes the object from the source folder and moves it to the destination folder (a basic move function).
  
  
• Keep Links--All of the links between objects except for the link to the parent folder are retained when they are moved into the destination folder. (This displays when Move Selected Devices is specified.)

Once you have moved and copied all of the objects to their proper places, you have finished customizing your topological representation.

Adding a Background Map

It is very common for users to want to add a background to the maps in their Unicenter TNG displays. The most common background is a map of the geographic area where the network is located. For example, a company with locations scattered around the United States might want to have a map of the United States for the background of the highest level display. Unicenter TNG provides a selection of commonly requested geographical maps to use as backgrounds for folders. The TRIX feature, which enables objects to be moved in and out of the repository for external customization, creation, or backup, is also available.

You must be in Design mode and perform the following steps in order to add a special background:

1. Click Map on the menu bar at the top of the 2D window.

2. Select the appropriate map type from the Map menu. The choices are Continents, Countries, Regions, Sub-Regions, and Groups. (Select Countries if you want to overlay a map of the U.S.)

3. Scroll through the selections on the dialog box and select the map that you want by highlighting it. Then click OK. The map that you have selected will now appear on your screen beneath your network layout.

4. You can drag and drop your Network icon onto the map and place it near its location. Unicenter TNG can automatically place an object on the map based upon user-supplied telephone area codes or latitude and longitude coordinates.

5. To use this automatic positioning feature, right-click the object that you are positioning in Design mode. Select the Edit option from the pop-up menu. The Edit Folder dialog box will now appear (see Figure 3.12).

FIGURE 3.12 Background map.

---

NOTE: If the Edit Folder dialog box does not contain the positioning fields, click Cancel and drag the object slightly onto the geographic map. This will reset the object to register the geographic map as its background. Select Edit again and the Edit folder should contain the positioning fields. 

---

You can now enter the information that will position the network. Enter the area code and prefix (exchange) for U.S. and Canadian locations. Include the country code for international locations. You may enter the latitude and longitude coordinates in the Alternate Location group box instead of the telephone information. Click the Replace button when you are done. Your network will appear in the correct location if you have entered the correct information.

6. Do the following if you want more information overlaid on the map (place names, roads, and the like): Click Map on the menu bar. Select Map Overlays from the pop-up menu. You can customize the level of detail that will be displayed on your map on the Set Overlays dialog box. The folder automatically brings in levels of detail if you select the Auto option. The other options are On and Off.

Your map is now customized. Through the use of this feature, it is possible to transfer more information to the operators in less time.

The Business Process View (BPV)

The previously described tools are visual versions of traditional system management tools. Such traditional management methods and tools, however, allow system managers to track the status of resources (individual servers, clients, routers, printers, operating systems, databases, applications, and so on), but only in isolation from other contexts.

If a problem with a critical business process develops, it is incumbent on the system manager to figure out which of the enterprise's computers, software, and network devices support the impacted business process. Then the system manager extracts the data applicable to the problem at hand from the torrent of (mostly irrelevant) information received from devices throughout the entire network. This complicated process must be repeated every time the system manager needs to determine status.

IT professionals tend to focus their attention using a horizontal, resource-centric perspective. For example, there are traditionally separate system management groups for application support, database administration, systems programming, and network management.

This horizontal view is limiting when IT organizations are called upon to answer business-relevant questions. Answering business-relevant questions requires cutting across different resource technologies and seeing the bigger picture.

Business people tend to organize themselves and focus their attention using a vertical perspective. A typical business-oriented question is "When can I get my Accounts Receivable reports?" To answer this question, an enterprise manager must, at the very least, know the status of the Accounts Receivable application, its database(s), whether other applications on which the Accounts Receivable application depends are working, and whether the underlying systems, network, and printers are functioning well. Business Process Views provide this vertical perspective. Figure 3.13 shows the relationship between Business Process Views and the underlying information system.

FIGURE 3.13 The Business Process View.

Unicenter TNG's Business Process Views invert an IT infrastructure's traditional resource-centric view. It organizes its Business Process Views by application (Accounts Receivable, Building Management, and so on), functional role (financial, security, maintenance), geography (Europe, physical plant 185), organization (the XB97 License Group), and so on. These Business Process Views, however, cross all the horizontal views for that business process. This allows system managers to deal with both applications and resources simultaneously and to filter and map IT resource information to business problems.

Figure 3.14 shows an example of a real Business Process View for a Payroll application in a medium sized, networked company. The Payroll application requires a database server, a database, a Payroll application server, the Payroll application, the operating systems for the two servers, a workstation for data entry, a printer, and a network router and hub all working together.

FIGURE 3.14 A typical Business Process View for a Payroll application.

Maintaining a list of Business Process Views in one place is a good idea. Suppose some payroll checks have not been printed. If you always display this list, as shown in Figure 3.15, the manager can see when the problem occurs in Payroll because the Payroll Business Process turns red, indicating a Critical status.

FIGURE 3.15 Displayed list of Business Process Views.

Double-clicking the problematic Business Process View brings up the Payroll Business Process View (see Figure 3.14). This view shows all the IT resources involved in the payroll process. At a glance, the system manager can determine that the router, hub, servers, workstation, printer, operating systems, and Payroll application are running properly. However, the Oracle database icon is red, indicating that it has a problem. A database problem could cause the application to run erratically and skip the printing of some checks.

Right-clicking the Oracle icon brings up a pop-up menu. Selecting Go There brings the system manager to the 2D map in which the errant Oracle database is located. From here, the system manager can double-click the corporate database server on which Oracle runs in order to drill down into the server components, then right-click the Oracle icon in order to bring up the Oracle Agent. The agent might show that the database is currently overloaded. Bouncing some users will cause the database to run properly again, thereby solving the skipped-checks problem.

In this way, system managers can focus only on the Payroll process. The Business Process View filters out all extraneous or irrelevant information, but provides a vertical view that cuts across all the relevant horizontal resource technologies (applications, databases, systems, and networks).

The following formal methodology provides an example (a subset) of developing a sophisticated Business Process View for a distribution application. The company, a large distributor, began its Business Process View development by first drawing a paper diagram that showed the applications that are part of their distribution system and the interactions between these applications. Then the company's architecture, IT, and systems and network management groups performed the following steps using Unicenter TNG:

1. Start Unicenter TNG's 2D map facility. When the Managed Objects folder comes up, switch to Design mode. Drag the icon for the Business Process View object from the Design Mode toolbox that appears in the Managed Objects folder. Then click the Business Process View icon to open its folder.

2. Still in Design mode and in the Business Process View folder, draw the application interaction diagram using Unicenter TNG's shapes and text icons, as shown in Figure 3.16. Of course, drawing an application interaction diagram and using it as the basis for a Business Process View is not technically necessary to define a Business Process View. It is a simple method, however, for ensuring that nothing is inadvertently omitted from the Business Process View created.

FIGURE 3.16 Application interactions in a distribution application.

3. Open the 2D maps of the enterprise in which the hardware and software involved in the distribution application are located. Drag the platforms, devices, databases, applications, and other software involved in the distribution application from these maps to the application interaction diagram you created. Choosing Create New Parent from the pop-up menu causes the platform to be copied, rather than deleted, from the original map (see Figure 3.17).

FIGURE 3.17 Computers involved in the application interactions.

4. Remove the ovals used to create the application interaction diagram. This will result in a folder containing all the platforms, devices, and software involved in the Business Process View. Right-clicking anywhere in the folder and selecting Arrange, Bus from the pop-up menu causes Unicenter TNG to arrange the computer icons on the bus (see Figure 3.18).

FIGURE 3.18 Creating the final distribution Business Process View.

5. Save the Business Process View. In the future, this Distribution Business Process View will be displayed in the list of Business Process Views. Should a problem be indicated (by a change in color or any other method), a single-click on the desired Business Process View opens it for viewing.

A Business Process View is itself a managed object. As such, it is stored in the Common Object Repository and is accessible using either Unicenter TNG 2D or 3D maps. Business Process Views are visually represented as separate folders in the 2D map; they are represented as specific views on the 3D map.
The greatest value of Business Process Views is that they show, at a glance, not only the status of different computers, devices, networks, and software, but also the dependencies between component devices. Although an application may not appear to be working properly, the problem may really be on an interconnected computer. This is easier to figure out using Business Process Views than with traditional tools.

See Chapter 10, "Application Management," for step-by-step instructions on two ways to create Business Process Views.

Network Performance Management

Unicenter TNG will allow you not only to monitor the managed objects in your network, but also to manage the performance of those objects.

Leveraging ObjectView is the best way to gauge responsiveness of individual network components in real-time. ObjectView allows for instrumentation of network components and the creation of formulas behind these performance gauges, making their data meaningful for non-technical personnel. Unicenter TNG's Response Management Option (RMO) should be installed, however, for actual end-to-end network performance monitoring, including analysis of historical data.

ObjectView

ObjectView is primarily a performance tool. It provides performance statistics on a device based on the agent's monitoring of the device. Additionally, it provides device configuration information based on the device's MIB.

ObjectView is commonly used for monitoring network performance (see Figure 3.19). Examples of ObjectView-provided information are the number of devices connected, which interfaces are down, and the number of packets coming in compared with the number going out. This information makes ObjectView a good troubleshooting tool and performance monitor.

FIGURE 3.19 Monitoring network performance with ObjectView.

ObjectView also allows system managers to visually display the monitored attributes in various types of graphs, meters, and tables. System managers select the attributes they want to monitor and add them to Excel or to the ObjectView DashBoard (see Figure 3.20).

FIGURE 3.20 Visually monitoring performance with the DashBoard: dial gauge (a) and line
graphs (b).

Response Management Option (RMO)

Unicenter TNG Response Manager Option is a client/server performance manager for the distributed network. It measures service levels, capacity utilization, and errors for LAN segments and server machines. It also provides information on Ethernet segments, WAN links, and Cisco routers.

The Response Manager Option's historical database shares object identifiers with the repository, enabling the Response Manager Option to use Unicenter TNG's discovery of the environment while enhancing it with non-IP network resources. Performance alerts are sent directly to Unicenter TNG's repository, displayed on the map, and accessible through the Unicenter TNG Event browser.

Unicenter TNG RMO is able to manage very large environments by having separate servers collect data from different regional areas of the network. The data is then presented in an integrated fashion. Response Manager Option's historical database contains interval data and data summarized by the day, week, month, and year. Historical and real-time reports are available.

RMO works by monitoring client/server applications and network hardware and software and then comparing them against established service-level agreements. Response Manager Option also reports a problem when the predefined performance objectives are not met. It does this by collecting network performance statistics from Response Manager probes or from SNMP agents (using RMON and MIB II data), which are already deployed in your environment.

RMO can also be used to help with capacity planning for your enterprise network. Using Response Manager Option's data, you determine when and how to move workstations, split over- utilized resources, expand or add file servers, or provide more efficient communication gateways.

Creating Reports on Network Assets

Asset identification is the first step in asset management. With Unicenter TNG, the inventory of assets is created through the discovery process. Once the inventory has been created, the next step is to analyze it and make decisions. Unicenter TNG's report facilities are well suited for this task. The bundled reporting facilities are intuitive and easy to use and provide a sophisticated level of reporting.

Reports can be generated from several locations:

• 2D map
  
  
• Object Browser
  
  
• Class Browser
  
  
• Topology Browser
  
  
• Common Object Repository

The views presented by these browsers organize and display complicated information and allow a simplified, yet comprehensive, look at your IT assets and infrastructure.

Many reports are designed to provide specific details about subsets of objects, object classes, folders, critical events, and topology. There are two options for creating reports on managed objects or the assets listed in the Common Object Repository:

• The 2D map provides an object detail report using the Report menu.
  
  
• The Object Browser provides object-specific information using the Print Objects List option in the File menu.

Generating Reports from the 2D Map

This dialog is accessible in Run mode from the Report Object Details menu command. You simply do the following when you need a report on all critical segments in the network:

1. Select Report option.

2. Select By Object Detail.

3. Select LANS.

4. Select Critical.

5. Select Report.

This simple five-step process produces a detailed report on the critical segments. In addition to Class of Objects, other choices include Severity States and Output Destination.

The 2D browser provides the following in addition to the object detail report:

• Summary report of the network. This is a high-level report providing summary information about the network components.
  
  
• Object by name. This is a report that lets you select the objects for the report by their name.
  
  
• Object by folder. This report allows you to select certain folders and report on all the objects within them. This is useful for reporting on certain portions of the network.
  
  
• Object by class. For this report you need to select certain classes of objects. The result is a report for all of the objects in that class. For example, you might want to review the information about all of the Cisco routers in the network.

These reports allow you to select exactly which objects are reported on by a number of criteria so you can examine network subsets.

In a similar way, Unicenter TNG can produce reports based on the Object, Class, or Topology Browsers, as well as from the Common Object Repository.

Distributed State Machine

A distributed state machine (DSM) tracks the status of objects across a network. One such object might be a shared laser printer. The printer can be in different states. It might be out of paper or toner. It might be jammed or offline. It might have too many jobs waiting to be printed, or it may be running fine. The DSM's job is to collect information from this printer, its brethren, and all the workstations under its surveillance in order to track their status.

The DSM pulls information from agents and from the repository. The repository is used to determine which systems are in a DSM's domain, as well as the class of those systems. Object classification was performed during Network Discovery.

The DSM talks to software agents (see Chapter 4, "Server Management") to collect information about the monitored resource. It periodically asks (or polls) the agent to get data. The DSM can retrieve information like the number of jobs queued for printing. It can also accept unsolicited events, in particular SNMP traps, sent from the agent.

The DSM even has its own discovery process. In the same way that Network Discovery finds the elements on a network, the DSM discovers what resources exist inside monitored systems. This discovery process provides greater detail on what software and hardware resources reside on a system. For example, it would identify the Microsoft SQL Server database and Exchange application on a groupware server. DSM's reason for finding these objects is to keep their status up to date via its state machine. In summary, the DSM knows an object's state, remembers how it has changed, and stores the object's current state in the repository.

In the repository, the status of the object is mapped to a severity using alarm sets. Alarm sets are simple tables mapping status to severity. They can be applied to specific objects, which allows operators or users to apply whatever policy they desire to a given severity level. In some situations, you can simply remove certain status values from consideration if they aren't relevant.

A DSM policy can be thought of as a collection of rules. A policy tells the DSM what objects should be watched, how to find them, what their potential states are, what data to poll for, how often to poll, what events to accept (collect), and most importantly, how to make state changes as various things happen.

Basically, rules are distilled from knowledge about how an object works. However, they can also be customized to reflect desires about how things ought to work. For example, a rule can set polling frequency. Polling more often detects problems faster, while polling less often keeps network traffic down. You can change the threshold level on a print queue to reflect exactly what y ou mean by too many jobs queued. Whoever sets policy determines what really matters. If operators are not responsible for refilling supplies, they can alter policy so that a printer doesn't enter into a problem status when the paper runs out.

DSM policies are defined on classes of objects and then applied to instances. What this means is that we only have to develop a policy once, and then the DSM automatically applies it to all the objects of that class within the DSM's domain. Potentially, this saves tremendous amounts of work. For example, if your domain contains 1,000 NetPCs, you need only develop policy for one and apply it to them all.

Writing DSM policy from scratch takes some practice, so Unicenter TNG includes a policy generator and wizards to help develop new policies. In practice, however, most customers modify or supplement policies supplied by CA or by the vendor of the managed object.

Once the DSM has been set up and is operating, it is largely invisible. That's good, since it is only meant to mind the store while you do something more interesting. The best tools stay out of the way.

How to Set Up a Distributed State Machine

Setting up a DSM on a system is very easy. There are only three steps required: install the DSM software, identify the systems for which the DSM is responsible, and turn it on.

The DSM is installed as a part of the overall Agent Technology installation. The components that make up the DSM are shown in Figure 3.21. Focus here on the Domain Manager, which keeps track of what the DSM watches, the network state machine, which actually watches the state of objects, and the repository gateway, which interacts with the repository and sets the status of objects there. The SNMP gateway, SNMP Admin, Object Store, and Object Request Broker are components used in SNMP Agents, which are covered in Chapter 4.

FIGURE 3.21 The components of the distributed state machine.

Configuring the Domain

Edit the configuration file TNGAWS\Services\AWS_WVGATE\gwipflt.dat to set up the domain that the DSM will watch.

Each line of the file identifies a system, or collection of systems, that is to be monitored. The systems are identified by their IP addresses. Addresses are used so the DSM can operate even if a large part of the network is down. You can either list each system or include a collection of addresses using wildcard syntax. For example, 141.202.15.* tells the DSM to monitor all the systems from 141.202.15.0 to 141.202.15.255.

Initially, the DSM configuration file tells the DSM to monitor every system in the repository (via *.*.*.*). Depending upon the size of your network, you might want to divide the network among multiple DSMs.

Listing 3.1 shows a configuration file for monitoring a single subnet and a few routers. Note that the address of the routers is the address associated with the router in the repository.

LISTING 3.1  gwipflt.dat--DSM Domain Configuration File

141.202.15.* 141.202.39.1 141.202.2.1 141.202.35.1 

141.202.92.1 

Viewing Status with Node View

The DSM stores the status of objects in the repository for the use of Real World Interface browsers and other programs. More importantly, the DSM also maintains the internal state of the objects. This is usually more granular (detailed) than the status stored in the repository. For example, when the Windows NT System Agent watches a file system (or even an individual file), the DSM tracks that information too, while the repository remains ignorant.

The Node View viewer included with the TNG Agent technologies allows you to see the detailed state information kept by the DSM for a particular system. To run it, select an icon for one of the agents in the node, right-click it, and choose View Node from the pop-up menu. You will see the Node View window, as it's shown in Figure 3.22.

FIGURE 3.22 The Node View window.

The Node View display contains a number of panes, as shown in Figure 3.23. Starting from the top, there is a standard window title and menu bar. Below that is a status bar. It displays the update status on the left, and when the status is being updated the indicator turns red. On the right is the address of the node being displayed, along with the name of the DSM watching it. In Figure 3.23 the system being viewed has the address 141.202.4.78, and the DSM is the one on PDC110. Below the status line is a toolbar.

FIGURE 3.23 The Node View window panes.

The main part of the window is given to a tree of objects in the node that the DSM is monitoring. Each object shows its status (at least as far as the DSM knows it). The status is color-coded. The meaning of the various colors is given in Table 3.1. The status is propagated up the tree, so the top object, the node, shows the worst status of any object it contains.

TABLE 3.1 Node View Colors

Color	Description
Dark Green	The object is OK.
Light Green	The object has returned to OK from a problem state; acknowledge the object to return it to OK.
Red	The object has a problem.
Orange	The object has a problem, but it has been acknowledged.
Blue	The status of the object is unknown (either because the Node View can't communicate with the DSM, or because the DSM hasn't yet determined the state of the object).

A guidance window is at the bottom of the Node View display. This area echoes any commands that are invoked through Node View. These commands could be entered into a command line via an application.

Mini Tree Navigation Window

The number of objects in a node can be quite large. Node View provides a mini tree, which helps you navigate the objects by providing an overview. Choose View, Show Mini Tree to display it, or View, Hide Mini Tree to close it.

If you click any object in the mini tree, the main object tree will be changed to show the corresponding icon.

Object Description

Node View maintains quite a bit of information about the objects. View, Show Object Description in the menu brings up the Object Description window (shown in Figure 3.24) for whatever object is selected in the tree. View, Hide Object Description closes the window.

FIGURE 3.24 The Object Description window.

Customizing the Node View Display

The Node View display can be customized to show more or less information in the icons. By default, window panes can be displayed or hidden. To control these preferences, choose View, Display Preferences from the menu. You will see the Display Preferences window (see Figure 3.25).

FIGURE 3.25 The Display Preferences window.

You can launch the Agent View from the Node View display to see more detailed information about the specific object. You can also acknowledge any status change or view a history of recent events collected by the DSM about the object.

To invoke any of these, right-click the object and select the appropriate function from the pop-up menu. View Agent brings up the Agent View; Acknowledge acknowledges the status.

DSM Event Viewer

Right-clicking an object and choosing View Events from the pop-up menu displays a list of events for the object and its children, as shown in Figure 3.26. These events are sent to the event log, which is described in Chapter 4. The display shows what the DSM remembers sending (which is not always identical to events the event log receives). The DSM remembers these events temporarily. When the DSM is restarted, all of the events are cleared.

FIGURE 3.26 The Event Browser window.

Each event is displayed as a single line. You can select the information displayed about an event by clicking the Filter button. It will open the Filter window (shown in Figure 3.27), where fields can be added or removed. The fields are Timestamp, State, Reported By (the DSM detecting the event), Reason, Host, Object, Class, and Domain.

FIGURE 3.27 The Filter window.

There is a status line at the bottom of the window that displays a number of facts. On the left it shows the domain (the DSM that is supplying the events, for example). In the middle it shows the specific object for which the events apply.

Setting Status

As the DSM determines the status of various objects, it reports that to the Real World Interface browsers by setting the status of the object in the Object Repository. You can also set the status through the SETSTAT command. This command can be used in scripts or invoked by the message/action engine as a way to reflect the status of some object in the repository. The command's syntax is available in the Unicenter TNG Administrator's Guide.

Mapping Status to Severity

The Real World Interface browsers display an object's severity. The severity is determined from the status of the object (by the DSM itself or by the SETSTAT command) and the status of the objects included within it.

Status is converted into severity by an alarm set, which is a table that maps the many possible status values into the few severity values.

The severity of objects propagates up to their parent in the display, allowing operators and even casual users to track down a problem by following the red ball (in 3D) or tracking the red icons (in 2D). The severity of the PDC110-Unispace object is determined by the combined severity of all the objects it contains. In turn, the PDC110-Unispace object's status propagates up to the PDC110 object, on to the 141.202.4.78 Segment.1 object, and so on, all the way to the top of the inclusion tree.

Viewing Status and Severity

From any of the Real World Interface browsers, you can see the status and severity of an object by opening its notebook and turning to the Status page, shown in Figure 3.28. To open the notebook, right-click the object and choose Object Details from the pop-up menu.

FIGURE 3.28 The Status page of the Managed Object Notebook.

AlarmSet

An alarmset is a table that maps status values into severity. Each managed object has an alarmset associated with it. This information is listed on the Main page of the object's notebook. Many objects share alarmsets. All objects of the same class generally use the same alarmset. This makes managing status and severity easier, since the policy can then be shared for all objects of a class. To handle exceptions, or to handle new classes of objects, you can create new alarmsets and assign specific alarmsets to specific objects.

You can view and edit an alarmset by right-clicking an object in one of the Real World Interface browsers and choosing Open AlarmSet from the pop-up menu. You will see a window like that in Figure 3.29; it shows the entries in the table. You can double-click an entry to change it or click the New button to add a new entry, using the window in Figure 3.30.

FIGURE 3.29 The AlarmSet Dialog box.

FIGURE 3.30 Adding an Alarmset entry.

Propagating Status and Severity

By default, the status of an object propagates up to its parent. Sometimes that is not appropriate. If a particular service is always down, or its status does not matter because it is a test system, then you can ignore its status by turning propagation off for that object. To turn propagation off, uncheck the Propagate box on the Status page of the managed object's notebook.

You can also turn off propagation of specific status values in an alarmset entry. That way, you can arrange it so that critical problems are propagated, but warnings are not. To turn off propagation of a specific status value, uncheck the Propagate Status box on the alarmset entry previously shown in Figure 3.29.

Technically Speaking: Polling and Event Notification

In enterprise management, polling is a request-response interaction between a manager and an agent. The manager discovers information about a managed resource by periodically querying an agent and requesting that certain values be provided. The agent responds by gathering the information from the target resource and sending it to the manager. The two top arrows in Figure 3.31 show this kind of request-response scenario.

FIGURE 3.31 Manager/agent communications infrastructure.

Periodic polling stands in contrast to event notification whereby agents automatically and autonomously notify managers of events of interest. This notification is asynchronous and is not based on any request that a manager issues. The bottom arrow in the figure shows such a notification scenario.

Polling and event notification complement one another. Polling is a simple and robust method. However, because there must be time intervals between the polling of any given device, there can be a delay between the occurrence of a problem and its detection. Event notification can provide immediate notification when events occur. On the other hand, event notification limits the information an agent provides to a network or systems manager.

Some products in the marketplace support either polling or event notification, but not both. You might hear about the advantages of not having to poll for information, or vice versa. Do not get the idea that polling and event notification is an either/or situation. The reality is that there are situations where polling is efficient and event notification is informative. Neither polling nor event notification (SNMP traps, for example) provides a complete management solution. The two methodologies are complementary and together provide a reasonably accurate and timely view of each device without incurring unnecessary overhead.

For example, it is inefficient to monitor a router by polling that router's agent every five seconds to find out if the router's bit error rate exceeds a threshold. This is like asking somebody every few moments if they feel sick. Having to respond 10,000 times that you feel fine is a heavy price to pay just to let somebody know on question 10,001 that you are getting a headache. It is much more efficient for the agent to raise an alarm (send an alert event) when the router exceeds the pre-specified bit error rate threshold, or for you to ask for aspirin when you need it.

On the other hand, the manager might need more information to fix the problem after receiving the notification that the router's bit error rate is too high. Is the bit error rate a problem on the input side or on the output side? A manager really has to poll agents to get additional specific information.

The most important reason for polling, however, is to clear up the situation when a manager hasn't heard from its agent for a while. There are two reasons for an agent not sending out any notification for awhile. First, lack of notification may mean that the resource is functioning properly and there is no reason to communicate. Second, no notification may mean that the agent or resource is down. The management system does not know the difference for certain. If the manager cannot poll the agent to find out that it is still responding to events, it has no way of telling, on its own initiative, whether the managed resource is up or down!