SNMP in ACI: Configuration and Verification

SNMP is a protocol that plays a crucial role in the management and monitoring of network devices. This article covers the SNMP protocol in Cisco ACI, exploring the necessary SNMP configuration and verification for APIC and fabric switches.

In This Article

SNMP in ACI Overview
- SNMP in ACI Configuration Prerequisites
SNMP Configuration in ACI
- (SNMP Polling) Configuration Using GUI
- (SNMP TRAPs) Configuration Using GUI
SNMP Verification in ACI
Conclusion

SNMP in ACI Overview

Cisco ACI provides SNMP v1, v2c, and v3 support, including Management Information Bases (MIBs) and notifications (Traps). The SNMP standard allows any third-party applications that support the different MIBs to manage and monitor the ACI node switches and APIC controllers. However, SNMP write commands (Set) are NOT supported in ACI.

The SNMP policy is applied and runs independently on node switches and APIC controllers because each ACI device has its own SNMP entity, i.e. multiple APICs in an APIC Cluster must be monitored separately. However, the SNMP policy source is created as a monitoring policy for the entire ACI fabric.

By default, the SNMP protocol uses UDP port 161 for polling and port 162 for TRAPs. In ACI, the SNMPD process on the APIC controller has two components:

Agent: The SNMP Agent is an open-source net-snmp agent. The SNMP agent handles SNMP sessions from the snmp clients. It handles the SNMP protocol processing.
DME: The SNMP DME handles the MIT interface to read the Managed Objects (MOs) and translate the information into SNMP Object Format.

SNMP in ACI Configuration Prerequisites

Before configuring SNMP in ACI, we need to make sure we meet the following requirements:

The ACI fabric discovery was completed.
In-band (INB) or out-of-band (OOB) IP connectivity to the ACI APICs and fabric switches with the NMS server (SNMP Polling server/ TRAP destination).
In-band (INB) or Out-of-band (OOB) contracts configured to allow SNMP traffic (UDP ports 161 and 162), the SNMP packets will be dropped unless the contract is created for enabling the SNMP port (UDP:161/162). This is different from enabling/disabling the SNMP protocol.
Static node management addresses are configured for the APICs and fabric switches under the default mgmt tenant (without this, pulling SNMP info from an APIC will fail).

SNMP Configuration in ACI

We will cover the configuration using the GUI only! for both SNMP polling and SNMP Traps.

(SNMP Polling) Configuration Using GUI

■ In ACI, there are two SNMP scopes that we can pull the information from:

(1) Global: pull chassis MIBs such as number of interfaces, interface indexes, interface names, interface status, etc., in a leaf or spine node. The MIB in the global scope has only one instance in the system. i.e., The data in the global MIB relates to the overall system.
(2) VRF Context: pull VRF-specific information such as IP addresses and routing protocol information. The MIB in the VRF-specific scope has per-VRF instances in the system. i.e., The data in the VRF-specific MIB relates only to that VRF.

Find the full list of the supported APIC and fabric nodes global and VRF context MIBs here.

■ Configuration Steps (for both global and VRF context scopes):

Step 1: Configure the SNMP Fabric policy. (SNMP settings specified, such as SNMP community policies and SNMP Client Group policies).
Step 2: Apply SNMP policy to the Pod policy group (Fabric Policy Group).
Step 3: Associate the Pod policy group with the Pod profile.
At this stage, we configure basic SNMP configuration for global MIBs.
Step 4: Configure VRF context scopes.

Step 1: Configure the SNMP Fabric Policy

The first step in configuring SNMP is to create the necessary SNMP Fabric Policies. To create the SNMP Fabric Policies, navigate to the following APIC web GUI path:

Fabric -> Fabric Policies -> Policies -> Pod -> SNMP

In our example here, the SNMP policy is called New_SNMP_Policy. We will use SNMP version 2c, so the only fields needed here are Community Policies and Client Group Policies.

The Community Policy Name field defines the SNMP community string to be used. In our case, New_CommString1 and New_CommString2. We will see where these two community strings are used later.

The next step is to add the Client Group Policy/Profile; the purpose of the Client Group Policy/Profile is to define what IPs/subnets can pull SNMP data from APICs and fabric switches:

Our Client Group Policy/Profile is called ALL_Networks.

In the Client Group Policy/Profile, we need to associate our preferred Management EPG. We must ensure the Management EPG you choose has the necessary contracts to allow SNMP traffic (UDP ports 161 and 162). For our purposes, we are going to use the default Out-of-Band Management EPG.

The last step is to define your Client Entries to allow specific IPs or entire subnets access to pull ACI SNMP data; below is the syntax for defining a specific IP or an entire subnet:
– Specific host IP: 192.168.100.5
– Entire Subnet: 192.168.100.0/24

Step 2: Apply SNMP policy to the Pod policy group

