Download Network Management Protocols

Network Management Protocols and
Applications
by Fretless
Cliff Leach
Mike Looney
Danny Mar
Monty Maughon
ISQS 3349-002
April 19, 2002
As the importance of networking technology increases in our everyday lives, the
demand for efficiency and reliable networks increase. Many days go by in America
alone where there are constant problems with connections between networks, businesses,
and even consumers. Ever had an internet service provider disconnect you without
warning? Or was it the internet service provider that disconnected you? Has there been
an instance where you had an important file or document to submit, but the network was
down?
When comparing a reliable network to simple computer network, many can use
the analogy of a telephone network. Telephone networks are recognized by their
reliability and robustness. When was the last time you remember being disconnected
from a long distance call? (not due to your equipment and the other person’s equipment
failure) This analogy creates a good benchmark for computer networking. Of course, the
two networks differ, but the reliability and effectiveness is what all network managers
strive to achieve.
To deal with these common problems, there are a set of tools, protocols, and
applications that network managers and other information technology specialists should
learn. These network management tools provide professionals ways to prevent and even
recover from these problems. When recovering from a problem, the amount of time that
it takes to solve the problem may be greatly reduced. In the business world, time is
money!
Network Management Protocols
SNMP - Simple Network Management Protocol
SNMP was first developed in 1988, after its predecessor SGMP (Simple Gateway
Management Protocol) which was used to manage internet routers. According to Mani
Subramanian, SNMP is most widely used network management protocol because it is a
simple architecture and easy to integrate. This protocol is a set of “simple” operations
that allow administrators to manage network devices, modems, power supplies, and even
servers from a remote location. Any device that has SNMP capabilities can be managed.
Even software such as database software and web server software can utilize the
capabilities of SNMP. With the ability to manage remotely, networks that are offline can
be troubleshooted away from the office, providing more opportunities to maintain the
network.
How does it work?
There are two classifications of networking devices, and those are unmanaged and
managed devices. Those that are classified as unmanaged do not have the capability of
being analyzed by a network management protocol or application. On the other hand, a
managed device allows a network administrator or information technology professional
to manage the device. Each managed network device such as a router, gateway, or a
server has a collector called an agent. The agent gathers information about the device,
and stores that information in a database called the management information base (MIB).
Sometimes this is referred to as a manager managing a manageable device, and in this
manager is a database that contains the information collected by an agent and then
processed. The manager is typically a server with network management software on it
that sends requests to the agents, which are located on the manageable network devices.
SNMP uses UDP (User Datagram Protocol) to send a receive messages between
the manager and the agent. Because SNMP uses UDP, this makes the transmission less
reliable due to the lack of acknowledgements of requests and sending of data. Instead, a
network manager can set a timeout on the manager to send another request to the agent if
there is no response. Managers either poll the agent or receive traps from an agent.
During the process of polling, the manager queries the agent to retrieve information about
that device. This network information is commonly referred to as a protocol data unit
which an object that has variables, data types, and values. This information is sent back
to the manager and stored in the database. In a process of a trap, the agent sends
information to the manager without a request. An example of this could be a UPS
(uninterruptible power supply) that has a SNMP agent sending information about the
battery running out of power. Since SNMP there are no acknowledgments with sending
and receiving of protocol data units, traps that are sent from agents can be lost and the
agent will not be notified of the lost data. This may lead to problems.
SNMP can be a very powerful tool. It allows for the constant analysis of the
network. Of course, your network devices must be manageable devices. This consistent
flow of analysis can help network managers detect for potential problems. Wouldn’t you
like for SNMP to monitor performance on a router, tell what speed a connection is on the
network, and even monitors the temperature of a switch?
If you take a look at a computer with a Microsoft Windows NT-based operating system,
you will find a SNMP as an option for network services.
CMIP – Common Management Information or Interface Protocol
The standard for the Open Systems Interconnection management is CMIP. It uses
a service calls Common Management Information Service to performs its various tasks.
Since it is based on the OSI model, it addresses all seven layers of the OSI model:
Physical, Data Link, Network, Transport, Session, Presentation, and Application. Both
local area networks and wide area networks can be addressed using CMIP. This protocol
is object-oriented, so it calls for more memory than its scalar object counterpart, SNMP.
CMIP is commonly associated with Telecommunications Management Network because
telephones networks are based on the older seven-layer OSI model.
Telephone companies and large name network service providers use this protocol
over SNMP because there is no room for error when the consumer is heavily reliant on
the connection. CMIP is expensive to develop and takes much more time to develop, but
the level of control that CMIP has is quite more than its counterpart. Not only can CMIP
transfer PDU’s like SNMP, but the individual variables can be used perform various
tasks.
RMON – Remote Network Monitoring
RMON is a standard MIB (Management Information Base) used by network
administrators to monitor network usage and troubleshoot network-related problems. It
was initially defined by Internet communities along with IETF (Internet Engineering
Task Force) in 1992.
This standard was known as RFC (Request For Comments) 1271 and later
became obsolete in 1995 when RFC 1757 became the new standard. This standard
defines current and historical statistics and control objects that allow the network
administrator to get real-time statistics and information from across the whole network.
To make this a viable tool, all console managers and network probes on the
network have to be RMON compliant. This gives network administrators a comprehensive network-fault diagnosis, planning, and performance-tuning information.
Generally, RMON configurations are composed of a central network management station
and a RMON agent. The management station is a Windows-based or UNIX-based
workstation or PC running a management application, and the RMON agent or probe is a
remote monitoring device and is used in LANs and WANs in conjunction with hubs,
routers and switches. Some switches include software that allow the switch to collect and
record information to it’s MIB as traffic flows through it. The RMON agent can then
gather this information and hold it until the network administrator issues SNMP
commands requesting the information.
RMON information is divided into nine optional groups of monitoring elements.
The different options of each of these groups allow the vender to choose which groups to
support within the MIB. Although for some groups to be functional, they need the
support of some of the other RMON groups. The specifications of these groups are listed
in the following table:
RMON Monitoring Groups
RMON Group
Function
Elements
Statistics
Contains statistics measured
by the probe for each
monitored interface on this
device.
Packets dropped, packets
sent, bytes sent (octets),
broadcast packets, multicast
packets, CRC errors, runts,
giants, fragments, jabbers,
collisions, and counters for
packets ranging from 64 to
128, 128 to 256, 256 to 512,
512 to 1024, 1024 to 1518
bytes.
History
Records periodic statistical
Sample period, number of
samples from a network and samples, items sampled.
stores them for later retrieval.
Alarm
Periodically takes statistical
samples from variables in the
probe and compares them
with previously configured
thresholds. If the monitored
variable crosses a threshold,
an event is generated.
Includes the alarm table and
requires the implementation
of the event group. Alarm
type, interval, starting
threshold, stop threshold.
Host
Contains statistics associated
with each host discovered on
the network
Host address, packets, and
bytes received and
transmitted, as well as
broadcast, multicast, and
error packets.
HostTopN
Prepares tables that describe
the hosts that top a list
ordered by one of their base
statistics over an interval
specified by the management
station. Thus, these statistics
are rate-based.
Statistics, host(s), sample
start and stop periods, rate
base, duration.
Matrix
Stores statistics for
conversations between sets
of two addresses. As the
device detects a new
conversation, it creates a new
entry in its table.
Source and destination
address pairs and packets,
bytes, and errors for each
pair.
Filters
Enables packets to be
matched by a filter equation.
These matched packets form
a data stream that might be
captured or that might
generate events.
Bit-filter type (mask or not
mask), filter expression (bit
level), conditional expression
(and, or not) to other filters.
Packet Capture
Enables packets to be
captured after they flow
through a channel.
Size of buffer for captured
packets, full status (alarm),
number of captured packets.
Events
Controls the generation and
notification of events from
this device.
Event type, description, last
time event sent.
Figure 1.1 – Example of RMON Probe in manageable hubs.
Figure 1.2 – Example of how RMON works.
Figure 1.3 – A graphic depicting how RMON works with a console manager.
Network Management Applications
Network management applications are software packages that provide network
administrators tools to maintain a network. These applications typically create graphs
and charts based on data gathered from the LAN that the program is analyzing. The
application can display information from amount of packets received on a particular node
to overall network traffic on the network. Administrators need ways to identify where
potential problems may occur on the network. These programs give them insight to
where bottlenecks occur, when traffic is heaviest, and where there is a need for
maintenance or an upgrade.
Lanwatch32
LANWatch32 is a network analysis tool available on the market today.
LANWatch32 succeeds in packet sniffing and filtering, however it is not well suited for
more complex tasks. LANWatch32 monitors traffic in real time and displays a wide
range of statistics, and is also easy to install and use. Network Administrators
implementing LANWatch32 can quickly identify problems and keep networks running at
peak performance. LANWatch32 is also a useful tool for Network Application and
Protocol Developers. Network protocols can easily be monitored, examined and verified
in both hexadecimal and formatted views. A sample screenshot of the interface is shown
below.
Figure 2.1 - Screenshot of LANWatch32 in action
Features






