Managing SNMP

This chapter describes how to manage SNMP services on a DMF Controller.

SNMP Overview

SNMP provides a method for communication between an NMS or other client and agents (servers) on network devices, which send reports, called traps, regarding their operation and configuration. The information managed by an SNMP agent is organized as a collection of objects called MIBs.

In SNMPv3, an agent (SNMP server) is identified by an engineID, which helps prevent unauthorized SNMPv3 messages, such as traps, from being accepted or traps being intercepted by unauthorized receivers. The engineID of the SNMP agent is required when configuring an SNMPv3 trap receiver to receive messages from an agent, including a DMF Controller or fabric switch.

In DMF, the engineID is autogenerated for the Controller and fabric switches. The engineID of the DMF Controller is configured for the local node and this configuration must be entered separately on the Active and Standby Controllers. It is recommended to configure a different engineID for each Controller.

Using the DMF GUI to Configure SNMP

To manage or view the Controller SNMP configuration, complete the following steps:

Select Maintenance > SNMP from the main menu.

Figure 1. Configuring SNMP

By default, the SNMP server is disabled.
To enable access to SNMP for the Controller, click the Settings control in the Configuration section.

Figure 2. Configuring SNMP Settings (Page 1 of 4)
To enable SNMP traps, move the slider to Enabled in the Traps section.
Type the appropriate values for the Contact, Location, and Community that helps identify the Controller during SNMP communications.
Click Next.

Figure 3. Configuring SNMP Settings
To apply one or more SNMP community strings, enable the checkbox for the entry.
To define a new community string, click the Provision control (+) at the top of the table.

Figure 4. SNMP Community
Type the community string in the Secret field.
Set the permission to Read-Write if required by sliding the Permission slider to the Right.
Click Append.
Enable the checkbox of the newly added community string and click Next.

Figure 5. Identifying the SNMP Trap Receiver
To add a trap receiver, enable the checkbox for an existing entry on the table.
To add a new entry, click the Provision control (+).

Figure 6. Configuring SNMP Trap Host
Type the IP address and port number for the NMS or other SNMP client to which the controller should sent SNMP trap messages and click Append.

Note: UDP port 162 is the default for SNMP trap messages; UPD port 161 is the default port for general SNMP messages.
Enable the checkbox for the newly added trap receiver and click Submit.
To create an SNMPv3 user, click Next to display page 4 of the dialog.

Figure 7. Configuring SNMPv3 User
Enable the checkbox to add an existing user.
To define a new SNMPv3 user, click Provision control at the top of the table.

Figure 8. Configuring SNMPv3 User
Type the name of the user, the authentication passphrase for the user, and the Private Passphrase for encrypting messages.

Note: You can use the Private Protocol option to perform Advanced Encryption Standard (AES) or Data Encryption Standard (DES) encryption to encrypt the SNMP messages between the SNMP agent and the manager.
Click Append.
Enable the checkbox for each user and click Submit.

Configuring SNMP Traps

To configure the SNMP traps sent to the trap host, complete the following steps:

Select Maintenance > SNMP and on the SNMP landing page, click the Settings control to the left of the SNMP Traps section.

Figure 9. Configure SNMP Traps
Change the percentage of disk utilization or disable the trap by moving the slider to the left. Configuring the disk-percent trap enables monitoring the size of /var/log and the root partitions.
Click Submit.
To enable or disable specific traps, click the Settings control in the Switch Traps section.

Figure 10. Setting Threshold Traps: Events
Enable or disable the event traps on this page, as required.
For the status traps, select the interval after which to send the trap.
After making any changes required, click Next.

Figure 11. Setting Threshold Traps: Thresholds

This page lets you configure threshold-based traps.
Enable or disable any of these traps, and set the percentages, as required. For the Total Available Memory Threshold, select the units (bytes, KB, MB, or GB), and specify the number of units.
Click Next.

Figure 12. Thermal Traps

This dialog lets you enable and configure the minimum and maximum temperature for thermal traps, and the interval between sending traps. You can also enable a trap to be sent when the sensor status is failed, missing, good, or all.
After completing the SNMP trap configuration, click Save.

Using the CLI to Configure SNMP

This section describes how to use the CLI to configure and manage SNMP settings for the DMF Controller cluster.

Note: To configure a separate SNMP server for switches or Service Nodes, configure an access list to permit access from required clients.

Configuring SNMP Access to the Controller

By default, SNMP access to the Controller is disabled. The default access list for SNMP is empty, which means that access is not permitted unless specifically enabled.

The following commands enable access to the Controller by remote SNMP clients on the specified subnetwork:

controller-1(config)# controller
controller-1(config-controller)# access-control
controller-1(config-controller-access)# access-list snmp
controller-1(config-controller-access-list)# 10 permit from 10.8.67.0/24/0

