cc/td/doc/product/webscale/uce/acns41
hometocprevnextglossaryfeedbacksearchhelp
PDF

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.


Figure 11-1: SNMP Components


Versions of SNMP

ACNS 4.1 software supports the following versions of SNMP:

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:

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.


Table 11-1: SNMP Security Models and Security Levels
Model Level Authentication Encryption Process

v1

noAuthNoPriv

Community string

No

Uses a community string match for user authentication.

v2c

noAuthNoPriv

Community string

No

Uses a community string match for user authentication.

v3

noAuthNoPriv

Username

No

Uses a username match for user authentication.

v3

AuthNoPriv

Message Digest 5 (MD5)
or Secure Hash Algorithm (SHA)

No

Provides authentication based on the HMAC-MD5 or HMAC-SHA algorithms.

v3

AuthPriv

MD5 or SHA

Yes

Provides authentication based on the HMAC-MD5 or HMAC-SHA algorithms. Provides DES 56-bit encryption (packet authentication) based on the CBC-DES (DES-56) standard.

The SNMPv3 agent can be used in the following modes:

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:

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:

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

hometocprevnextglossaryfeedbacksearchhelp
Posted: Mon Nov 18 11:28:47 PST 2002
Copyright 1989-2000©Cisco Systems Inc.