InstallShield based installation
Easy-to-use interface with pull-down menus
Graphic display of detailed network statistics
Decodes over 60 network protocols, including:
o TCP
o UDP
o IP
o IPv6
Provides over 400 filters to isolate network traffic
Software-based, easily portable to remote sites
Any system running Windows95, Windows98, Windows2000, or WindowsNT 4.0 can
run LANWatch32.
Network Statistics Displayed











Current bandwidth utilization
Bandwidth utilization highwater mark
Actual and captured packets per time interval
Actual and captured bytes per time interval
Total number of packets on network
Total number of packets captured
Counts of packets by protocol
Packet size distribution
Counts of error packets (CRC errors, IP checksum
errors, alignment errors, overruns, shorts and longs)
Total number of broadcast packets
Total number of packets dropped
After reviewing this product James Sanders, writer for PC Magazine, voiced his
opinion of LANWatch32 compared to other network analysis tools. He said that the first
immediate problem was that the interface is poorly designed, and the main view is similar
to a DOS command prompt with colored ANSI text. As you can clearly see from the
sample screen shot, his opinion is simple to agree with.
Multi-Router Traffic Grapher
Multi Router Traffic Grapher (MRTG) is another networking management
application. It works on many platforms such as Windows OS, Unix, and Mac OS 10.1.
It was first published on the Internet in spring 1995 and became very popular among
people. It consists of a Perl script, which uses the SNMP to read the traffic counters of
your routers and a C program to log the traffic data. It then creates graphs in GIF format
representing the traffic on the monitored network connection. These graphs are
embedded into web pages, which can be viewed from any web-browser.
Figure 3.1 – Example GIF file
MRTG also has the ability to create visual representations of network traffic as far
back as twelve months. MRTG logs its data to an ASCII file that it takes from the router.
It is constantly being consolidated, so the log file will not grow over time, but it still
contains relevant data for all the traffic in the past two years. This makes it possible to
monitor two hundred plus network links from any UNIX-based computer.
Figure 3.2 -Example of MRTG processing log files
MRTG is not just limited to monitoring network traffic though. It can also
monitor any SNMP variable you choose. You can even use an external program to gather
the data, which should be monitored through MRTG. Some examples of MRTG in
action include monitoring system loads, login sessions, and modem availability. MRTG
even has the flexibility to allow you to accumulate two or more data sources into a single
graph.
MRTG does have two major problems, which include scalability and portability.
Because of these two problems and many user requests to enhance features of MRTG, a
new version of MRTG was released in January 1997 (MRTG-2.0). This new release
became even more popular by users because it was much faster and more user-friendly
than the previous release. For example, Version 2.0 had a tool, which is included in the
MRTG distribution, that has the ability to build a skeleton configuration file for a router
by reading its interface table through SNMP. This gives people the ability to successfully
configure MRTG even when their knowledge about SNMP is minimal or about how to
find out which physical router interface is mapped to which SNMP variable. Another
key feature of MRTG-2.0 is that it no longer requires the PBM package or an external
SNMP gatherer. This made the porting of the package very simple.
MRTG-2.0 has a more efficient method for maintaining its log files too, as
opposed to the previous release. The basic assumption for designing the MRTG-2.0 log
file was that the interest in detailed information about the load of the network diminishes
proportionally to the amount of time, which has passed between the collection of the
information and its analysis. This led to the implementation of a log file, which stores
traffic data with a decreasing resolution into the past. Data older than two years is
dropped from the log file. The resolution of the log file matches the resolution of the
graphs shown on the web page. This log file has the advantage that it does not grow over
time and therefore, allows unattended operation of the system for extended periods of
time. Drawing the individual graphs is relatively fast because no data reduction step is
required and thus, disk utilization is minimized.
MRTG-2.0 log files are stored in plain ASCII. Each line starts with a time stamp
followed by corresponding traffic data. The file starts with the most current entry and
ends about two years in the past. For processing, it is read as a whole, processed in
memory, and written back to the disk. This process takes place for every single update.
Figure 3.3 - MRTG-2.0 processing log files
Although MRTG-2.0 had many improvements from its previous version, it too
had two problem areas, performance and flexibility. The performance issue was that it
could not monitor more than about six hundred router ports in a five-minute interval,
which is due to the way the log files are updated. Also, MRTG-2.0 was not flexible in
the since of configurability when using the program to monitor time-series data other
than network traffic. As MRTG is constantly being revised for further enhancements and
more key features, many large sites are beginning to use MRTG. Some are even starting
to use MRTG to monitor “non-traffic” data sources, requiring more user control over the
generated web pages and graphs. These problems would soon lead to the development of
yet, another new release, MRTG-3.0.
Conclusion
These protocols and applications prove to be an important resource for anyone
working with data communications, more specifically networking. Without the ability to
manage networks, lots of money would be lost trying to solve any problems that may
exist. Not only money would be lost, but time would be another critical factor to
consider when you do not have the right resources. AS mentioned before, in the business
world, time is money!
All these protocols discussed in our project provide professionals the ability to
monitor any device available on the network that has an agent. Companies that have the
ability to monitor and control every key component within their corporation have power
to expand into the future. Although networks are just a way to connect technology inside
and outside the company, it proves to be a key factor in delivering information to its
stakeholders.
Fretless believes that network management is already an important role and will
continue to be important in the success of our information revolution. Without this
knowledge, information technology professionals lack key skills to troubleshoot
problems in networking technology. They will lose time and patience, and therefore, the
company itself will suffer. Many of these professionals do not even have a clue about
these protocols and applications that are available. As a matter of fact, many students in
data communications will not even have any of these skills after they graduate.
References
Douglas R. Mauro and Kevin J. Schmidt, Essential SNMP 2001: O’ Reilly & Associates.
Mani Subramanian, Network Management 2000: Addison & Wesley
LANWatch 32 6.5
http://www.sandstorm.net/products/lanwatch/
CMIP/CMIS - Object Oriented Network Management
http://www.cellsoft.de/telecom/cmip.htm
Network Management Industry
http://opennet.com/papers/nms/sld001.htm
MRTG - The Multi Router Traffic Grapher
http://www.usenix.org/publications/library/proceedings/lisa98/full_papers/oetiker/
oetiker_html/oetiker.html
RMON Overview
http://support.baynetworks.com/library/tpubs/html/router/soft1101/114070B/N_2
4.HTM