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 in ACI configuration and verification for APIC and fabric switches.
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 managementUsing 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
Other resources: Configuring SNMP in APIC
Thank you for breaking down the steps well. The SNMP configuration worked
You’re welcome.