Configuring Network Management

Simple Network Management Protocol Overview

Simple Network Management Protocol (SNMP) is an interoperable standards-based protocol that allows for external monitoring of the Content Engine through an SNMP agent.

An SNMP-managed network consists of three primary components: managed devices, agents, and management systems. A managed device is a network node that contains an SNMP agent and resides on a managed network. Managed devices collect and store management information and use SNMP to make this information available to management systems that use SNMP. Managed devices include routers, access servers, switches, bridges, hubs, computer hosts, and printers.

An agent is a software module that resides in a managed device. An agent has local knowledge of management information and translates that information into a form compatible with SNMP. The SNMP agent gathers data from the management information base (MIB), which is the repository for information about device parameters and network data. The agent can also send traps, or notification of certain events, to the manager. Figure 11-1 illustrates these SNMP operations.

Versions of SNMP

ACNS 4.1 software supports the following versions of SNMP:

• Version 1 (SNMPv1)—This is the initial implementation of SNMP. Refer to RFC 1157 for a full description of its functionality.
  
  
• Version 2 (SNMPv2c)—This is the second release of SNMP, described in RFC 1902. It provides additions to data types, counter size, and protocol operations.
  
  
• Version 3 (SNMPv3)—This is the most recent version of SNMP defined in RFC 2271 through RFC 2275.
  
  

SNMPv1 and SNMPv2C do not have any security (that is, authentication or privacy) mechanisms to keep SNMP packet traffic on the wire confidential. As a result, packets on the wire can be detected and SNMP community strings compromised.

To solve the security shortcomings of SNMPv1 and SNMPv2c, SNMPv3 provides secure access to Content Engines by authenticating and encrypting packets over the network. In ACNS 4.1 software, SNMPv3 features are added to the SNMP agent in addition to SNMPv1 and SNMPv2c.

The following security features are provided in SNMPv3:

• Message integrity—Ensures that nothing has interfered with a packet during transmission.
  
  
• Authentication—Determines that the message is from a valid source.
  
  
• Encryption—Scrambles the contents of a packet to prevent it from being seen by an unauthorized source.
  
  

SNMPv3 provides both security models and security levels. A security model is an authentication process that is set up for a user and the group in which the user resides. A security level is the permitted level of security within a security model. A combination of a security model and a security level determines which security process is used when handling an SNMP packet. Three security models are available: SNMPv1, SNMPv2c, and SNMPv3. Table 11-1 describes the combinations of security models and security levels.

The SNMPv3 agent can be used in the following modes:

• noAuthnoPriv mode (that is, no security mechanisms turned on for packets)
  
  
• AuthNoPriv mode (for packets that do not need to be encrypted using the privacy algorithm [DES 56])
  
  
• AuthPriv mode (for packets that must be encrypted; privacy requires that authentication to be performed on the packet).
  
  

Using SNMPv3, users can securely collect management information from their SNMP agents without fear that the data has been tampered with. Also, confidential information, such as SNMP set packets that change a Content Engine's configuration, can be encrypted to prevent their contents from being exposed on the wire. Also, the group-based administrative model allows different users to access the same SNMP agent with varying access privileges.

Key SNMP CLI Commands

Use the snmp-server group global configuration command to select one of three SNMP versions, SNMPv1, SNMPv2c, or SNMPv3. Use the no form of this command to remove the specified version. Refer to the Cisco Application and Content Networking Software Command Reference for more information on how to use this and other SNMP commands.

The snmp-server community string command provides view-based access control for SNMPv1, SNMPv2c, and SNMPv3 but also continues to provide backward compatibility between different versions. The previous version of this command did not have an option to create a community string that allows SNMP messages to execute a set operation on a MIB object. A rw option has been introduced for this purpose. Also, the previous version of the SNMP agent did not provide selective access control to MIB objects. Access to any MIB object was denied or granted based on authentication of the SNMP community string. With the introduction of view-based access control, it is now possible to configure a community string that grants access to only part of the MIB subtree. To provide backward compatibility with the previous version of this command, a default read group or default write group (if the rw option is specified on the command line) is associated with the community string if no group name is specified. Both of these default groups are hidden from users and not displayed in the configuration file or in the show snmp group command, but are created during initialization of the SNMP agent.

