Shulou(Shulou.com)05/31 Report--

This article mainly explains "what are the Zabbix 3.0 monitoring network equipment". The content of the article is simple and clear, and it is easy to learn and understand. Please follow the editor's train of thought to study and learn "what are the Zabbix 3.0monitoring network equipment"?

Introduction to SNMP 1 Overview of SNMP

SNMP has become the most widely used network management protocol so far. At present, the main applied versions are SNMP v1, SNMP V2C and SNMP v3. The main differences between different versions are shown in the definition of information, the operation of communication protocols and security mechanisms. At the same time, there are two extended remote network monitoring RMON (Remote Network Monitoring) and RMON2 of SNMP applications.

From the point of view of the physical layer, using SNMP to manage the network should include: network management station (NMS), agent (Agent), proxy server (proxy). NMS can generate commands, receive notification messages, and have at least one NMS in network management. Agent can respond to the request of the management node, can also actively generate notification information, there can be one or more in network management. Proxy forwards SNMP requests and notification information between different networks or between different versions.

From the perspective of protocol layer, SNMP includes: SMI (Structure of Management Information, management information structure) and MIB (Management InformationBase, management information base). SMI is a subset of ASN.1 (Abstract SyntaxNotation one, abstract syntax tags). SMI specifies that elements in ASN.1, custom data types and macros can be used in SNMP. MIB in SNMP can be defined by these elements, data types, macros and other related syntax. MIB is an abstract description of manageable objects in Agent. In SNMP, MIB is organized to view in a tree structure. Each node in the tree is called OID (Object identifier, object identification). It is organized in a way similar to the domain name of a URL, representing each node with a certificate, such as 1.3.6.4.

SNMP is an application layer protocol belonging to TCP/IP protocol stack, which is similar to HTTP and FTP protocols. It's just that the SNMP transport layer uses the UDP protocol.

In SNMP v1, a simple authentication mode from NMS to Agent is provided-Community,NMS needs to provide a Community string when sending a request to Agent. After receiving the string, Agent needs to check whether it is consistent with the local one. Due to the use of plaintext to transmit Community, there are obvious security risks.

In 1996, IETF released SNMP v2C (Community-BasedSNMP v2), which defines the communication between management stations on the basis of v1. All of them support distributed network management, but the security mechanism is the same as that of v1.

In 1998, IETF released SNMP v3, which extends security (user-based security model and view-based access control model) and management mechanism based on SNMP v2. In terms of security, v3 version adds security parameters to the protocol message, which allows encrypted transmission and mandatory authentication of the message, which is a secure protocol. SNMP v3 defines each module of the protocol using the idea of modularization, improves the architecture of the protocol, and the most important thing is to maintain compatibility with SNMP v1 and SNMP v2.

2 functions of SNMP

Agent in SNMP is mainly responsible for uploading information. NMS not only has the level function of SNMP protocol, but also has the functions of logging, recording, managing and configuring the sent and received information, and can provide a graphical configuration and management interface.

In order to achieve these functions, SNMP contains a series of operation commands, including:

Read command: Get series of commands, NMS sends a request like Agent to collect management information.

Setting command: Set command, NMs writes the data carried in the message to Agent.

Alarm function: Trap series, Agent actively sends alarm / event messages to NMS.

Figure 13-1

1. Get operation

The Get operation is an active action initiated by NMS. The message not only carries the Get request flag, but also includes the OID name and value pair to be requested, and realizes the transmission of management object information in the binding form of this name and value pair. Of course, the corresponding value of OID in the Get operation is NILL.

2. Get-Next operation

The Get-Next operation is similar to the Get function, except that the information queried is not the OID information bound in the message but the next OID information of the object (if the next OID information is readable). For example, NMS wants to collect the information of the next node sysLocation of the sysName on the Agent side. It is sysName.0 in the request message, and the returned message binds sysLocation.0 and value.

3. Get-Bulk operation

It is actually a collection of multiple Get-Next operations, which is a new operation method added in SNMP v2.

4. Set operation

The Set operation is to set the parameters of the OID with writeable authority, and to realize the parameter management, configuration and control of the equipment. Unlike the Get operation binding variable, the Set needs to bind the value set by the corresponding OID.

5 、 Get-Response

Get-Response is a response to NMS's Get and Set commands. According to different commands and different parameters in the command, the corresponding information about variable binding and error status (indicating the success or failure of the command) is returned.

6. Trap series

Trap is a mechanism for Agent to actively report important events to NMS. For such reports, NMS does not need to respond to Agent. The content in the Trap message indicates when, where and what happened.

3 SMI and MIB

1 、 SMI

