Network traffic monitor MRTG Overview

Introduction

MRTG (Multi Router Traffic Grapher, MRTG) is a tool software used to monitor network link traffic load. It obtains device traffic information through the SNMP protocol, in addition, the traffic load is displayed to the user in HTML document containing PNG format, and the traffic load is displayed in a very intuitive form (the output result example of MRTG can be obtained at the website http://www.stat.ee.ethz.ch/mrtg ).

The most detailed information about MRTG can be from the http://people.ee.ethz.ch /~ Oetiker/WebTools/mrtg.

MRTG has the following features:

• Portability: currently, it can run on most Unix systems and Windows NT.
• Open source code: MRTG is written in Perl and the source code is fully open.
• High-portability SNMP support: MRTG uses a high-portability SNMP implementation module compiled by Simon Leinen, which does not depend on the operating system's SNMP module support.
• Support snmpv2c: MRTG can read the 64-bit counter of snmpv2c, thus greatly reducing the number of turns of the counter.
• Reliable Interface Identification: interfaces of monitored devices can be identified by IP addresses, device descriptions, SNMP serial numbers, and MAC addresses.
• Constant size Log File: MRTG logs will not become larger, because the unique data merging algorithm is used here.
• Automatic Configuration: MRTG has its own configuration tool suite, making the configuration process very simple.
• Performance: The time-sensitive part is written in C code, so it has good performance.
• PNG format: The image uses the GD library to directly generate the PNG format.
• Customization: The Web pages generated by MRTG can be completely customized.

The home page of MRTG is a http://www.mrtg.org where software can be downloaded.

MRTG compatibility

The MRTG software can run on the following operating systems:

Linux 1.2.x, 2.0.x, 2.2.x, 2.4.x (Intel and Alpha and iSCSI and PowerPC)
Linux MIPS, Linux S/390
SunOS 4.1.3
Solaris 2.4, 2.5, 2.5.1, 2.6, 7, 8
AIX 4.1.4, 4.2.0.0, 4.3.2
HPUX 9, 10, 11
WindowsNT 3.51, 4.0, 2 K, XP
IRIX 5.3, 6.2
Bsdi BSD/OS 2.1, 4.X, 3.1
NetBSD 1.5.x
FreeBSD 2.1.x, 2.2.x, 3.1, 3.4, 4.x
OpenBSD 2.x
Digital, UNIX 4.0
SCO Open Server 5.0
Reliant Unix
Nextstep 3.3
Open Step 4.2
Mac OS X 10.1
And about and other sensible Unix

Devices that can be monitored through MRTG (most products on the market currently support the SNMP protocol, as long as the devices that support the SNMP protocol can use MRTG for monitoring ):

3Com netbuilders, lanplex 6012 and 2500
3Com etherswitches and hubs
3Com linkswitching 1000 1100 3300
3Com SuperStack II Switch 3900,330 0 MX
3Com 812 ADSL Router
Alantec power hub 7000
Allied Telesyn-8224xl and 8324xl 24 port managed Switches
Annex Terminal Server
Asante Hub
Ascend (Lucent) Max 600, [24] 00x, pipeline 50, TNT, APX-8000, MAX-6000
Alcatel (Assured Access) x1600, omnisr9, Omnicore 5022
At&t wave point, LAN
Baynetworks (Wellfleet) 7.80 and up, baystack 350 t, instant internet, see Nortel
Breezecom AP, SA
Cabletron ESX-820 etherswitch, smartswitch 2000,6000 and Router
Centillion Token Ring speedswtich 100 (IBM 8251 Token Ring switch)
About every Cisco kit there is...
Centrecom 8116
Compatible Systems
Decbridge 620, Dec 900ef, 900ee, gigaswitch
ELSA lancom L 11 (wireless router)
Enterasys Matrix E5, VH-4802 and VH-2402S switche
Ericsson tirgis series Ras servers
Extreme Networks -- blackdiamond 6808 & Alpine 3808 Layer 3 switches
Fore asx200 ATM
Flowpoint 2200 ATM/DSL Router
Formula 8200 Series
Foundry bigiron 8000 Gigabit, fastiron switch, serveriron Switch
Cable Modems from lancity, terayon and DOCSIS
HP-network interfaces, disks, database Informix
HP advancestack/procurve switch 2000 and 2524, advancestack switch 200
HP procurve switches, model 4000 m, 2424 m and 2400 m
IBM 8260 swtich (with 155 mb atm blades installed), IBM 2210 ISDN routers.
Intel switches (details) -- 510 T, Intel Gigabit server adapter
IMV victron netpro 3000 UPS
Kentrox pacesetter pro
Lantronix Bridge
Lucent/xedia access pointt 450,100 0
Livingston (Lucent) irx 3.2.1r, irx 114, pm2e (r) PM3-2E OR-U
Motorola 6560 regional node, sb3100 cablemodem, 320,643 0 and 6455 Routers
Morningstar terminal servers/Routers
MGE (Merlin gerin) upses (details)
Network Appliance
Netopia r7100c SDSL
Netscreen 5/10/100
Nortel Networks, Bay routers BCN, bln, Asn, Arn, An, passport 1 K and passport 8k3 series L3 switches, baystack 450 L2 switches.
Nortel Networks, accelar L3 Switches
Nokia IP 330/440/650
Nbase Ethernet Switch
Novell 3.11, 4.11
Rmon probes
SGI-server (IRIX 5.3)
Any server running HP-UX, Ultrix, Solaris, SunOS, OSF, NetBSD, FreeBSD, bsdi, Linux, Aix, OpenBSD, IRIX or even Windows operating systems (badly ), when using NET-SNMP (former Co., UCD-SNMP ).
Apple Mac (an SNMP service is supported ded on the OS Cd> = 8.5)
Shiva accesport
Solaris Server
Squid Web Cache
US-robotics total control modemracks
Wellfleet (later Bay Networks): see Nortel Routers
Wavewireless speedlan 8x00 RF Routers
MS proxy, winnt
Xylan (today Alcatel) 4024c 24 port 10/100 omnistack switch, 9 K devices, including ATM links.
Yamaha rt100i
Zyxel prestige p310, 153x, 642.
Devices that do not support MRTG:
D-Link switches (details)

SNMP Introduction

A network management system generally includes the following elements: ① several (possibly many) network device nodes to be managed, such as routers, servers, and other devices, each node runs an application process called the device agent, it collects information about various Managed Objects of managed devices, such as traffic, and supports access to these managed objects. ② At least one management workstation, the management station runs the management platform application system to provide administrators with a visual graphical interface for managed devices, allowing administrators to conveniently manage the devices. ③ a management protocol, defines procedures for managing information transfer between device agents and Management workstations. Management Protocol operations are performed under the management framework. The management framework defines security-related authentication, authorization, access control, encryption policies, and other security protection frameworks.

In an Internet environment running TCP/IP, the management protocol standard is Simple Network Management Protocol (SNMP ), it defines the protocol message format for transmitting management information and the procedure for transmitting messages between the management station and the device agent.

Driven by the industry's urgent requirements for standardized network management protocols, IETF released an official RFC file for SNMPv1 in 1990; its design philosophy focuses on ensuring protocol simplicity, flexibility, and scalability, we also hope to use SNMP as a transitional Network Management Protocol as a standard for managing interconnected network devices, after the development, implementation, and standardization of the OSI Network Management Protocol-CMIP are mature and improved to be available in the industry, CMIP will be used to replace SNMP. However, for various reasons, CMIP does not replace SNMP, and SNMP has evolved into an industry standard.

SNMP has developed three main versions: SNMPv1, SNMPv2, and SNMPv3. SNMPv2 is divided into several sub-versions, among which snmpv2c is most widely used:

1. SNMPv1: the first formal protocol version, defined in the RFC1155-RFC1158, which uses a security mechanism based on the community name;
2. Snmpv2c: This version is known as the Community name-based SNMPv2, which is defined by the RFC1901-RFC1906 using an extension of the Community name-based security mechanism and protocol operations made by snmpv2p;
3. SNMPv3: This Protocol version uses a user-based security mechanism. Its security mechanism is updated after a large number of reviews are conducted on the basis of snmpv2u and SNMPv2, the logic function modules of the protocol machine are divided to ensure good scalability, which is defined by the RFC2271-RFC2275.

Principles and protocols for running an SNMP Management System

The management structure of the network management system using the SNMP Protocol generally includes: the management process regularly sends query request messages (in polling mode) to the device proxy process of each device ), to track the status of each device. When a device encounters an exception event, such as a cold start, the device proxy process sends a trap message to the management process to report the exception event. The sending and receiving procedures and format definitions of these polling messages and trap messages are defined by the SNMP protocol; managed devices store the information of various management objects in a database structure called Management Information Base.