Note   The SNMP agent is disabled by default and a community string is not configured.

The following example enables the SNMP agent and assigns the community string comaccess to SNMP:

507-1(config)# snmp-server community comaccess

 

The preceding example defines a community string comaccess used as a password for authentication when you access the SNMP agent of the Content Engine. Any SNMP message sent to the Content Engine must have the "Community Name" field of the message match the community string defined here in order to be authenticated. Entering a community string enables the SNMP agent.

The following example disables the SNMP agent and removes the previously defined community string.

507-1(config)# no snmp-server community 

 

Supported MIBs

The ACNS 4.1 software implementation of SNMP supports the following MIBs:

• MIB-II
  
  
• ENTITY-MIB
  
  
• CISCO-CONTENT-ENGINE-MIB
  
  
• CISCO-ENTITY-ASSET-MIB
  
  
• CISCO-CONFIG-MAN-MIB
  
  
• CISCO-CDP-MIB
  
  

Use the following link to access these MIBs:

ftp://ftp.cisco.com/pub/mibs/v2/.

SNMP Traps

To enable the Content Engine to send SNMP traps, use the snmp-server enable traps global configuration command. If you do not enter the snmp-server enable traps command, no traps are sent. Use the no form of this command to disable all SNMP traps or only SNMP authentication traps.

The snmp-server enable traps command is used in conjunction with the snmp-server host command. Use the snmp-server host command to specify which hosts or hosts receive SNMP traps. To send traps, you must configure at least one host.

For a host to receive a trap, both the snmp-server enable traps command and the snmp-server host command for that host must be enabled.

In addition, SNMP must be enabled with the snmp-server community command.

To disable the sending of the MIB-II SNMP authentication trap, you must enter the command no snmp-server enable traps snmp authentication.

The following example enables the Content Engine to send all traps to the host 172.31.2.160 using the community string public:

ContentEngine(config)# snmp-server enable traps

ContentEngine(config)# snmp-server host 172.31.2.160 public

 

The following example disables all traps:

Content Engine (config)# no snmp-server enable traps

CiscoWorks2000

CiscoWorks2000 (CW2K) is a Cisco product that provides a suite of management applications used to manage most Cisco devices. The Content Engine can interoperate with CiscoWorks2000 without any modification in the following ways:

• CW2K can list the Content Engine under "Generic SNMP" devices.
  
  
• The CW2K inventory module lists the Content Engine with the device name, system name, description (including the software version), uptime, and network interface information.
  
  
• The CW2K syslog module can understand Content Engine syslogs.
  
  
• The CW2K availability module can track the Content Engine.
  
  

You can enable or disable syslog message generation in CiscoWorks2000- compliant format through either the command-line interface (CLI) or the graphical user interface (GUI).

Use the logging cw2k command to enable CiscoWorks2000 syslog message generation. Use the no logging cw2k command to disable CiscoWorks2000 syslog message generation.

Cisco Discovery Protocol

Cisco Discovery Protocol (CDP) is a device discovery protocol that runs on all Cisco manufactured devices. With CDP, each device within a network sends periodic messages to all devices within the network. These devices listen to periodic messages sent by others in order to learn about neighboring devices and determine the status of their interfaces.

With CDP, network management applications can learn the device type and the SNMP agent address of neighboring devices. Applications are then able to send SNMP queries within the network.

Also, CiscoWorks 2000 discovers the Content Engine by noticing the CDP packets that are sent by the Content Engine after booting.

Content Engine-related tasks require that the Content Engine platform support CDP in order to be able to notify the system manager of the existence, type, and version of the Content Engine platform.

The following example enables CDP implementation with a single CLI command:

ContentEngine(config)# interface FastEthernet 0/0 cdp enable