SMI is an information module defined by ASN.1 syntax in SNMP, which is a subset of ASN.1. These modules define many SNMP-specific macros, custom data types, rules, and so on. There are three main purposes of defining these macros, data types and rules: the first is to represent and define the unique data types in SNMP applications; the second is to simplify the definition of management objects; the third is to allocate object identifier space in SNMP and manage object coding. Based on these information modules defined in RFC documents, SNMP realizes the standardization of protocols and makes organizations, enterprises and individuals consistent in defining management objects.

In SNMP, two versions of SMI are actually defined, SMI v1 defined in RFC 1151 and SMI v2 defined in RFC 2578. SMI v1 simply defines several data types, rule descriptions, OBJECT- type macros, etc., while in SMI v2, it organizes all the related content in a modular way.

The underlying data types defined in SMI v1 are:

INTEGER: it's actually a 32-bit integer.

OCTET STRING:0 or more 8-bit characters (single bytes), which can represent either text characters or physical addresses. Values range from 0 to 65535.

OBJECT IDENTIFIER: OID in dotted decimal.

NULL: only defined in SMI v1, it is no longer used in SMI v2.

SEQUENCE: define the list.

SEQUENCE OF: define the table.

The scope restrictions and updates for the above data types are further clarified in SMI v2, and the BITS type is also introduced.

Custom data types in SMI v1 include:

NetworkAddress (network address), which can be a family of network addresses other than Internet

NetworkAddress:: = CHOICE {Internet IPAddress}

32-bit IP address, expressed in network byte order

IPAddress:: = [APPLICATION 0] IMPLICIT OCTET STRING (SIZE (4))

The Counter type value increases unidirectionally, and after reaching the maximum, it returns to 0 and starts counting again (it will also be reset to 0 after Agent restart), which is mainly used to count the number of bytes sent and received by the interface.

Counter:: = [APPLICATION 1] IMPLICIT INTEGER (0.. 4294967295)

The value of the Gauge type can be increased or decreased, and it can be kept at the maximum value when it reaches the maximum value. For example, the rate of the interface in the router can be expressed by this type.

Gauge:: = [APPLICATION 2] IMPLICIT INTEGER (0.. 4294967295)

TimeTicks is timed in 1% seconds, which represents the timing between two time points. Its timing benchmark is required to be stated in the description information.

TimeTicks:: = [APPLICATION 3] IMPLICIT INTEGER (0.. 4294967295)

Opaque encapsulates the encoded values of other ASN.1 types twice. For backward compatibility, this type is also defined in SMIv2 and is not recommended.

Opaque:: = [APPLICATION 4] IMPLICIT OCTET STRING

The custom data types in SMI v2 that change relative to SMI v1 are:

Gauge32 and Gauge are actually the same. In addition, Gauge32 and Unsigned32 share the same application type tag number, so their coding is actually the same.

Gauge32:: = [APPLICATION 2] IMPLICIT INTEGER (0.. 4294967295)

Unsigned32:: = [APPLICATION 2] IMPLICIT INTEGER (0.. 4294967295)

Counter64 is a wider range of Counter, with 64: 2 ^ 64-1 (0. 18446744073709551615). In the standard MIB module, it is only used when the counter is returned to zero in less than an hour when using Counter32.

Counter64:: = [APPLICATION6] IMPLICIT INTEGER (0. 18446744073709551615)

The IPAddress type is still retained in SMI v2, and there is no change. However, it does not apply to the 128th address of IPv6. A further explanation of Counter32: the current count value has a clear meaning only when there are initial values and recorded changes.

From the perspective of MIB, SMI is the charter that directly guides the definition of MIB, defines the data type and syntax of MIB, and allocates OID space to management objects in MIB.

2 、 MIB

MIB is a collection of management information, which is a structured text file written according to the agreed organization rules and definition syntax according to the requirements of business or network management standards.

The management object in each MIB should clearly describe all the properties of the object, including name, description, data type, etc. The contents of these attributes can be identified by both sides of the communication through the unique identifier OID of the object. In other words, MIB is the bridge between NMS and Agent. Only when Agent implements the MIB and NMS understands the MIB, can the two correctly cooperate to achieve the corresponding management functions. After importing MIB into NMS, NMS can know all the details of the object to be managed. After implementing the management object defined in MIB in Agent, it shows that the Agent supports the MIB.

An Agent can implement multiple MIB, each MIB can contain more or less management objects, there are no clear requirements. MIB mainly consists of two parts, one is the standard management object defined by the International Organization for Standardization, including MIB-I (RFC1156) and MIB-II (RFC1213). Some general and basic management objects are defined in the standard MIB, which are supported by all devices on the network. The other part is the private MIB customized by major manufacturers, organizations or individuals. These private MIB are customized by manufacturers according to the needs of device management, which are not available in the standard MIB. Private MIB is defined under node enterprises (1.3.6.1.4.1).

