Lecture 21: Network Management #1


Network Management

Note that in many respects, the functions of network manager, system manager and security 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 few 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 Message 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".

Ping generates one (or more, see later) ICMP "echo request" packets (IP datagrams) 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 (ie, the remote host is "reachable") and is "up" (the remote host's operating system is running, and was able to generate the ping reponse). Ping is the single most important frontline weapon of the intelligent network manager...


Advanced Ping

The usefulness of ping is greatly increased when it is used at regular intervals. For example, a monitored system could be "pinged" at one to ten second intervals or so.

  1. Large variations in the ping time can indicate impending congestion in the routers between the monitored system and the network management station -- such variations are usually related to packets waiting in router buffers.

  2. Some pings (or ping responses) may be dropped in the network, indicating actual congestion (ie, routers experiencing buffer exhaustion) or possibly a "flakey" connection somewhere. Since an occasional loss of a packet is actually quite normal, the most interesting parameter here is the packet loss rate, expressed as a percentage of total pings sent.

  3. Most ping implementations can flood ping -- sending pings as fast as the originating system can generate them! Such stress testing can reveal problems with the network that only show up under heavy load. Needless to say, this option should be used sparingly!

  4. Most pings allow the user to set both the size of the ping packet (which can be up to the maximum possible datagram size) and the contents, which will pad the data area beyond the section needed for ping itself. These options can be used to reveal size and data-dependent problems with network components.

One other thing. The "man" page for ping wisely states:
This program is intended for use in network testing, measurement and management. Because of the load it can impose on the network, it is unwise to use ping during normal operations or from automated scripts.
Even more importantly -- you should only use ping for management purposes within your own network. Repeated pings to external hosts can be interpreted as indicating a Denial-of-Service attack.


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. Read the "man" page for traceroute before using it in "regular operations". As for ping, the manual states:
This program is intended for use in network testing, measurement and management. It should be used primarily for manual fault isolation. Because of the load it could impose on the network, it is unwise to use traceroute during normal operations or from automated scripts.
netstat

gives information about the UNIX kernel data structures associated with TCP/IP. For example, netstat -r prints the kernel routing table, netstat -a reports on all current TCP activity and netstat -C gives a continually updated real-time display of most network-related parameters. netstat is a very useful piece of software.

arp

This command reports on all current Address Resolution Protocol (IP to MAC address mapping) information, and allows the network manager to "hard-wire" an ARP entry if desired. Can be very useful where Proxy-ARP is in use, or where "ARP spoofing is suspected.

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. Always remember that telnet passwords cross the network in plain text.


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. In the most common scenario, SNMP is used to monitor network devices (usually, but not always, routers).

The key concept in SNMP is the Management Information Base, or MIB. The MIB is formally described using the Abstract Syntax Notation-1 (ASN.1) specification language, and defines all of the information which a nettwork manager would like to measure in the network device.

ASN.1 is used to define what the data items are. A companion standard defines a set of Basic Encoding Rules (BER)[1] which detail how an ASN.1 data entity is encoded for transmission across a network service. Note that for our purposes, ASN.1 is a Read-Only Language -- you will not be required to write ASN.1 specifications, but you will be expected to understand (approximately, at least) definitions given in ASN.1.

The use of ASN.1 illustrates an interesting aspect of the history of the Internet. It was adopted in the 1980s when it was widely believed that the OSI protocols would eventually replace the TCP/IP protocol set -- that the Internet would eventually be replaced by a global OSI-based network. ASN.1 was developed by the OSI standards groups, and the designers of SNMP wanted their protocol to survive the anticipated migration to OSI. In the end, it never happened, and the use of ASN.1 is simply an interesting historical artifact. Nevertheless, we have to deal with it...

[1] In some ASN.1 applications (X.509 certificates in particular), a somewhat "tightened" set of Distinguished Encoding Rules are used, but SNMP uses the original BER, and so shall we! BTW: ASN.1 and BER are International Standards, defined in ISO/IEC 8824:1987 and ISO/IEC 8825:1987


ASN.1 Basic Data Types

At its simplest, ASN.1 defines data items in a comparable way to the "declarations" used in most programming languges, so the definitions of basic types should look familiar, even if the syntax is a little strange. Simple[2] data types include:
BOOLEAN(1)
takes values true and false
INTEGER(2)
any positive or negative whole number
REAL(9)
expressed as mantissa, base, exponent
BITSTRING(3), OCTETSTRING(4)
an ordered sequence of 0 or more bits or octets (we would call these bytes)
NULL(5)
takes only one value, null...
ENUMERATED(10)
a list of values is supplied
Examples of some of these include:
brainDamaged ::= BOOLEAN
numberOfEmployees ::= INTEGER
avogadrosNumber ::= REAL(602,10,23)
sevenDeadlySins	::= ENUMERATED {
    pride(1), envy(2), gluttony(3), avarice(4), lust(5), sloth(6),
wrath(7)
} -- corresponding to OSI 7 layers :-)
NB: The numbers given in parentheses, eg (1), are called TAGS, see later this lecture. [2] A Java programmer would probably call these primitive data types; in some other languages they would be called scalars, although most programming languages don't include the "string" types in this category.