Note: The permit command enables access to the controller from an SNMP client in the subnetwork 10.8.67.0.

To enable access from any subnet, use the access list entry 0.0.0.0/0 (IP v4) and ::/0 (IPv6), as in the following example:

controller-1(config)# controller
controller-1(config-controller)# access-control
controller-1(config-controller-access)# access-list snmp
controller-1(config-controller-access-list)# 10 permit from 0.0.0 .0/0
controller-1(config-controller-access-list)# 20 permit from ::/0

Configuring SNMP Access to the Analytics Node

To allow SNMP walk to the Analytics Node, use the steps highlighted in the section Configuring SNMP Access to the Controller above.

Identifying the SNMP Trap Receiver

To identify a host to receive SNMP traps, from config mode, enter the snmp-server host command, which has the following syntax:

controller-1(config)# snmp-server host <ipaddress> [udp-port <udp-port>]

Replace ipaddress with the IP address of the host. Replace udp-port with the port number used by the SNMP traps. For example, the following command identifies a management system at 192.168.17.150 using UDP port 162.

controller-1(config)# snmp-server host 192.168.17.150 udp-port 162

UDP port 162 is the default for SNMP trap messages; UPD port 161 is the default port for general SNMP messages.

The following are the SNMP traps generated by the Controller running on a VM or the hardware appliance:

Name OID Trap generation
--------------------------------------------------------------------------
cpuload .1.3.6.2.4.1.2021.10.1.5.1 when load (average over 1 minute) > %90
memtotalfree .1.3.6.2.4.1.2021.4.11.0 when freemen (of entire Linux OS) < 50K

The following are the SNMP traps generated only by the hardware appliance:

cputemp .1.3.6.2.2.1.99.1.1.1.4.1001 when CPU core temp > vendor
specified threshold value
ambienttemp .1.3.6.2.2.1.99.1.1.1.4.2001 when chassis inlet temp >
vendor specified threshold value
powersupply .1.3.6.2.2.1.99.1.1.1.4.3001 when power consumption >
vendor specified threshold value
fan**speed .1.3.6.2.2.1.99.1.1.1.4.40** when fan speed < vendor
specified threshold

Starting in DMF 7.3 release, configuring disk-percent trap will monitor root partition in addition to /var/log partition. To configure the trap:

controller-1(config)# snmp-server trap
disk-percent set logging partition space use percentage at which to send trap
<disk-percent> Percent disk utilization (1..100)
controller-1(config)# snmp-server trap disk-percent 75

The following is the entry created in /etc/snmp/snmpd.conf file when you configure the trap on the DMF controller:

monitor -r 30 -I dskPercent .1.3.6.2.4.1.2021.9.1.9.1 > 75

Configuring SNMP Settings

To set the SNMP community string, which is a password used by a management application for accessing SNMP information, enter the snmp-server community command from config mode, as in the following example:

Note: Even though the CLI has options for ro or read-only and rw or read-write types of community strings, currently DANZ Monitoring Fabric supports only the ro option.

controller-1(config)# snmp-server community ro <string>

This sets the community string for read-only access to the SNMP trap server.

Note: For SNMP trap host configuration to be pushed to the monitoring switches, the community string or the SNMPv3 user must be configured on the Controller.

To set the SNMP location, enter the snmp-server location command from config mode, as in the following example:

controller-1(config)# snmp-server location <location>

To set the SNMP contact, enter the snmp-server contact command from config mode, as in the following example:

controller-1(config)# snmp-server contact <contact>

To view the current SNMP configuration, enter the show running-config snmp command.

Note: The community string is displayed in the running-config as a Type 7 encoded value.

To monitor controller’s /var/log and root partitions, configure the following trap:

disk-percent percent: Replace percent with the percentage that triggers a trap when it is exceeded.
Note: Configuring the disk-percent trap on the Analytics Node will monitor the /var/lib/analytics/data folder in addition to the /var/log folder and the root partition.

Configuring SNMP Switch Trap Thresholds

To configure the thresholds for the SNMP traps generated by fabric switches, use the following command:

[no] snmp-server switch trap {cpu-load <cpu-load>| cpu-load 5min <cpu-load5>| cpu-load 15min <cpu-load15>| fm-flow-table-util <util>| mem-free <mem-free>| percent-idle <percent> | percent-utilization <percent>| psu-status <psu-status>| fan-status <fan-status> | link- status <link-status> | auth-fail | thermal [all | failed | good | missing | <interval> <min-temp> <max- temp>]

The following keywords can be used with the snmp-server switch trap command.

auth-fail: Sends a trap when an authentication attempt fails.
cpu-load cpu-load: Replace cpu-load with the threshold for CPU utilization.
fan-status: Sends a trap when the fan status changes. Set the interval for monitoring between 10 and 100,000 seconds.
fm-flow-table-util util: Replace util with the percentage that triggers a trap when it is exceeded.
link-status: Sends a trap when the status of a link changes. Set the interval for monitoring between 1 and 100,000 seconds.
mem-free mem-free: Replace mem-free with the threshold (in bytes) for memory utilization.
percent-idle percent: Replace percent with the percentage of CPU idle utilization that triggers a trap when it is exceeded.
percent-utilization percent: Replace percent with the with the percentage of CPU utilization that triggers a trap when it is exceeded.
psu-status: Generate a trap when PSU status changes. Set the interval for monitoring between 10 and 100,000 seconds.
thermal: Sends a trap when the thermal sensor status changes as specified using the following options.
- all: Includes failed, good, and missing.
- failed: Sends a trap when the thermal sensor fails.
- good: Sends a trap when the thermal environment is normal.
- missing: Sends a trip when the thermal sensor is not present.
- interval: Sends the trip after the expiry of the specified interval. The range is 10 to 100,000 seconds.
- [ min-temp | max-temp ]: A trap is generated when the temperature in degrees Celsius is less than min-temp or greater than max-temp.
  Note: It is highly recommended to use percent-idle or percent-utilization instead of cpu-load trap.

SNMP Traps for DMF Service Node Appliance

The following are the SNMP traps supported by the DMF Service Node appliance.

PSU failed/recovered
Fan failed/recovered
Temp exceeded some threshold or came back to normal
Interfaces up / down
SN inaccessible by controller
SN Netﬂow GW is inaccessible
Percent (%) packet drop exceeded some threshold

Managing the SNMPv3 Engine ID for Trap Receivers

SNMPv3 adds authentication and encryption to the features provided by earlier versions of SNMP (v1 and v2). DMF Release 6.1.0 introduced support for the SNMPv3 user-based security model (USM) for message security through authentication and encryption.

In DMF, the engineID is autogenerated for the fabric switches. To view the engineID for a specific fabric switch, enter the following command:

controller-1> show switch <switch-name> running-config

For the DMF Controller, specify an engine-ID keyword that is used to generate the Controller engine-ID. The engine-ID keyword is a text string, up to 27 characters. To configure the engine-id, use the snmp-server engine-id string command from the config-local-node submode, as in the following example:

controller-1(config)# local node
controller-1(config-local)# snmp-server engine-id controller-1_EngineID

The engineID of the DMF Controller is configured for the local node and this configuration must be entered separately on the active and standby Controllers. It is recommended to configure a different engineID for each Controller.

Note: The engine-id configuration is not included when applying a saved running-config to the Controller. The engine-id configuration must be reapplied using snmp-server engine-id command.

The snmp-server engine-id command sets the engine-ID for the Controller using the following format:

0x80001f8804 + <hex string>

where hex string is the ASCII hex version of the user-supplied string, which can be found using a tool like xxd:

$ echo "abcdef--g" | xxd -ps
6162636465662d2d670a

This command lets you calculate the engine ID, as in the following example.

snmp-server engine-id Controller2_Engine_ID
workstation$ echo "Controller2_Engine_ID" | xxd -ps
436f6e74726f6c6c6572325f456e67696e655f49440a
workstation$

The following is the output from the above with the trailing 0a removed.

0x80001f8804
workstation:~$ sudo cat /var/lib/snmp/snmpd.conf | grep old
oldEngineID 0x80001f8804436f6e74726f6c6c6572325f456e67696e655f4944 <--------

Configuring SNMPv3 Users

Use the snmp-server user command in config mode to create a user account for SNMP v3 access. When running an snmpwalk (snmpget, snmpgetnext, snmpbulkget) from a shell, passphrases should be enclosed in single quotes. Entering the passphrase with double quotes (” “), may result in an error. This command has the following syntax:

[no] snmp-server user <name> {auth [0] <cleartext passphrase> | 7 <auth-passphrase>} [ priv {aes | des}{[0] <cleartext passphrase> | 7 <priv-passphrase>}]

The following is the meaning of each keyword:

auth | auth 0 | auth 7: Use a plaintext passphrase or a type 7 encoded passphrase.
cleartext-passphrase: A cleartext passphrase from 8 to 64 alphanumeric characters including dash (“-” and space). A dash or whitespace is not allowed at the beginning or end of the passphrase. Other special characters are not allowed.
private-passphrase: A type 0 encoded passphrase from 8 to 64 alphanumeric characters including dash (“-”) and space. A dash or whitespace is not allowed at the beginning or end of the passphrase. Other special characters are not allowed
type-7-passphrase: A type 7 encoded passphrase from 8 to 128 alphanumeric characters including dash (“-”) and space. The maximum text string length that can be used with a Type 7 encoder, which can be found online, is 64. A dash or whitespace is not allowed at the beginning or end of the passphrase. Other special characters are not allowed.
priv {aes | des}: Optional keyword to perform Advanced Encryption Standard (AES) or Data Encryption Standard (DES) encryption of the following passphrase, which is used as an encryption key to encrypt the SNMP messages between the SNMP agent and the manager.
user username: Up to 32 alphanumeric characters including dash (“-“) and underscore (“_”) Spaces are not permitted. After you configure the username with a plaintext passphrase, the output from the show snmp-server command displays the passphrases in Type7 encoded strings. The controller configuration gets pushed through zero touch networking (ZTN) to the connected fabric switches.
Note: Currently DANZ Monitoring Fabric supports only the ro or read-only type of community string option.

SNMPv3 Command Examples

In the following example the snmp_1 user is configured for authentication (authNoPriv) with the plaintext password authauth1.

controller-1(config)# snmp-server user snmp_1 auth authauth1

In the following example, the snmp-2 user is configured for authentication (authNoPriv) with the plaintext password authauth1.

controller-1(config)# snmp-server user snmp-2 auth 0 authauth2

In the following example, the snmp11 user is configured for authentication and DES encryption (authpriv) with the auth password authauth11 and the encryption key privpriv11.

controller-1(config)# snmp-server user snmp11 auth 0 authauth11 priv des 0 privpriv11

In the following example, the snmp21 user is configured for authentication and AES encryption (authpriv) with the auth password authauth21 and the encryption key privpriv21.

controller-1(config)# snmp-server user snmp21 auth 0 authauth21 priv aes 0 privpriv21

The following are examples of Type7 encoded passphrases:

controller-1(config)# snmp-server user snmp1 auth 7 0207114f03071a35441f
controller-1(config)# snmp-server user snmp20 auth 7 0207114f03071a35441c59 priv des 7 021616521d161d285a1c59
controller-1(config)# snmp-server user snmp30 auth 7 0207114f03071a35441d59 priv aes 7 021616521d161d285a1d59

Configuring SNMP on a Specific Switch

Configuring SNMP for a specific switch does not affect the Controller or other switches. Otherwise, the configuration is similar to configuring SNMP at the Controller level, using the Maintenance > SNMP option.

Note: Before you can configure SNMP for a specific switch, you must enable SNMP access to the Controller.

Using the GUI to Configure SNMP on a Specific Switch

To use the GUI to merge/override the default SNMP configuration with switch specific SNMP configuration, complete the following steps:

Select Fabric > Switches and click the link for a specific switch.
On the Switches page, click the Settings control for Configure Switch.

Figure 13. Configure Switch Dialog

This page allows merging and overriding the default configuration pushed from the DANZ Monitoring Fabric (DMF) Controller with switch specific SNMP configuration.
To merge/override the SNMP configuration, click the 3. SNMP link. Choose from the SNMP Settings drop down to either Merge with Global Config or Override Global Config.
Make any changes required to the specific switch configuration and click Next if you want to customize the SNMP traps, or click Submit if you are done.
To merge/override the configuration for SNMP traps, click the 4. SNMP Traps link and choose from the SNMP Switch Trap Settings drop down to either Merge with Global Config or Override Global Config.
Make any changes required to the specific switch configuration and click Submit.

Using the CLI to Configure SNMP on a Specific Switch

Note: Before you can enter SNMP commands from the config-switch submode, you must enable SNMP access to the Controller.

When using the config-switch submode for a specific switch, configuration changes, including SNMP, do not affect the Controller or other switches. Otherwise, the configuration is very similar to configuring SNMP in config mode at the Controller level.
When you enter the snmp-server enable traps command in config mode, this pushes snmp-server enable configuration to each connected fabric switch. You can verify the switch configuration by entering the show effective-config switch switch-name snmp from the CLI, as in the following example.
```
controller-1(config)# snmp-server enable traps
```

From the switch CLI:

controller-1(config)# show effective-config switch switch-btsw-1 snmp
! switch
switch switch-btsw-1
snmp-server enable traps

Like the GUI, CLI can also be used to merge/override the default SNMP configuration with switch specific SNMP configuration. To do so, complete the following steps:

Add SNMP configuration at the Controller. This is the default SNMP configuration that is pushed to all the switches. An example configuration is shown below:

controller-1(config)# show running-config snmp
! snmp-server
snmp-server host 10.1.1.1
snmp-server enable traps
snmp-server community ro 7 02161159070f0c
snmp-server contact Alice
snmp-server location 'San Francisco'
snmp-server user user1 auth 7 0217135e191216344541

Configure switch specific parameters at the config-switch submode. Steps shown below:

controller-1(config)# switch-btsw-1
controller-1(config-switch)# snmp-server host 10.1.1.2
controller-1(config-switch)# snmp-server contact Bob
controller-1(config-switch)# snmp-server location 'San Jose'
controller-1(config-switch)# snmp-server user user2 auth 0 qwertyuiop

In the config-switch submode, type either merge-global to merge global config with switch specific config or override-global to override the global config with the switch config. If neither is chosen, the switch inherits the global con- fig and any configuration added under the config-switch submode will be redundant.
```
controller-1(config-switch)# snmp-server merge-global
```

Check the snmp config running on the switch using the CLI command show effective-config switch switch-name snmp:

controller-1(config-switch)# show effective-config switch switch-btsw-1 snmp
! switch
switch switch-btsw-1
snmp-server host 10.1.1.1
snmp-server host 10.1.1.2
snmp-server enable traps
snmp-server community ro 7 02161159070f0c
snmp-server contact Bob
snmp-server location 'San Jose'
snmp-server user user1 auth 7 0217135e191216344541
snmp-server user user2 auth 7 0207175f0d01072b4742

It is seen that with merge-global, the effective configuration on the switch is a merge of the global configuration and the switch specific configuration.

Note: SNMP community, user and host are of list-type. In merge-mode these list-type configs append to potentially existing global config.

Below is an example with override-global:

controller-1(config-switch)# snmp-server override-global
controller-1(config-switch)# show effective-config switch switch-btsw-1 snmp
! switch
switch switch-btsw-1
snmp-server host 10.1.1.2
snmp-server contact Bob
snmp-server location 'San Jose'
snmp-server user user2 auth 7 0207175f0d01072b4742

It is seen that with override-global, the effective configuration on the switch is only the switch specific configuration. The default configuration inherited from the controller is completely overridden.

Configuring SNMP traps using merge and override global commands are similar. See examples below:

controller-1(config)# snmp-server switch trap thermal all
controller-1(config)# snmp-server switch trap link-status 5
controller-1(config)# snmp-server switch trap percent-utilization 80
controller-1(config)# switch-btsw-1
controller-1(config-switch)# snmp-server switch trap thermal failed
controller-1(config-switch)# snmp-server switch trap link-status 1
controller-1(config-switch)# snmp-server switch trap percent-utilization 90

Example with merge-global:

controller-1(config-switch)# snmp-server trap merge-global
controller-1(config-switch)# show effective-config switch switch-btsw-1 snmp-trap
! switch
switch switch-btsw-1
snmp-server switch trap thermal failed
snmp-server switch trap link-status 1
snmp-server switch trap percent-utilization 90

Example with override-global:

controller-1(config-switch)# snmp-server trap override-global
controller-1(config-switch)# show effective-config switch switch-btsw-1 snmp-trap
! switch
switch switch-btsw-1
snmp-server switch trap thermal failed
snmp-server switch trap link-status 1
snmp-server switch trap percent-utilization 90

To limit SNMP access to clients in specific IP subnetworks, Enter the snmp-server community command from the config-switch submode on the DMF Controller. This command has the following syntax:
```
snmp-server community {rw | ro} {<cleartext secret> | 0 <cleartext secret> | 7 <obfuscated secret>}
```

Using the merge-global and override-global commands at the config-switch submode, the SNMP community for the switch can be changed. An example configuration is shown below:

SNMP config at the controller:

controller-1(config)# show running-config snmp
! snmp-server
snmp-server host 10.1.1.1
snmp-server community ro 7 02161159070f0c
snmp-server contact Alice
snmp-server location 'San Francisco'
snmp-server user user1 auth 7 0217135e191216344541

SNMP config at the switch:

controller-1(config-switch)# show run switch switch-btsw-1
! switch
switch switch-btsw-1
snmp-server override-global
snmp-server enable traps
snmp-server host 10.1.1.2
snmp-server community ro 7 021616521d071b24
snmp-server contact Bob
snmp-server location 'San Jose'
snmp-server user user2 auth 7 0207175f0d01072b4742

SNMP Clear Trap

SNMP trap messages are sent whenever a threshold is reached or HW failure happens like PSU failure/removal. SNMP clear trap message is sent whenever threshold is less than user specified range or HW failure is fixed such as PSU starts working.

There is no command to enable this feature. This feature is automatically enabled when SNMP trap is configured in the Controller.

SNMP traps which do not have associated clear traps have other ways of notifying state change. For example link up and link down traps are sent when the link goes up and down. All SNMP traps and clear trap settings are listed under /etc/snmp/snmpd.conf file.

Note: SNMP clear traps will be sent without any prior associated SNMP traps when system comes up or there is any SNMP config change. Ignore these SNMP clear traps.

SNMP clear trap messages are not supported on DMF switches running EOS.

The following are switch traps for which clear traps will be sent:

switch trap cpu-load
switch trap fm-ﬂow-table-util
switch trap mem-free
switch trap percent-idle
switch trap percent-utilization

These are the appliance (Controller, Service Node, Recorder Node, Analytic Node) traps for which clear traps will be sent.

Note: Appliance IDRAC Firmware version should upgraded to recommended version 5.10.50.00 or later.

disk-percent
memtotalfree
lowmemavailable
cpuload
cputemp
cpu1temp
ambienttemp
exhausttemp
powersupply
fanspeed	Number of fans on appliance vary. Depending on number of fans on the appliance fanspeed clear traps are sent. Fan speed traps are named `fan1Aspeed`, `fan1Bspeed` etc.
psuCount
fanCount

SNMP Trap Generation for Packet Drops and Link Saturation

Users wishing to be notified about packet drops or high link saturation in the DMF fabric can receive SNMP traps for these events.

Specifically, when trap generation is enabled, the following events will send an SNMP trap to the configured trap collector:

Transmit packet drop counter increase at a switch interface managed by DMF.
Traffic saturation levels above the high watermark of 90% on a link managed by DMF.
A drop in traffic saturation levels to below the low watermark of 70% if the link was previously saturated.

Note: This feature is compatible with all hardware platforms compatible with DMF 8.4. However, this does not include the DMF Managed Analytics, Recorder Node, and Service Node appliances.

SNMP Trap Generation for Packet Drops and Link Saturation introduces the following OIDs:

OID	Type	Description
`.1.3.6.1.4.1.37538.68.77.70`	none	Root of the tree for custom DMF extensions.
`.1.3.6.1.4.1.37538.68.77.70.1`	none	Subtree root for link saturation warnings based on data from the endpoint applications/dmf/info/warnings/link-saturation.
`.1.3.6.1.4.1.37538.68.77.70.1.1.0`	integer	The number of new link saturation warnings that have been detected since the last polling interval (15 seconds).
`.1.3.6.1.4.1.37538.68.77.70.1.2.0`	integer	The number of link saturation warnings that have cleared since the last polling interval (15 seconds).
`.1.3.6.1.4.1.37538.68.77.70.1.3.0`	oidref	The OID to the start of the table containing all known link saturation warnings. Always holds the value: `.1.3.6.1.4.1.37538.68.77.70.1.5` This object is sent as a varbind in the trap newLinkSaturationWarnings to indicate to the trap collector that this OID should be used in a walk for the updated list of warnings.
`.1.3.6.1.4.1.37538.68.77.70.1.4.0`	oidref	The OID to the start of the table containing all cleared link saturation warnings since the last polling interval. Always holds the value: `.1.3.6.1.4.1.37538.68.77.70.1.6` This object is sent as a varbind in the trap linkSaturationWarningsCleared to indicate to the trap collector that this OID should be used in a walk for the updated list of cleared warnings.
`.1.3.6.1.4.1.37538.68.77.70.1.5`	string	Start/root of the table of link saturation warnings. Holds the string: "Table of current warnings"

SNMP Trap Generation for Packet Drops and Link Saturation OIDs (cont'd):

OID	Type	Description
`.1.3.6.1.4.1.37538.68.77.70.1.5.1`	string	[Table row 1] A string summarizing a link saturation warning as a dot-separated tuple of switch DPID, interface name, and traffic direction (either ‘RX’ or ‘TX’). Example: "00:00:52:54:00:a2:d8:9d.ethernet2.TX" Indicates that port ethernet2 on the switch identified by DPID 00:00:52:54:00:a2:d8:9d has experienced transmit link saturation levels above 90%.
`.1.3.6.1.4.1.37538.68.77.70.1.6`	string	Start/root of the table of cleared link saturation warnings. Holds the string: "Table of cleared warnings"
`.1.3.6.1.4.1.37538.68.77.70.1.6.1`	string	[Table row 1] A string summarizing a recently-cleared link saturation warning as a dot-separated tuple of switch DPID, interface name, and traffic direction (either ‘RX’ or ‘TX’). Example: "00:00:52:54:00:a2:d8:9d.ethernet2.TX" Indicates that the transmit link saturation warning for port ethernet2 on the switch identified by DPID 00:00:52:54:00:a2:d8:9d has cleared (dropped below the low watermark of 70%).
`.1.3.6.1.4.1.37538.68.77.70.2`	None	Subtree root for packet drop warnings which are issued when the TX drop counter of an interface increases. Based on the data from the endpoint `core/switch/dmf-stats/interface`
`.1.3.6.1.4.1.37538.68.77.70.2.1.0`	integer	The number of interfaces that have experienced an increase in the transmit drop counter since the last polling interval (15 seconds).
`.1.3.6.1.4.1.37538.68.77.70.2.2.0`	oidref	The OID to the start of the table containing all of the interfaces that have seen its transmit drop counter increase since the last polling interval. Always holds the value: `.1.3.6.1.4.1.37538.68.77.70.2.3` This object is sent as a varbind in the trap newPacketDropsWarnings to indicate to the trap collector that this OID should be used in a walk for the updated list of interfaces with increased counters.
`.1.3.6.1.4.1.37538.68.77.70.2.3`	string	Start/root of the table of interfaces. Holds the string: "Table of interfaces with incremented drop counters"
`.1.3.6.1.4.1.37538.68.77.70.2.3.1`	string	[Table row 1] A string representing an interface that has experienced a transmit drop counter increase. Example: “00:00:52:54:00:a2:d8:9d.ethernet2” represents interface ethernet2 on the switch identified by DPID 00:00:52:54:00:a2:d8:9d.
`.1.3.6.1.4.1.37538.68.77.70.2.3.2`	counter64	[Table row 2] An unsigned integer holding the current counter value.

This feature introduces the following traps:

newLinkSaturationWarnings
- When new link saturation warnings are generated, in addition to its name, the trap contains the following varbinds:
  - .1.3.6.1.4.1.37538.68.77.70.1.1.0
  - .1.3.6.1.4.1.37538.68.77.70.1.3.0
linkSaturationWarningsCleared
- When one or more existing link saturation warnings are cleared, in addition to its name, the trap contains the following varbinds:
  - .1.3.6.1.4.1.37538.68.77.70.1.2.0
  - .1.3.6.1.4.1.37538.68.77.70.1.4.0
newPacketDropsWarnings
- When packet drop counters are seen incrementing on one or more managed interfaces, in addition to its name, the trap contains the following varbinds:
  - .1.3.6.1.4.1.37538.68.77.70.2.1.0
  - .1.3.6.1.4.1.37538.68.77.70.2.2.0

When traps are enabled, the Controller can be queried for the monitored data to send the traps. The MIB for this feature is rooted at the OID .1.3.6.1.4.1.37538.68.77.70 . For a controller at 192.0.2.1 with an SNMP community named example, a query using snmpwalk and the corresponding response may resemble the following:

$ snmpwalk -v2c -c example 192.0.2.1 .1.3.6.1.4.1.37538.68.77.70
iso.3.6.1.4.1.37538.68.77.70.1.1.0 = INTEGER: 0
iso.3.6.1.4.1.37538.68.77.70.1.2.0 = INTEGER: 0
iso.3.6.1.4.1.37538.68.77.70.1.3.0 = OID: iso.3.6.1.4.1.37538.68.77.70.1.5
iso.3.6.1.4.1.37538.68.77.70.1.4.0 = OID: iso.3.6.1.4.1.37538.68.77.70.1.6
iso.3.6.1.4.1.37538.68.77.70.1.5 = STRING: "Table of current warnings"
iso.3.6.1.4.1.37538.68.77.70.1.5.1.1 = STRING: "00:00:52:54:00:a2:d8:9d.ethernet2.TX"
iso.3.6.1.4.1.37538.68.77.70.1.5.1.2 = STRING: "00:00:5c:54:00:f2:81:03.ethernet0.RX"
iso.3.6.1.4.1.37538.68.77.70.1.5.1.3 = STRING: "00:00:12:b0:03:22:07:a2.ethernet1.RX"
iso.3.6.1.4.1.37538.68.77.70.1.5.1.4 = STRING: "00:00:50:ef:0c:a2:16:f6.ethernet3.TX"
iso.3.6.1.4.1.37538.68.77.70.1.6 = STRING: "Table of cleared warnings"
iso.3.6.1.4.1.37538.68.77.70.2.1.0 = INTEGER: 2
iso.3.6.1.4.1.37538.68.77.70.2.2.0 = OID: iso.3.6.1.4.1.37538.68.77.70.2.3
iso.3.6.1.4.1.37538.68.77.70.2.3 = STRING: "Table of interfaces with incremented drop counters"
iso.3.6.1.4.1.37538.68.77.70.2.3.1.1 = STRING: "00:00:52:54:00:a2:d8:9d.ethernet2"
iso.3.6.1.4.1.37538.68.77.70.2.3.1.2 = STRING: "00:00:52:a4:31:f2:81:56.ethernet0"
iso.3.6.1.4.1.37538.68.77.70.2.3.2.1 = Counter32: 11
iso.3.6.1.4.1.37538.68.77.70.2.3.2.2 = Counter32: 1

The tables in the response are empty when there are no warnings:

iso.3.6.1.4.1.37538.68.77.70.1.1.0 = INTEGER: 0
iso.3.6.1.4.1.37538.68.77.70.1.2.0 = INTEGER: 0
iso.3.6.1.4.1.37538.68.77.70.1.3.0 = OID: iso.3.6.1.4.1.37538.68.77.70.1.5
iso.3.6.1.4.1.37538.68.77.70.1.4.0 = OID: iso.3.6.1.4.1.37538.68.77.70.1.6
iso.3.6.1.4.1.37538.68.77.70.1.5 = STRING: "Table of current warnings"
iso.3.6.1.4.1.37538.68.77.70.1.6 = STRING: "Table of cleared warnings"
iso.3.6.1.4.1.37538.68.77.70.2.1.0 = INTEGER: 0
iso.3.6.1.4.1.37538.68.77.70.2.2.0 = OID: iso.3.6.1.4.1.37538.68.77.70.2.3
iso.3.6.1.4.1.37538.68.77.70.2.3 = STRING: "Table of interfaces with incremented drop counters"

Using the CLI to Configure the SNMP Traps

This feature is enabled by enabling trap generation, configuring an SNMP community or USM user for sending the traps, and specifying a trap receiver host, as shown below.

(config)# snmp-server enable traps
(config)# snmp-server community ro example
(config)# snmp-server host 192.0.2.10

Traps are disabled when trap generation is disabled using the following command:

(config)# no snmp-server enable traps

CLI Show Commands

SNMP configurations, including traps, communities, or users, appear in the running-config using the show command.

# show running-config snmp

! snmp-server
snmp-server host 192.0.2.10
snmp-server enable traps
snmp-server community ro 7 02031c5a06160324

The configuration entry snmp-server enable traps indicates that trap support, including this feature, are enabled.

Syslog Messages

SDCACHE7001: Error while refreshing cache for Query{<query>, includedStateTypes=[LOCAL_CONFIG, GLOBAL_CONFIG, OPERATIONAL]}

<query> is one of:
- basePath=/applications/dmf/info/warnings/link-saturation
- basePath=/core/switch, selectedPaths=[dmf-stats/interface]
Generated when the statistics collected and monitored for this feature could not be cached. The message is logged along with a stack trace containing further details.

SDCACHE7002: Query for data failed for Query{<query>, includedStateTypes=[LOCAL_CONFIG, GLOBAL_CONFIG, OPERATIONAL]}

<query> is one of:
- basePath=/applications/dmf/info/warnings/link-saturation
- basePath=/core/switch, selectedPaths=[dmf-stats/interface]
Generated when the periodic query to the Controller for collecting the statistics monitored when evaluating if traps should be sent failed. The message is logged along with a stack trace containing further details.

SNMPEXT4001: Could not disable configuration <configuration>

<configuration> is one of:
- dmf_trap_monitors
- dmf_warning_extensions
Generated when the SNMP configurations associated with a trap, named [configuration], could not be disabled. The message is logged along with a stack trace containing further details.

SNMPEXT4002: Could not enable configuration <configuration>

<configuration> is one of:
- dmf_trap_monitors
- dmf_warning_extensions
Generated when the SNMP configurations associated with a trap, named [configuration], could not be enabled. The message is logged along with a stack trace containing further details.

Troubleshooting

If the CLI show command indicates:

traps are enabled;
a community or user is configured; and
a trap host is configured.

The trap host may not be reachable from the Controller, or statistics collection and monitoring for packet drops or link saturation may need to be enabled correctly. Check the logs for any messages described in the previous section using the following command:

> show logging controller | grep ‘SDCACHE\|SNMPEXT’

Contact This email address is being protected from spambots. You need JavaScript enabled to view it. if any of these logs appear and:

Traps are not sent from a system with known link saturation or packet drop warnings, e.g., via the CLI or GUI.
A query, e.g., snmpwalk for OIDs rooted under 1.3.6.1.4.1.37538.68.77.70 do not result in responses or return errors.

Considerations

The link saturation trap thresholds cannot be specified by the user. Traps are sent when link saturation levels cross the 90% threshold, and are cleared once levels drop below 70%.
The tree associated with this feature is only available through polling with snmpwalk when traps are enabled.
The OIDs do not have resolvable names.
Polling of link and interface states happens on a fixed interval; there may be a several-second delay between the occurrence of a trap-triggering event and sending the trap.

DANZ Monitoring Fabric Deployment Guide