The standard MIB divides the managed objects into 10 groups, that is, 10 branches in the MIB tree. They are: System, Interfaces, AT (Address Translation with a status of deprecated, indicating that the next version is no longer used), IP, ICMP, TCP, UDP, EGP, Transmission, SNMP, whose parent node is 1.3.6.1.2.1 (mib-2). The management objects in these 10 groups are one of the most important parts of network management.

System group: mainly used to describe Agent system-level information. Including sysName, sysLocation, sysDescr, sysServices, sysUpTime, sysContact, sysObjectID and so on. These OID provide the name, location, online time and other information of the device, which is very important in network management. In the actual environment, these information can not be updated in time, so it is easy to be ignored.

Interfaces group: this group is used to provide all the interface information of network devices. It includes interface type, interface description, interface rate, interface status and so on.

AT group: that is, address translation group. This set of time is a table object, which realizes the mapping from network address to physical address. Iterate through the table to get the correspondence between the IP address and the MAC address.

IP group: a management object that defines information related to the IP layer. These objects involve IP packet objects, error messages, address information, routing information, and address mapping information.

ICMP group: this group defines 26 scalar objects that describe the sending and receiving of various ICMP messages, all of which are of Counter type. Through these objects, it is easy to get the rate of sending and receiving messages and the rate of various message types (request, response) of ICMP.

TCP group: this group mainly includes: the TCP retransmission policy for configuration management, the objects with the longest and shortest retransmission time, the number of requests rejected by links for performance management, the number of TCP communication state transfer records, the total number of retransmissions, the total number of receiving errors, etc., the technical objects of sending and receiving TCP data segments that may be used for billing management, and tcpConnTable table objects that may be used for security management. Trace suspicious links from the remote end by analyzing the remote IP, port number, status, and other information recorded by the table.

UDP group: this group includes counting objects for receiving and sending UDP packets, error report counting objects, and related information such as ports and IP addresses that can be used for performance and billing management.

EGP (Exterior Gateway Protocol, exterior Gateway Protocol) group: EGP is a protocol used to exchange routing information between autonomous systems (neighbors). The group includes the egpNeighTable table object of all kinds of information such as the neighbor running status of the user failure management, the domain number of the local autonomous system managed by the user configuration, the rate of EGP messages entering and leaving the local entity for performance management, and the error counting object.

Transmission group: the function of this group is to provide corresponding management information according to different transmission media. This group is special. There is no clearly defined management object under this branch in MIB-II, but the corresponding interface type is added to the group when a transport medium needs to be managed.

SNMP group: this group defines objects that describe SNMP in detail. For example, the statistics of the number of different types of errors that can be used for fault management, whether the Trap authentication failure can be used for configuration management to generate messages, and the statistics of the number of various messages that can be sent and received for performance management.

4 OID tree

In SNMP, all the management objects are organized by a tree structure, and the management objects are embodied as the nodes in the tree, which is maintained and managed by the relevant international standardization organizations. Through this structured and hierarchical organization, it is very convenient for the management and expansion of objects. This kind of management and expansion is reflected in the allocation of nodes.

For example, enterprises, organizations or individuals can apply for nodes to the international organization responsible for managing and assigning nodes as a branch of the tree. When a node is successfully applied, other nodes can be allocated freely under the branch to meet the needs of its monitoring or management business.

OID number, also known as MIB number. MIB is actually a module of ASN.1 composed of OID, which is embodied as a tree structure in reality. There are many standard MIB,SNMP in Internet that define MIB-I, MIB-II, etc., as well as MIB defined by enterprises, organizations, and individuals. This is shown in the following figure.

In the OID tree, only the top root node does not have a specific number, so it can be regarded as a virtual node, and the other nodes have a unique number in the same layer to make a distinction.

The next layer node at the top level is ccitt (0) managed by CCITT (that is, the current ITU-T) and ISO (1) managed by ISO.

There are many child nodes under the internet node, which are reserved by directory (1) and may be used for OSI directory services in the future. Mgmt (2) is taken care of by IAB and is used to define the standard management objects in RFC, which are actually MIB-I and MIB-II. Experimental (3) is also managed by IAB and is used to define the management objects of internet experimental nature. Private (4) and subordinate node enterprises (1) are assigned and managed by IANA, which is mainly used for allocation to enterprises or organizations under enterprises (1) node.

The OID tree structure is shown in figure 13-2 below.

Figure 13-2