The SNMP protocol runs on UDP and uses UDP port 161/162. Port 161 is listened by the device agent and waits for the management information query request message sent by the Administrator process. port 162 is listened by the Administrator process to report the Trap Message for the exception event sent by the device agent process, such as trap.

All information of a device that needs to be managed is considered as a collection of various managed objects. These managed objects are defined by OSI in a Management Information Base (MIB).

Manage Object Library MIB

MiB is a tree structure organized by hierarchies (similar to the domain name system). management objects are defined as corresponding leaf nodes in the tree. Management objects are organized in the form of modules. The parent node of each object shows which module of the object belongs to the upper layer. In addition, OSI defines a unique digital ID for each node in each layer of the tree. The Number ID in each layer increases progressively from 1, in this way, each node in the tree can be represented by a series of numbers corresponding to the corresponding identification from the root to the target node, for example, 1.3.6.1.2.1.1 indicates the system group subtree in mibii, 1.3.6.1.2.1.1.1.0 indicates the system description (sytem descrption) object in the system group. A series of numbers of each object indicates the object identifier (OID ).

A collection of related objects is defined as a MIB module. These modules are written in a subset of the abstract syntax mark (Abstract Syntax Notation One, ASN.1) of OSI. This subset is defined as the management information structure (SMI ).