Next, we need to tie the newly created SNMP Policy, New_SNMP_Policy, to the Pod Policy Group. For our purposes, we will use a custom one called New_Pod_Policy_Group.

Fabric -> Fabric Policies -> Pods -> Policy Groups -> POD_POLICY_GROUP (New_Pod_Policy_Group: in our example)

On the right hand pane you will see a field for SNMP Policy. From the drop down, select your newly created SNMP Policy and submit your changes.

Step 3: Associate the Pod policy group with the Pod profile

In our case, we will use the default pod profile for simplicity. To do so, navigate to the following APIC web GUI path:

Fabric -> Fabric Policies -> Pods -> Profiles -> POD_PROFILE (default: in our example)

At this point, we have completed all the necessary steps (Steps 1-3) for SNMP configuration, and we implicitly used the global MIB scope, where an snmp walk can be done for any ACI node or APIC now.

Step 4: Configure VRF context scopes

Once we associate a community string to a VRF Context, that specific community string cannot be used to pull Global scope SNMP data, so it is required to create two SNMP community strings if you want to pull both Global scope and VRF Context SNMP data.

In our case, we previously created two community strings (in step 1), namely (New_CommString1 and New_CommString2). We will use New_CommString2 for the VRF context scope.

In our case, we will use VRF-1 custom VRF in the salhiary custom tenant. To do so, navigate to the following APIC web GUI path:

Tenants -> salhiary -> Networking -> VRFs -> VRF-1 (right click) -> Create SNMP Context

After submitting the configuration, you can verify the SNMP Context configuration you applied by left-clicking your VRF, going to the Policy tab on the VRF, and scrolling down toward the bottom of the page (see below):

To disable an SNMP Context on a VRF, you can de-select the Create SNMP Context checkbox (seen in the above screenshot) or right-click the VRF and select Delete SNMP Context.

(SNMP TRAPs) Configuration Using GUI

SNMP TRAPs are sent to the SNMP server (SNMP Destination/NMS) without polling; ACI node/APIC will send the SNMP TRAP once the fault/event (defined condition) happens.

SNMP Traps are enabled based on policy scope under Access/Fabric/Tenant monitoring policies. ACI supports a maximum of 10 Trap receivers.

To configure SNMP TRAPs in ACI, we need the following two steps in addition to steps 1, 2, and 3 in the previous section:
– Step 1: Configure SNMP TRAP Server (Destination).
– Step 2: Configure SNMP TRAP Source under (Access/Fabric/Tenant) monitoring policy.

Notes:
– Without Steps 1-3 from the previous section, SNMP TRAPs configuration won’t be enough.
– Step 2 in SNMP TRAP configuration related to the Monitoring Policies of (Access/Fabric/Tenant).

Step 1: Configure SNMP TRAP Server (Destination)

To do so, navigate to the following APIC web GUI path:

Admin -> Eternal Data Collectors -> Monitoring Destinations -> SNMP

In our case, we will use SNMP_TRAP_Destination for our SNMP Monitoring Destination Group name, 192.168.100.250 for the SNMP trap destination IP address, and New_CommString1 for Community Name.

Step 2: Configure SNMP TRAP Source under (Access/Fabric/Tenant) monitoring policy

» We can create monitoring policies with the following scopes:
– Access: access ports, FEX, VM controllers …
– Fabric: fabric ports, line-cards, chassis, fans …
– Tenant: EPGs, application profiles, services…

The following is an example for each one of them:

(Step 2.1) Define SNMP Source Under Access Policies

Fabric -> Access Polices -> Polices ->  Monitoring -> Default -> Callhome/Smart Callhome/SNMP/Syslog/TACACS

Notes:
We can use a custom-defined Monitoring policy (if configured) instead of the default one. Here, I used the default one. Also, we can specify which monitoring object to monitor. Here, I used ALL.

(Step 2.2) Define SNMP Source Under Fabric Policies

Fabric -> Fabric Polices -> Polices -> Monitoring -> Default -> Callhome/Smart Callhome/SNMP/Syslog/TACACS

(Step 2.3) Define SNMP Source Under Tenant Policies

Tenant-> (Tenant Name) -> Polices ->  Monitoring -> (Custom monitoring policy) -> Callhome/Smart Callhome/SNMP/Syslog/TACACS

At this point, we finished the configuration part.

SNMP Verification in ACI

In this article, I will be discussing a series of CLI commands that are essential for verifying SNMP in ACI:
– Using CLI “show” commands.
– Using CLI “moquery” commands.

Using CLI “show” Commands

For APIC:

show snmp
show snmp policy <SNMP_policy_name>
show snmp summary
show snmp clientgroups
show snmp community
show snmp hosts
show snmp engineid

For Nodes (Leaf/Spine):