Configure the SNMP1 data type in Zabbix

You will find the data types defined in SNMP in RFC 2578. Relative to these data types, when configuring monitoring options in Zabbix, it is recommended that the Type ofinformation and Store value options be configured as shown in the table below.

SNMP Typ

Description

Recommended monitoring item options in Zabbix

INTEGER

Signed 32 is an integer

Numeric Unsigned,decimal

Store value: as is

Show value mappings

STRING

Any binary or text data, which can be multiple lines

Text

Store value: as is

OID

SNMP Object Identifier, expressed in dotted decimal

Character

Store value:as is

IPAddress

IPv4 address

Character

Store value:as is

Counter32

The value of one-way growth (0. 4294967295), after reaching the maximum, return to 0 and start counting again

Numeric Unsigned,decimal

Store value:delta (speed per second)

Gauge32

The value can be increased or decreased (0. 4294967295), keep it at the maximum when it reaches the maximum

Numeric Unsigned,decimal

Store value:as is

Counter64

The value of one-way growth, after reaching the maximum, return to 0 and start counting again (0. 18446744073709551615)

Numeric Unsigned,decimal

Store value:delta (speed per second)

TimeTicks

Unsigned integer, 2 ^ 32 modulo (4294967296), 1% seconds between two values

Numeric Unsigned,decimal

Store value:as is

2 Discovery OID

Before using SNMP to monitor devices in Zabbix, you need to determine the OID value and data type corresponding to the monitoring item. In addition to the standard MIB and OID, you need to consult the equipment manufacturer to quickly and accurately find the OID values that need to be monitored through the manufacturer's documentation and MIB library files.

You can use some graphical tools such as MG-SOFT MIB Browser to import the MIB file and query the device information in the graphical interface, as shown in figure 13-3 below.

Figure 13-3

Using graphical tools can help us quickly browse, query and determine the OID types and values of monitoring items.

You can also use the snmpwalk tool to query directly from the device. Before using snmpwalk, make sure whether it has been installed on the system. If not, you can install it using the following command:

# yum install net-snmp-utils

Execute snmpwalk to query device information.

# snmpwalk-v 2c-c public 10.60.0.19 1.3.6.1.2.1.1

SNMPv2-MIB::sysDescr.0 = STRING: Cisco IOS Software, ME380x Software (ME380x-UNIVERSALK9-M), Version 15.4 (3) S2, RELEASE SOFTWARE (fc1)

Technical Support: http://www.cisco.com/techsupport

Copyright (c) 1986-2015 by Cisco Systems, Inc.

Compiled Wed 28-Jan-15 11:43 by prod_rel_team

SNMPv2-MIB::sysObjectID.0 = OID: SNMPv2-SMI::enterprises.9.1.1252

DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks: (2030697335) 235days, 049 235days 33.35

SNMPv2-MIB::sysContact.0 = STRING:

SNMPv2-MIB::sysName.0 = STRING: XZX-3800

SNMPv2-MIB::sysLocation.0 = STRING:

SNMPv2-MIB::sysServices.0 = INTEGER: 6

SNMPv2-MIB::sysORLastChange.0 = Timeticks: (0) 0VOULARO 00.00

You can also output the digital path corresponding to OID:

# snmpwalk-v 2c-On-c public 10.60.0.19 1.3.6.1.2.1.1

.1.3.6.1.2.1.1.1.0 = STRING: Cisco IOS Software, ME380x Software (ME380x-UNIVERSALK9-M), Version 15.4 (3) S2, RELEASE SOFTWARE (fc1)

Technical Support: http://www.cisco.com/techsupport

Copyright (c) 1986-2015 by Cisco Systems, Inc.

Compiled Wed 28-Jan-15 11:43 by prod_rel_team

.1.3.6.1.2.1.1.2.0 = OID: .1.3.6.1.4.1.9.1.1252

.1.3.6.1.2.1.1.3.0 = Timeticks: (2030720756) 235 days, 0virtual 53

.1.3.6.1.2.1.1.4.0 = STRING:

.1.3.6.1.2.1.1.5.0 = STRING: XZX-3800

.1.3.6.1.2.1.1.6.0 = STRING:

.1.3.6.1.2.1.1.7.0 = INTEGER: 6

.1.3.6.1.2.1.1.8.0 = Timeticks: (0) 00.00

The OID is displayed differently in the result due to the different parameters specified by the above snmpwalk execution. No matter how it is displayed, the result consists of three parts: OID, data type, and return value. For example, the device name is displayed as follows:

SNMPv2-MIB::sysName.0 = STRING: XZX-3800

.1.3.6.1.2.1.1.5.0 = STRING: XZX-3800

