Network Management

Provision of a reliable network service by...
Monitoring of:
- Devices (reachability, uptime)
- Loads (eg: Percentage Ethernet load, TRIB for IBM-style point-to-point links)
- Performance (eg: packets routed per second, idle time, CPU load)
- Error rates (collisions, BER, dropped packets, lost tokens)
- (and lots more)
Configuration of hosts, routers, bridges, etc.

Note that in many respects, the functions of network manager and system manager are becoming increasingly blurred.

Much of the day-to-day work of the network manager can be done using simple, and freely available, utility programs (see next two slides).

For more complex monitoring, the Simple Network Management Protocol (SNMP) provides the network manager with the means to observe the performance of every network device.

Echo Request

The basic connectivity tool is the availability of the echo request packet type in virtually all network-layer protocols.

In IP, the echo request type is supplied by ICMP, the Internet Control Messsage Protocol, which is required to be "builtÊin" to every IP implementation. ICMP is internal to IP: few "hooks" are available for users to generate ICMP packets.

The notable exception is provided by the user program ping, the "Packet INternet Groper".>p> Ping generates one or more ICMP "echo request" packets addressed to a specified remote host. On receipt of such a packet, the remote host is required to send a time-stamped "echo reply" packet to the originating host.

Such a transaction confirms packet delivery, and gives a rough indication of the presence of unacceptable delays in the network. In an IP network, ping is the single most important frontline weapon of the intelligent network manager...

Other Basic Tools

The network manager can also make intelligent use of:

Traceroute: enables the network manager to discover the route taken by IP datagrams in travelling to a remote host
netstat: gives information about the UNIX kernel data structures associated with TCP/IP. For example, netstat -r prints the kernel routing table, whilst netstat -a reports on all current TCP activity.
arp: reports on all current Address Resolution Protocol (IP to MAC layer mappings) information. Can be very useful where Proxy-ARP is in use!
nslookup, dig: useful for checking DNS (Name Service) operation. Note that if DNS is not operational, other tools may still be usable with dotted IP addresses instead of names.
telnet: useful for checking operation of the TCP sub-system. In addition, many network devices (eg, most routers) support telnet connection by the network manager to check loads, error rates, etc.
finger: may be useful to check for existence of this basic TCP service, also to check for excessive system loads on remote machines.

Simple Network Management Protocol

SNMP describes the Structure of network Management Information (SMI) in network devices, and the protocols for accessing (and possibly modifying) such information.

The key concept in SNMP is the Management Information dataBase, or MIB. This is formally described in the Abstract Syntax Notation -1 (ASN.1) specification language and its associated Basic Encoding Rules (BER).

SNMP is documented in various Internet RFCs: 1109, 1052, 1057, 1155, etc.

The MIB is defined in terms of only a few basic (or UNIVERSAL) ASN.1 object types.

Some of these include:

OBJECT IDENTIFIER (OID): A unique sequence of integers which specifies the object's location in a global tree structure - the MIB
OBJECT DESCRIPTOR: A unique printable string which describes the object's type
INTEGER
OCTET STRING

SNMP Application Types

SMI describes six new data types for use in the management framework:

IpAddress

A data type representing an IP address:

IpAddress ::=
    [APPLICATION 0]
    IMPLICIT OCTET STRING (SIZE (4))

NetworkAddress

a data type represnting an address from one of several protocol families. Usually identical to IpAddress.

Counter

A data type representing a non-negative integer which monotonically increases until it reaches a maximum value when it wraps to zero.

Counter ::=
    [APPLICATION 1]
    IMPLICIT INTEGER (0..4292967295)

Gauge

A data type representing a non-negative integer which may increase or decrease, but which latches at a maximum value.

Gauge ::=
    [APPLICATION 2]
    IMPLICIT INTEGER (0..4292967295)

TimeTicks

hundredths of a second

Opaque

arbitrary encoding

The SNMP SMI

Thus the "TCP" subtree of object identifiers in the MIB starts with the prefix (OBJECT IDENTIFIER):

1.3.6.1.2.1.6

The "System" subtree starts at: 1.3.6.1.2.1.1

MIB Contents

The MIB describes objects which are expected to be implemented by managed nodes. For the original (1988) version of the MIB, the following rules were used in deciding on a minimum set of MIB objects:

The object must be essential for either fault or configuration analysis.
Due to lack of a secure authentication framework, any control objects must have weak (limited) properties.
The object must have evidenced utility
The number of objects must be kept reasonably small (initially 114 objects)
The object must not be easily derivable from other objects (eg, arithmetically)
The object must be sufficiently general in nature as to be found on many different platforms.
Only one counter-like object was allowed per critical loop (not fully realised in practice)

Format Of MIB Entries

By convention, no object in the Internet standard MIB has a sub-identifer of zero. Thus, the first variable in the system group is:

system OBJECT IDENTIFIER ::= { mib 1 }

which has the name:

{ system 1 }

1.3.6.1.2.1.1.1

A second convention is that symbolic descriptors of objects should be short, mnemonic strings, thus:

sysDescr OBJECT-TYPE
	SYNTAX OCTET STRING
	ACCESS read-only
	STATUS mandatory
		::= { system 1 }

(The SNMP type sysDescr is a string which gives the manufacturer's type designation of the managed device)

This lecture is also available in PostScript format. The tutorial for this lecture is Tutorial #15.

Phil Scott