ASN.1 Structured Data Types

Structured ASN.1 data types include:
SET(17)
a fixed, unordered set of distinct types, some possibly optional
SET OF(17)
an unordered list of zero or more of the same type
SEQUENCE(16), SEQUENCE OF(16)
a fixed, ordered list of distinct or same types. In ASN.1 based applications such as SNMP, protocol data units (PDUs) (packets?) are commonly defined using this type.
CHOICE(11)
like SET, except more general.
ANY
like CHOICE, except containing a list of anything that can be defined in ASN.1

Some examples are:

messageBodyPart	::= CHOICE {
    [0] IMPLICIT asciiText, -- note TAG*
    [1] IMPLICIT telex
    ...etc... }

Tags in ASN.1

Note that in the previous slides, each element of a structured data item was associated with a TAG.

There are four classes of tags:

UNIVERSAL
a universal tag is defined in ISO/IEC 8824 and gives a machine-readable identification of all of the basic types of an ASN.1 specification. The tags attached to the basic data types in slides 2 & 3 of this lecture are an example.

APPLICATION
these tags are only required to be unique within a particular application. An example is a tag representing a particular packet type (PDU) sent by an application, and we see tags of this type in SNMP, later.

CONTEXT-SPECIFIC
these tags are only required to be unique within an already tagged type. The tags attached to values in the CHOICE and ENUMERATED examples in slides 2 & 3 are an example.

PRIVATE
these are defined for the use of a particular organisation and have no meaning outside of that organisation.


Subranges and "Derived Types" in ASN.1

In "pure" ASN.1, there are no constraints on the range of values that a variable can take. This is in contrast to "real world" languages such as Java and C where data items are usually associated with "reserved storage" -- eg, defining an integer typically reserves 4 bytes (32 bits) of memory in the program's data area.

Most ASN.1-based applications (eg SNMP) use derived types, which are specified using the sub-range (or sub-type) capabilities of the language[3]. These types usually match up with the storage which the application will reserve for them. Some examples include:

 
Month ::= INTEGER (1..12) 
Day ::= INTEGER (1..31) 
Daily-temperatures ::= SEQUENCE SIZE (31) OF INTEGER 
Name ::= PrintableString (SIZE (1..20 )) 

Digression on ASN.1 Syntax Conventions

In writing ASN.1 specifications, the case of the characters used conventionally indicates to a human reader the part of the ASN.1 grammar in use. Thus:

Note that in these notes, an attempt will also be made to present all ASN.1 (and other) syntactic elements in the fixed-width courier typeface. Occasional lapses from this convention may have to be forgiven by the reader... Examples:

MyType ::= TYPE
nameOfValue MyType ::= VALUE
Note also that, where appropriate, we adopt the OSI convention of referring to "octets", instead of "bytes", even though the terms have almost universally identical meaning.

[3] These are usually given APPLICATION-specific tags, as noted earlier, although some are sufficiently important to be defined in the standard.
[4] Reminding us of the quote fromThough The Looking Glass by Lewis Carroll: "When I use a word," Humpty Dumpty said in rather a scornful tone, "it means just what I choose it to mean -- neither more nor less."... La Trobe Uni Logo


Copyright © 2003 by Philip Scott, La Trobe University.
Valid HTML 3.2!