Although the content displayed is the same, all are the return values of sysName, but the expression of OID is different. When defining items in Zabbix, some of the most commonly used OID in SNMP OID configuration parameters can use OID names, and Zabbix will automatically convert some of the most commonly used SNMP OID into numbers, for example, SNMPv2-MIB::sysName.0 will be converted to 1.3.6.1.2.1.1.5.0. However, the OID of an enterprise private MIB can only use an all-digital path. The OID that can be automatically converted in Zabbix is shown in Table 13-1 below.

Table 13-1

Special OID

Identifier

Description

IfIndex

1.3.6.1.2.1.2.2.1.1

Port index

IfDescr

1.3.6.1.2.1.2.2.1.2

Port description

IfType

1.3.6.1.2.1.2.2.1.3

Port Typ

IfMtu

1.3.6.1.2.1.2.2.1.4

Maximum number of bytes of transmission packets on the port

IfSpeed

1.3.6.1.2.1.2.2.1.5

Port speed

IfPhysAddress

1.3.6.1.2.1.2.2.1.6

Port physical address

IfAdminStatus

1.3.6.1.2.1.2.2.1.7

Port Management statu

IfOperStatus

1.3.6.1.2.1.2.2.1.8

Port operation statu

IfInOctets

1.3.6.1.2.1.2.2.1.10

Port received byte

IfInUcastPkts

1.3.6.1.2.1.2.2.1.11

Number of non-broadcast packets received by the port

IfInNUcastPkts

1.3.6.1.2.1.2.2.1.12

Number of broadcast packets received by the port

IfInDiscards

1.3.6.1.2.1.2.2.1.13

Number of packets dropped received by the port

IfInErrors

1.3.6.1.2.1.2.2.1.14

Number of errors received by the port

IfInUnknownProtos

1.3.6.1.2.1.2.2.1.15

Number of unknown protocol packets received by the port

IfOutOctets

1.3.6.1.2.1.2.2.1.16

Number of bytes sent by port

IfOutUcastPkts

1.3.6.1.2.1.2.2.1.17

Number of non-broadcast packets sent by the port

IfOutNUcastPkts

1.3.6.1.2.1.2.2.1.18

Number of broadcast packets sent by the port

IfOutDiscards

1.3.6.1.2.1.2.2.1.19

Number of packets dropped sent by the port

IfOutErrors

1.3.6.1.2.1.2.2.1.20

Number of errors that the port sends packets

IfOutQLen

1.3.6.1.2.1.2.2.1.21

Port send queue length

3 configure SNMP

Before you start configuring SNMP in Zabbix, make sure that Zabbix server has turned on SNMP monitoring. When Zabbixserver starts, a list of Zabbixserver features is listed in the log file, as follows:

911:20160218:103649.120 Starting Zabbix Server. Zabbix 3.0.1 (revision58734).

911Rom 20160218Rose 103649.160 * Enabled features *

911:20160218:103649.160 SNMPmonitoring: YES

911:20160218:103649.160 IPMI monitoring: YES

911:20160218:103649.160 Web monitoring: YES

911:20160218:103649.160 VMware monitoring: YES

911:20160218:103649.160 SMTP authentication: YES

911:20160218:103649.160 Jabber notifications: YES

911:20160218:103649.160 Ez Texting notifications: YES

911:20160218:103649.160 ODBC: YES

911:20160218:103649.160 SSH2 support: YES

911:20160218:103649.160 IPv6 support: YES

911:20160218:103649.160 TLS support: YES

911Rom 20160218Rose 103649.160 * *

911:20160218:103649.160 using configuration file:/etc/zabbix/zabbix_server.conf

If you do not find SNMP monitoring enabled information, then you need to install Zabbixserver, if you use the source code compilation installation, you need to use the compilation configuration option-with-net-snmp.

Only UDP protocol is used for SNMP monitoring in Zabbix, and multiple values can be queried in a single request, whether it is regular SNMPitems, dynamic indexes (dynamic index) SNMPitems, or SNMPlow-level discovery rules, which can provide efficiency when dealing with a large number of SNMP. Allow or disable bulk queries by setting the host's SNMP Interfaces option Use bulkrequests. Figure 13-4 below shows.

Figure 13-4

All SNMP monitoring items with the same parameters in a single interface are queried at the same time at a set time interval. For regular SNMPitems and dynamic indexes SNMPitems, pollers processes 128monitoring items at the same time, while SNMP low-leveldiscovery rules processes them separately. There are two types of operations completed during query: collecting multiple specified objects and traversing the OID tree. Collection means that a GetRequest-PDU can bind up to 128variables, and traversal refers to the use of GetNextRequest-PDU,SNMP v2 or SNMP v3 in GetNextRequest-PDU,SNMP v2 or SNMP v3 in GetBulkRequest with max-repetitions fields, and up to 128variables can be bound.

