Technical Tip: Configure and validate Cisco SNMPv3

[FortiKoala]

Description

This article describes general guidance to configure and validate Cisco SNMPv3.  To configure MAC notification traps, refer to the MAC notification traps reference manual in the Fortinet Document Library.

Note: Depending on the switch model or IOS version, some of the commands may vary.

It is recommended to review any associated Cisco product documentation.

For additional information, refer to the Cisco product command reference.

Scope

FortiNAC.

Solution

Requirements:

• Switches must have unique Engine IDs. Engine IDs are used to identify the unit.
• Read and write SNMP v3 privileges are required. The write privileges are necessary for admin control of the port state.
• There are suggestions to skip using '@' symbol in the SNMP community strings (https://www.cisco.com/en/US/docs/switches/lan/catalyst3850/software/release/3se/consolidated_guide/b...).

Unique Engine IDs.

An SNMP engine ID is generated automatically on Cisco devices based on Cisco's enterprise number and the physical address of one of the switch's interfaces. 

Since this method ensures the uniqueness of the engine ID, configuring engine IDs is not needed (although it is possible to do so). 

The ID can be displayed by using the show snmp engineID command.      

Care should be taken when configuring a different engine ID. Refer to the appropriate Cisco documentation for consideration.  It is not uncommon for customers to copy and paste configurations between switches. 

However, the same Engine ID cannot be used on multiple switches.  When the settings are added, an SNMP user is created.  It does not delete the user when a line is deleted, and cleanup can be very tedious. 

If Engine IDs need to be deleted (due to duplicates):

1. Identify the user that corresponds to the Engine ID to be deleted.
2. Delete the user before deleting the corresponding Engine ID. A user cannot be deleted if its corresponding Engine ID was already removed. If the Engine ID was already deleted, add it back and then delete the user.
   
   The commands below show what is configured for SNMP Engine ID, users, groups, and views:

show snmp engineID
show snmp user
show snmp group

show snmp view

Delete the user and the group, then delete the SNMP-server group commands and add them back.

This will recreate the new SNMP user.

SNMP v3 Cisco Configuration Example:

Key:

ACL (if used) = fortinac-acl
SNMP v3 Username = fortinac-user
SNMP v3 Group = fortinac-group
SNMP v3 View (Permissions) = fortinac-view

Example:

snmp-server user fortinac-user fortinac-group v3 auth sha ******** priv aes 128 ******** access fortinac-acl
snmp-server group fortinac-group v3 priv read fortinac-view write fortinac-view notify fortinac-view access fortinac-acl
snmp-server group fortinac-group v3 priv context vlan- match prefix read fortinac-view access fortinac-acl
snmp-server view fortinac-view iso included
snmp-server view fortinac-view system included
snmp-server view fortinac-view interfaces included
snmp-server enable traps snmp coldstart warmstart
snmp-server enable traps mac-notification change move threshold
snmp-server host 192.168.22.131 traps version 3 priv fortinac-user mac-notification

Using the 'context vlan- match prefix' command.

When a MAC Notification trap is received, the trap contains a VLAN ID and a dot1dBasePortTable interface ID. 

To determine the port ID, the dot1dBasePortTable needs to be accessible to read. 

SNMP v3 will not allow access to this table by default, meaning the appliance must be granted rights to read the table.

In more recent versions of IOS, the wildcard 'context vlan- match prefix' can be used to allow  the 'dot1dBasePortTable' to be read. 

Example:

snmp-server group fortinac-group v3 priv context vlan- match prefix read fortinac-view

If older versions of IOS do not accept the 'match prefix' command, then every VLAN id must be added to the allow list. 

Example:

snmp-server group fortinac-group v3 priv context vlan-20 read fortinac-view
snmp-server group fortinac-group v3 priv context vlan-21 read fortinac-view
snmp-server group fortinac-group v3 priv context vlan-22 read fortinac-view

If the appliance does not have the right to read dot1dBasePortTable, authentication failures in the output.master are printed.

Testing the Ability to Read dot1dBasePortTable.

Run the following commands in the appliance CLI:

snmpwalk -v3 -u snmp-user -l AuthPriv -a SHA -A <password> -x AES -X <password> -n vlan-20 <switch ip> 1.3.6.1.2.1.17.1.4.1.2.9

Change the VLAN ID to a valid VLAN on the switch. If authentication errors are returned, something is wrong.

This example calls a specific port (1.3.6.1.2.1.17.1.4.1.2.9). 

Remove the .9 at the end to return all ports on that VLAN.

Once access is specified for the dot1d table, lockout other tables that had access before.

This is why the following line is also included:

snmp-server group fortinac-group v3 priv read fortinac-view write net-monitor notify fortinac-view

To test other tables:

snmpwalk -v3 -u snmp-user -l AuthPriv -a SHA -A <password> -x AES -X <password> <switch ip> ifadminstatus

snmpwalk -v3 -u snmp-user -l AuthPriv -a SHA -A <password> -x AES -X <password> <switch ip> dot1dTpFdbTable

snmpwalk -v3 -u snmp-user -l AuthPriv -a SHA -A <password> -x AES -X <password> <switch ip> iftable

snmpwalk -v3 -u snmp-user -l AuthPriv -a SHA -A <password> -x AES -X <password> <switch ip> ifxtable

snmpwalk -v3 -u snmp-user -l AuthPriv -a SHA -A <password> -x AES -X <password> <switch ip> ifadminstatus

If there are either '@', or '$' signs in the passphrases, it is necessary type passwords within the single quota signs, otherwise, it will fail to test it with snmpwalk service. In the screen of the example below, the passphrase used is 'String$78' (the tested device is not Cisco, it is FortiGate just for testing):

Watch the event logs for SNMP errors. As issues are fixed, the errors will no longer appear.

Related articles:

Technical Note: Troubleshooting SNMP Timeout Errors.