SNMP uses the Basic Encoding Rules (BER) to encode messages when sending and transmitting messages.

The basic standard MIB library of SNMP is mibii. For details, refer to RFC 1213.

SNMP protocol operations

SNMP provides three types of operations: Get, set, and trap.

The get operation reads the management information represented by the managed object. In SNMPv1, The get operation has two forms:

Get and getnext operations: the get operation indicates to directly read the Management Information Value of the managed object represented by the oId specified by the operation parameter. The getnext operation indicates the value of the management information of the managed object indicated by the oId specified by the read operation parameter in the MIB Tree in alphabetical order. In SNMPv2, a GETBULK operation is added, which is a combination of get and getnext, to improve the efficiency of access to managed information.

The set operation writes the management information of the managed object, and directly sets the value of the management information corresponding to the managed object indicated by the oId specified by the operation parameter.

The management workstation initiates round-robin access to the managed devices to obtain various information about the managed devices; when an abnormal event occurs on the managed device, it is necessary to report it to the management workstation in a timely manner. This operation enables the managed device to report the abnormal event on the device to the management workstation, information such as network interface failure, recovery, and device restart. In addition, an Inform operation is added to SNMPv2 to implement communication between the management site and the management site.

The preceding operation message can specify one or more management object OID information at a time in the operation parameter, that is, one message can perform operations on multiple managed objects at a time.

SNMPv1 and snmpv2c adopt a simple security mechanism based on the community name:

Both the management site and the managed device store the community name that acts as the password; message sender (usually the Manager) enter the community name corresponding to the receiver in the community name segment of the message to be sent, and then send the message on the network in plain text. After the receiver (managed device) receives the message, if the message format is correct, read the field and compare it with the saved community name to authenticate the sender. In some implementations, there is a machine address list corresponding to each community name, indicating that only messages sent by machines in the list using the community name are considered credible. The community name serves as the password. At the same time, each community name has an access control permission, which may be set to read/write. Only the requested operation and the permission of the community name are allowed.

For details, see RFC 1157, RFC 1902, RFC 2273, and RFC 2274.

MRTG installation configuration installation support software

Here we useRehat7.2For example, we will discuss the configuration and installation of MRTG. To install MRTG, install the following software packages: GCC, Perl, Gd, LibPNG, and zlib. You can use the following command to determine whether the system has installed these software packages:

