Simple Network Management Protocol - SNMP
Cumulus Linux uses the open source Net-SNMP agent snmpd
version 5.8,
which provides support for most of the common industry-wide MIBs,
including interface counters and TCP/UDP IP stack data.
History
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 Linux
is based on the latest net-snmp
5.8 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.
SNMP Managers
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).
SNMP Agents
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
1.3.6.1.2.1.1.6 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).
/home/cumulus# snmptranslate -Td -On SNMPv2-MIB::sysLocation
.1.3.6.1.2.1.1.6
sysLocation OBJECT-TYPE
-- FROM SNMPv2-MIB
-- TEXTUAL CONVENTION DisplayString
SYNTAX OCTET STRING (0..255)
DISPLAY-HINT "255a"
MAX-ACCESS read-write
STATUS current
DESCRIPTION "The physical location of this node (e.g., 'telephone
closet, 3rd floor'). If the location is unknown, the
value is the zero-length string."
::= { iso(1) org(3) dod(6) internet(1) mgmt(2) mib-2(1) system(1) 6 }
/home/cumulus# snmptranslate -Tp -IR system
+--system(1)
|
+-- -R-- String sysDescr(1)
| Textual Convention: DisplayString
| Size: 0..255
+-- -R-- ObjID sysObjectID(2)
+-- -R-- TimeTicks sysUpTime(3)
| |
| +--sysUpTimeInstance(0)
|
+-- -RW- String sysContact(4)
| Textual Convention: DisplayString
| Size: 0..255
+-- -RW- String sysName(5)
| Textual Convention: DisplayString
| Size: 0..255
+-- -RW- String sysLocation(6)
| Textual Convention: DisplayString
| Size: 0..255
+-- -R-- INTEGER sysServices(7)
| Range: 0..127
+-- -R-- TimeTicks sysORLastChange(8)
| Textual Convention: TimeStamp
The section 1.3.6.1
or iso.org.dod.internet
is the OID that
defines internet resources. The 2
or mgmt
that follows is for a
management subcategory. The 1
or 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).
Getting Started
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
Configure SNMP
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
GetRequest
and GetResponse
packets. SNMPv3 does not expose the
username passwords and has the option of encrypting the packet contents.
- Consider using NCLU to configure
snmpd
even though NCLU does not provide functionality to configure everysnmpd
feature. You are not restricted to using NCLU for configuration and can edit the/etc/snmp/snmpd.conf
file and controlsnmpd
withsystemctl
commands. SNMP configuration with NCLU is supported in Cumulus Linux 3.4 and later. - Cumulus Linux 3.6 and later provides VRF listening-address, as well as Trap/Inform support. When management VRF is enabled, the eth0 interface is placed in the management VRF. When you configure the
listening-address
forsnmp-server
, you must run thenet add snmp-server listening-address <address> vrf mgmt
command to enable listening on the eth0 interface. These additional parameters are described in detail below. - You must add a default community string for v1 or v2c environments so that the
snmpd
daemon can respond to requests. For security reasons, the default configuration configuressnmpd
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 forsnmpd
to function are alistening-address
and either ausername
or areadonly-community
string.
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.
Command | Summary |
---|---|
| 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
|
| Configures the Note: This command does not allow
|
| Sets
|
| Sets
|
| 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 Examples of
|
| 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.
Command | Summary |
---|---|
| 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.
cumulus@switch:~$ net add snmp-server listening-address all
cumulus@switch:~$ net add snmp-server readonly-community tempPassword access any
cumulus@switch:~$ net add snmp-server trap-destination 1.1.1.1 community-password mypass version 2c
cumulus@switch:~$ net add snmp-server trap-link-up check-frequency 15
cumulus@switch:~$ net add snmp-server trap-link-down check-frequency 10
cumulus@switch:~$ net add snmp-server trap-cpu-load-average one-minute 7.45 five-minute 5.14
cumulus@switch:~$ net add snmp-server trap-snmp-auth-failures
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 /etc/snmp/snmpd.conf
file.
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.
Syntax | Meaning |
---|---|
agentaddress | Required. This command sets the protocol, IP address, and the port for |
rocommunity | 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 Examples of
|
view | 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 |
trapsink trap2sink | 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, |
createuser iquerysecName rouser | These three commands define an internal SNMPv3 username that is required for
|
linkUpDownNotifications yes | 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:
|
defaultMonitors yes | 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 systemctl
.
As mentioned above, if you intend to run this service within a VRF, including the management VRF, follow these steps for configuring the service.
To start the SNMP daemon:
Start the
snmpd
daemon:cumulus@switch:~$ sudo systemctl start snmpd.service
Configure the
snmpd
daemon to start automatically after reboot:cumulus@switch:~$ sudo systemctl enable snmpd.service
To enable
snmpd
to restart automatically after failure:Create a file called
/etc/systemd/system/snmpd.service.d/restart.conf
.Add the following lines:
[Service] Restart=always RestartSec=60
Run
sudo systemctl daemon-reload
.
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, 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 Cumulus Linux 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
snmpd
daemon in the default VRF.Manually stop the
snmpd
daemon from running in the default VRF.Manually restart the
snmpd
daemon in the management VRF.
Running Multiple Instances of snmpd
Prior to Cumulus Linux 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). This is not recommended 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:
cumulus@switch:~$ sudo /usr/sbin/snmpd -y -LS 0-4 d -Lf /dev/null -u snmp -g snmp -I -smux -p /run/snmpd.pid -C -c <new snmp config filename> (edited)
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.
cumulus@switch:~$ net add snmp-server listening-address 10.10.10.10
cumulus@switch:~$ net add snmp-server readonly-community tempPassword access any
cumulus@switch:~$ net pending
cumulus@switch:~$ net commit
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.
cumulus@switch:mgmt-vrf:~$ systemctl stop snmpd.service
cumulus@switch:mgmt-vrf:~$ systemctl disable snmpd.service
cumulus@switch:mgmt-vrf:~$ ps aux | grep snmpd
cumulus@switch:mgmt-vrf:~$
cumulus@switch:mgmt-vrf:~$ systemctl start snmpd@mgmt.service
cumulus@switch:mgmt-vrf:~$ systemctl enable snmpd.service
cumulus@switch:mgmt-vrf:~$ systemctl status snmpd@mgmt.service
root@switch:mgmt-vrf:/home/cumulus# systemctl status snmpd@mgmt.service
● snmpd@mgmt.service - Simple Network Management Protocol (SNMP) Daemon.
Loaded: loaded (/lib/systemd/system/snmpd.service; disabled)
Drop-In: /run/systemd/generator/snmpd@.service.d
└─vrf.conf
Active: active (running) since Thu 2017-12-07 20:05:41 UTC; 2min 22s ago
Main PID: 30880 (snmpd)
CGroup: /system.slice/system-snmpd.slice/snmpd@mgmt.service
└─30880 /usr/sbin/snmpd -y -LS 0-4 d -Lf /dev/null -u snmp -g snmp -I -smux -p /run/snmpd.pid -f
Dec 07 20:05:41 cel-redxp-01 systemd[1]: Started Simple Network Management Protocol (SNMP) Daemon..
cumulus@switch:mgmt-vrf:~$ ps aux | grep snmpd
snmp 30880 0.4 0.3 57176 12276 ? Ss 20:05 0:00 /usr/sbin/snmpd -y -LS 0-4 d -Lf /dev/null -u snmp -g snmp -I -smux -p /run/snmpd.pid -f
Set up the Custom MIBs
No changes are required in the /etc/snmp/snmpd.conf
file on the switch
to support the custom MIBs. The following lines are
already included by default and provide support for both the Cumulus
Counters and the Cumulus Resource Query MIBs.
sysObjectID 1.3.6.1.4.1.40310
pass_persist .1.3.6.1.4.1.40310.1 /usr/share/snmp/resq_pp.py
pass_persist .1.3.6.1.4.1.40310.2 /usr/share/snmp/cl_drop_cntrs_pp.py
However, you need to copy several files to the NMS server for the custom Cumulus MIB to be recognized on NMS server.
/usr/share/snmp/mibs/Cumulus-Snmp-MIB.txt
/usr/share/snmp/mibs/Cumulus-Counters-MIB.txt
/usr/share/snmp/mibs/Cumulus-Resource-Query-MIB.txt
Set the Community String
The 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:
Open the
/etc/snmp/snmpd.conf
file in a text editor.To allow read-only access, uncomment the following line, then save the file:
rocommunity public default -V systemonly
Keyword
Meaning
rocommunity
Read-only community; rwcommunity is for read-write access.
public
Plain text password/community string.
Change this password to prevent security issues.
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.
Restart
snmpd
:cumulus@switch:~$ sudo systemctl restart snmpd.service
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.conf
configuration 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 1.3.6.1.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 1.3.6.1.2.1.14 and to 1.3.6.1.2.1.191 for the OSPv3 MIB.
To enable SNMP support for FRRouting:
Configure AgentX access in FRRouting:
cumulus@switch:~$ net add routing agentx cumulus@switch:~$ net pending cumulus@switch:~$ net commit
Update the SNMP configuration to enable FRRouting to respond to SNMP requests. Open the
/etc/snmp/snmpd.conf
file in a text editor and verify that the following configuration exists:agentxsocket /var/agentx/master agentxperms 777 777 snmp snmp master agentx
Make sure that the
/var/agentx
directory is world-readable and world-searchable (octal mode 755).Optionally, you might need to expose various MIBs:
- For the BGP4 MIB, allow access to
1.3.6.1.2.1.15
- For the OSPF MIB, allow access to
1.3.6.1.2.1.14
- For the OSPFV3 MIB, allow access to
1.3.6.1.2.1.191
- 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:
cumulus@switch:~$ sudo snmpwalk -v2c -cpublic localhost 1.3.6.1.2.1.14
Enable the .1.3.6.1.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 .1.3.6.1.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 .1.3.6.1.2.1 range, make sure the view name commands include the required MIB objects.
Configure SNMPv3
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.
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 /etc/snmp/snmpd.conf
file.
The NCLU command structures for configuring SNMP user passwords are:
cumulus@switch:~$ net add snmp-server username <username> [auth-none] | [(auth-md5 | auth-sha) <auth-password>]
cumulus@switch:~$ net add snmp-server username <username> auth-(none | sha | md5) (oid <OID> | view <view>)
The example below defines five users, each with a different combination of authentication and encryption:
cumulus@switch:~$ net add snmp-server username user1 auth-none
cumulus@switch:~$ net add snmp-server username user2 auth-md5 user2password
cumulus@switch:~$ net add snmp-server username user3 auth-md5 user3password encrypt-des user3encryption
cumulus@switch:~$ net add snmp-server username user666 auth-sha user666password encrypt-aes user666encryption
cumulus@switch:~$ net add snmp-server username user999 auth-md5 user999password encrypt-des user999encryption
cumulus@switch:~$ net add snmp-server username user1 auth-none oid 1.3.6.1.2.1
cumulus@switch:~$ net add snmp-server username user1 auth-none oid system
cumulus@switch:~$ net add snmp-server username user2 auth-md5 test1234 view testview oid 1.3.6.1.2.1
cumulus@switch:~$ net add snmp-server username user3 auth-sha testshax encrypt-aes testaesx oid 1.3.6.1.2.1
cumulus@switch:~$ net pending
cumulus@switch:~$ net commit
# simple no auth user
#createuser user1
# user with MD5 authentication
#createuser user2 MD5 user2password
# user with MD5 for auth and DES for encryption
#createuser user3 MD5 user3password DES user3encryption
# user666 with SHA for authentication and AES for encryption
createuser user666 SHA user666password AES user666encryption
# user999 with MD5 for authentication and DES for encryption
createuser user999 MD5 user999password DES user999encryption
# restrict users to certain OIDs
# (Note: creating rouser or rwuser will give
# access regardless of the createUser command above. However,
# createUser without rouser or rwuser will not provide any access).
rouser user1 noauth 1.3.6.1.2.1
rouser user2 auth 1.3.6.1.2.1
rwuser user3 priv 1.3.6.1.2.1
rwuser user666
rwuser user999
After configuring user passwords and restarting the snmpd
daemon, you
can check user access with a client.
The snmp
Debian package contains snmpget
, 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:
# check user1 which has no authentication or encryption (NoauthNoPriv)
snmpget -v 3 -u user1 -l NoauthNoPriv localhost 1.3.6.1.2.1.1.1.0
snmpwalk -v 3 -u user1 -l NoauthNoPriv localhost 1.3.6.1.2.1.1
# check user2 which has authentication but no encryption (authNoPriv)
snmpget -v 3 -u user2 -l authNoPriv -a MD5 -A user2password localhost 1.3.6.1.2.1.1.1.0
snmpget -v 3 -u user2 -l authNoPriv -a MD5 -A user2password localhost 1.3.6.1.2.1.2.1.0
snmpwalk -v 3 -u user2 -l authNoPriv -a MD5 -A user2password localhost 1.3.6.1.2.1
# check user3 which has both authentication and encryption (authPriv)
snmpget -v 3 -u user3 -l authPriv -a MD5 -A user3password -x DES -X user3encryption localhost .1.3.6.1.2.1.1.1.0
snmpwalk -v 3 -u user3 -l authPriv -a MD5 -A user3password -x DES -X user3encryption localhost .1.3.6.1.2.1
snmpwalk -v 3 -u user666 -l authPriv -a SHA -x AES -A user666password -X user666encryption localhost 1.3.6.1.2.1.1
snmpwalk -v 3 -u user999 -l authPriv -a MD5 -x DES -A user999password -X user999encryption localhost 1.3.6.1.2.1.1
The following procedure shows a slightly more secure method of configuring SNMPv3 users without creating cleartext passwords:
Install the
net-snmp-config
script that is inlibsnmp-dev
package:cumulus@switch:~$ sudo -E apt-get update cumulus@switch:~$ sudo -E apt-get install libsnmp-dev
Stop the daemon:
cumulus@switch:~$ sudo systemctl stop snmpd.service
Use the
net-snmp-config
command 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
-a
and-x
have different meanings innet-snmp-config
thansnmpwalk
.cumulus@switch:~$ sudo net-snmp-config --create-snmpv3-user -a md5authpass -x desprivpass -A MD5 -X DES userMD5withDES cumulus@switch:~$ sudo net-snmp-config --create-snmpv3-user -a shaauthpass -x aesprivpass -A SHA -X AES userSHAwithAES cumulus@switch:~$ sudo systemctl start snmpd.service
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.
The 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 userMD5withDES
and
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 -x
, -a
and -X
and -A
are reversed on the client side as
compared with the net-snmp-config
command used above.)
snmpwalk -v 3 -u userMD5withDES -l authPriv -a MD5 -x DES -A md5authpass -X desprivpass localhost 1.3.6.1.2.1.1.1
snmpwalk -v 3 -u userSHAwithAES -l authPriv -a SHA -x AES -A shaauthpass -X aesprivpass localhost 1.3.6.1.2.1.1.1
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 /etc/snmp/snmpd.conf
.
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 createUser
command. 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:
createuser trapusername
iquerysecname trapusername
rouser trapusername
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:
trap2sink 192.168.1.1 public
# For SNMPv1 Traps, use
# trapsink 192.168.1.1 public
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 trap2sink
directive.
Restart the snmpd
service to apply the changes.
cumulus@switch:~$ sudo systemctl restart snmpd.service
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 -e
field.
trapsess -Ci -e 0x80ccff112233445566778899 -v3 -l authPriv -u trapuser1 -a MD5 -A trapuser1password -x DES -X trapuser1encryption 192.168.1.1
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
-l
(NoauthNoPriv, authNoPriv,
or authPriv
).
You can define multiple trap receivers and use the domain name instead
of an IP address in the trap2sink
directive.
After you complete the configuration, restart the snmpd
service to
apply the changes:
cumulus@switch:~$ sudo systemctl restart snmpd.service
Source Traps from a Different Source IP Address
When client SNMP programs (such as snmpget
, snmpwalk
, or 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.
snmptrap
, snmpget
, snmpwalk
and snmpd
itself must be able to
bind to this address.
For more information, read snmp.conf
man page:
clientaddr [<transport-specifier>:]<transport-address>
specifies the source address to be used by command-line applica-
tions when sending SNMP requests. See snmpcmd(1) for more infor-
mation about the format of addresses.
This value is also used by snmpd when generating notifications.
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 (load
, file
, proc
, disk
, or
swap
commands), or customized monitor
commands.
From the snmpd.conf
man page, the monitor
command is defined this
way:
monitor [OPTIONS] NAME EXPRESSION
defines a MIB object to monitor. If the EXPRESSION condition holds then
this will trigger the corresponding event, and either send a notification or
apply a SET assignment (or both). Note that the event will only be triggered once,
when the expression first matches. This monitor entry will not fire again until the
monitored condition first becomes false, and then matches again. NAME is an administrative
name for this expression, and is used for indexing the mteTriggerTable (and related tables).
Note also that such monitors use an internal SNMPv3 request to retrieve the values
being monitored (even if normal agent queries typically use SNMPv1 or SNMPv2c).
See the iquerySecName token described above.
EXPRESSION
There are three types of monitor expression supported by the Event MIB - existence, boolean and threshold tests.
OID | ! OID | != OID
defines an existence(0) monitor test. A bare OID specifies a present(0) test,
which will fire when (an instance of) the monitored OID is created. An expression
of the form ! OID specifies an absent(1) test, which will fire when the monitored
OID is delected. An expression of the form != OID specifies a changed(2) test,
which will fire whenever the monitored value(s) change. Note that there must be
whitespace before the OID token.
OID OP VALUE
defines a boolean(1) monitor test. OP should be one of the defined comparison operators
(!=, ==, <, <=, >, >=) and VALUE should be an integer value to compare against. Note that
there must be whitespace around the OP token. A comparison such as OID !=0 will not be
handled correctly.
OID MIN MAX [DMIN DMAX]
defines a threshold(2) monitor test. MIN and MAX are integer values, specifying
lower and upper thresholds. If the value of the monitored OID falls below the lower
threshold (MIN) or rises above the upper threshold (MAX), then the monitor entry will
trigger the corresponding event.
Note that the rising threshold event will only be re-armed when the monitored value
falls below the lower threshold (MIN). Similarly, the falling threshold event will
be re-armed by the upper threshold (MAX).
The optional parameters DMIN and DMAX configure a pair of similar threshold tests,
but working with the delta differences between successive sample values.
OPTIONS
There are various options to control the behavior of the monitored expression. These include:
-D indicates that the expression should be evaluated using delta differences between sample
values (rather than the values themselves).
-d OID or -di OID
specifies a discontinuity marker for validating delta differences. A -di object instance
will be used exactly as given. A -d object will have the instance subidentifiers from
the corresponding (wildcarded) expression object appended. If the -I flag is specified,
then there is no difference between these two options. This option also implies -D.
-e EVENT
specifies the event to be invoked when this monitor entry is triggered. If this option
is not given, the monitor entry will generate one of the standard notifications defined
in the DISMAN-EVENT-MIB.
-I indicates that the monitored expression should be applied to the specified OID as a
single instance. By default, the OID will be treated as a wildcarded object, and the
monitor expanded to cover all matching instances.
-i OID or -o OID
define additional varbinds to be added to the notification payload when this monitor
trigger fires. For a wildcarded expression, the suffix of the matched instance will be
added to any OIDs specified using -o, while OIDs specified using -i will be treated
as exact instances. If the -I flag is specified, then there is no difference between
these two options.
See strictDisman for details of the ordering of notification payloads.
-r FREQUENCY
monitors the given expression every FREQUENCY, where FREQUENCY is in seconds or optionally
suffixed by one of s (for seconds), m (for minutes), h (for hours), d (for days),
or w (for weeks). By default, the expression will be evaluated every 600s (10 minutes).
-S indicates that the monitor expression should not be evaluated when the agent first starts up.
The first evaluation will be done once the first repeat interval has expired.
-s indicates that the monitor expression should be evaluated when the agent first starts up.
This is the default behavior.
Note: Notifications triggered by this initial evaluation will be sent before the coldStart trap.
-u SECNAME
specifies a security name to use for scanning the local host, instead of the default
iquerySecName. Once again, this user must be explicitly created and given suitable access rights.
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
entPhySensorOperStatus
integer:# without installing extra MIBS we can check the check Fan1 status # if the Fan1 index is 100011001, monitor this specific OID (-I) every 10 seconds (-r), and defines additional information to be included in the trap (-o). monitor -I -r 10 -o 1.3.6.1.2.1.47.1.1.1.1.7.100011001 "Fan1 Not OK" 1.3.6.1.2.1.99.1.1.1.5.100011001 > 1 # Any Entity Status non OK (greater than 1) monitor -r 10 -o 1.3.6.1.2.1.47.1.1.1.1.7 "Sensor Status Failure" 1.3.6.1.2.1.99.1.1.1.5 > 1
Using the OID name:
# for a specific fan called Fan1 with an index 100011001 monitor -I -r 10 -o entPhysicalName.100011001 "Fan1 Not OK" entPhySensorOperStatus.100011001 > 1 # for any Entity Status not OK ( greater than 1) monitor -r 10 -o entPhysicalName "Sensor Status Failure" entPhySensorOperStatus > 1
You can use the OID name if the
snmp-mibs-downloader
package is installed.The
entPhySensorOperStatus
integer can be found by walking theentPhysicalName
table.To get all sensor information, run
snmpwalk
on theentPhysicalName
table. For example:cumulus@leaf01:~$ snmpwalk -v 2c -cpublic localhost .1.3.6.1.2.1.47.1.1.1.1.7 iso.3.6.1.2.1.47.1.1.1.1.7.100000001 = STRING: "PSU1Temp1" iso.3.6.1.2.1.47.1.1.1.1.7.100000002 = STRING: "PSU2Temp1" iso.3.6.1.2.1.47.1.1.1.1.7.100000003 = STRING: "Temp1" iso.3.6.1.2.1.47.1.1.1.1.7.100000004 = STRING: "Temp2" iso.3.6.1.2.1.47.1.1.1.1.7.100000005 = STRING: "Temp3" iso.3.6.1.2.1.47.1.1.1.1.7.100000006 = STRING: "Temp4" iso.3.6.1.2.1.47.1.1.1.1.7.100000007 = STRING: "Temp5" iso.3.6.1.2.1.47.1.1.1.1.7.100011001 = STRING: "Fan1" iso.3.6.1.2.1.47.1.1.1.1.7.100011002 = STRING: "Fan2" iso.3.6.1.2.1.47.1.1.1.1.7.100011003 = STRING: "Fan3" iso.3.6.1.2.1.47.1.1.1.1.7.100011004 = STRING: "Fan4" iso.3.6.1.2.1.47.1.1.1.1.7.100011005 = STRING: "Fan5" iso.3.6.1.2.1.47.1.1.1.1.7.100011006 = STRING: "Fan6" iso.3.6.1.2.1.47.1.1.1.1.7.100011007 = STRING: "PSU1Fan1" iso.3.6.1.2.1.47.1.1.1.1.7.100011008 = STRING: "PSU2Fan1" iso.3.6.1.2.1.47.1.1.1.1.7.110000001 = STRING: "PSU1" iso.3.6.1.2.1.47.1.1.1.1.7.110000002 = STRING: "PSU2"
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
snmpd.conf
file.
Open
/etc/apt/sources.list
in a text editor.Add the
non-free
repository, then save the file:cumulus@switch:~$ sudo deb http://ftp.us.debian.org/debian/ jessie main non-free
Update the switch:
cumulus@switch:~$ sudo -E apt-get update
Install the
snmp-mibs-downloader
:cumulus@switch:~$ sudo -E apt-get install snmp-mibs-downloader
Open the
/etc/snmp/snmp.conf
file to verify that themibs :
line is commented out:# # As the snmp packages come without MIB files due to license reasons, loading # of MIBs is disabled by default. If you added the MIBs you can reenable # loading them by commenting out the following line. #mibs :
Open the
/etc/default/snmpd
file to verify that theexport MIBS=
line is commented out:# This file controls the activity of snmpd and snmptrapd # Don't load any MIBs by default. # You might comment this lines once you have the MIBs Downloaded. #export MIBS=
After you confirm the configuration, remove or comment out the
non-free
repository in/etc/apt/sources.list
.#deb http://ftp.us.debian.org/debian/ jessie main non-free
Configure Link Up/Down Notifications
The linkUpDownNotifications
directive is used to configure link
up/down notifications when the operational status of the link changes.
linkUpDownNotifications yes
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 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 -r
option.:
monitor lmTemSensor -o lmTempSensorsDevice lmTempSensorsValue > 68000
To monitor the sensors individually, first use the sensors
command to
determine which sensors are available to be monitored on the platform.
cumulus@switch:~$ sudo sensors
CY8C3245-i2c-4-2e
Adapter: i2c-0-mux (chan_id 2)
fan5: 7006 RPM (min = 2500 RPM, max = 23000 RPM)
fan6: 6955 RPM (min = 2500 RPM, max = 23000 RPM)
fan7: 6799 RPM (min = 2500 RPM, max = 23000 RPM)
fan8: 6750 RPM (min = 2500 RPM, max = 23000 RPM)
temp1: +34.0 C (high = +68.0 C)
temp2: +28.0 C (high = +68.0 C)
temp3: +33.0 C (high = +68.0 C)
temp4: +31.0 C (high = +68.0 C)
temp5: +23.0 C (high = +68.0 C)
Configure a 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.
monitor -I -r 300 lmTemSensor3 -o lmTempSensorsDevice.3 lmTempSensorsValue.3 > 68000
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:
monitor MemFreeTotal -o memTotalReal memTotalFree < 1000000
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%.
load 12 10 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:
includeAllDisks 1%
monitor -r 60 -o dskPath -o DiskErrMsg "dskTable" diskErrorFlag !=0
Configure Authentication Notifications
To generate authentication failure traps, use the authtrapenable
directive:
authtrapenable 1
snmptrapd.conf
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:
cumulus@switch:~$ man 5 snmptrapd.conf
###############################################################################
#
# EXAMPLE-trap.conf:
# An example configuration file for configuring the Net-SNMP snmptrapd agent.
#
###############################################################################
#
# This file is intended to only be an example. If, however, you want
# to use it, it should be placed in /etc/snmp/snmptrapd.conf.
# When the snmptrapd agent starts up, this is where it will look for it.
#
# All lines beginning with a '#' are comments and are intended for you
# to read. All other lines are configuration commands for the agent.
#
# PLEASE: read the snmptrapd.conf(5) manual page as well!
#
# this is the default (port 162) and defines the listening
# protocol and address (e.g. udp:10.10.10.10)
snmpTrapdAddr localhost
#
# defines the actions and the community string
authCommunity log,execute,net public
Supported MIBs
Below are the MIBs supported by Cumulus Linux, as well as suggested uses
for them. The overall Cumulus Linux MIB is defined in the
/usr/share/snmp/mibs/Cumulus-Snmp-MIB.txt
file.
MIB Name | Suggested Uses |
---|---|
BGP4-MIB , RIPv2-MIB | 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 custom Power over Ethernet PoE MIB defined in the
| |
CUMULUS-RESOURCE-QUERY-MIB | Cumulus Linux includes its own resource utilization MIB, which is similar to using |
CUMULUS-SNMP-MIB | SNMP counters.. |
DISMAN-EVENT-MIB | Trap monitoring |
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. |
HOST-RESOURCES-MIB | Users, storage, interfaces, process info, run parameters |
BRIDGE-MIB Q-BRIDGE-MIB | The |
IEEE8023-LAG-MIB | Implementation of the IEEE 8023-LAG-MIB includes the
|
IF-MIB | Interface description, type, MTU, speed, MAC, admin, operation status, counters. By default, IF-MIB can handle a maximum of 500 interfaces. You can change this setting by editing the value for the As of Cumulus Linux 3.7.11, the IF-MIB cache is enabled by default. To disable the IF-MIB caching for any reason, add the
|
IP-FORWARD-MIB | IP routing table |
IP-MIB (includes ICMP) | IPv4, IPv4 addresses, counters, netmasks |
IPv6-MIB | IPv6 counters |
LLDP-MIB | Layer 2 neighbor information from |
LM-SENSORS MIB | 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 |
NET-SNMP-VACM-MIB | Agent timers, user, group config |
NOTIFICATION-LOG-MIB | Local logging |
SNMP-FRAMEWORK-MIB | Users, access |
SNMP-MPD-MIB | Users, access |
SNMP-TARGET-MIB | |
SNMP-USER-BASED-SM-MIB | Users, access |
SNMP-VIEW-BASED-ACM-MIB | Users, access |
TCP-MIB | TCP-related information |
UCD-SNMP-MIB | System memory, load, CPU, disk IO |
UDP-MIB | UDP-related information |
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:
- bgp4_pp.py
- bridge_pp.py
- cl_drop_cntrs_pp.py
- cl_poe_pp.py
- entity_pp.py
- entity_sensor_pp.py
- ieee8023_lag_pp.py
- resq_pp.py
- snmpifAlias_pp.py
- sysDescr_pass.py
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.
Troubleshooting
Use the following commands to troubleshoot potential SNMP issues:
cumulus@switch:~$ net show snmp-server status
Simple Network Management Protocol (SNMP) Daemon.
--------------------------------- ------------------------------------------------------------------------------------
Current Status failed (failed)
Reload Status enabled
Listening IP Addresses localhost 9.9.9.9
Main snmpd PID 0
Version 1 and 2c Community String Configured
Version 3 Usernames Not Configured
Last Logs (with Errors) -- Logs begin at Thu 2017-08-03 16:23:05 UTC, end at Fri 2017-08-04 18:17:24 UTC. --
Aug 04 18:17:19 cel-redxp-01 snmpd[8389]: Error opening specified endpoint "9.9.9.9"
Aug 04 18:17:19 cel-redxp-01 snmpd[8389]: Server Exiting with code 1
--------------------------------- ------------------------------------------------------------------------------------
cumulus@switch:~$ net show configuration snmp-server
snmp-server
listening-address 127.0.0.1
readonly-community public access default
readonly-community allpass access any
readonly-community temp2 access 1.1.1.1
readonly-community temp2 access 2.2.2.2
trap-destination 1.1.1.1 community-password public version 2c
trap-link-up check-frequency 10
trap-snmp-auth-failures
cumulus@switch:~$ net show configuration commands
...
net add snmp-server listening-address all
net add snmp-server readonly-community allpass access any
net add snmp-server readonly-community temp2 access 1.1.1.1
net add snmp-server readonly-community temp2 access 2.2.2.2
net add snmp-server trap-destination 1.1.1.1 community-password public version 2c
net add snmp-server trap-link-up check-frequency 10
net add snmp-server trap-snmp-auth-failures
...