show snmp
show snmp | grep "SNMP packets"
show snmp summary
show snmp community
show snmp host
show snmp engineID
show snmp context
show snmp user
show snmp internal dump-internal-log
show snmp internal globals
show snmp internal trace log

The best show command to start with is the ‘show snmp summary‘ to retrieve summary information on SNMP configuration in both APIC and Nodes.
Check the following from the “show snmp summary” command output:
- The “Admin State” should be “Enabled”.
- The “SNMP Community” is configured.
- The “Client Group” Hosts & VRF are allowed to send SNMP Get\Walk Requests (UDP PORT 161).
- The Destination Host(s), PORT# & VRF for sending SNMP Traps (UDP PORT 162 or Custom Port).

Example:

apic1# show snmp summary
Active Policy:  New_SNMP_Policy, Admin State: enabled
Local SNMP engineID: [Hex] 0x8000000980e2b6c2088976c88600000000
----------------------------------------
Community Description
----------------------------------------
New_CommString1                          
New_CommString2

------------------------------------------------------------
User                 Authentication       Privacy             
------------------------------------------------------------

------------------------------------------------------------
Client-Group         Mgmt-Epg                  Clients
------------------------------------------------------------
ALL_Networks         default (Out-Of-Band)     --

------------------------------------------------------------
Host                 Port  Version  Level      SecName             
------------------------------------------------------------
192.168.100.250      162   v2c      noauth     New_CommString1 


leaf1# show snmp summary 

Admin State : enabled, running (pid:10740)

Local SNMP engineID: [Hex] 8000000903002A103ECAB5
                     [Dec] 128:000:000:009:003:000:042:016:062:202:181

----------------------------------------------------------------------
Community                         Context                   Status
----------------------------------------------------------------------
New_CommString2                   New_SNMP_Ctx              ok
New_CommString1                                             ok

----------------------------------------------------------------------
User                              Authentication  Privacy   Status
----------------------------------------------------------------------

----------------------------------------------------------------------
Context                           VRF                       Status              
----------------------------------------------------------------------
New_SNMP_Ctx                      salhiary:VRF-1            ok

----------------------------------------------------------------------
Client                                  VRF                 Status
----------------------------------------------------------------------

-------------------------------------------------------------------------------
Host                                    Port Ver  Level   SecName        VRF
-------------------------------------------------------------------------------
192.168.100.250                         162  v2c  noauth  New_CommString1 management

Using CLI “moquery” Commands

Another method to confirm the setup of SNMP Policies in ACI is through Managed Object (MO) queries. For each Leaf, Spine, or APIC where SNMP is configured, we can utilize tools like moquery or Visore.

moquery -c snmpGroup – The SNMP destination group, which contains information needed to send traps or informs to a set of destinations.
moquery -c snmpTrapDest – A destination to which traps and informs are sent.
moquery -c snmpRtDestGroup – A target relation to SNMP destination group. This group contains information needed to send traps or informs to a set of destinations.
moquery -c snmpPol – The SNMP policy, which enables you to monitor client group, v3 user, and/or community SNMP policies.
moquery -c snmpClientGrpP – A client group, which is a group of client IP addresses that allows SNMP access to APICs or switches.
moquery -c snmpCommunityP – The SNMP community profile, which enables access to APICs or switches statistics for monitoring.
moquery -c snmpRtSnmpPol – A target relation to an SNMP policy that contains site information and general protocol configuration parameters.
moquery -c snmpClientP – The client profile information.
moquery -c snmpRsEpg – A source relation to the endpoint group VRF through which the clients can connect. The VRF is an in-band or out-of-band management endpoint.
moquery -c snmpSrc – The SNMP source profile, which determines the fault information, severity level, and destination for sending messages to the SNMP destination.
moquery -c snmpCtxP – The SNMP context profile, which enables you to specify a context to monitor with a community profile.

Example:

apic1# moquery -c snmpPol
Total Objects shown: 2

# snmp.Pol
name         : default
adminSt      : disabled
annotation   : 
childAction  : 
contact      : 
descr        : SNMP-test
dn           : uni/fabric/snmppol-default
extMngdBy    : 
lcOwn        : local
loc          : 
modTs        : 2020-05-15T04:51:14.444+00:00
monPolDn     : uni/fabric/monfab-default
nameAlias    : 
ownerKey     : 
ownerTag     : 
rn           : snmppol-default
status       : 
uid          : 0

# snmp.Pol
name         : New_SNMP_Policy
adminSt      : enabled
annotation   : 
childAction  : 
contact      : 
descr        : 
dn           : uni/fabric/snmppol-New_SNMP_Policy
extMngdBy    : 
lcOwn        : local
loc          : 
modTs        : 2020-05-15T04:31:23.890+00:00
monPolDn     : uni/fabric/monfab-default
nameAlias    : 
ownerKey     : 
ownerTag     : 
rn           : snmppol-New_SNMP_Policy
status       : 
uid          : 15374