Therefore, batch processing of each SNMP monitor item has the following benefits:

The performance of regular SNMP monitoring items collecting data has been improved.

The performance of Dynamic indexes (dynamic index) SNMP monitoring items in collecting and traversing data has been improved.

The performance of SNMP low-level discovery rules traversing data has been improved.

But technically, not all devices can return 128values per request, some devices can return some response values, some devices return an error code tooBig (1) or no response at all. In order to determine the optimal number of objects to query the device, Zabbix uses some strategies to initially query only one value in the query request, if it is successful to query 2 values in the query request, if it is successful to query 3 values in the query request, and continue to query the same number of objects multiplied by 1.5. The order by number of queries is: 1, 2, 3, 4, 6, 9, 13, 19, 28, 42, 63, 94, 128. When the device refuses to return the correct response (such as querying 42 variables), Zabbix or do two things:

Currently, the item of batch queries is halved, that is, 21 variables are queried. If the device returns a normal value, then there should be no problem in most cases, because we know that there is no problem querying 28 variables, 21 should be significantly less than 28. If the item still does not return a normal value after halving, then roll back the number of variables in the query one by one until the normal return value.

Zabbix queries subsequent queries with the number of variables that were successful in the last query (our example is 28) and continues to increase the number of query variables requested (1 at a time) until the upper limit is reached. For example, suppose the maximum response is 32 variables. Subsequent requests will be queried by 29, 30, 31, 32, and 33, preferably one request will fail (33 variables), and Zabbix will never issue another request to bind 33 variables. Zabbix's SNMP query binds up to 32 variables on this device.

When Zabbix server or proxy server receives an incorrect SNMP response, something similar to the following is added to the log file:

SNMP responsefrom host "gateway" does not contain all of the requested variablebindings

Although this information does not cover all problematic situations, at least one thing is that the option Use bulk requests in the host's SNMP interface should be disabled.

4 configure general SNMP monitoring items

When using SNMP to monitor devices, regular SNMP monitoring items can be configured as follows:

1. Create the host and add SNMP Interfaces. You can use the Template SNMP Generic template provided in Zabbix to automatically add monitoring items that collect basic information about the device.

2. Determine the OID for monitoring.

Find and determine the OID that needs to be monitored through MIB Browser or snmpwalk, for example, we want to monitor the traffic of a switched gigabit port, and the index of looking up the GigabitEthernet0/1 interface through snmpwalk is 10101.

# snmpwalk-v 2c-c public 10.60.0.19 IF-MIB::ifDescr

IF-MIB::ifDescr.10101 = STRING: GigabitEthernet0/1

IF-MIB::ifDescr.10102 = STRING: GigabitEthernet0/2

IF-MIB::ifDescr.10103 = STRING: GigabitEthernet0/3

IF-MIB::ifDescr.10104 = STRING: GigabitEthernet0/4

IF-MIB::ifDescr.10105 = STRING: GigabitEthernet0/5

IF-MIB::ifDescr.10106 = STRING: GigabitEthernet0/6

IF-MIB::ifDescr.10107 = STRING: GigabitEthernet0/7

...

The OID that obtains the egress traffic of the GigabitEthernet0/1 interface is .1.3.6.1.2.2.2.1.16.10101.

# snmpwalk-v 2c-On-c qhdpublic 10.60.0.19IF-MIB::ifOutOctets.10101

.1.3.6.1.2.2.2.1.16.10101 = Counter32: 3619738552

3. Create a monitoring item and use SNMPv2 agent monitoring method. The SNMP OID is .1.3.6.1.2.2.2.1.16.10101.

5 configure dynamic index SNMP monitoring items

In the OID tree of a device, the OID of some management objects often uses index, such as the network interface, which uses the same index to associate to different objects of the network interface. Just like the snmpwalk output below.

# snmpwalk-v 2c-c public 10.60.0.19 .1.3.6.1.2.1.2.2.1

IF-MIB::ifIndex.1 = INTEGER: 1

IF-MIB::ifIndex.5001 = INTEGER: 5001

IF-MIB::ifIndex.5002 = INTEGER: 5002

IF-MIB::ifIndex.5003 = INTEGER: 5003

IF-MIB::ifIndex.10101 = INTEGER: 10101

IF-MIB::ifIndex.10102 = INTEGER: 10102

...

IF-MIB::ifDescr.1 = STRING: Vlan1

