2.1 Planning for Network Management

Before installing the agent software and starting the management Console, you need to plan for the installation. Ask yourself this question: How will we use SunNet Manager to manage our network?

The following steps indicate the types of specific questions you will need to answer:

1. What are our critical nodes?

   Identify devices that have impact on the greatest number of network users--devices such as gateways, hubs, print servers, and software servers. If you only want to monitor these devices, you can reduce the number of elements to create and monitor.

2. What views of the network are most important?

   On a small network, you might place all critical nodes into a single view. For example, Figure 2-1 shows a network consisting of two subnets, A and B, which are connected by a gateway.

You could create a separate view for each subnet as well as separate views by type of device -- routers, software servers, and print servers. You could create these views one-at-a-time using the Console Edit >> Create function, as described in Section 3.8, "Creating Elements Using the Editor." Usually, it is more convenient to let the Discover Tool build a hierarchy of views to represent your network topology, as described in the Tools section of this manual. (You should use IPX Discover, if you have Novell Netware IPX nodes in your network.) For the example in Figure 2-1, you could create views in the Home view which would group elements by function (software servers, routers, etc.) and subnetwork.

SPARCstations and diskless workstations mount software from servers. One software server in each subnet doubles as a print server. An IPX.25 router provides a connection to a public switching network.

Assuming the servers and gateways are critical nodes, they could be placed into a single view. You could create these elements one-at-a-time, using the Console's Edit >> Create function, as described in Section 3.8, "Creating Elements Using the Editor." With only one view required, the elements could be placed in the Home view, as shown in Figure 2-2.

For most situations, however, you will want multiple views to represent functional groupings of network devices and to represent the network topology -- the various networks and subnetworks, types of connections used, and locations of routers and gateways. For example, you might want views to depict devices in particular buildings, or a view that consists of only routers.

.

Figure 2-1

Figure 2-2

The cloud glyphs in Figure 2-3 represent the separate views into the LAN and its subnetworks. Figure 2-4 shows the elements within these clouds. The same element can occur within multiple views. A software server, such as poignant, can occur both in the Servers view and in the Net_B view, which shows all nodes in a subnetwork.

Figure 2-3

Figure 2-4

3. What type of information do we need to use this product effectively?

   SunNet Manager provides three types of information:

   a. Event notification

   You want to be notified of critical events. The event request mechanism allows you to define conditions that generate an event notification. After it is specified, the event request is sent to the agent. The agent generates an event whenever the specified condition becomes true.

   If one of your critical nodes becomes unavailable to users, you will want to know this immediately. This means you must specify frequent polling intervals, such as every five minutes, in the appropriate event requests.

   If you want to know the status of a certain device, for example, whether a router is currently down and whether it has been down at any time since you last cleared an event, you want to choose Color By Priority as the method for notifying you. You can then take advantage of the "decay" feature. When the specified event occurs, its glyph changes to the priority color you have selected, then changes to blue, or the color you select, if the condition (e.g., unavailability) is no longer true.

   Starting with this release of SunNet Manager, you are not limited to yellow, orange, red, and blue as the colors representing low, medium, high priority, and the decay state. You can customize colors to create ones that you prefer. See Chapter 5, "Specifying Event Requests" or Chapter 4, "Requesting Data" for more information.

   Also starting with the current release, you can put a glyph in pending state to avoid logging repeated events or traps against the device it represents. This is useful when a device has been down for an extended time. When pending state is turned off, the current status of the device is displayed. See Chapter 5, "Specifying Event Requests," for more information.

   In addition to events generated by agents in response to event requests, there are also unsolicited events -- called "traps" -- generated by Simple Network Management Protocol (SNMP) devices, such as routers. For information on how to set up SunNet Manager to receive traps, refer to Chapter 8, "Managing SNMP Devices."

b. Data reporting

Over a period of time, statistical information can help you compare the performance of your critical nodes, such as servers and gateways. Data reporting provides this information in addition to statistics on network traffic levels at various times. Collecting data on resource utilization rates can help you determine whether particular network resources are being overburdened.