[Root @ mail Doc] # rpm-Qa | grep GD
Gd-1.8.4-4
Gd-devel-1.8.4-4

[Root @ mail Doc] # rpm-Qa | grep Perl
Perl-5.6.0-17
Mod_perl-1.24_01-3

[Root @ mail Doc] # rpm-Qa | grep libp
Libpng-1.0.12-2
Libpng-devel-1.0.12-2

[Root @ mail Doc] # rpm-Qa | grep zlib
Zlib-1.1.3-24
Zlib-devel-1.1.3-24
[Root @ mail Doc] # rpm-Qa | grep gcc
Gcc-2.96-98
Gcc-g77-2.96-98
Gcc-C ++-2.96-98

If you find that the software package is not installed, simply install the corresponding RPM package from the RedHat installation disk. For example:
Root @ mail Doc] # rpm-IVH zlib-1.1.3-24 zlib-devel-1.1.3-24

MRTG Installation

The latest version of MRTG is 2.9.17:

[Root @ mail SRC] # tar xvfz mrtg-2.9.17.tar.gz
[Root @ mail SRC] # cd mrtg-2.9.17
[Root @ mail mrtg-2.9.17] #./configure -- prefix =/usr/local/mrtg-2
[Root @ mail mrtg-2.9.17] # Make
[Root @ mail mrtg-2.9.17] # make install

Now we have correctly installed the MRTG system.

Configure the SNMP service

For different devices, the methods supported for configuring SNMP are inconsistent. For more information, see the device's random document. Here we will discuss how to configure the SNMP server in a Linux environment to analyze and report the incoming data from the Local Machine (my application environment uses Linux to drive a small LAN to access the Internet, monitor incoming and outgoing traffic of the local machine ).

It is easy to install the SNMP software package in Linux. You only need to install the corresponding software package:

[Root @ mail Doc] # rpm-Qa | grep SNMP
Ucd-snmp-4.2.1-7
Ucd-snmp-utils-4.2.1-7
Ucd-snmp-devel-4.2.1-7

Run the following command:

[Root @ mail Doc] #/etc/rc. d/init. d/snmpd start
Starting snmpd: [OK]

If the command output is shown above, the SNMP server is started normally.

