Abstract:
Publisher: NetBull Readings: 1424
http://www.linuxbyte.net
Introduction
MRTG (Multi Router Traffic Grapher, MRTG) is a tool software that monitors network link traffic loads, which delivers traffic information from the device from the device via the SNMP protocol, and displays the traffic load to the user with the HTML document containing the PNG format. Display traffic load in very intuitive form (you can get the output result example of the MRTG) in the website http: // www.stat.ee.ethz.ch/mrtg/.
The most detailed information about MRTG can be obtained from http://people.ee.ethz.ch/mrtg/webtools/mrtg.
MRTG has the following features:
Portability: It is currently running on most UNIX systems and Windows NT.
Source opening: MRTG is written in Perl, and the source code is fully open.
High-profit SNMP support: MRTG uses high-portability SNMP implementation modules prepared by Simon Leiner, which is not supported by SNMP module of the operating system.
Support SNMPv2c: MRTG can read the 64-bit integer of SNMPv2c, which greatly reduces the number of revolutions.
Reliable interface ID: The interface of the monitored device can be identified by the IP address, device description, SNMP to the interface number and MAC address.
Constant size log file: MRTG's log will not be large, because the unique data merge algorithm is used here.
Auto Configuration Function: MRTG itself has a configuration tool kit that makes the configuration process very simple.
Performance: Time-sensitive part is written using C code, so it has good performance.
PNG format graphics: Graphics use GD libraries to generate PNG formats.
Destative: The web page generated by the MRTG is fully customized.
MRTG's homepage is http://www.mrtg.org, you can download the software from here.
MRTG compatibility
The MRTG software can run on the following operating system:
Linux 1.2.x, 2.0.x, 2.2.x, 2.4.x (Intel And Alpha And Sparc 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, 4.3.2
HPUX 9, 10, 11
WindowsNT 3.51, 4.0, 2K, 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
Openstep 4.2
Mac OS X 10.1
And About And Other Sensible Unix
It can be monitored by MRTG (most products on the market support SNMP protocol, as long as the device supporting the SNMP protocol can be used to monitor):
3Com NetBuilders, LANPLEX 6012 and 2500
3COM Etherswitches and hubs
3COM LINKSWITCH 1000 1100 3300
3Com SuperStack II Switch 3900, 3300 MX
3COM 812 ADSL ROUTER
Alantec Powerhub 7000
Allied Telesyn - 8224xl and 8324xl 24 Port Managed Switchesannex 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 350T, 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 lant, terayon and docsis
HP - NetWork Interfaces, Disks, Database INFORMIX
HP AdvanceStack / Procurve Switch 2000 and 2524, Advancestack Switch 200
HP Procurve Switches, Model 4000M, 2424M and 2400M
IBM 8260 SWTICH (with 155MB ATM Blades Installed), IBM 2210 ISDN Routers.
Intel Switches (Details) - 510T, Intel GigaBit Server Adapter
IMV VICTRON NETPRO 3000 UPS
Kentrox Pacesetter Pro
Lantronix Bridge
Lucent / Xedia Access PoinTt 450, 1000
Livingston (Lucent) IRX 3.2.1R, IRX 114, PM2E (R) PM3-2E OR-U
Motorola 6560 Regional Node, SB3100 Cablemodem, 320, 6430 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 1K 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 Server Running HP-UX, Ultrix, Solaris, Sunos, OSF, NetBSD, FreeBSD, BSDI, Linux, AIX, OpenBSD, IRIX OREVEN Windows Operating Systems (Badly), WHEN Using Net-SNMP (FORMER UCD-SNMP).
Apple Mac (AN SNMP Service Is Included on the OS CD> = 8.5)
Shiva Accesport
Solaris Server
Squid Web Cache
US-Robotics Total Control Modemracks
Wellflet (Later Bay Networks): See Nortel Routers
Wavewireless Speedlan 8x00 RF Routers
Winnt, MS Proxy
XYLAN (Today Alcatel) 4024C 24port 10/100 Omnistack Switch, 9k Devices, Including ATM Links.
Yamaha RT100i
Zyxel PRESTIGE P310, 153X, 642.
MRTG device does not support:
D-Link Switches (DETAILS)
SNMP introduction
A network management system generally includes the following elements: 1 Several (possibly a number) requires managed network device nodes, such as routers, servers, etc., each node is running a device representation (Agent) The application process, its collection of information such as traffic such as traffic such as traffic such as traffic, etc., and supports these managed objects; 2 at least one management workstation, the management station runs the management platform application system, Implementation provides administrators with visual graphical interfaces of the managed equipment, enabling administrators to manage; 3 A management protocol to define the management information transfer between device proxy and management workstations. The operation of the management protocol is conducted in the management framework, the management framework defines a variety of security protection frameworks such as security-related authentication, authorization, access control, and encryption policies.
In an Internet environment running the TCP / IP protocol, the management protocol standard is a Simple Network Management Protocol (SNMP) that defines the protocol message format and management station and device proxy for transmission management information. Procedure.
For the industry's urgent requirements for the standardization of network management protocols, IETF issued the formal RFC document of SNMPv1 in 1990; its design idea focuses on the simplicity, flexibility and scalability of the protocol, and hopes to use SNMP as A transitional network management protocol comes as a standard that implements the interconnection of network devices to manage, the development, implementation, and standardization of the network management protocol of OSIP - CMIP can be used after the industry is promoted. Replace SNMP. However, due to various reasons, CMIP did not replace SNMP, while SNMP developed as the industry standard.
SNMP has three main versions of SNMPv1, SNMPv2, and SNMPv3, respectively. The SNMPv2 is divided into several subsets, where SNMPv2c is the most widely: SNMPv1: is the first formal protocol version, defined in RFC1155-RFC1158, which uses a community-based security mechanism;
SNMPv2c: This version is called SNMPv2 based on common names, expansion by RFC1901-RFC1906 using a joint-based security mechanism and SNMPv2p.
SNMPv3: This protocol version adopts user-based security mechanism, and its security mechanism is updated after SNMPv2U and SNMPv2 *, and has been updated after a large number of reviews, and the logical function module of the protocol has ensured good. The expansion is defined by RFC2271-RFC2275.
The principle and SNMP protocol running the SNMP management system
The network management system management structure of the SNMP protocol generally includes: the management process transmits a query request message (in polling mode) to each device, to track the status of each device (in polling mode), and an abnormal event such as device When cold start, the device proxy process actively transmits a trap message to the management process, and report an exception event that appears. These polling messages and trap messages and their formatted definitions are defined by the SNMP protocol; and the information managed by the managed device puts the information of various management objects in a management information base. In the library structure.
Where the SNMP protocol is running over the UDP protocol, it uses the 161/162 port of the UDP protocol. The 161 port is listened by the device agent, waiting for the management information query request message sent by the manager process; 162 ports are listened by the manager to listen to the exception event report trap message sent by the device agent process, such as TRAP.
All of the device's information is managed is considered a collection of various managed objects, which are defined in the virtual information library called Management Information Base (MIB) in a virtual information library.
Manage object library MIB
The MIB is a tree structure (defined by a domain name system) according to the hierarchical structure (a domain name system), and the management object is defined as the corresponding leaf node in the tree. The management object is organized according to the form of the module, and the parent node of each object indicates which module belongs to the upper layer. Moreover, OSI is defined a unique digital identifier for each node of each layer in the tree, and the number identifier in each layer begins to increment, so that each node in the tree can be used from the beginning to the destination node. Identify the corresponding series of numbers, as 1.3.6.1.2.1.1 represents the system group tree in the MIBII, and 1.3.6.1.2.1.1.1.0 represent the system description object in the system group. A series of string numbers for each object is called an object identifier (Object Indentifier, OID).
A collection of related groups of objects is defined as a MIB module. These modules are written using a subset of Abstract Syntax Notation One, ASN.1) using OSI's abstract syntax tags. This subset is defined as a management information structure (SMI).
The message of SNMP is encoded for the message using the Basic Coding Rules (BER) when sending and transferring.
SNMP basic standard MIB library is MIBII, please refer to RFC 1213 for details.
SNMP protocol operation
SNMP provides three types of operations, which are GET, SET, and TRAP, respectively.
The GET operation implements a read operation of the management information represented by the managed object. In SNMPv1, there are two forms in the GET operation.
GET and GetNext Actions: The GET operation indicates 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 managed object represented by the OID specified by the operation parameter in the MIB tree in the MIB tree, according to the management information of the management information of the sequence of the dictionary. In SNMPv2, a getBulk operation is added, which is a comprehensive integrated GET and GetNext, which is increasing to increase access to the access to managed information. The SET operation implementation writes the management information of the managed object, which implements the setting of the value corresponding to the management information corresponding to the OID specified by the operating parameter.
The previous message is a variety of information that is sent to the managed device to get the managed device by active implementation of the management station to obtain the managed device; when the abnormality event in the managed device needs to report to the management station report, it is necessary to TRAP operation. This action implements an exception event that is managed on the management of the management workstation, such as faulty or recovery work, and device restarts, such as network interfaces. In addition, an Inform operation is added to the SNMPv2 to implement communication between the management station and the management station.
The above operations can specify one or more management object OID information at a time in the operational parameter, that is, a message can be implemented at a time.
SNMPv1 and SNMPv2c use a simple commonly used security mechanism:
The management station and the tube device are stored on the tangible function. The message sender (typically manager) fill in the common body name corresponding to the recipient in the Community Name field in the message to be sent, and then The apparent manner is sent on the network, and after receiving the message, if the message format is correct, read the field, compare the sympathy of the self-saving, to realize the authentication of the sender . In some implementations, there is a list of machine address list corresponding to each common name, which means that only messages sent by the address in this list is only trusted. The common name here serves as a password. At the same time, there is an access control permission corresponding to each common body name, and the value is read or read or written. Only the right to operate and the permissions of the common names used will only be permitted.
For details, please refer to RFC 1157, RFC 1902, RFC 2273, RFC 2274.
MRTG installation configuration
Install support software
We will discuss the configuration and installation of MRTG here with rehat7.2 as an example. To install MRTG, you need to install the following packages: GCC, Perl, GD, LIBPNG, and ZLIB. You can use the following command to determine if the system is installed with these 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 libl
LIBPNG-1.0.12-2
Libpng-debPPNG-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 which package is not installed, just install the corresponding RPM package directly from the RedHat installation disk, for example:
Root @ mail doc] # rpm -ivh zlib-1.1.3-24 zlib-wevel-1.1.3-24
MRTG installation
At present, 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 installed the MRTG system correctly.
Configure SNMP services
For different devices, configure SNMP support is inconsistent, please refer to the device's random document, generally introduce a detailed introduction. Here we discuss the configuration of the SNMP server in the Linux environment to achieve the analysis and report of the data of the flow of data (my application environment is using Linux to drive a small LAN to surveillance, monitor the native into and out of traffic).
It is easy to install the SNMP package in the Linux environment, just install the appropriate 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
At this time, run the following command:
[root @mail doc] # /etc/rc.d/init.d/snmpd start
Starting snmpd: [OK]
If the command output is as shown above, it means that the SNMP server starts normally.
In order to use the MRTG, also modify the configuration of the SNMPD to allow MRTG to read its interface traffic data.
Vi /etc/snmp/snmpd.conf
will
#view systemview include MIB2
The content is modified to:
View mib2 include .iso.org.dod.internet.mgmt.minb-2 fc
followed by
Access Notconfiggroup "Any Noauth Exact SystemView None None
change into:
Access notconfiggroup "Any Noauth Exact MIB2 NONE NONE
Then restart SNMPD:
/etc/rc.d/init.d/snmpd restart
Configure MRTG
The next step is to configure MRTG to implement monitoring of network devices. The MRTG configuration information is saved in the mrtg.cfg file, created the file and defines the desired monitoring characteristics. Fortunately, it is generally not necessary to manually edit the configuration file, because the MRTG package provides a cfgmaker configuration tool, which is a script file that automatically generates a MRTG.cfg configuration file according to the running parameter. You can get the tool in the bin subdirectory of the MRTG source directory.
First, create a subdirectory to store the MRTG generated in the documentroot directory of the WWW server, where the Apache is the default installation, so the DocumentRoot is in / var / www / html directory, we create a sub-directory MRTG in this directory:
MKDIR / VAR / WWW / HTML / MRTG
The / var / www / html / mrtg here is the working directory of the MRTG. Below you will generate a MRTG configuration file:
Cfgmaker - Global "Workdir: / VAR / WORKDIR: / MRTG"
--Global "options" [_]: growright, bits "
--Ifref = IP
--output /etc/mrtg.cfg
Public@192.168.0.1 Here -Global parameter indicates that the options of the following are the devices specified later (if you want to monitor multiple equipment, this parameter will act). Workdir is used to indicate the MRTG's working directory; Options is used to specify some specific options, and the GrowRight, bits is used to specify the default Options configuration. For common applications, the default Options configuration can meet the requirements. IFREF is used to indicate what option to identify the device interface, here specifying the use of IP addresses to identify network device interfaces. IFREF can be specified as NR, IP, Eth, DESCR, and NAME. NR represents the IFINDEX of the interface interface in the MIBII library; IP represents the use of an IP address identification interface; Eth represents the physical address identification interface of the interface; DESCR represents the use of the interface to identify the interface; NAME means using an interface name To identify the interface. Generally, IP addresses are unique, but in some cases, the interface is not IP address, such as the switch, there will be this situation. For interfaces, NR (interface number) is unique, so it is possible to use IP addresses for normal conditions, and for other cases, NR is required. "--output /etc/mrtg.cfg" ID stores the generated configuration file in / etc / directory. "public@192.168.0.1" means that the monitoring IP address is 192.168.0.1, using public as a common name to monitor device 192.168.0.1 through the SNMP protocol.
For situations where you want to use MRTG to monitor multiple devices, as follows:
Cfgmaker - Global "Workdir: / VAR / WORKDIR: / 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
Here is indicated to monitor four devices: router1.Place.xyz, router2.Place.xyz, switch1.Place.xyz
And Switch2.Place.xyz, all devices are monitored in common name public. And the two routers use DESCR as the description of the device, and the two switches use Alias as the device description (both of which, for example, for the Cisco router, for DESCR, the device is described as "serial0", and For AliaSL, "LINK TO HQ").
For my application environment, the generated mrtg.cfg content is as follows:
# Created by
# / usr / local / mrtg-2 / bin / cfgmaker - 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 Defaults
# 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 (configure /etc/snmp/snmp.local.conf)
# Location: unknown (edit /etc/snmp/snmpd.conf)
######################################################################################################################################################################################################################################################################################################## ####################
### interface 1 >> Descr: LO | NAME: | IP: 127.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:
# STENV [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]:
Traffic Analysis for 127.0.0.1 - 192.168.0.1
#
#
#
#
#
#
#
#
#
SYSTEM:
192.168.0.1 in unknown (edit /etc/snmp/snmpd.conf)
Maintainer:
Root
Description:
LO
IFTYPE:
Softwareeloopback (24)
IFNAME:
Max speed:
10.0 MBITS / S
IP:
127.0.0.1 (Localhost)
### interface 2 >> Descr: eth0 | Name: | IP: 211.99.43.111 | Eth:
Target [192.168.0.1_211.99.43.158:/211.99.43.158:0.1:
Stenv [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.158]: Traffic analyysis for 211.99.43.158 - 192.168.0.1pagetop [192.168.0.1_211.99.43.158]:
Traffic Analysis for 211.99.43.158 - - 192.168.0.1
SYSTEM:
192.168.0.1 in unknown (edit /etc/snmp/snmpd.conf)
Maintainer:
Root
Description:
Eth0
IFTYPE:
EthernetCSMACD (6)
IFNAME:
Max speed:
10.0 MBITS / S
IP:
211.99.43.158 (192.168.0.1)
### interface 3 >> Descr: Eth1 | Name: | IP: 192.168.0.1 | Eth:
Target [192.168.0.1]: /192.168.0.1: /192.168.0.1:Public@192.168.0.1:
STENV [192.168.0.1_192.168.0.1]: mRTG_INT_IP = "192.168.0.1" MRTG_INT_DESCR = "Eth1"
Maxbytes [192.168.0.1]: 1250000
Title [192.168.0.1]: Traffic analyysis for 192.168.0.1 - 192.168.0.1
PageTop [192.168.0.1_192.168.0.1]:
Traffic Analysis for 192.168.0.1 - 192.168.0.1
>
SYSTEM:
192.168.0.1 in unknown (edit /etc/snmp/snmpd.conf)
Maintainer:
Root
Description:
Eth1
IFTYPE:
EthernetCSMACD (6)
IFNAME:
Max speed:
10.0 MBITS / S
IP:
192.168.0.1 (192.168.0.1)
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 device and create an initial traffic map and web page in the working directory. The alarm message for the lost log file may be reported at the top three runtime. Do not pay attention to this, just need to run three times in succession. Will not produce alarm information. If there is still a warning, then you need to see if the problem is.
Using manual running MRTG does not regularly generate appropriate statistics, it is best to automatically run MRTG to generate statistics, and the default is five minutes. As the root identity crontab -e enters the editing state, the added content is as follows:
* / 5 * * * * / usr / local / mRTG-2 / bin / mrtg /etc/mrtg.cfg
