The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.
This chapter provides an overview of the Cisco Cable Modem Termination System (CMTS) router. This chapter contains the following topics:
A MIB is a database of objects managed on a device using the SNMP manager. The managed objects or variables can be set or read to provide information on the network devices and interfacesand are organized hierarchically. The objects in a MIB are organized hierarchically, which are identified by object identifiers (OID) defined by IETF and other organizations. Our implementation of SNMP uses MIBs that conform to the MIB II definition that is described in RFC 1213.
Objects can refer to a physical device (such as a line card or clock card or shared port adapter), a software parameter (such as an IP address or operation mode), or a run-time statistic (such as number of packets passed or temperature). When the device contains multiple objects of the same type, it appends a unique instance number to the end of the OID, so that the SNMP manager and agent can distinguish between the different objects.
MIBs can contain two types of managed objects:
Typically, each row in a table is identified by a unique index number. Depending on the table, this index either could reflect a physical attribute (such as the slot number in a chassis or port number on a card) or it could be an arbitrary number (such as is used for tables that list error messages or packet statistics).
Each row also has a status object that shows whether the row is created, activated, deactivated, or deleted. When an SNMP manager creates a new row, it typically sets the row’s status to create and then populates the row with the desired parameters. The SNMP agent does not use the objects in a row until the SNMP manager sets the row’s status to activate. This ensures that the SNMP agent does not try to use a row’s parameters until the SNMP manager has finished creating the row and entered all of the row’s required parameters.
The Cisco CMTS uBR router enhanced management feature allows the router to be managed through the Simple Network Management Protocol (SNMP). The feature also expands the number of Management Information Bases (MIBs) included with the router.
Using the Cisco CMTS uBR router enhanced management feature, you can:
The SNMP specifications define MIBs in a highly structured hierarchical format, in which MIBs that are lower in the hierarchy use objects that are defined by MIBs higher up in the hierarchy. Each MIB includes a section titled “IMPORTS” that lists the objects it uses that are defined by other MIBs.
For example, the IF-MIB, which defines standard objects for router interfaces, uses the following IMPORT block:
This section shows that the IF-MIB uses objects that are defined by the SNMPv2-SMI, SNMPv2-TC, SNMPv2-CONF, SNMPv2-MIB, and IANAifType-MIB MIBs. To use the IF-MIB with your SNMP management software, you must load these other MIBs as well.
Typically, most SNMP managers use the IMPORT blocks in the MIBs to automatically determine the order in which the MIBs must be loaded. However, if you are manually loading MIBs, you must do so in the proper order.
To determine the dependencies among MIBs, you can use the “View and Download MIBs” tool, which is part of the SNMP Object Navigator on the Cisco IOS MIB Tools page. This URL takes you to the MIB Locator:
http://tools.cisco.com/ITDIT/MIBS/servlet/index
MIBs on the Cisco CMTS can be arranged in the following categories:
– DOCSIS-specified MIBs—Defined by CableLabs, which created and maintains the DOCSIS specification. When the DOCSIS specifications have been finalized, these MIBs are also submitted to the IETF and are eventually released as RFCs. These MIBs can also include other services, such as DOCSIS Set-Top Gateway (DSG), as CableLabs continues to develop specifications for these additional cable services.
– Cisco-specific cable MIBs—Provide extensions to the DOCSIS MIBs for features that are specific to Cisco platforms.
An object identifier (OID) uniquely identifies a MIB object on a managed router or other network device. All OIDs are arranged in a hierarchical order, with top-level OIDs assigned by standards organizations such as IETF, ISO, and ITU. Lower-level OIDs are assigned by individual vendor organizations.
Each level in an OID is assigned both a number and a name. The hierarchical structure of the OIDs allow for easy translation between the number and name forms of an OID.
For example, SNMP standard MIBs that are intended for use by all vendors typically start with “1.3.6.1.2.1”, which translates as follows:
iso(1).org(3).dod(6).internet(1).mgmt(2).mib-2(1)
Typically, vendor-specific MIBs have OIDs that start with “1.3.6.1.4.1”, which translates as follows:
iso(1).org(3).dod(6).internet(1).private(4).enterprises(1)
Cisco Systems was assigned the next OID of “9”, so most OIDs for items that are specific to Cisco platforms start with “1.3.6.1.4.1.9”:
iso(1).org(3).dod(6).internet(1).private(4).enterprises(1).cisco(9)
For illustrative purposes, the OIDs above are shown with both number and name forms combined. Typically, only the name or number for a level is used. However, names and numbers can be mixed in the same OID. For example, the top-most Cisco-specific OID could also be given as either “1.3.6.1.4.1.cisco” or “iso.org.dod.internet.private.enterprises.9”.
To translate OIDs between their name and number format, and to display the location of any OID in the OID tree, you can use the SNMP Object Navigator on the Cisco IOS MIB Tools page. This URL takes you to the MIB Locator:
http://tools.cisco.com/ITDIT/MIBS/servlet/index
For a listing of all of the objects and OIDs that are included in any particular MIB, you can download the text files at the following URL:
ftp://ftp.cisco.com/pub/mibs/oid/
The Cisco CMTS routers can be managed through SNMP, which is an application-layer protocol that provides a standardized framework and a common language for monitoring and managing devices in a network. The SNMP framework has the following main parts:
The SNMP manager communicates with the SNMP agent in the following ways:
An SNMP agent can notify the SNMP manager when important system events occur, such as the following:
When an agent detects an alarm condition, the agent:
SNMP notifications are sent as either:
The Cisco implementation of SNMP uses the definitions of SNMP traps described in RFC 1215.
When an agent detects an alarm condition, it logs information about the time, type, and severity of the condition and generates a notification message, which it then sends to a designated IP host. SNMP notifications can be sent as either traps or informs. See Chapter 4, “Enabling Notifications”, for instructions on how to enable traps on the Cisco CMTS Universal Broadband Series Router. Use the snmp-server host command to specify whether to send SNMP notifications as traps or informs. See “Monitoring Notifications,” for information about Cisco CMTS uBR router notifications.
Cisco IOS software supports the following versions of SNMP:
– Message integrity—Ensuring that a packet has not been tampered with in transit.
– Authentication—Determining that the message is from a valid source.
– Encryption—Scrambling the contents of a packet to prevent it from being learned by an unauthorized source.
Tip We recommend using SNMPv3 wherever possible because of its superior security features.
Both SNMPv1 and SNMPv2c use a community-based form of security. The community of managers who are able to access the agent MIB is defined by an IP address access control list (ACL) and password.
SNMPv2c support includes a retrieval mechanism and more detailed error message reporting to management stations. The retrieval mechanism supports the retrieval of tables and large quantities of information, minimizing the number of round-trip transmissions required.
SNMPv2c improved error handling support. SNMPv1 reported all error conditions using a single error code, but SNMPv2c includes a number of expanded error codes that use different error types to distinguish between different kinds of error conditions.
SNMPv3 improves security for SNMP communications by using encryption and by defining security models and security levels:
A combination of a security model and a security level determines which security mechanism is employed when handling an SNMP packet.
Table 1-1 describes the security models and levels provided by the different SNMP versions.
You must configure the SNMP agent to use the version of SNMP supported by the management station. An agent can communicate with multiple managers; for this reason, you can configure the Cisco IOS software to support communications with one management station using the SNMPv1 protocol, one using the SNMPv2c protocol, and another using SNMPv3.
Note We recommend using SNMPv3 for all SNMP applications, because of its significant security improvements. In addition, SNMPv3 supports 64-bit counters, which are not supported in SNMPv1. If you use SNMPv1, you can not view any objects that are defined as 64-bit counters.
MIB modules are typically defined in Request for Comments (RFC) documents that have been submitted to the Internet Engineering Task Force (IETF) for formal discussion and approval. RFCs are written by individuals or groups for consideration by the Internet Society and the Internet community as a whole.
Before being given RFC status, recommendations are first published as Internet Draft (I-D) documents. RFCs that have become recommended standards are also labeled as standards (STD) documents. For more information, see the Internet Society and IETF websites ( http://www.internetsociety.org/ and http://www.ietf.org).
We provide private MIB extensions with each Cisco system. Cisco enterprise MIBs comply with the guidelines described in the relevant RFCs unless otherwise noted in the documentation.
The following URLs provide access to general information about Cisco MIBs. Use these links to access MIBs for download, and to access related information (such as application notes and OID listings).
The following URLs provide access to SNMP information developed by the Cisco Technical Assistance Center (TAC):
The following Cisco documents provide information about configuring the cable-specific parameters on the Cisco CMTS router:
The following are standards and specifications that are used on DOCSIS cable networks. Some of these standards define the MIBs and other aspects of network management that are required for DOCSIS networks.
Note Many of these standards do not directly affect SNMP operations, but they define operational modes and parameters that must be understood to be able to interpret many of the tables and objects that are monitored and managed through SNMP.
|
|
---|---|
DOCSIS Specifications—These specifications describe the operation and behavior of both CMTS and cable modem platforms on a DOCSIS cable network. |
|
Data-over-Cable Service Interface Specifications Radio Frequency Interface, version 1.0 |
|
Data-over-Cable Service Interface Specifications Radio Frequency Interface Specification, version 1.1 |
|
Data-over-Cable Service Interface Specifications Radio Frequency Interface Specification, version 2.0 |
|
Data-over-Cable Service Interface Specifications Operations Support System Interface Specification, version 2.0 |
|
Data-over-Cable Service Interface Specifications Baseline Privacy Plus Interface Specification, version 2.0 |
|
|
|
|