Cumulus Linux uses the open source Net-SNMP agent
snmpd, version 5.7, which provides support for most of the common industry-wide MIBs, including interface counters and TCP/UDP IP stack data.
SNMP is an IETF standards-based network management architecture and protocol that traces its roots back to Carnegie-Mellon University in 1982. Since then, it has been modified by programmers at the University of California. In 1995, this code was also made publicly available as the UCD project. After that,
ucd-snmp was extended by work done at the University of Liverpool as well as later in Denmark. In late 2000, the project name changed to
net-snmp and became a fully-fledged collaborative open source project. The version used by Cumulus Networks is based on the latest
net-snmp 5.7 branch with added custom MIBs and pass-through and pass-persist scripts (see below for more information on pass persist scripts).
Introduction to Simple Network Management Protocol
SNMP Management servers gather information from different systems in a consistent manner and the paths to the relevant information are standardized in IETF RFCs. SNMPs longevity is due to the fact that it standardizes the objects collected from devices, the protocol used for transport, and architecture of the management systems. The most widely used, and most insecure, versions of SNMP are versions 1 and 2c and their popularity is largely due to implementations that have been in use for decades. SNMP version 3 is the recommended version because of its advanced security features. In general, a network being profiled by SNMP Management Stations mainly consist of devices containing SNMP agents. The agent running on Cumulus Linux switches and routers is the snmpd daemon.
An SNMP Network Management System (NMS) is a computer that is configured to poll SNMP agents (in this case, Cumulus Linux switches and routers) to gather information and present it. This manager can be any machine that can send query requests to SNMP agents with the correct credentials. This NMS can be a large set of monitoring suite or as simple as some scripts that collect and display data. The managers generally poll the agents and the agents respond with the data. There are a variety of polling command-line tools (snmpget, snmpgetnext, snmpwalk, snmpbulkget, snmpbulkwalk, and so on). SNMP agents can also send unsolicited Traps/Inform messages to the SNMP Manager based on predefined criteria (like link changes).
The SNMP agents (
snmpd) running on the switches do the bulk of the work and are responsible for gathering information about the local system and storing data in a format that can be queried updating an internal database called the management information base, or MIB. The MIB is a standardized, hierarchical structure that stores information that can be queried. Parts of the MIB tree are available and provided to incoming requests originating from an NMS host that has authenticated with the correct credentials. You can configure the Cumulus Linux switch with usernames and credentials to provide authenticated and encrypted responses to NMS requests. The
snmpd agent can also proxy requests and act as a master agent to sub-agents running on other daemons (FRR, LLDP).
Management Information Base (MIB)
The MIB is a database that is implemented on the daemon (or agent) and follows IETF RFC standards to which the manager and agents adhere. It is a hierarchical structure that, in many areas, is globally standardized, but also flexible enough to allow vendor-specific additions. Cumulus Networks implements a number of custom enterprise MIB tables and these are defined in text files located on the switch and in files named
/usr/share/snmp/mibs/Cumulus*. The MIB structure is best understood as a top-down hierarchical tree. Each branch that forks off is labeled with both an identifying number (starting with 1) and an identifying string that is unique for that level of the hierarchy. These strings and numbers can be used interchangeably. A specific node of the tree can be traced from the unnamed root of the tree to the node in question. The parent IDs (numbers or strings) are strung together, starting with the most general to form an address for the MIB Object. Each junction in the hierarchy is represented by a dot in this notation so that the address ends up being a series of ID strings or numbers separated by dots. This entire address is known as an object identifier (OID).
Hardware vendors that embed SNMP agents in their devices sometimes implement custom branches with their own fields and data points. However, there are standard MIB branches that are well defined and can be used by any device. The standard branches discussed here are all under the same parent branch structure. This branch defines information that adheres to the MIB-2 specification, which is a revised standard for compliant devices. You can use various online and command-line tools to translate between numbers and string and to also provide definitions for the various MIB Objects. For example, you can view the
sysLocation object in the system table with either a string of numbers 220.127.116.11.18.104.22.168 or the string representation iso.org.dod.internet.mgmt.mib-2.system.sysLocation. You can view the definition with the snmptranslate (1) command (found in the snmp Debian package).
iso.org.dod.internet is the OID that defines internet resources. The
mgmt that follows is for a management subcategory. The
mib-2 under that defines the MIB-2 specification. And finally, the 1 or system is the parent for a number of child objects (sysDescr, sysObjectID, sysUpTime, sysContact, sysName, sysLocation, sysServices, and so on).
The simplest use case for using SNMP consists of creating a readonly community password and enabling a listening address for the loopback address (this is the default listening-address provided). This allows for testing functionality of
snmpd before extending the listening addresses to IP addresses reachable from outside the switch or router. This first sample configuration adds a listening address on the loopback interface (this is not a change from the default so we get a message stating that the configuration has not changed), sets a simple community password (SNMPv2) for testing, changes the system-name object in the system table, commits the change, checks the status of
snmpd, and gets the first MIB object in the system table:
cumulus@router1:~$ net add snmp-server listening-address localhost
Configuration has not changed
cumulus@router1:~$ net add snmp-server readonly-community mynotsosecretpassword access any
cumulus@router1:~$ net add snmp-server system-name my little router
cumulus@router1:~$ net commit
cumulus@router1:~$ net show snmp-server status
Simple Network Management Protocol (SNMP) Daemon.
Current Status active (running)
Reload Status enabled
Listening IP Addresses localhost
Main snmpd PID 13669
Version 1 and 2c Community String Configured
Version 3 Usernames Not Configured
cumulus@router1:~$ snmpgetnext -v 2c -c mynotsosecretpassword localhost SNMPv2-MIB::sysName
SNMPv2-MIB::sysName.0 = STRING: my little router
For external SNMP NMS systems to poll Cumulus Linux switches and routers, you must configure the SNMP agent (snmpd) running on the switch with one or more IP addresses (with
net add snmp-server listening-address <ip>) on which the agent listens. You must configure these IP addresses on interfaces that have link state UP. By default, the SNMP configuration has a listening address of localhost (or 127.0.0.1), which allows the daemon to respond to SNMP requests originating on the switch itself. This is a useful method of checking the configuration for SNMP without exposing the switch to attacks from the outside. The only other required configuration is a readonly community password (configured with
net add snmp-server readonly-community <password> access <ip | any>
), that allows polling of the various MIB objects on the device itself. SNMPv3 is recommended since SNMPv2c (with a community string) exposes the password in the
GetResponse packets. SNMPv3 does not expose the username passwords and has the option of encrypting the packet contents.
Cumulus Linux 3.4 and later releases support configuring SNMP with NCLU. While NCLU does not provide functionality to configure every single
snmpd feature, it is the recommended method of configuring
snmpd. You are not restricted to using NCLU for configuration and can edit the
/etc/snmp/snmpd.conf file and control
systemctl commands. For Cumulus Linux versions earlier than 3.0,
snmpd has a default configuration that listens to incoming requests on all interfaces.
Cumulus Linux 3.6 and later releases support configuring VRFs for listening-addresses as well as Trap/Inform support. If management VRF is enabled on the switch, this places the eth0 interface in the management VRF. When configuring the listening-address for snmp-server, you must specify an additional parameter to enable listening on the eth0 interface with the following command:
cumulus@router1:~$ net add snmp-server listening-address 10.10.10.10 vrf mgmt
These additional parameters are described in detail below.
You must add a default community string for v1 or v2c environments or the
snmpd daemon does not respond to any requests. For security reasons, the default configuration configures
snmpd to listen to SNMP requests on the loopback interface so access to the switch is restricted to requests originating from the switch itself. The only required commands for
snmpd to function are a
listening-address and either a
username or a
Configure SNMP with NCLU
The table below highlights the structure of NCLU commands available for configuring SNMP. An example command set is provided below the table. NCLU restarts the
snmpd daemon after configuration changes are made and committed.
|Removes all entries in the |
For security reasons, the localhost is set to a listening address 127.0.0.1 by default so that the SNMP agent only responds to requests originating on the switch itself. You can also configure listening only on the IPv6 localhost address with localhost-v6. When using IPv6 addresses or localhost, you can use a
Note: This command does not allow
Creates an SNMPv3 username and the necessary credentials for access. You can restrict a user to a particular OID tree or predefined view name if these are specified. If you specify auth-none, no authentication password is required. Otherwise, an MD5 or SHA password is required for access to the MIB objects. If specified, an encryption password is used to hide the contents of the request and response packets.
Creates a view name that is used in readonly-community to restrict MIB tree exposure. By itself, this view definition has no effect; however, when linked to an SNMPv3 username or community password, and a host from a restricted subnet, any SNMP request with that username and password must have a source IP address within the configured subnet.
Note: OID can be either a string of period separated decimal numbers or a unique text string that identifies an SNMP MIB object. Some MIBs are not installed by default; you must install them either by hand or with the latest Debian package called snmp-mibs-downloader. You can remove specific view name entries with the delete command or with just a view name to remove all entries matching that view name. You can define a specific view name multiple times and fine tune to provide or restrict access using the included or excluded command to specify branches of certain MIB trees.
This command defines the password required for SNMP version 1 or 2c requests for GET or GETNEXT. By default, this provides access to the full OID tree for such requests, regardless of from where they were sent. There is no default password set, so
For SNMP versions 1 and 2C, this command sets the SNMP Trap destination IP address. Multiple destinations can exist, but you must set up at least one to enable SNMP Traps to be sent. Removing all settings disables SNMP traps. The default version is 2c, unless otherwise configured. You must include a VRF name with the IP address to force Traps to be sent in a non-default VRF table.
For SNMPv3 Trap and Inform messages, this command configures the trap destination IP address (with an optional VRF name). You must define the authentication type and password. The encryption type and password are optional. You must specify the engine ID/user name pair. The
For Traps, the engine ID/user name is for the CL switch sending the traps. This can be found at the end of the
For Inform messages (Informs are acknowledged version 3 Traps), the engine ID/user name is the one used to create the username on the receiving Trap daemon server. The Trap receiver sends the response for the Trap message using its own engine ID/user name. In practice, the trap daemon generates the usernames with its own engine ID and after these are created, the SNMP server (or agent) needs to use these engine ID/user names when configuring the Inform messages so that they are correctly authenticated and the correct response is sent to the
Enables notifications for interface link-up to be sent to SNMP Trap destinations.
Enables notifications for interface link-down to be sent to SNMP Trap destinations.
Enables SNMP Trap notifications to be sent for every SNMP authentication failure.
Enables a trap when the cpu-load-average exceeds the configured threshold. You can only use integers or floating point numbers.
This table describes system setting configuration commands for SNMPv2-MIB.
Sets the system physical location for the node in the SNMPv2-MIB system table.
Sets the identification of the contact person for this managed node, together with information on how to contact this person.
Sets an administratively-assigned name for the managed node. By convention, this is the fully-qualified domain name of the node.
The example commands below enable an SNMP agent to listen on all IPv4 addresses with a community string password, set the trap destination host IP address, and create four types of SNMP traps.
Configure SNMP Manually
If you need to manually edit the SNMP configuration; for example, if the necessary option has not been implemented in NCLU, you need to edit the configuration directly, which is stored in the
Use caution when editing this file. The next time you use NCLU to update your SNMP configuration, if NCLU is unable to correctly parse the syntax, some of the options might be overwritten.
Make sure you do not delete the
snmpd.conf file; this can cause issues with the package manager the next time you update Cumulus Linux.
The SNMP daemon,
snmpd, uses the
/etc/snmp/snmpd.conf configuration file for most of its configuration. The syntax of the most important keywords are defined in the following table.
Required. This command sets the protocol, IP address, and the port for
Required. This command defines the password that is required for SNMP version 1 or 2c requests for GET or GETNEXT. By default, this provides access to the full OID tree for such requests, regardless of from where they were sent. There is no default password set, so
This command defines a view name that specifies a subset of the overall OID tree. You can reference this restricted view by name in the
The systemonly view is used by
This command defines the IP address of the notification (or trap) receiver for either SNMPv1 traps or SNMPv2 traps. If you specify several sink directives, multiple copies of each notification (in the appropriate formats) are generated. You must configure a trap server to receive and decode these trap messages (for example,
These three commands define an internal SNMPv3 username that is required for
This command enables link up and link down trap notifications, assuming the other trap configurations settings are set. This command configures the Event MIB tables to monitor the ifTable for network interfaces being taken up or down, and triggering a linkUp or linkDown notification as appropriate. This is equivalent to the following configuration:
This command configures the Event MIB tables to monitor the various UCD-SNMP-MIB tables for problems (as indicated by the appropriate xxErrFlag column objects) and send a trap. This assumes you have downloaded the
Start the SNMP Daemon
Use the recommended process described below to start
snmpd and monitor it using
To start the SNMP daemon:
snmpddaemon to start automatically after reboot:
- To enable
snmpdto restart automatically after failure:
- Create a file called
Add the following lines:
sudo systemctl daemon-reload.
- Create a file called
After the service starts, you can use SNMP to manage various components on the switch.
Configure SNMP with Management VRF (used prior to Cumulus Linux 3.6)
When you configure Management VRF, you need to be aware of the interface IP addresses on which SNMP is listening. If you set listening-address to all, the
snmpd daemon responds to incoming requests on all interfaces that are in the default VRF. If you prefer to listen on a limited number of IP addresses, Cumulus Networks recommends that you run only one instance of the
snmpd daemon and specify the VRF name along with the listening-address. You can configure IP addresses in different VRFs and a single SNMP daemon listens on multiple IP addresses each with its own VRF. Because SNMP has native VRF awareness, using systemctl commands to manage snmpd in different VRFs is no longer necessary.
SNMP configuration in NCLU is VRF aware so you can configure the
snmpd daemon to listen to incoming SNMP requests on a particular IP address within particular VRFs. Because interfaces in a particular VRF (routing table) are not aware of interfaces in a different VRF, the
snmpd daemon only responds to polling requests and sends traps on the interfaces of the VRF on which it is configured.
When management VRF is configured, configure the listening-address with a VRF name as shown above. This allows snmpd to receive and respond to SNMP polling requests on eth0.
Prior to CL 3.6, you could not configure a VRF name in the listening-address or the trap-destination commands. To manually handle VRF functionality, you had to do the following:
- Configure all the required SNMP settings with NCLU. Pay particular attention to the listening-address configuration setting, which should contain one or more IP addresses that belong to interfaces within a single VRF (if management VRF is configured, this is typically the IP address of eth0 ). You can use IP addresses other than eth0, but the interfaces for these IP addresses must be in the same VRF (typically the management VRF).
Commit the changes to start the
snmpddaemon in the default VRF.
Manually stop the
snmpddaemon from running in the default VRF.
Manually restart the
snmpddaemon in the management VRF.
Running Multiple Instances of snmpd
Prior to CL 3.6, more complex configurations may have been needed; for example, you can run more than one
snmpd daemon (one in each VRF designed to receive SNMP polling requests). Cumulus Networks does not recommend this for memory and cpu resource reasons. However, if this is required, you must use a separate configuration file with each instance of the
snmpd daemon. You can use a copy of the
/etc/snmp/snmpd.conf file. When you use this file, start an
snmpd daemon with the following command:
To use management VRF, you need to configure the IP address of eth0 as the listening-address. In the example below, eth0 IP address is 10.10.10.10. You can also add other
snmp-server configurations, then commit the changes.
This restarts the
snmpd daemon in the default VRF. Then, to run
snmpd in the correct VRF, stop the daemon in the default VRF (or stop any other
snmpd daemons that happen to be running), then restart
snmpd in the management VRF so that it can respond to requests on interfaces only in that VRF. Make sure that only one instance of the
snmpd daemon is running and that it is running in the desired VRF. Assuming the Management VRF has been enabled, the following example shows how to stop
snmpd and restart it in the management VRF.
Set up the Custom Cumulus Networks MIBs
No changes are required in the
/etc/snmp/snmpd.conf file on the switch to support the custom Cumulus Networks MIBs. The following lines are already included by default and provide support for both the Cumulus Counters and the Cumulus Resource Query MIBs.
However, you need to copy several files to the NMS server for the custom Cumulus MIB to be recognized on NMS server.
Set the Community String
snmpd authentication for versions 1 and 2 is disabled by default in Cumulus Linux. You can enable this password (called a community string) by setting rocommunity (for read-only access) or rwcommunity (for read-write access). Setting a community string is required.
To enable read-only querying by a client:
/etc/snmp/snmpd.conffile in a text editor.
To allow read-only access, uncomment the following line, then save the file:
Keyword Meaning rocommunity Read-only community; rwcommunity is for read-write access. public
Plain text password/community string.
Cumulus Networks strongly recommends you change this password to something else.
default The default keyword allows connections from any system. The localhost keyword allows requests only from the local host. A restricted source can either be a specific hostname (or address), or a subnet, represented as IP/MASK (like 10.10.10.0/255.255.255.0), or IP/BITS (like 10.10.10.0/24), or the IPv6 equivalents. systemonly The name of this particular SNMP view. This is a user-defined value.
Enable SNMP Support for FRRouting
SNMP supports Routing MIBs in FRRouting. To enable SNMP support for FRRouting, you need to:
- Configure AgentX (ASX) access in FRRouting
- The default
/etc/snmp/snmpd.confconfiguration already enables agentx and sets the correct permissions
Enabling FRRouting includes support for BGP. However, if you plan on using the BGP4 MIB, be sure to provide access to the MIB tree 22.214.171.124.2.1.15.
At this time, SNMP does not support monitoring BGP unnumbered neighbors.
If you plan on using the OSPFv2 MIB, provide access to 126.96.36.199.2.1.14 and to 188.8.131.52.2.1.191 for the OSPv3 MIB.
To enable SNMP support for FRRouting:
Configure AgentX access in FRRouting:
Update the SNMP configuration to enable FRRouting to respond to SNMP requests. Open the
/etc/snmp/snmpd.conffile in a text editor and verify that the following configuration exists:
Make sure that the
/var/agentxdirectory is world-readable and world-searchable (octal mode 755).
Optionally, you might need to expose various MIBs:
- For the BGP4 MIB, allow access to
- For the OSPF MIB, allow access to
- For the OSPFV3 MIB, allow access to
- For the BGP4 MIB, allow access to
To verify the configuration, run
snmpwalk. For example, if you have a running OSPF configuration with routes, you can check this OSPF-MIB first from the switch itself with:
Enable the .184.108.40.206.2.1 Range
Some MIBs, including storage information, are not included by default in
snmpd.conf in Cumulus Linux. This results in some default views on common network tools (like
librenms) to return less than optimal data. You can include more MIBs by enabling all the .220.127.116.11.2.1 range. This simplifies the configuration file, removing concern that any required MIBs will be missed by the monitoring system. Various MIBs were added to version 3.0 and include the following: ENTITY and ENTITY-SENSOR MIB and parts of the BRIDGE-MIB and Q-BRIDGE-MIBs. These are included in the default configuration.
This configuration grants access to a large number of MIBs, including all SNMPv2-MIB, which might reveal more data than expected. In addition to being a security vulnerability, it might consume more CPU resources.
To enable the .18.104.22.168.2.1 range, make sure the view name commands include the required MIB objects.
SNMPv3 is often used to enable authentication and encryption, as community strings in versions 1 and 2c are sent in plaintext. SNMPv3 usernames are added to the
/etc/snmp/snmpd.conf file, along with plaintext authentication and encryption pass phrases.
Cumulus Networks recommends that you configure SNMPv3 usernames and passwords with NCLU. However, if you prefer to edit the
/etc/snmp/snmpd.conf manually instead, be aware that
snmpd caches SNMPv3 usernames and passwords in the /
var/lib/snmp/snmpd.conf file. Make sure you stop
snmpd and remove the old entries when making changes. Otherwise, Cumulus Linux uses the old usernames and passwords in the
/var/lib/snmp/snmpd.conf file instead of the ones in the
The NCLU command structures for configuring SNMP user passwords are:
The example below defines five users, each with a different combination of authentication and encryption:
After configuring user passwords and restarting the
snmpd daemon, you can check user access with a client.
snmpDebian package contains
snmpwalk, and other programs that are useful for checking daemon functionality from the switch itself or from another workstation.
The following commands check the access for each user defined above from the localhost:
The following procedure shows a slightly more secure method of configuring SNMPv3 users without creating cleartext passwords:
net-snmp-configscript that is in
Stop the daemon:
net-snmp-configcommand to create two users, one with MD5 and DES, and the next with SHA and AES.
The minimum password length is eight characters and the arguments
-xhave different meanings in
This adds a
createUser command in
/var/lib/snmp/snmpd.conf. Do not edit this file by hand unless you are removing usernames. You can edit this file and restrict access to certain parts of the MIB by adding noauth, auth or priv to allow unauthenticated access, require authentication, or to enforce use of encryption.
snmpd daemon reads the information from the
/var/lib/snmp/snpmd.conf file and then the line is removed (eliminating the storage of the master password for that user) and replaced with the key that is derived from it (using the EngineID). This key is a localized key, so that if it is stolen, it cannot be used to access other agents. To remove the two users
userSHAwithAES, stop the
snmpd daemon and edit the
/var/lib/snmp/snmpd.conf file. Remove the lines containing the username, then restart the
snmpd daemon as in step 3 above.
From a client, you access the MIB with the correct credentials. (The roles of
-A are reversed on the client side as compared with the
net-snmp-config command used above.)
Manually Configure SNMP Traps (Non-NCLU)
Generate Event Notification Traps
The Net-SNMP agent provides a method to generate SNMP trap events using the Distributed Management (DisMan) Event MIB for various system events, including:
- Link up/down.
- Exceeding the temperature sensor threshold, CPU load, or memory threshold.
- Other SNMP MIBs.
To enable specific types of traps, you need to create the following configurations in
Define Access Credentials
An SNMPv3 username is required to authorize the DisMan service even though you are not configuring SNMPv3 here. The example
snmpd.conf configuration shown below creates trapusername as the username using the
iquerySecName defines the default SNMPv3 username to be used when making internal queries to retrieve monitored expressions.
rouser specifies which username to use for these SNMPv3 queries. All three are required for
snmpd to retrieve information and send traps (even with the
monitor command shown below in the examples). Add the following lines to your
/etc/snmp/snmpd.conf configuration file:
iquerysecname specifies the default SNMPv3 username to be used when making internal queries to retrieve any necessary information — either for evaluating the monitored expression or building a notification payload. These internal queries always use SNMPv3, even if normal querying of the agent is done using SNMPv1 or SNMPv2c. Note that this user must also be explicitly created via
createUser and given appropriate access rights, for
rouser, for example. The
iquerysecname directive is purely concerned with defining which user should be used, not with actually setting this user up.
Define Trap Receivers
The following configuration defines the trap receiver IP address where SNMPv2 traps are sent:
Although the traps are sent to an SNMPV2 receiver, the SNMPv3 user is still required. Starting with Net-SNMP 5.3,
snmptrapd no longer accepts all traps by default.
snmptrapd must be configured with authorized SNMPv1/v2c community strings and/or SNMPv3 users. Non-authorized traps/informs are dropped. Refer to the snmptrapd.conf(5) manual page for details.
It is possible to define multiple trap receivers and to use the domain name instead of an IP address in the
snmpd service to apply the changes.
SNMP Version 3 Trap and Inform Messages
You can configure SNMPv3 trap and inform messages with the
trapsess configuration command. Inform messages are traps that are acknowledged by the receiving trap daemon. You configure inform messages with the
-Ci parameter. You must specify the EngineID of the receiving trap server with the
The SNMP trap receiving daemon must have usernames, authentication passwords, and encryption passwords created with its own EngineID. You must configure this trap server EngineID in the switch
snmpd daemon sending the trap and inform messages. You specify the level of authentication and encryption for SNMPv3 trap and inform messages with
NoauthNoPriv, authNoPriv, or
You can define multiple trap receivers and use the domain name instead of an IP address in the
After you complete the configuration, restart the
snmpd service to apply the changes:
Source Traps from a Different Source IP Address
When client SNMP programs (such as
snmptrap) are run from the command line, or when
snmpd is configured to send a trap (based on
snmpd.conf), you can configure a clientaddr in
snmp.conf that allows the SNMP client programs or
snmpd (for traps) to source requests from a different source IP address.
snmpd itself must be able to bind to this address.
For more information, read the the
snmp.conf man page:
Monitor Fans, Power Supplies, and Transformers
An SNMP agent (
snmpd) waits for incoming SNMP requests and responds to them. If no requests are received, an agent does not initiate any actions. However, various commands can configure
snmpd to send traps based on preconfigured settings (
swap commands), or customized
snmpd.conf man page, the
monitor command is defined this way:
You can configure
snmpd to monitor the operational status of an Entity MIB or Entity-Sensor MIB. You can determine the operational status, given as a value of ok(1), unavailable(2) or nonoperational(3), by adding the following example configuration to
/etc/snmp/snmpd.conf and adjusting the values:
Using the OID name:
You can use the OID name if the
snmp-mibs-downloaderpackage is installed.
entPhySensorOperStatusinteger can be found by walking the
To get all sensor information, run
entPhysicalNametable. For example:
Enable MIB to OID Translation
MIB names can be used instead of OIDs, by installing the
snmp-mibs-downloader, to download SNMP MIBs to the switch prior to enabling traps. This greatly improves the readability of the
/etc/apt/sources.listin a text editor.
non-freerepository, then save the file:
Update the switch:
/etc/snmp/snmp.conffile to verify that the
mibs :line is commented out:
/etc/default/snmpdfile to verify that the
export MIBS=line is commented out:
After you confirm the configuration, remove or comment out the
Configure Link Up/Down Notifications
linkUpDownNotifications directive is used to configure link up/down notifications when the operational status of the link changes.
The default frequency for checking link up/down is 60 seconds. You can change the default frequency using the
monitor directive directly instead of the
linkUpDownNotifications directive. See
man snmpd.conf for details.
Configure Temperature Notifications
Temperature sensor information for each available sensor is maintained in the the lmSensors MIB. Each platform can contain a different number of temperature sensors. The example below generates a trap event when any temperature sensor exceeds a threshold of 68 degrees (centigrade). It monitors each
lmTempSensorsValue. When the threshold value is checked and exceeds the
lmTempSensorsValue, a trap is generated. The
-o lmTempSenesorsDevice option is used to instruct SNMP to also include the lmTempSensorsDevice MIB in the generated trap. The default frequency for the
monitor directive is 600 seconds. You can change the default frequency with the
To monitor the sensors individually, first use the
sensors command to determine which sensors are available to be monitored on the platform.
monitor command for the specific sensor using the
-I option. The
-I option indicates that the monitored expression is applied to a single instance. In this example, there are five temperature sensors available. Use the following directive to monitor only temperature sensor 3 at 5 minute intervals.
Configure Free Memory Notifications
You can monitor free memory using the following directives. The example below generates a trap when free memory drops below 1,000,000KB. The free memory trap also includes the amount of total real memory:
Configure Processor Load Notifications
To monitor CPU load for 1, 5, or 15 minute intervals, use the
load directive with the
monitor directive. The following example generates a trap when the 1 minute interval reaches 12%, the 5 minute interval reaches 10%, or the 15 minute interval reaches 5%.
Configure Disk Utilization Notifications
To monitor disk utilization for all disks, use the
includeAllDisks directive together with the
monitor directive. The example code below generates a trap when a disk is 99% full:
Configure Authentication Notifications
To generate authentication failure traps, use the
Use the Net-SNMP trap daemon to receive SNMP traps. The
/etc/snmp/snmptrapd.conf file is used to configure how incoming traps are processed. Starting with Net-SNMP release 5.3, you must specify who is authorized to send traps and informs to the notification receiver (and what types of processing these are allowed to trigger). You can specify three processing types:
- log logs the details of the notification in a specified file to standard output (or stderr), or through syslog (or similar).
- execute passes the details of the trap to a specified handler program, including embedded Perl.
- net forwards the trap to another notification receiver.
Typically, this configuration is log,execute,net to cover any style of processing for a particular category of notification. But it is possible (even desirable) to limit certain notification sources to selected processing only.
authCommunity TYPES COMMUNITY [SOURCE [OID | -v VIEW ]] authorizes traps and SNMPv2c INFORM requests with the specified community to trigger the types of processing listed. By default, this allows any notification using this community to be processed. You can use the SOURCE field to specify that the configuration only applies to notifications received from particular sources. For more information about specific configuration options within the file, look at the
snmpd.conf(5) man page with the following command:
Below are the MIBs supported by Cumulus Linux, as well as suggested uses for them. The overall Cumulus Linux MIB is defined in the
|MIB Name||Suggested Uses|
You can enable FRRouting SNMP support to provide support for OSPF-MIB (RFC-1850), OSPFV3-MIB (RFC-5643), and BGP4-MIB (RFC-1657). See the FRRouting section above.
Discard counters: Cumulus Linux also includes its own counters MIB, defined in
The Cumulus Networks custom Power over Ethernet PoE MIB defined in the
Cumulus Linux includes its own resource utilization MIB, which is similar to using
|SNMP counters. For information on exposing CPU and memory information with SNMP, see this knowledge base article.|
|ENTITY-MIB||From RFC 4133, the temperature sensors, fan sensors, power sensors, and ports are covered.|
|ENTITY-SENSOR-MIB||Physical sensor information (temperature, fan, and power supply) from RFC 3433.|
Users, storage, interfaces, process info, run parameters
Implementation of the IEEE 8023-LAG-MIB includes the
Interface description, type, MTU, speed, MAC, admin, operation status, counters
The IF-MIB cache is disabled by default. The non-caching code path in the IF-MIB treats 64-bit counters like 32-bit counters (a 64-bit counter rolls over after the value increments to a value that extends beyond 32 bits). To enable the counter to reflect traffic statistics using 64-bit counters, remove the
|IP-FORWARD-MIB||IP routing table|
|IPv4, IPv4 addresses, counters, netmasks|
|LLDP-MIB||Layer 2 neighbor information from |
|Fan speed, temperature sensor values, voltages. This is deprecated since the ENTITY-SENSOR MIB has been added.|
|NET-SNMP-AGENT-MIB||Agent timers, user, group config|
|See this knowledge base article on extending NET-SNMP in Cumulus Linux to include data from power supplies, fans, and temperature sensors.|
|Agent timers, user, group config|
|UCD-SNMP-MIB||System memory, load, CPU, disk IO|
The ENTITY MIB does not show the chassis information in Cumulus Linux.
Pass Persist Scripts
The pass persist scripts in Cumulus Linux use the pass_persist extension to Net-SNMP. The scripts are stored in
/usr/share/snmp and include:
All the scripts are enabled by default in Cumulus Linux, except for:
bgp4_pp.py, which is now handled by FRRouting instead of Quagga, so monitoring has changed accordingly.
cl_poe_pp.py, which is disabled by default as only certain platforms that Cumulus Linux supports are capable of doing Power over Ethernet.
Use the following commands to troubleshoot potential SNMP issues: