- Audience
- Getting Started with Cisco ME 2600X
- Ethernet Virtual Circuit
- Quality of Service
- Resilient Ethernet Protocol
- Link Aggregation Group and Link Aggregation Control Protocol
- MAC Learning
- Multicast VLAN Registration
- IGMP Snooping
- Remote Network Monitoring and Alarm Troubleshooting
- Authentication, Authorization, and Accounting (AAA)
- Cisco Discovery Protocol
- SNMP
- IP Source Guard for Service Instance
- DHCP Snooping
- Dynamic ARP Inspection
- MAC Address Security
- Layer 2 Access Control Lists on EVCs
- Layer 3 Access Control Lists on EVCs
- Storm Control over EVC
- Control Plane Policing
- ICMP Unreachable Rate Limiting User Feedback
- IP Version 6 Support for the Management Port
- SSH
- PPPoE Intermediate Agent
- CFM over EVC
- Index
Cisco ME 2600X Series Ethernet Access Switch Software Configuration Guide
- Updated:
- September 3, 2014
Chapter: SNMP
Contents
- SNMP
- Understanding SNMP
- Understanding SNMP Components
- Understanding MIB
- MIBs Supported in Cisco ME 2600X
- Understanding SNMP Traps
- Generic IETF Traps
- Understanding SNMP Community Names
- Understanding SNMP Messages
SNMP
This chapter explains Simple Network Management Protocol (SNMP) as implemented by Cisco ME 2600X.
- Understanding SNMP
- Understanding SNMP Components
- Understanding MIB
- Understanding SNMP Traps
- Understanding SNMP Community Names
- Understanding SNMP Messages
Understanding SNMP
This chapter explains Simple Network Management Protocol (SNMP) as implemented by Cisco ME 2600X.
SNMP is an application–layer communication protocol that allows network devices to exchange management information among these systems and with other devices outside the network. Through SNMP, network administrators can manage network performance, find and solve network problems, and plan network growth. SNMP makes network monitoring more cost effective and allows your network to be more reliable.
Cisco ME 2600X supports SNMP Version 2c (SNMPv2c). As compared to SNMPv1, SNMPv2c includes additional protocol operations and 64–bit performance monitoring support.
The figure below illustrates the basic layout idea of an SNMP-managed network.
The advantages of SNMP are as follows:
Understanding SNMP Components
An SNMP–managed network consists of a manager, agents, and managed devices.
The manager provides the interface between the human network manager and the management system. The agent provides the interface between the manager and the physical device being managed
Management systems execute most of the management processes and provide the bulk of memory resources used for network management. A network might be managed by one or several management systems.
The figure below illustrates the relationship between the network manager, the SNMP agent, and the managed devices.
An agent residing on each managed device translates local management information data—such as performance information or event and error information—caught in software traps, into a readable form for the management system.
The figure below illustrates SNMP agent get–requests that transport data to the network management software.
The SNMP agent captures data from MIBs, which are device parameter and network data repositories, or from error or change traps.
A managed element—such as a router, access server, switch, bridge, hub, computer host, or network element—is accessed through the SNMP agent. Managed devices collect and store management information, making it available through SNMP to other management systems having the same protocol compatibility.
 Note | It is recommended that the SNMP Manager timeout value be set to 60 seconds. Under certain conditions, if this value is lower than the recommended time, the TNC/TSC card can be reset. However, the response time depends on various parameters such as object being queried, complexity, number of hops in the node and so on. |
Understanding MIB
The Management Information Base (MIB) is a data structure that describes SNMP network elements as a list of data objects. The SNMP manager must compile the MIB file for each equipment type in the network to monitor SNMP devices.
The manager and agent use a MIB and a relatively small set of commands to exchange information. The MIB is organized in a tree structure with individual variables being represented as leaves on the branches. A long numeric tag or object identifier (OID) is used to distinguish each variable uniquely in the MIB and in SNMP messages. The MIB associates each OID with a readable label and various other parameters related to the object. The MIB then serves as a data dictionary or codebook that is used to assemble and interpret SNMP messages.
When the SNMP manager wants to know the value of an object, such as the state of an alarm point, the system name, or the element uptime, it will assemble a GET packet that includes the OID for each object of interest. The element receives the request and looks up each OID in its code book (MIB). If the OID is found (the object is managed by the element), a response packet is assembled and sent with the current value of the object included. If the OID is not found, a special error response is sent that identifies the unmanaged object.
MIBs Supported in Cisco ME 2600X
The table below lists the MIBs supported in Cisco ME 2600X.
| MIB Module | Type | ||
|---|---|---|---|
ENTITY-MIB |
Generic |
||
SNMPv2-MIB |
Generic
|
||
CISCO-CDP-MIB |
Generic |
||
CISCO-IETF-IP-FORWARD-MIB |
Generic |
||
CISCO-IETF-IP-MIB |
Generic |
||
IF-MIB |
Generic |
||
RMON-MIB |
Generic
|
||
IP-MIB |
Generic
|
||
TCP-MIB |
Generic |
||
UDP-MIB |
Generic |
||
RMON-MIB-V1SMI/HC-RMON-MIB |
Generic |
||
Ether-Like-MIB |
Generic |
||
CISCO-PROCESs-MIB |
Generic |
||
OLD-CISCO-MEMORY |
Generic |
||
CISCO-AAA-SERVER-MIB |
Feature |
||
CISCO-AAA-SESSION-MIB |
Feature |
||
CISCO-EVC-MIB |
Feature |
||
CISCO-CLASS-BASED-QOS-MIB |
Feature |
||
CISCO-IGMP-SNOOPING-MIB |
Feature |
||
IEEE8023-LAG-MIB |
Feature |
Each MIB includes compliance and conformance groups— these are not expected to return any output.
ENTITY-MIB—This is used for entity mapping. There is only one entity in ME2600X and therefore no entity is mapped. As a result, this table does not respond with any data.
IP-MIB—ipNetToMediaTable, ipNetToPhysicalTable, ipDefaultRouterTable, and ipv6 related tables are not supported.
TCP-MIB—tcpListenerTable is not supported.
The following feature MIBs are not supported in Cisco ME 2600X:
Note | Access tables with table name are not supported. |
Understanding SNMP Traps
Cisco ME 2600X uses SNMP traps to generate all the alarms and events. The traps contain the following information:
Generic IETF Traps
Cisco ME 2600X supports the generic IETF traps listed in the table below.
| Trap | Description |
|---|---|
coldStart |
Agent up, cold start. |
warmStart |
Agent up, warm start. |
Authentication |
Community string does not match. |
linkdown |
Test linkdown trap. |
linkup |
Test linkup trap. |
Examples of IETF Traps
coldStart
DISMAN-EVENT-MIB::sysUpTimeInstance = 21775 SNMPv2-MIB::snmpTrapOID.0 = SNMPv2-MIB::coldStart CERENT-454-MIB::cerent454NodeTime.0 = 20110705135346D CERENT-454-MIB::cerent454AlarmState.1.1 = administrative SNMP-COMMUNITY-MIB::snmpTrapAddress.0 = 10.64.106.142"
warmStart
DISMAN-EVENT-MIB::sysUpTimeInstance = 21775 SNMPv2-MIB::snmpTrapOID.0 = SNMPv2-MIB::warmStart CERENT-454-MIB::cerent454NodeTime.0 = 20110705135346D CERENT-454-MIB::cerent454AlarmState.1.1 = administrative SNMP-COMMUNITY-MIB::snmpTrapAddress.0 = 10.64.106.142"
Authentication
DISMAN-EVENT-MIB::sysUpTimeInstance = 6335948 SNMPv2-MIB::snmpTrapOID.0 = SNMPv2-MIB::Authentication CERENT-454-MIB::cerent454NodeTime.0 = 20110705121300D CERENT-454-MIB::cerent454AlarmState.1.1 = administrative SNMP-COMMUNITY-MIB::snmpTrapAddress.0 = 10.64.106.142"
linkup, linkdown
Snmptrap sample for mgmt. i/f shut/noshut
blr-ong-lnx1:168> snmptrapd -f -Lo -OQ -Ob -Ot -F "%V\n%B\n%N\n%w\n%q\n%P\n%v\n\n" 40000 2012-09-10 16:32:32 NET-SNMP version 5.1.2 Started. 10.64.106.180 . 0 0 TRAP2, SNMP v2c, community public DISMAN-EVENT-MIB::sysUpTimeInstance = 255394 SNMPv2-MIB::snmpTrapOID.0 = SNMPv2-SMI::enterprises.9.9.43.2.0.1 SNMPv2-SMI::enterprises.9.9.43.1.1.6.1.3.2 = 1 SNMPv2-SMI::enterprises.9.9.43.1.1.6.1.4.2 = 2 SNMPv2-SMI::enterprises.9.9.43.1.1.6.1.5.2 = 3 10.64.106.180 . 0 0 TRAP2, SNMP v2c, community public DISMAN-EVENT-MIB::sysUpTimeInstance = 256172 SNMPv2-MIB::snmpTrapOID.0 = IF-MIB::linkDown IF-MIB::ifIndex.49153 = 49153 IF-MIB::ifAdminStatus.49153 = down IF-MIB::ifOperStatus.49153 = down IF-MIB::ifDescr.49153 = GigabitEthernet1/1 IF-MIB::ifType.49153 = ethernetCsmacd SNMPv2-SMI::enterprises.9.2.2.1.1.20.49153 = "administratively down" 10.64.106.180 . 0 0 TRAP2, SNMP v2c, community public DISMAN-EVENT-MIB::sysUpTimeInstance = 258277 SNMPv2-MIB::snmpTrapOID.0 = IF-MIB::linkUp IF-MIB::ifIndex.49153 = 49153 IF-MIB::ifAdminStatus.49153 = up IF-MIB::ifOperStatus.49153 = up IF-MIB::ifDescr.49153 = GigabitEthernet1/1 IF-MIB::ifType.49153 = ethernetCsmacd SNMPv2-SMI::enterprises.9.2.2.1.1.20.49153 = "up"
Understanding SNMP Community Names
Community names are used to group SNMP trap destinations.
Understanding SNMP Messages
SNMP uses the following messages to communicate between the manager and the agent.
The Get and GetNext messages allow the manager to request information for a specific variable. The agent, upon receiving a Get or GetNext message, will issue a GetResponse message to the manager with either the information requested or an error indication as to why the request cannot be processed.
A Set message allows the manager to request a change be made to the value of a specific variable in the case of an alarm remote that will operate a relay. The agent will then respond with a GetResponse message indicating the change has been made or an error indication as to why the change cannot be made.
The Trap message allows the agent to inform the manager of an important event. An SNMP Trap is a change–of–state (COS) message—it could mean an alarm, a clear or simply a status message.