IF-MIB::ifDescr.5001 = STRING: Port-channel1

IF-MIB::ifDescr.5002 = STRING: Port-channel2

IF-MIB::ifDescr.5003 = STRING: Port-channel3

IF-MIB::ifDescr.10101 = STRING: GigabitEthernet0/1

IF-MIB::ifDescr.10102 = STRING: GigabitEthernet0/2

...

IF-MIB::ifType.1 = INTEGER: propVirtual (53)

IF-MIB::ifType.5001 = INTEGER: propVirtual (53)

IF-MIB::ifType.5002 = INTEGER: propVirtual (53)

IF-MIB::ifType.5003 = INTEGER: propVirtual (53)

IF-MIB::ifType.10101 = INTEGER: ethernetCsmacd (6)

IF-MIB::ifType.10102 = INTEGER: ethernetCsmacd (6)

...

IF-MIB::ifMtu.1 = INTEGER: 1500

IF-MIB::ifMtu.5001 = INTEGER: 1500

IF-MIB::ifMtu.5002 = INTEGER: 1500

IF-MIB::ifMtu.5003 = INTEGER: 1500

IF-MIB::ifMtu.10101 = INTEGER: 1500

IF-MIB::ifMtu.10102 = INTEGER: 1500

...

IF-MIB::ifSpeed.1 = Gauge32: 1000000000

IF-MIB::ifSpeed.5001 = Gauge32: 2000000000

IF-MIB::ifSpeed.5002 = Gauge32: 2000000000

IF-MIB::ifSpeed.5003 = Gauge32: 1000000000

IF-MIB::ifSpeed.10101 = Gauge32: 1000000000

IF-MIB::ifSpeed.10102 = Gauge32: 1000000000

...

IF-MIB::ifPhysAddress.1 = STRING: b0:7d:47:be:ea:c0

IF-MIB::ifPhysAddress.5001 = STRING: b0:7d:47:be:ea:c2

IF-MIB::ifPhysAddress.5002 = STRING: b0:7d:47:be:ea:c3

IF-MIB::ifPhysAddress.5003 = STRING: b0:7d:47:be:ea:c4

IF-MIB::ifPhysAddress.10101 = STRING: b0:7d:47:be:ea:c2

IF-MIB::ifPhysAddress.10102 = STRING: b0:7d:47:be:ea:c3

...

IF-MIB::ifAdminStatus.1 = INTEGER: down (2)

IF-MIB::ifAdminStatus.5001 = INTEGER: up (1)

IF-MIB::ifAdminStatus.5002 = INTEGER: up (1)

IF-MIB::ifAdminStatus.5003 = INTEGER: up (1)

IF-MIB::ifAdminStatus.10101 = INTEGER: up (1)

IF-MIB::ifAdminStatus.10102 = INTEGER: up (1)

...

From the above data, you can see that each network interface has a lot of OID, and each OID represents different indicators of the network interface, such as interface name, type, physical address, and so on. You will find that different OID are all connected by the same index. For example, the name of the first gigabit interface is GigabitEthernet0/1, the physical address is b0:7d:47:be:ea:c2, the status is up (1), and its index is 10101.

To monitor different metrics of the same network interface, you can create different monitoring items and enter the completed OID in the SNMP OID field. There is no problem with this approach, but there will be some problems with using index in the real world, because index will change due to software or hardware upgrades, resulting in inconsistent configuration. To solve this problem, Zabbix provides a method of dynamic indexing, which does not affect the monitoring of monitoring items even if the index value changes.

The syntax for using dynamic indexes SNMP OID is as follows:

["index", "", "]

The meanings of the parts of the grammar are as follows:

The OID defined in OID of data:item that needs to be queried.

Index: the method of processing, which is currently only supported. Index means to search for index and append it to OID.

Base OID of index: the OID will be followed to find its corresponding index value.

String to search for: use this string to match when looking up, case-sensitive.

For example, if you want to monitor the ifInOctets of the GigabitEthernet0/1 interface, it can be defined as:

IfInOctets ["index", "ifDescr", "GigabitEthernet0/1"]

It can be understood as matching to find the GigabitEthernet0/1 interface in ifDescr, and or the interface index value in ifDescr, and then append the collected index value to the end of ifInOctets to collect the ifInOctets value of the GigabitEthernet0/1 interface.

When using dynamic indexes, Zabbix will receive and cache the entire SNMP table of the index OID, and the OID of the index can be quickly found through the cache. If other monitoring items query the same index OID in the future, it is directly from the cache, and there is no need to query the monitoring host.

Then, when receiving the data of the monitoring item, it will verify whether the index has changed. If the index does not send the change, it will continue to use this value query. If the index sends the change, Zabbix will rebuild the cache, and each poller will traverse the SNMP table of the index OID again.

In Zabbix, each poller process has its own cache.

6 configure SNMP low-level discovery rules

When creating discovery rules for SNMP OIDs, unlike those that define file systems or network interfaces, you can use SNMP agnet monitoring instead of snmp.discovery Key. Define the OIDs to be discovered in the SNMPOID field in the format of discovery [{# MACRO1}, oid1, {# MACRO2}, oid2, … ,] .

{# MACRO1}, {# MACRO2}... Are all valid macro variable names, oid1, oid2... The value used to generate the macro variable. In discovery, the system sets up a macro variable named {# SNMPINDEX} by default, which is used to establish an index for discovery OID. The found results are grouped with {# SNMPINDEX}.

The following examples can help you understand better. First use snmpwalk to collect relevant data from the switch.

# snmpwalk-v 2c-OT-c public 10.60.0.19 IF-MIB::ifDescr

IF-MIB::ifDescr.1 = STRING: Vlan1

IF-MIB::ifDescr.10101 = STRING: GigabitEthernet0/1

IF-MIB::ifDescr.10102 = STRING: GigabitEthernet0/2

IF-MIB::ifDescr.10103 = STRING: GigabitEthernet0/3

# snmpwalk-v 2c-OT-c public 10.60.0.19 IF-MIB::ifPhysAddress

IF-MIB::ifPhysAddress.1 = STRING: b0:7d:47:be:ea:c0

IF-MIB::ifPhysAddress.10101 = STRING: b0:7d:47:be:ea:c2

IF-MIB::ifPhysAddress.10102 = STRING: b0:7d:47:be:ea:c3

IF-MIB::ifPhysAddress.10103 = STRING: b0:7d:47:be:ea:c4

Then enter in the SNMP OID field when creating the discovery rule:

Discovery [{# IFDESCR}, ifDescr, {# IFPHYSADDRESS}, ifPhysAddress]

After running the discovery rule, you get the following results:

{

"data": [

{

"{# SNMPINDEX}": "1"

"{# IFDESCR}": "Vlan1"

"{# IFPHYSADDRESS}": "b0:7d:47:be:ea:c0"

}

{

"{# SNMPINDEX}": "2"

"{# IFDESCR}": "GigabitEthernet0/1"

"{# IFPHYSADDRESS}": "b0:7d:47:be:ea:c2"

}

{

"{# SNMPINDEX}": "3"

"{# IFDESCR}": "GigabitEthernet0/2"

"{# IFPHYSADDRESS}": "b0:7d:47:be:ea:c3"

}

{

"{# SNMPINDEX}": "4"

"{# IFDESCR}": "GigabitEthernet0/3"

"{# IFPHYSADDRESS}": "b0:7d:47:be:ea:c4"

}

]

}

If the specified OID does not return a value, the corresponding macro is ignored in the discovery results, as in the following example.

The hypothetical data are as follows:

IfDescr.1 "Interface # 1"

IfDescr.2 "Interface # 2"

IfDescr.4 "Interface # 4"

IfAlias.1 "eth0"

IfAlias.2 "eth2"

IfAlias.3 "eth3"

IfAlias.5 "eth5"

Then enter in the SNMP OID field when creating the discovery rule:

Discovery [{# IFDESCR}, ifDescr, {# IFALIAS}, ifAlias]

After running the discovery rule, you get the following results:

{

"data": [

{

"{# SNMPINDEX}": 1

"{# IFDESCR}": "Interface # 1"

"{# IFALIAS}": "eth0"

}

{

"{# SNMPINDEX}": 2

"{# IFDESCR}": "Interface # 2"

"{# IFALIAS}": "eth2"

}

{

"{# SNMPINDEX}": 3

"{# IFALIAS}": "eth3"

}

{

"{# SNMPINDEX}": 4

"{# IFDESCR}": "Interface # 4"

}

{

"{# SNMPINDEX}": 5

"{# IFALIAS}": "eth5"

}

]

}

To give a practical example, first create a discovery rule, as shown in figure 13-5 below.

Figure 13-5

Create an item prototype based on the defined discovery rules, as shown in figure 13-6 below.

Figure 13-6

Multiple item prototypes can be created, as shown in figure 13-7 below.

Figure 13-7

Thank you for your reading, the above is the content of "what are the Zabbix 3.0 monitoring network equipment". After the study of this article, I believe you have a deeper understanding of what the Zabbix 3.0 monitoring network equipment has, and the specific use needs to be verified in practice. Here is, the editor will push for you more related knowledge points of the article, welcome to follow!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.