To work with MRTG, you must modify the snmpd configuration so that MRTG can read traffic data from its interface (Network Interface.

VI/etc/snmp/snmpd. conf

Set

# View systemview embedded ded mib2

To:

View mib2 shortded .iso.org. DOD. Internet. Mgmt. mib-2 FC

Then

Access notconfiggroup "" any noauth exact systemview none

To:

Access notconfiggroup "" any noauth exact mib2 none

Then restart snmpd:

/Etc/rc. d/init. d/snmpd restart

Configure MRTG

The next step is to configure MRTG to monitor network devices. The configuration information of MRTG is stored in the mrtg. cfg file, which creates the file and defines the desired monitoring features. Fortunately, you do not need to manually edit the configuration file, because the MRTG package provides the mongomaker Configuration tool, which is a script file that automatically generates the mrtg. cfg configuration file based on running parameters. You can get this tool in the bin subdirectory of the MRTG source code directory.

First, create a sub-directory under the DocumentRoot directory of the WWW server to store the statistics file generated by mrtg. Here we assume that Apache is installed by default, so DocumentRoot is in the/var/www/html directory, in this directory, create the subdirectory MRTG:

Mkdir/var/www/html/MRTG

Here/var/www/html/MRTG is the working directory of MRTG. The MRTG configuration file is generated as follows:

Registrant maker -- Global "workdir:/var/www/html/MRTG "/
-- Global "options [_]: growright, Bits "/
-- Ifref = IP/
-- Output/etc/mrtg. cfg/
Public@192.168.0.1

In this example, the -- Global parameter indicates that the following options are valid for the specified devices (if you want to monitor multiple devices, this parameter will take effect ). Workdir is used to indicate the working directory of MRTG. Options is used to specify some specific options. growright and bits are used to specify the default options configuration, for common applications, the default options configuration can meet the requirements. Ifref indicates the options used to identify the device interface. Here, the IP address is used to identify the network device interface. Ifref can be specified as NR, IP, Eth, descr, and name. NR indicates using the ifindex of the interface interface interface in the mibii database to identify the interface; IP indicates using the IP address recognition interface; ETH indicates using the interface's physical address identification interface; descr indicates that the interface description is used to identify the interface; name indicates that the interface name is used to identify the interface. Generally, the IP address is unique, but in some cases the interface does not have an IP address, such as a switch. The NR (interface number) is unique for the interface, so IP address can be used in general cases, while nr is required in other cases. "-- Output/etc/mrtg. cfg" indicates that the generated configuration file is stored in the/etc/directory. "Public@192.168.0.1" indicates the device that monitors IP address 192.168.0.1, using public as the community name through SNMP protocol to monitor the device 192.168.0.1.

The following is an example of how to use MRTG to monitor multiple devices:

Registrant maker -- Global "workdir:/var/www/html/MRTG "/
-- Global "options [_]: growright, Bits "/
-- Ifref = descr/
-- Ifdesc = alias/
Public@router1.place.xyz/
Public@router2.place.xyz/
-- Global "options [_]: growright "/
-- Ifref = Name/
-- Ifdesc = descr/
Public@switch1.place.xyz/
-- Ifdesc = Name/
Public@switch2.place.xyz> mrtg. cfg

Four devices are monitored: router1.place. XYZ, router2.place. XYZ, and switch1.place. XYZ.
And switch2.place. XYZ, all devices use the Community name public for monitoring. The two routers use descr as the device description, while the two vswitches use alias as the device description (the two are different, for example, for a Cisco router, for descr, the device is described as "serial0", but for aliasl, it is "link to HQ ").

For my application environment, the generated mrtg. cfg content is as follows:

# Created
#/Usr/local/mrtg-2/bin/movie maker -- Global 'workdir:/var/www/html/MRTG '-- global' options [_]: growright, BITs'
-- Output/etc/mrtg. cfg -- ifref = IP public@192.168.0.1

### Global config options

# For Unix
# Workdir:/home/HTTP/MRTG

# Or for NT
# Workdir: C:/mrtgdata

### Global ults

# To get bits instead of bytes and graphs growing to the right
# Options [_]: growright, Bits

Workdir:/var/www/html/MRTG
Options [_]: growright, Bits

######################################## ##############################
# System: 192.168.0.1
# Description: Linux 192.168.0.1 2.4.7-10smp #1 SMP Thu Sep 6 17:09:31 EDT 2001 i686
# Contact: Root <root @ localhost> (Configure/etc/snmp. Local. conf)
# Location: Unknown (edit/etc/snmp/snmpd. conf)
######################################## ##############################

### Interface 1> descr: 'lo' | Name: ''| IP: '2017. 0.0.1 '| ETH :''###
### The following interface is commented out because:
### * It is a software loopback interface
#
# Target [192.168.0.1 _ 127.0.0.1]:/127.0.0.1: public@192.168.0.1:
# Setenv [192.168.0.1 _ 127.0.0.1]: mrtg_int_ip = "127.0.0.1" mrtg_int_descr = "Lo"
# Maxbytes [192.168.0.1 _ 127.0.0.1]: 1250000
# Title [192.168.0.1 _ 127.0.0.1]: Traffic Analysis for 127.0.0.1 -- 192.168.0.1
# Pagetop [192.168.0.1 _ 127.0.0.1]: # <Table>
# <Tr> <TD> system: </TD> <TD> 192.168.0.1 in unknown (edit/etc/snmp/snmpd. conf) </TD> </tr>
# <Tr> <TD> maintainer: </TD> <TD> root & lt; root @ localhost & gt; (Configure/etc/snmp. local. conf) </TD> </tr>
# <Tr> <TD> Description: </TD> <TD> lo </TD> </tr>
# <Tr> <TD> iftype: </TD> <TD> softwareloopback (24) </TD> </tr>
# <Tr> <TD> ifname: </TD> </tr>
# <Tr> <TD> max speed: </TD> <TD> 10.0 Mbits/S </TD> </tr>
# <Tr> <TD> IP: </TD> <TD> 127.0.0.1 (localhost) </TD> </tr>
# </Table>

### Interface 2> descr: 'eth0' | Name: ''| IP: '2017. 99.43.111 '| ETH: '00-d0-b7-b7-bb-30 '###

Target [192.168.0.1 _ 211.99.43.158]:/211.99.43.158: public@192.168.0.1:
Setenv [192.168.0.1 _ 211.99.43.158]: mrtg_int_ip = "211.99.43.158" mrtg_int_descr = "eth0"
Maxbytes [192.168.0.1 _ 211.99.43.158]: 1250000
Title [192.168.0.1 _ 211.99.43.158]: Traffic Analysis for 211.99.43.158 -- 192.168.0.1
Pagetop [192.168.0.1 _ 211.99.43.158]: </H1>
<Table>
<Tr> <TD> system: </TD> <TD> 192.168.0.1 in unknown (edit/etc/snmp/snmpd. conf) </TD> </tr>
<Tr> <TD> maintainer: </TD> <TD> root & lt; root @ localhost & gt; (Configure/etc/snmp. local. conf) </TD> </tr>
<Tr> <TD> Description: </TD> <TD> eth0 </TD> </tr>
<Tr> <TD> iftype: </TD> <TD> ethernetcsmacd (6) </TD> </tr>
<Tr> <TD> ifname: </TD> </tr>
<Tr> <TD> max speed: </TD> <TD> 10.0 Mbits/S </TD> </tr>
<Tr> <TD> IP: </TD> <TD> 211.99.43.158 (192.168.0.1) </TD> </tr>
</Table>
### Interface 3> descr: 'eth1' | Name: ''| IP: '192. 168.0.1 '| ETH: '00-10-4b-0c-b4-23 '###

Target [192.168.0.1 _ 192.168.0.1]:/192.168.0.1: public@192.168.0.1:
Setenv [192.168.0.1 _ 192.168.0.1]: mrtg_int_ip = "192.168.0.1" mrtg_int_descr = "eth1"
Maxbytes [192.168.0.1 _ 192.168.0.1]: 1250000
Title [192.168.0.1 _ 192.168.0.1]: Traffic Analysis for 192.168.0.1 -- 192.168.0.1
Pagetop [192.168.0.1 _ 192.168.0.1]: >
<Table>
<Tr> <TD> system: </TD> <TD> 192.168.0.1 in unknown (edit/etc/snmp/snmpd. conf) </TD> </tr>
<Tr> <TD> maintainer: </TD> <TD> root & lt; root @ localhost & gt; (Configure/etc/snmp. local. conf) </TD> </tr>
<Tr> <TD> Description: </TD> <TD> eth1 </TD> </tr>
<Tr> <TD> iftype: </TD> <TD> ethernetcsmacd (6) </TD> </tr>
<Tr> <TD> ifname: </TD> </tr>
<Tr> <TD> max speed: </TD> <TD> 10.0 Mbits/S </TD> </tr>
<Tr> <TD> IP: </TD> <TD> 192.168.0.1 (192.168.0.1) </TD> </tr>
</Table>

Run MRTG

Once the correct configuration file is generated, run the following command:

/Usr/local/mrtg-2/bin/MRTG/etc/mrtg. cfg

This will query the monitored devices and create an initial traffic diagram and web page in the working directory. During the first three operations, alarms for lost log files may be reported and ignored, you only need to run it three times in a row without generating alarm information. If an alarm still occurs, you need to check the problem.

Manual running of MRTG does not generate appropriate statistics on a regular basis. Therefore, it is best to run MRTG regularly to generate statistics. The default value is five minutes. As the root identity, crontab-e enters the editing status. The added content is as follows:

*/5 */usr/local/mrtg-2/bin/MRTG/etc/mrtg. cfg

Then you can access the http: // 192.168.0.1/MRTG/address in the browser to view the traffic information. If you want to generate something similar to http: // www. stat. ee. ethz. for information on CH/MRTG/, You can manually edit an index.html file and store it in the/var/www/html/MRTG directory. The content is the interface description and the daily statistics of the interface.