In most cases, you will probably not want continual polling for data, as this can add an additional burden to the network. If you periodically activate data-gathering periodically, you can develop a historical record to help you spot trends and determine "normal" load levels.

c. Topology information

You also want information on changes to the network's topology, such as the addition of new devices and connections. IP Discover tool's Monitor function searches the network to provide this information. You might want to limit these to weekly searches, since network configuration typically changes slowly.

Starting with this release, you can use IPX Discover to search your network for Novell Netware IPX nodes. See Chapter 23, "IPX Discover," for more information.

4. What agents can provide the type of information we want?

   After you know the type of event or data reports you need, you can determine which agents are required.

   Table 2-1 provides a summary of the agents shipped with the product. In some cases, agents return information similar to that provided by certain UNIX commands; this is indicated in the table.

Table 2-1

Name	Description	Related UNIX Command	Type
cpustat	Gather CPU statistics for multiprocessor systems		Agent
diskinfo	Reports disk usage information	df	Agent
etherif	Ethernet interface statistics for SunOS 4.x clients	--	SunOS 4.x agent
etherif2	Ethernet interface statistics for Solaris 2.x clients	--	Solaris 2.x agent
hostif	Monitors interfaces that send IP packets	netstat -i	Agent (see note)

Table 2-1

Name	Description	Related UNIX Command	Type
hostmem	Memory utilization information for SunOS 4.x clients	netstat -m	SunOS 4.x agent
hostmem2	Memory utilization information for Solaris 2.x clients	netstat -m	Solaris 2.x agent
hostperf	Host system performance data	rup and perfmeter	Proxy agent
iostat	Input/output statistics for SunOS 4.x clients	iostat	SunOS 4.x agent
iostat2	Input/output statistics for Solaris 2.x clients	iostat	Solaris 2.x agent
ippath	IP packet trace information	--	Proxy agent
iproutes	IP route table and statistics	netstat -r	Agent
layers	Protocol layer statistics for SunOS 4.x clients	netstat -rs netstat -s	SunOS 4.x agent
layers2	Protocol layer statistics for Solaris 2.x clients	netstat -rs, netstat -s	Solaris 2.x agent
lpstat	Printer status	lpq and lpstat	Proxy agent
ping	IP connectivity information	ping	Proxy agent
rpcnfs	Remote Procedure Call and Network File System statistics	nfsstat	Agent
snmp	Information from MIB I-compliant SNMP devices.	--	Proxy agent
snmpv2	For managing SNMP Version 1 and Version 2 devices	--	Proxy agent
snmp-mibII	Information from MIB II-compliant SNMP devices.	--	Proxy agent
sun-snmp	MIB I-compliant and Sun-specific information from Sun workstations.	--	Proxy agent
sync	Synchronous serial lines monitoring	syncstat	Agent
traffic	Ethernet traffic analyzer	--	Proxy Agent

After you have installed SunNet Manager, you can get specific information about each agent by consulting the man page for na.<agent-name>. For example:

hostname% man na.ping

To have access to the man pages, make sure you have set your MANPATH environment variable, as described in your installation manual.

In the case of the na.snmp proxy agent, there are three schema files shipped with SunNet Manager that can be used with it (snmp, snmp-mibII, and sun-snmp). You can get information on the snmp and snmp-mibII schema files in the man pages for <agent-name>.schema. For example:

hostname% man snmp-mibII.schema

The sun-snmp.schema file supports the features of the Sun enterprise-specific SNMP agent, snmpd, for Sun workstations and servers. To access information on this agent, enter the following command:

hostname% man snmpd

An efficient arrangement for proxy agents is to distribute them to collect information within separate domains or subnetworks. This reduces network traffic between the management station and managed devices.

For example, to find out if a router is down in a remote subnet, the management station can send an event request to a ping proxy agent in the target subnet. The proxy agent responds if it detects that a router is not available. Regular polling of routers is limited to the subnet where the proxy system is located.

For information on installing the SunNet Manager agents, refer to your installation manual.