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
Other Resources:
- You can read the full article (including the SNMP Verification in ACI) here.
- Cisco ACI MIB Quick Reference - Configuring SNMP in APIC.
