Abstract:
Publisher: NetBull Readings: 1424HTTP: //www.linuxByte.NET Introduction MRTG (Multi Router Traffic Grapher, MRTG) is a tool software that monitors network link traffic loads, which gets the traffic information of the device from the device via the SNMP protocol. The traffic load is displayed to the user in an HTML document that contains a graphic in the PNG format to display traffic load in a very intuitive form (you can get the output of MRTG). The result example). The most detailed information about MRTG can be obtained from http://people.ee.ethz.ch/mrtg/webtools/mrtg. MRTG has the following features: portability: 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 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. HPUX 9, 10, 11 WindowsNT 3.51, 4.0, 2K, XPirix 5.3, 6.2 BSDI BSD / OS 2.1, 4 .X, 3.1 NetBSD 1.5.x FreeBSD 2.x, 2.2.x, 3.1, 3.4, 4.0 SCO Open Server 5.0 Reliant UNIX NEXTSTEP 3.3 Openstep 4.2 Mac OSTEN X 10.1 And About and Other Sensible UNIX can be monitored by MRTG (most products in the current market support SNMP protocol, as long as the device supporting SNMP protocols can monitor using MRTG 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 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 350T, i nstant 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 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 OR EVEN 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 Wellfleet (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. Devices that do not support MRTG: D-Link Switches (Details) SNMP Introduction A network management system generally contains the following elements: 1 Several (possibly multiple) Managed network equipment nodes such as routers, servers, etc., running a application process called device agent (Agent) on each node, which realizes information such as traffic for various managed objects managed. Collection and support for access to these managed objects; 2 at least one management workstation, the management station runs the management platform application, implements the visual graphical interface of the managed device, so that the administrator can be convenient Performance; 3 A management protocol to define a procedure for managing 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 subprins, where SNMPv2c application is the most widely: SNMPv1: is the first formal protocol version, defined in RFC1155-RFC1158, which uses a safety mechanism based on common name; SNMPv2c: This version is called Based on SNMPv2 based on common, use a commonly brand-based security mechanism and SNMPv2P expansion by RFC1901-RFC1906; SNMPv3: This protocol version adopts user-based security mechanism, its security mechanism is in SNMPv2u and SNMPv2 * Based on a large number of reviews, it has been updated in the future, and good expansion is guaranteed by dividing the logical function module of the protocol, and is defined by RFC2271-RFC2275.
The principle of running the SNMP management system and the SNMP protocol uses the SNMP protocol network management system management structure. The management process generally includes the management process to send a query request message (in polling mode) to the device agent process of each device to track the status of each device. When the device has an exception event such as equipment cold start, the device agent 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. The management object library MIBMIB is a tree structure (defined method similar to the domain name system) according to the hierarchical organization, 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 a total of two forms of forms GET and GETNEXT operations in the GET operation: 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 safety mechanism based on common-gaps: the management station and the managed device are stored on the tangible device; the message sender (generally manager) is in the message to send In the Community Name, fill in the common name corresponding to the recipient, and then send a message on the network in a clear text, and after receiving the message, if the message format is correct, read the field, with It is compared to the common name of the self-saving to realize the authentication of the sending message. 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 Installation Support Software We are discussing 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: [root @ mail doc] # rpm -qa | grep gdgd-1.8.4-4GD-devel-1.8.4-4 [root @mail doc] # rpm -QA | grep perlperl-5.6.0-17mod_perl-1.24_01-3 [root @ mail doc] # rpm -qa | grep libplibpng-1.0.12-2libpng-design [root @ mail doc] # RPM -QA | GREP ZLIBZLIB-1.1.3-24ZLIB-Devel-1.1.3-24 [root @ mail doc] # rpm -qa | grep GCC GCC-2.96-98GCC-G77-2.96-98GCC-C - 2.96-98 If you find which package is not installed, just directly install the corresponding RPM package directly from the RedHat installation disk, for example: root @ mail doc] # rpm -ivh zlib-1.1.3-24 zlib-deb-1.1.3-24mrtg 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 to now we are correct The MRTG system is installed. Configuring SNMP services For different devices, configuring SNMP support methods is inconsistent, please refer to the random document of the device, in general, in detail. 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-7UCD-SNMP-UTILS- 4.2.1-7UCD-SNMP-DEVEL-4.2.1-7 Operation at this time: [Root @ mail doc] # /etc/rc.d/init.d/snmpd startstarting snmpd: [OK] If the command output 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 change the contents of #VIEW SYSTEMVIEW INCLUDED MIB2 to: view mib2 include .iso.dod.internet.mgmt.mib-2 fc then use Access NotconfigGroup "ANY Noauth Exact SystemView None None Modify to: Access Notconfiggroup "" Any NoAuth Exact Mib2 None None then restart SNMPD: /etc/rc.d/init.d/snmpd restart configuration MRTG Next 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 in the documentroot directory of the WWW server to store the statistics generated by MRTG, where Apache is installed by default, so DocumentRoot In / var / www / html directory, we create subdirectory MRTG in this directory: MKDIR / VAR / WWW / HTML / MRTG This / var / www / html / mrtg is the work directory of MRTG. Below, the MRTG configuration file is generated: cfgmaker - Global "Workdir: / var / www / html / mrtg" --global "options [_]: growright, bits" --IFREF = ip --output /etc/mrtg.cfg Public@192.168.0.1 The - Global parameter indicates that the options later are valid for the devices specified later (if you want to monitor multiple devices, 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 MRTG want to monitor multiple devices, examples: cfgmaker - 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 Here you indicate four devices: router1.Place.xyz, router2.Place.xyz, switch1.place.xyz and switch2.place.xyz, all devices are adopted Common names PUBLIC for monitoring. 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 the application environment here, 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 growth to the right # options [_]: growright, bitsworkdir: / var / www / html / mrtgoptions [_]: 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 folload 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.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 analyysis for 127.0.0.1 - 192.168.0.1 #### ##### System: 192.168.0.1 in unknown (edit /etc/snmp/snmpd.conf )maintainer :root
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]: 1250000Title [192.168.0.1_211.99.43.158 ]: Traffic Analysis 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.1System: 192.168.0.1 in Unknown (edit / etc / snmp / snmpd.conf) Maintainer: Root
