Chapter 1. Configuring Cisco IOS Configuration Engine

- Prerequisites for Configuring the Configuration Engine

- Restrictions for Configuring the Configuration Engine

- Information About Configuring the Configuration Engine

- How to Configure the Configuration Engine

- Monitoring CNS Configurations

- Additional References

- Feature Information for Cisco IOS Configuration Engine

Prerequisites for Configuring the Configuration Engine

- Obtain the name of the configuration engine instance to which you are connecting.

- Because the CNS uses both the event bus and the configuration server to provide configurations to devices, you must define both ConfigID and Device ID for each configured device.

- All devices configured with the cns config partial global configuration command must access the event bus. The DeviceID, as originated on the device, must match the DeviceID of the corresponding device definition in the Cisco Configuration Engine. You must know the hostname of the event bus to which you are connecting.

Restrictions for Configuring the Configuration Engine

- Within the scope of a single instance of the configuration server, no two configured devices can share the same value for ConfigID.

- Within the scope of a single instance of the event bus, no two configured devices can share the same value for DeviceID.

Information About Configuring the Configuration Engine

This section provides information about configuring the configuration engine.

- Cisco Configuration Engine Software

- Configuration Service

- Event Service

- NameSpace Mapper

- Cisco Networking Services IDs and Device Hostnames

- Automated CNS Configuration

Cisco Configuration Engine Software

The Cisco Configuration Engine is network management utility software that acts as a configuration service for automating the deployment and management of network devices and services. Each Cisco Configuration Engine manages a group of Cisco devices (switches and routers) and the services that they deliver, storing their configurations and delivering them as needed. The Cisco Configuration Engine automates initial configurations and configuration updates by generating device-specific configuration changes, sending them to the device, executing the configuration change, and logging the results.

The Cisco Configuration Engine supports standalone and server modes and has these Cisco Networking Services (CNS) components:

- Configuration service:

- Web server

- File manager

- Namespace mapping server

- Event service (event gateway)

- Data service directory (data models and schema)

Note

Support for Cisco Configuration Engine will be deprecated in future releases. Use the configuration described in Cisco Plug and Play Feature Guide .

In standalone mode, the Cisco Configuration Engine supports an embedded directory service. In this mode, no external directory or other data store is required. In server mode, the Cisco Configuration Engine supports the use of a user-defined external directory.

Cisco Configuration Engine Architectural Overview

Configuration Service

The Configuration Service is the core component of the Cisco Configuration Engine. It consists of a Configuration Server that works with Cisco IOS CNS agents on the device. The Configuration Service delivers device and service configurations to the device for initial configuration and mass reconfiguration by logical groups. Switches receive their initial configuration from the Configuration Service when they start up on the network for the first time.

The Configuration Service uses the CNS Event Service to send and receive configuration change events and to send success and failure notifications.

The Configuration Server is a web server that uses configuration templates and the device-specific configuration information stored in the embedded (standalone mode) or remote (server mode) directory.

Configuration templates are text files containing static configuration information in the form of CLI commands. In the templates, variables are specified by using Lightweight Directory Access Protocol (LDAP) URLs that reference the device-specific configuration information stored in a directory.

The Cisco IOS agent can perform a syntax check on received configuration files and publish events to show the success or failure of the syntax check. The configuration agent can either apply configurations immediately or delay the application until receipt of a synchronization event from the configuration server.

Event Service

The Cisco Configuration Engine uses the Event Service for receipt and generation of configuration events. The Event Service consists of an event agent and an event gateway. The event agent is on the device and facilitates the communication between the devices and the event gateway on the Cisco Configuration Engine.

The Event Service is a highly capable publish-and-subscribe communication method. The Event Service uses subject-based addressing to send messages to their destinations. Subject-based addressing conventions define a simple, uniform namespace for messages and their destinations.

NameSpace Mapper

The Cisco Configuration Engine includes the NameSpace Mapper (NSM) that provides a lookup service for managing logical groups of devices based on application, device or group ID, and event.

Cisco IOS devices recognize only event subject-names that match those configured in Cisco IOS software; for example, cisco.cns.config.load. You can use the namespace mapping service to designate events by using any desired naming convention. When you have populated your data store with your subject names, NSM changes your event subject-name strings to those known by Cisco IOS.

For a subscriber, when given a unique device ID and event, the namespace mapping service returns a set of events to which to subscribe. Similarly, for a publisher, when given a unique group ID, device ID, and event, the mapping service returns a set of events on which to publish.

Cisco Networking Services IDs and Device Hostnames

The Cisco Configuration Engine assumes that a unique identifier is associated with each configured device. This unique identifier can take on multiple synonyms, where each synonym is unique within a particular namespace. The event service uses namespace content for subject-based addressing of messages.

The Cisco Configuration Engine intersects two namespaces, one for the event bus and the other for the configuration server. Within the scope of the configuration server namespace, the term ConfigID is the unique identifier for a device. Within the scope of the event bus namespace, the term DeviceID is the CNS unique identifier for a device.

- ConfigID

- DeviceID

- Hostname and DeviceID

- Hostname, DeviceID, and ConfigID

ConfigID

Each configured device has a unique ConfigID, which serves as the key into the Cisco Configuration Engine directory for the corresponding set of device CLI attributes. The ConfigID defined on the device must match the ConfigID for the corresponding device definition on the Cisco Configuration Engine.

The ConfigID is fixed at startup time and cannot be changed until the device restarts, even if the device hostname is reconfigured.

DeviceID

Each configured device participating on the event bus has a unique DeviceID, which is analogous to the device source address so that the device can be targeted as a specific destination on the bus.

The origin of the DeviceID is defined by the Cisco IOS hostname of the device. However, the DeviceID variable and its usage reside within the event gateway adjacent to the device.

The logical Cisco IOS termination point on the event bus is embedded in the event gateway, which in turn functions as a proxy on behalf of the device. The event gateway represents the device and its corresponding DeviceID to the event bus.

The device declares its hostname to the event gateway immediately after the successful connection to the event gateway. The event gateway couples the DeviceID value to the Cisco IOS hostname each time this connection is established. The event gateway retains this DeviceID value for the duration of its connection to the device.

Hostname and DeviceID

The DeviceID is fixed at the time of the connection to the event gateway and does not change even when the device hostname is reconfigured.

When changing the device hostname on the device, the only way to refresh the DeviceID is to break the connection between the device and the event gateway. For instructions on refreshing DeviceIDs, see "Related Topics."

When the connection is reestablished, the device sends its modified hostname to the event gateway. The event gateway redefines the DeviceID to the new value.

Caution

When using the Cisco Configuration Engine user interface, you must first set the DeviceID field to the hostname value that the device acquires after, not before, and you must reinitialize the configuration for your Cisco IOS CNS agent. Otherwise, subsequent partial configuration command operations may malfunction.

Hostname, DeviceID, and ConfigID

In standalone mode, when a hostname value is set for a device, the configuration server uses the hostname as the DeviceID when an event is sent on hostname. If the hostname has not been set, the event is sent on the cn=<value> of the device.

In server mode, the hostname is not used. In this mode, the unique DeviceID attribute is always used for sending an event on the bus. If this attribute is not set, you cannot update the device.

These and other associated attributes (tag value pairs) are set when you run Setup on the Cisco Configuration Engine.

Automated CNS Configuration

To enable automated CNS configuration of the device, you must first complete the prerequisites listed in this topic. When you complete them, power on the device. At the setup prompt, do nothing; the device begins the initial configuration. When the full configuration file is loaded on your device, you do not need to do anything else.

For more information on what happens during initial configuration, see "Related Topics."

Prerequisites for Enabling Automatic Configuration

Device

Required Configuration

Access device

Factory default (no configuration file)

Distribution device

- IP helper address

- Enable DHCP relay agent[1]

- IP routing (if used as default gateway)

DHCP server

- IP address assignment

- TFTP server IP address

- Path to bootstrap configuration file on the TFTP server

- Default gateway IP address

TFTP server

- A bootstrap configuration file that includes the CNS configuration commands that enable the device to communicate with the Configuration Engine

- The device configured to use either the device MAC address or the serial number (instead of the default hostname) to generate the ConfigID and EventID

- The CNS event agent configured to push the configuration file to the device

CNS Configuration Engine

One or more templates for each type of device, with the ConfigID of the device mapped to the template.

[1] A DHCP Relay is needed only when the DHCP Server is on a different subnet from the client.

How to Configure the Configuration Engine

This section provides information about how to configure the configuration engine.

- Enabling the CNS Event Agent

- Refreshing DeviceIDs

Enabling the CNS Event Agent

Note

You must enable the CNS event agent on the device before you enable the CNS configuration agent.

Follow these steps to enable the CNS event agent on the device.

Procedure

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 3

cns event {hostname | ip-address} [port-number] [ [keepalive seconds retry-count] [failover-time seconds ] [reconnect-time time] | backup]

Example:

Device(config)# cns event 10.180.1.27 keepalive 120 10

Enables the event agent, and enters the gateway parameters.

- For {hostname | ip-address} , enter either the hostname or the IP address of the event gateway.

- (Optional) For port number , enter the port number for the event gateway. The default port number is 11011.

- (Optional) For keepalive seconds , enter how often the device sends keepalive messages. For retry-count , enter the number of unanswered keepalive messages that the device sends before the connection is terminated. The default for each is 0.

- (Optional) For failover-time seconds , enter how long the device waits for the primary gateway route after the route to the backup gateway is established.

- (Optional) For reconnect-time time , enter the maximum time interval that the device waits before trying to reconnect to the event gateway.

- (Optional) Enter backup to show that this is the backup gateway. (If omitted, this is the primary gateway.)

Note

Though visible in the command-line help string, the encrypt and the clock-timeout time keywords are not supported.

Step 4

end

Example:

Device (config)#end

Returns to privileged EXEC mode.

Step 5

show running-config

Example:

Device# show running-config

Verifies your entries.

Step 6

copy running-config startup-config

Example:

Device# copy running-config startup-config

(Optional) Saves your entries in the configuration file.

What to do next

To verify information about the event agent, use the show cns event connections command in privileged EXEC mode.

To disable the CNS event agent, use the no cns event { ip-address | hostname } global configuration command.

Refreshing DeviceIDs

Follow these steps to refresh a DeviceID when changing the hostname on the device.

Procedure

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

show cns config connections

Example:

Device# show cns config connections

Displays whether the CNS event agent is connecting to the gateway, connected, or active, and the gateway used by the event agent, its IP address and port number.

Step 3

Make sure that the CNS event agent is properly connected to the event gateway.

Examine the output of show cns config connections for the following:

- Connection is active.

- Connection is using the currently configured device hostname. The DeviceID will be refreshed to correspond to the new hostname configuration using these instructions.

Step 4

show cns event connections

Example:

Device# show cns event connections

Displays the event connection information for your device.

Step 5

Record from the output of Step 4 the information for the currently connected connection listed below. You will be using the IP address and port number in subsequent steps of these instructions.

Step 6

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 7

no cns event ip-address port-number

Example:

Device(config)# no cns event 172.28.129.22 2012

Specifies the IP address and port number that you recorded in Step 5 in this command.

This command breaks the connection between the device and the event gateway. It is necessary to first break, then reestablish, this connection to refresh the DeviceID.

Step 8

cns event ip-address port-number

Example:

Device(config)# cns event 172.28.129.22 2012

Specifies the IP address and port number that you recorded in Step 5 in this command.

This command reestablishes the connection between the device and the event gateway.

Step 9

end

Example:

Device(config)# end

Returns to privileged EXEC mode.

Step 10

Make sure that you have reestablished the connection between the device and the event connection by examining the output from show cns event connections .

Step 11

show running-config

Example:

Device# show running-config

Verifies your entries.

Step 12

copy running-config startup-config

Example:

Device# copy running-config startup-config

(Optional) Saves your entries in the configuration file.

Monitoring CNS Configurations

CNS show Commands

Command

Purpose

show cns config connections

Device# show cns config connections

Displays the status of the CNS Cisco IOS CNS agent connections.

show cns config outstanding

Device# show cns config outstanding

Displays information about incremental (partial) CNS configurations that have started but are not yet completed.

show cns config stats

Device# show cns config stats

Displays statistics about the Cisco IOS CNS agent.

show cns event connections

Device# show cns event connections

Displays the status of the CNS event agent connections.

show cns event gateway

Device# show cns event gateway

Displays the event gateway information for your device.

show cns event stats

Device# show cns event stats

Displays statistics about the CNS event agent.

show cns event subject

Device# show cns event subject

Displays a list of event agent subjects that are subscribed to by applications.

Additional References

Related Documents

Related Topic

Document Title

Configuration Engine Setup

Cisco Configuration Engine Installation and Setup Guide, 1.5 for Linux

https://www.cisco.com/en/US/docs/net_mgmt/configuration_engine/1.5/installation_linux/guide/setup_1.html

Feature Information for Cisco IOS Configuration Engine

This table provides release and related information for features explained in this module.

These features are available on all releases subsequent to the one they were introduced in, unless noted otherwise.

Release

Feature

Feature Information

Cisco IOS Configuration Engine

The Cisco Configuration Engine is network management utility software that acts as a configuration service for automating the deployment and management of network devices and services.

Use Cisco Feature Navigator to find information about platform and software image support. To access Cisco Feature Navigator, go to http://www.cisco.com/go/cfn.

Chapter 2. Configuring the Cisco Discovery Protocol

Cisco Discovery Protocol is a Layer 2, media-independent, and network-independent protocol that runs on Cisco devices and enables networking applications to learn about directly connected devices nearby. This protocol facilitates the management of Cisco devices by discovering these devices, determining how they are configured, and allowing systems using different network-layer protocols to learn about each other.

This module describes Cisco Discovery Protocol Version 2 and how it functions with SNMP.

- Information About Cisco Discovery Protocol

- How to Configure Cisco Discovery Protocol

- Monitoring and Maintaining Cisco Discovery Protocol

- Feature Information for Cisco Discovery Protocol

Information About Cisco Discovery Protocol

This section provides information about Cisco Discovery Protocol:

- Cisco Discovery Protocol Overview

- Default Cisco Discovery Protocol Configuration

Cisco Discovery Protocol Overview

Cisco Discovery Protocol is a device discovery protocol that runs over Layer 2 (the data-link layer) on all Cisco-manufactured devices (routers, bridges, access servers, controllers, and switches) and allows network management applications to discover Cisco devices that are neighbors of already known devices. With Cisco Discovery Protocol, network management applications can learn the device type and the SNMP agent address of neighboring devices running lower-layer, transparent protocols. This feature enables applications to send SNMP queries to neighboring devices.

Cisco Discovery Protocol runs on all media that support Subnetwork Access Protocol (SNAP). Because Cisco Discovery Protocol runs over the data-link layer only, two systems that support different network-layer protocols can learn about each other.

Each Cisco Discovery Protocol-configured device sends periodic messages to a multicast address, advertising at least one address at which it can receive SNMP messages. The advertisements also contain time-to-live, or holdtime information, which is the length of time a receiving device holds Cisco Discovery Protocol information before discarding it. Each device also listens to the messages sent by other devices to learn about neighboring devices.

On the device, Cisco Discovery Protocol enables Network Assistant to display a graphical view of the network. The device uses Cisco Discovery Protocol to find cluster candidates and maintain information about cluster members and other devices up to three cluster-enabled devices away from the command device by default.

Default Cisco Discovery Protocol Configuration

This table shows the default Cisco Discovery Protocol configuration.

Feature

Default Setting

Cisco Discovery Protocol global state

Enabled

Cisco Discovery Protocol interface state

Enabled

Cisco Discovery Protocol timer (packet update frequency)

60 seconds

Cisco Discovery Protocol holdtime (before discarding)

180 seconds

Cisco Discovery Protocol Version-2 advertisements

Enabled

How to Configure Cisco Discovery Protocol

This section provides information about how to configure Cisco Discovery Protocol:

- Configuring Cisco Discovery Protocol Characteristics

- Disabling Cisco Discovery Protocol

- Enabling Cisco Discovery Protocol

- Disabling Cisco Discovery Protocol on an Interface

- Enabling Cisco Discovery Protocol on an Interface

Configuring Cisco Discovery Protocol Characteristics

You can configure these Cisco Discovery Protocol characteristics:

- Frequency of Cisco Discovery Protocol updates

- Amount of time to hold the information before discarding it

- Whether or not to send Version 2 advertisements

Note

Steps 3 through 5 are all optional and can be performed in any order.

Follow these steps to configure the Cisco Discovery Protocol characteristics.

Procedure

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 3

cdp timer seconds

Example:

Device(config)# cdp timer 20

(Optional) Sets the transmission frequency of Cisco Discovery Protocol updates in seconds.

The range is 5 to 254; the default is 60 seconds.

Step 4

cdp holdtime seconds

Example:

Device(config)# cdp holdtime 60

(Optional) Specifies the amount of time a receiving device should hold the information sent by your device before discarding it.

The range is 10 to 255 seconds; the default is 180 seconds.

Step 5

cdp advertise-v2

Example:

Device(config)# cdp advertise-v2

(Optional) Configures Cisco Discovery Protocol to send Version 2 advertisements.

This is the default state.

Step 6

end

Example:

Device(config)# end

Returns to privileged EXEC mode.

Step 7

show running-config

Example:

Device# show running-config

Verifies your entries.

Step 8

copy running-config startup-config

Example:

Device# copy running-config startup-config

(Optional) Saves your entries in the configuration file.

What to do next

Use the no form of the Cisco Discovery Protocol commands to return to the default settings.

Disabling Cisco Discovery Protocol

Cisco Discovery Protocol is enabled by default.

Note

Device clusters and other Cisco devices (such as Cisco IP Phones) regularly exchange Cisco Discovery Protocol messages. Disabling Cisco Discovery Protocol can interrupt cluster discovery and device connectivity.

Follow these steps to disable the Cisco Discovery Protocol device discovery capability.

Procedure

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 3

no cdp run

Example:

Device(config)# no cdp run

Disables Cisco Discovery Protocol.

Step 4

end

Example:

Device(config)# end

Returns to privileged EXEC mode.

Step 5

show running-config

Example:

Device# show running-config

Verifies your entries.

Step 6

copy running-config startup-config

Example:

Device# copy running-config startup-config

(Optional) Saves your entries in the configuration file.

What to do next

You must reenable Cisco Discovery Protocol to use it.

Enabling Cisco Discovery Protocol

Cisco Discovery Protocol is enabled by default.

Note

Device clusters and other Cisco devices (such as Cisco IP Phones) regularly exchange Cisco Discovery Protocol messages. Disabling Cisco Discovery Protocol can interrupt cluster discovery and device connectivity.

Follow these steps to enable Cisco Discovery Protocol when it has been disabled.

Before you begin

Cisco Discovery Protocol must be disabled, or it cannot be enabled.

Procedure

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 3

cdp run

Example:

Device(config)# cdp run

Enables Cisco Discovery Protocol if it has been disabled.

Step 4

end

Example:

Device(config)# end

Returns to privileged EXEC mode.

Step 5

show running-config

Example:

Device# show running-config

Verifies your entries.

Step 6

copy running-config startup-config

Example:

Device# copy running-config startup-config

(Optional) Saves your entries in the configuration file.

What to do next

Use the show run all command to show that Cisco Discovery Protocol has been enabled. If you enter only show run , the enabling of Cisco Discovery Protocol may not be displayed.

Disabling Cisco Discovery Protocol on an Interface

Cisco Discovery Protocol is enabled by default on all supported interfaces to send and to receive Cisco Discovery Protocol information.

Note

Device clusters and other Cisco devices (such as Cisco IP Phones) regularly exchange Cisco Discovery Protocol messages. Disabling Cisco Discovery Protocol can interrupt cluster discovery and device connectivity.

Note

Cisco Discovery Protocol bypass is not supported and may cause a port go into err-disabled state.

Follow these steps to disable Cisco Discovery Protocol on a port.

Procedure

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode.

Enter your password if prompted.

Step 2

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 3

interface interface-id

Example:

Device(config)# interface gigabitethernet 1/0/1

Specifies the interface on which you are disabling Cisco Discovery Protocol, and enters interface configuration mode.

Step 4

no cdp enable

Example:

Device(config-if)# no cdp enable

Disables Cisco Discovery Protocol on the interface specified in Step 3.

Step 5

end

Example:

Device(config)# end

Returns to privileged EXEC mode.

Step 6

show running-config

Example:

Device# show running-config

Verifies your entries.

Step 7

copy running-config startup-config

Example:

Device# copy running-config startup-config

(Optional) Saves your entries in the configuration file.

Enabling Cisco Discovery Protocol on an Interface

Cisco Discovery Protocol is enabled by default on all supported interfaces to send and to receive Cisco Discovery Protocol information. This task is not mandatory.

Note

Device clusters and other Cisco devices (such as Cisco IP Phones) regularly exchange Cisco Discovery Protocol messages. Disabling Cisco Discovery Protocol can interrupt cluster discovery and device connectivity.

Note

Cisco Discovery Protocol bypass is not supported and may cause a port go into err-disabled state.

Follow these steps to enable Cisco Discovery Protocol on a port on which it has been disabled.

Procedure

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 3

interface interface-id

Example:

Device(config)# interface gigabitethernet 1/0/1

Specifies the interface on which you are enabling Cisco Discovery Protocol, and enters interface configuration mode.

Step 4

cdp enable

Example:

Device(config-if)# cdp enable

Enables Cisco Discovery Protocol on a disabled interface.

Step 5

end

Example:

Device(config)# end

Returns to privileged EXEC mode.

Step 6

show running-config

Example:

Device# show running-config

Verifies your entries.

Step 7

copy running-config startup-config

Example:

Device# copy running-config startup-config

(Optional) Saves your entries in the configuration file.

Monitoring and Maintaining Cisco Discovery Protocol

Commands for Displaying Cisco Discovery Protocol Information

Command

Description

clear cdp counters

Resets the traffic counters to zero.

clear cdp table

Deletes the Cisco Discovery Protocol table of information about neighbors.

show cdp

Displays global information, such as frequency of transmissions and the holdtime for packets being sent.

show cdp entry entry-name [ version] [ protocol]

Displays information about a specific neighbor.

You can enter an asterisk (*) to display all Cisco Discovery Protocol neighbors, or you can enter the name of the neighbor about which you want information.

You can also limit the display to information about the protocols enabled on the specified neighbor or information about the version of software running on the device.

show cdp interface [ interface-id]

Displays information about interfaces where Cisco Discovery Protocol is enabled.

You can limit the display to the interface about which you want information.

show cdp neighbors [ interface-id] [ detail]

Displays information about neighbors, including device type, interface type and number, holdtime settings, capabilities, platform, and port ID.

You can limit the display to neighbors of a specific interface or expand the display to provide more detailed information.

show cdp traffic

Displays Cisco Discovery Protocol counters, including the number of packets sent and received and checksum errors.

Feature Information for Cisco Discovery Protocol

This table provides release and related information for features explained in this module.

These features are available on all releases subsequent to the one they were introduced in, unless noted otherwise.

Release

Feature

Feature Information

Cisco Discovery Protocol

Cisco Discovery Protocol is a Layer 2, media-independent, and network-independent protocol that runs on Cisco devices and enables networking applications to learn about directly connected devices nearby.

Use Cisco Feature Navigator to find information about platform and software image support. To access Cisco Feature Navigator, go to http://www.cisco.com/go/cfn.

Chapter 3. Configuring Simple Network Management Protocol

- Prerequisites for SNMP

- Restrictions for SNMP

- Information About SNMP

- How to Configure SNMP

- Monitoring SNMP Status

- SNMP Examples

- Feature Information for Configuring SNMP

Prerequisites for SNMP

Supported SNMP Versions

This software release supports the following SNMP versions:

- SNMPv1—The Simple Network Management Protocol, a Full Internet Standard, defined in RFC 1157.

- SNMPv2C replaces the Party-based Administrative and Security Framework of SNMPv2Classic with the community-string-based Administrative Framework of SNMPv2C while retaining the bulk retrieval and improved error handling of SNMPv2Classic. It has these features:

- SNMPv2—Version 2 of the Simple Network Management Protocol, a Draft Internet Standard, defined in RFCs 1902 through 1907.

- SNMPv2C—The community-string-based Administrative Framework for SNMPv2, an Experimental Internet Protocol defined in RFC 1901.

- SNMPv3—Version 3 of the SNMP is an interoperable standards-based protocol defined in RFCs 2273 to 2275. SNMPv3 provides secure access to devices by authenticating and encrypting packets over the network and includes these security features:

- Message integrity—Ensures that a packet was not tampered with in transit.

- Authentication—Determines that the message is from a valid source.

- Encryption—Mixes the contents of a package to prevent it from being read by an unauthorized source.

Note

To select encryption, enter the priv keyword.

Both SNMPv1 and SNMPv2C use a community-based form of security. The community of managers able to access the agent’s MIB is defined by an IP address access control list and password.

SNMPv2C includes a bulk retrieval function and more detailed error message reporting to management stations. The bulk retrieval function retrieves tables and large quantities of information, minimizing the number of round-trips required. The SNMPv2C improved error-handling includes expanded error codes that distinguish different kinds of error conditions; these conditions are reported through a single error code in SNMPv1. Error return codes in SNMPv2C report the error type.

SNMPv3 provides for both security models and security levels. A security model is an authentication strategy set up for a user and the group within which the user resides. A security level is the permitted level of security within a security model. A combination of the security level and the security model determine which security method is used when handling an SNMP packet. Available security models are SNMPv1, SNMPv2C, and SNMPv3.

The following table identifies characteristics and compares different combinations of security models and levels:

SNMP Security Models and Levels

Model

Level

Authentication

Encryption

Result

SNMPv1

noAuthNoPriv

Community string

No

Uses a community string match for authentication.

SNMPv2C

noAuthNoPriv

Community string

No

Uses a community string match for authentication.

SNMPv3

noAuthNoPriv

Username

No

Uses a username match for authentication.

SNMPv3

authNoPriv

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

No

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

SNMPv3

authPriv

MD5 or SHA

Data Encryption Standard (DES) or Advanced Encryption Standard (AES)

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

Allows specifying the User-based Security Model (USM) with these encryption algorithms:

- DES 56-bit encryption in addition to authentication based on the CBC-DES (DES-56) standard.

- 3DES 168-bit encryption

- AES 128-bit, 192-bit, or 256-bit encryption

You must configure the SNMP agent to use the SNMP version supported by the management station. Because an agent can communicate with multiple managers, you can configure the software to support communications using SNMPv1, SNMPv2C, or SNMPv3.

Restrictions for SNMP

Version Restrictions

- SNMPv1 does not support informs.

Information About SNMP

This section provides information about Simple Network Management Protocol.

- SNMP Overview

- SNMP Manager Functions

- SNMP Agent Functions

- SNMP Community Strings

- SNMP MIB Variables Access

- SNMP Notifications

- SNMP ifIndex MIB Object Values

- Default SNMP Configuration

- SNMP Configuration Guidelines

SNMP Overview

SNMP is an application-layer protocol that provides a message format for communication between managers and agents. The SNMP system consists of an SNMP manager, an SNMP agent, and a management information base (MIB). The SNMP manager can be part of a network management system (NMS) such as Cisco Prime Infrastructure. The agent and MIB reside on the device. To configure SNMP on the device, you define the relationship between the manager and the agent.

The SNMP agent contains MIB variables whose values the SNMP manager can request or change. A manager can get a value from an agent or store a value into the agent. The agent gathers data from the MIB, the repository for information about device parameters and network data. The agent can also respond to a manager's requests to get or set data.

An agent can send unsolicited traps to the manager. Traps are messages alerting the SNMP manager to a condition on the network. Traps can mean improper user authentication, restarts, link status (up or down), MAC address tracking, closing of a TCP connection, loss of connection to a neighbor, or other significant events.

SNMP Manager Functions

The SNMP manager uses information in the MIB to perform the operations described in the following table:

SNMP Operations

Operation

Description

get-request

Retrieves a value from a specific variable.

get-next-request

Retrieves a value from a variable within a table.[1]

get-bulk-request[2]

Retrieves large blocks of data, such as multiple rows in a table, that would otherwise require the transmission of many small blocks of data.

get-response

Replies to a get-request, get-next-request, and set-request sent by an NMS.

set-request

Stores a value in a specific variable.

trap

An unsolicited message sent by an SNMP agent to an SNMP manager when some event has occurred.

[1] With this operation, an SNMP manager does not need to know the exact variable name. A sequential search is performed to find the needed variable from within a table.

[2] The get-bulk command only works with SNMPv2 or later.

SNMP Agent Functions

The SNMP agent responds to SNMP manager requests as follows:

- Get a MIB variable—The SNMP agent begins this function in response to a request from the NMS. The agent retrieves the value of the requested MIB variable and responds to the NMS with that value.

- Set a MIB variable—The SNMP agent begins this function in response to a message from the NMS. The SNMP agent changes the value of the MIB variable to the value requested by the NMS.

The SNMP agent also sends unsolicited trap messages to notify an NMS that a significant event has occurred on the agent. Examples of trap conditions include, but are not limited to, when a port or module goes up or down, when spanning-tree topology changes occur, and when authentication failures occur.

SNMP Community Strings

SNMP community strings authenticate access to MIB objects and function as embedded passwords. In order for the NMS to access the device, the community string definitions on the NMS must match at least one of the three community string definitions on the device.

A community string can have one of the following attributes:

- Read-only (RO)—Gives all objects in the MIB except the community strings read access to authorized management stations, but does not allow write access.

- Read-write (RW)—Gives all objects in the MIB read and write access to authorized management stations, but does not allow access to the community strings.

- When a cluster is created, the command device manages the exchange of messages among member devices and the SNMP application. The Network Assistant software appends the member device number (@esN, where N is the device number) to the first configured RW and RO community strings on the command device and propagates them to the member devices.

SNMP MIB Variables Access

MIB variables to set device variables and to poll devices on the network for specific information. The results of a poll can be displayed as a graph and analyzed to troubleshoot internetworking problems, increase network performance, verify the configuration of devices, monitor traffic loads, and more.

As shown in the figure, the SNMP agent gathers data from the MIB. The agent can send traps, or notification of certain events, to the SNMP manager, which receives and processes the traps. Traps alert the SNMP manager to a condition on the network such as improper user authentication, restarts, link status (up or down), MAC address tracking, and so forth. The SNMP agent also responds to MIB-related queries sent by the SNMP manager in get-request , get-next-request , and set-request format.

SNMP Network

SNMP Notifications

SNMP allows the device to send notifications to SNMP managers when particular events occur. SNMP notifications can be sent as traps or inform requests. In command syntax, unless there is an option in the command to select either traps or informs, the keyword traps refers to either traps or informs, or both. Use the snmp-server host command to specify whether to send SNMP notifications as traps or informs.

Note

SNMPv1 does not support informs.

Traps are unreliable because the receiver does not send an acknowledgment when it receives a trap, and the sender cannot determine if the trap was received. When an SNMP manager receives an inform request, it acknowledges the message with an SNMP response protocol data unit (PDU). If the sender does not receive a response, the inform request can be sent again. Because they can be resent, informs are more likely than traps to reach their intended destination.

The characteristics that make informs more reliable than traps also consume more resources in the device and in the network. Unlike a trap, which is discarded as soon as it is sent, an inform request is held in memory until a response is received or the request times out. Traps are sent only once, but an inform might be resent or retried several times. The retries increase traffic and contribute to a higher overhead on the network. Therefore, traps and informs require a trade-off between reliability and resources. If it is important that the SNMP manager receive every notification, use inform requests. If traffic on the network or memory in the device is a concern and notification is not required, use traps.

SNMP ifIndex MIB Object Values

In an NMS, the IF-MIB generates and assigns an interface index (ifIndex) object value that is a unique number greater than zero to identify a physical or a logical interface. When the device reboots or the device software is upgraded, the device uses this same value for the interface. For example, if the device assigns a port 2 an ifIndex value of 10003, this value is the same after the device reboots.

The device uses one of the values in the following table to assign an ifIndex value to an interface:

ifIndex Values

Interface Type

ifIndex Range

SVI[1]

1–4999

EtherChannel

5001–5048

Tunnel

5078–5142

Physical (such as Gigabit Ethernet or SFP[2]-module interfaces) based on type and port numbers

10000–14500

Null

14501

Loopback and Tunnel

24567+

[1] SVI = switch virtual interface

[2] SFP = small form-factor pluggable

Default SNMP Configuration

Feature

Default Setting

SNMP agent

Disabled[1].

SNMP trap receiver

None configured.

SNMP traps

None enabled except the trap for TCP connections (tty).

SNMP version

If no version keyword is present, the default is Version 1.

SNMPv3 authentication

If no keyword is entered, the default is the noauth (noAuthNoPriv) security level.

SNMP notification type

If no type is specified, all notifications are sent.

[1] This is the default when the device starts and the startup configuration does not have any snmp-server global configuration commands.

SNMP Configuration Guidelines

If the device starts and the device startup configuration has at least one snmp-server global configuration command, the SNMP agent is enabled.

An SNMP group is a table that maps SNMP users to SNMP views. An SNMP user is a member of an SNMP group. An SNMP host is the recipient of an SNMP trap operation. An SNMP engine ID is a name for the local or remote SNMP engine.

When configuring SNMP, follow these guidelines:

- When configuring an SNMP group, do not specify a notify view. The snmp-server host global configuration command auto-generates a notify view for the user and then adds it to the group associated with that user. Modifying the group's notify view affects all users associated with that group.

- To configure a remote user, specify the IP address or port number for the remote SNMP agent of the device where the user resides.

- Before you configure remote users for a particular agent, configure the SNMP engine ID, using the snmp-server engineID global configuration command with the remote option. The remote agent's SNMP engine ID and user password are used to compute the authentication and privacy digests. If you do not configure the remote engine ID first, the configuration command fails.

- When configuring SNMP informs, you need to configure the SNMP engine ID for the remote agent in the SNMP database before you can send proxy requests or informs to it.

- If a local user is not associated with a remote host, the device does not send informs for the auth (authNoPriv) and the priv (authPriv) authentication levels.

- Changing the value of the SNMP engine ID has significant results. A user's password (entered on the command line) is converted to an MD5 or SHA security digest based on the password and the local engine ID. The command-line password is then destroyed, as required by RFC 2274. Because of this deletion, if the value of the engine ID changes, the security digests of SNMPv3 users become invalid, and you need to reconfigure SNMP users by using the snmp-server user username global configuration command. Similar restrictions require the reconfiguration of community strings when the engine ID changes.

How to Configure SNMP

This section provides information about configuring SNMP.

- Disabling the SNMP Agent

- Configuring Community Strings

- Configuring SNMP Groups and Users

- Configuring SNMP Notifications

- Setting the Agent Contact and Location Information

- Limiting TFTP Servers Used Through SNMP

Disabling the SNMP Agent

The no snmp-server global configuration command disables all running versions (Version 1, Version 2C, and Version 3) of the SNMP agent on the device. You reenable all versions of the SNMP agent by the first snmp-server global configuration command that you enter. There is no Cisco IOS command specifically designated for enabling SNMP.

Follow these steps to disable the SNMP agent.

Before you begin

The SNMP Agent must be enabled before it can be disabled. The SNMP agent is enabled by the first snmp-server global configuration command entered on the device.

Procedure

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode.

Enter your password if prompted.

Step 2

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 3

no snmp-server

Example:

Device(config)# no snmp-server

Disables the SNMP agent operation.

Step 4

end

Example:

Device(config)# end

Returns to privileged EXEC mode.

Step 5

show running-config

Example:

Device# show running-config

Verifies your entries.

Step 6

copy running-config startup-config

Example:

Device# copy running-config startup-config

(Optional) Saves your entries in the configuration file.

Configuring Community Strings

You use the SNMP community string to define the relationship between the SNMP manager and the agent. The community string acts like a password to permit access to the agent on the device. Optionally, you can specify one or more of these characteristics associated with the string:

- An access list of IP addresses of the SNMP managers that are permitted to use the community string to gain access to the agent

- A MIB view, which defines the subset of all MIB objects accessible to the given community

- Read and write or read-only permission for the MIB objects accessible to the community

Follow these steps to configure a community string on the device.

Procedure

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 3

snmp-server community string [ view view-name] [ ro | rw] [ access-list-number]

Example:

Device(config)# snmp-server community comaccess ro 4

Configures the community string.

Note

The @ symbol is used for delimiting the context information. Avoid using the @ symbol as part of the SNMP community string when configuring this command.

- For string , specify a string that acts like a password and permits access to the SNMP protocol. You can configure one or more community strings of any length.

- (Optional) For view , specify the view record accessible to the community.

- (Optional) Specify either read-only (ro ) if you want authorized management stations to retrieve MIB objects, or specify read-write (rw ) if you want authorized management stations to retrieve and modify MIB objects. By default, the community string permits read-only access to all objects.

- (Optional) For access-list-number , enter an IP standard access list numbered from 1 to 99 and 1300 to 1999.

Step 4

access-list access-list-number { deny | permit} source [ source-wildcard]

Example:

Device(config)# access-list 4 deny any

(Optional) If you specified an IP standard access list number in Step 3, then create the list, repeating the command as many times as necessary.

- For access-list-number , enter the access list number specified in Step 3.

- The deny keyword denies access if the conditions are matched. The permit keyword permits access if the conditions are matched.

- For source , enter the IP address of the SNMP managers that are permitted to use the community string to gain access to the agent.

- (Optional) For source-wildcard , enter the wildcard bits in dotted decimal notation to be applied to the source. Place ones in the bit positions that you want to ignore.

Recall that the access list is always terminated by an implicit deny statement for everything.

Step 5

end

Example:

Device(config)# end

Returns to privileged EXEC mode.

Step 6

show running-config

Example:

Device# show running-config

Verifies your entries.

Step 7

copy running-config startup-config

Example:

Device# copy running-config startup-config

(Optional) Saves your entries in the configuration file.

What to do next

To disable access for an SNMP community, set the community string for that community to the null string (do not enter a value for the community string).

To remove a specific community string, use the no snmp-server community string global configuration command.

You can specify an identification name (engine ID) for the local or remote SNMP server engine on the device. You can configure an SNMP server group that maps SNMP users to SNMP views, and you can add new users to the SNMP group.

Configuring SNMP Groups and Users

You can specify an identification name (engine ID) for the local or remote SNMP server engine on the device. You can configure an SNMP server group that maps SNMP users to SNMP views, and you can add new users to the SNMP group.

Follow these steps to configure SNMP groups and users on the device.

Procedure

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 3

snmp-server engineID { local engineid-string | remote ip-address [ udp-port port-number] engineid-string}

Example:

Device(config)# snmp-server engineID local 1234

Configures a name for either the local or remote copy of SNMP.

- The engineid-string is a 24-character ID string with the name of the copy of SNMP. You need not specify the entire 24-character engine ID if it has trailing zeros. Specify only the portion of the engine ID up to the point where only zeros remain in the value. The Step Example configures an engine ID of 123400000000000000000000.

- If you select remote , specify the ip-address of the device that contains the remote copy of SNMP and the optional User Datagram Protocol (UDP) port on the remote device. The default is 162.

Step 4

snmp-server group group-name { v1 | v2c | v3 { auth | noauth | priv} } [ read readview] [ write writeview] [ notify notifyview] [ access access-list]

Example:

Device(config)# snmp-server group public v2c access lmnop

Configures a new SNMP group on the remote device.

For group-name , specify the name of the group.

Specify one of the following security models:

- v1 is the least secure of the possible security models.

- v2c is the second least secure model. It allows transmission of informs and integers twice the normal width.

- v3 , the most secure, requires you to select one of the following authentication levels:

auth —Enables the Message Digest 5 (MD5) and the Secure Hash Algorithm (SHA) packet authentication.

noauth —Enables the noAuthNoPriv security level. This is the default if no keyword is specified.

priv —Enables Data Encryption Standard (DES) packet encryption (also called privacy).

(Optional) Enter read readview with a string (not to exceed 64 characters) that is the name of the view in which you can only view the contents of the agent.

(Optional) Enter write writeview with a string (not to exceed 64 characters) that is the name of the view in which you enter data and configure the contents of the agent.

(Optional) Enter notify notifyview with a string (not to exceed 64 characters) that is the name of the view in which you specify a notify, inform, or trap.

(Optional) Enter access access-list with a string (not to exceed 64 characters) that is the name of the access list.

Step 5

snmp-server user username group-name { remote host [ udp-port port] } { v1 [ access access-list] | v2c [ access access-list] | v3 [ encrypted] [ access access-list] [ auth { md5 | sha} auth-password] } [ priv { des | 3des | aes { 128 | 192 | 256} } priv-password]

Example:

Device(config)#  snmp-server user Pat public v2c

Adds a new user for an SNMP group.

The username is the name of the user on the host that connects to the agent.

The group-name is the name of the group to which the user is associated.

Enter remote to specify a remote SNMP entity to which the user belongs and the hostname or IP address of that entity with the optional UDP port number. The default is 162.

Enter the SNMP version number (v1 , v2c , or v3 ). If you enter v3 , you have these additional options:

- encrypted specifies that the password appears in encrypted format. This keyword is available only when the v3 keyword is specified.

- auth is an authentication level setting session that can be either the HMAC-MD5-96 (md5 ) or the HMAC-SHA-96 (sha ) authentication level and requires a password string auth-password (not to exceed 64 characters).

If you enter v3 you can also configure a private (priv ) encryption algorithm and password string priv-password using the following keywords (not to exceed 64 characters):

- priv specifies the User-based Security Model (USM).

- des specifies the use of the 56-bit DES algorithm.

- 3des specifies the use of the 168-bit DES algorithm.

- aes specifies the use of the DES algorithm. You must select either 128-bit, 192-bit, or 256-bit encryption.

(Optional) Enter access access-list with a string (not to exceed 64 characters) that is the name of the access list.

Step 6

end

Example:

Device(config)# end

Returns to privileged EXEC mode.

Step 7

show running-config

Example:

Device# show running-config

Verifies your entries.

Step 8

copy running-config startup-config

Example:

Device# copy running-config startup-config

(Optional) Saves your entries in the configuration file.

Configuring SNMP Notifications

A trap manager is a management station that receives and processes traps. Traps are system alerts that the device generates when certain events occur. By default, no trap manager is defined, and no traps are sent. Devices running this Cisco IOS release can have an unlimited number of trap managers.

Note

Many commands use the word traps in the command syntax. Unless there is an option in the command to select either traps or informs, the keyword traps refers to traps, informs, or both. Use the snmp-server host global configuration command to specify whether to send SNMP notifications as traps or informs.

You can use the snmp-server host global configuration command for a specific host to receive the notification types listed in the following table. You can enable any or all of these traps and configure a trap manager to receive them.

Device Notification Types

Notification Type Keyword

Description

bridge

Generates STP bridge MIB traps.

cluster

Generates a trap when the cluster configuration changes.

config

Generates a trap for SNMP configuration changes.

copy-config

Generates a trap for SNMP copy configuration changes.

cpu threshold

Allow CPU-related traps.

entity

Generates a trap for SNMP entity changes.

envmon

Generates environmental monitor traps. You can enable any or all of these environmental traps: fan, shutdown, status, supply, temperature.

errdisable

Generates a trap for a port VLAN errdisabled. You can also set a maximum trap rate per minute. The range is from 0 to 10000; the default is 0, which means there is no rate limit.

flash

Generates SNMP FLASH notifications. In a switch stack, you can optionally enable notification for flash insertion or removal, which would cause a trap to be issued whenever a switch in the stack is removed or inserted (physical removal, power cycle, or reload).

fru-ctrl

Generates entity field-replaceable unit (FRU) control traps. In the switch stack, this trap refers to the insertion or removal of a switch in the stack.

ipmulticast

Generates a trap for IP multicast routing changes.

ipsla

Generates a trap for the SNMP IP Service Level Agreements (SLAs).

mac-notification

Generates a trap for MAC address notifications.

msdp

Generates a trap for Multicast Source Discovery Protocol (MSDP) changes.

ospf

Generates a trap for Open Shortest Path First (OSPF) changes. You can enable any or all of these traps: Cisco specific, errors, link-state advertisement, rate limit, retransmit, and state changes.

pim

Generates a trap for Protocol-Independent Multicast (PIM) changes. You can enable any or all of these traps: invalid PIM messages, neighbor changes, and rendezvous point (RP)-mapping changes.

port-security

Generates SNMP port security traps. You can also set a maximum trap rate per second. The range is from 0 to 1000; the default is 0, which means that there is no rate limit.

Note

When you configure a trap by using the notification type port-security , configure the port security trap first, and then configure the port security trap rate:

1. snmp-server enable traps port-security

2. snmp-server enable traps port-security trap-rate rate

snmp

Generates a trap for SNMP-type notifications for authentication, cold start, warm start, link up or link down.

storm-control

Generates a trap for SNMP storm-control. You can also set a maximum trap rate per minute. The range is from 0 to 1000; the default is 0 (no limit is imposed; a trap is sent at every occurrence).

stpx

Generates SNMP STP Extended MIB traps.

syslog

Generates SNMP syslog traps.

tty

Generates a trap for TCP connections. This trap is enabled by default.

vlan-membership

Generates a trap for SNMP VLAN membership changes.

vlancreate

Generates SNMP VLAN created traps.

vlandelete

Generates SNMP VLAN deleted traps.

vtp

Generates a trap for VLAN Trunking Protocol (VTP) changes.

Follow these steps to configure the device to send traps or informs to a host.

Procedure

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 3

snmp-server engineID remote ip-address engineid-string

Example:

Device(config)# snmp-server engineID remote 192.180.1.27 00000063000100a1c0b4011b

Specifies the engine ID for the remote host.

Step 4

snmp-server user username group-name { remote host [ udp-port port] } { v1 [ access access-list] | v2c [ access access-list] | v3 [ encrypted] [ access access-list] [ auth { md5 | sha} auth-password] }

Example:

Device(config)#  snmp-server user Pat public v2c

Configures an SNMP user to be associated with the remote host created in Step 3.

Note

You cannot configure a remote user for an address without first configuring the engine ID for the remote host. Otherwise, you receive an error message, and the command is not executed.

Step 5

snmp-server group group-name { v1 | v2c | v3 { auth | noauth | priv} } [ read readview] [ write writeview] [ notify notifyview] [ access access-list]

Example:

Device(config)# snmp-server group public v2c access lmnop

Configures an SNMP group.

Step 6

snmp-server host host-addr [ informs | traps] [ version { 1 | 2c | 3 { auth | noauth | priv} } ] community-string [ notification-type]

Example:

Device(config)# snmp-server host 203.0.113.1 comaccess snmp

Specifies the recipient of an SNMP trap operation.

For host-addr , specify the name or Internet address of the host (the targeted recipient).

(Optional) Specify traps (the default) to send SNMP traps to the host.

(Optional) Specify informs to send SNMP informs to the host.

(Optional) Specify the SNMP version (1 , 2c , or 3 ). SNMPv1 does not support informs.

(Optional) For Version 3, select authentication level auth , noauth , or priv .

Note

The priv keyword is available only when the cryptographic software image is installed.

For community-string , when version 1 or version 2c is specified, enter the password-like community string sent with the notification operation. When version 3 is specified, enter the SNMPv3 username.

The @ symbol is used for delimiting the context information. Avoid using the @ symbol as part of the SNMP community string when configuring this command.

(Optional) For notification-type , use the keywords listed in the table above. If no type is specified, all notifications are sent.

Step 7

snmp-server enable traps notification-types

Example:

Device(config)# snmp-server enable traps snmp

Enables the device to send traps or informs and specifies the type of notifications to be sent. For a list of notification types, see the table above, or enter snmp-server enable traps ?

To enable multiple types of traps, you must enter a separate snmp-server enable traps command for each trap type.

Note

When you configure a trap by using the notification type port-security , configure the port security trap first, and then configure the port security trap rate:

1. snmp-server enable traps port-security

2. snmp-server enable traps port-security trap-rate rate

Step 8

snmp-server trap-source interface-id

Example:

Device(config)# snmp-server trap-source gigabitethernet 1/0/1

(Optional) Specifies the source interface, which provides the IP address for the trap message. This command also sets the source IP address for informs.

Step 9

snmp-server queue-length length

Example:

Device(config)# snmp-server queue-length 20

(Optional) Establishes the message queue length for each trap host. The range is 1 to 5000; the default is 10.

Step 10

snmp-server trap-timeout seconds

Example:

Device(config)# snmp-server trap-timeout 60

(Optional) Defines how often to resend trap messages. The range is 1 to 1000; the default is 30 seconds.

Step 11

end

Example:

Device(config)# end

Returns to privileged EXEC mode.

Step 12

show running-config

Example:

Device# show running-config

Verifies your entries.

Step 13

show running-config

Example:

Device# show running-config

Verifies your entries.

Step 14

copy running-config startup-config

Example:

Device# copy running-config startup-config

(Optional) Saves your entries in the configuration file.

What to do next

The snmp-server host command specifies which hosts receive the notifications. The snmp-server enable traps command globally enables the method for the specified notification (for traps and informs). To enable a host to receive an inform, you must configure an snmp-server host informs command for the host and globally enable informs by using the snmp-server enable traps command.

To remove the specified host from receiving traps, use the no snmp-server host host global configuration command. The no snmp-server host command with no keywords disables traps, but not informs, to the host. To disable informs, use the no snmp-server host informs global configuration command. To disable a specific trap type, use the no snmp-server enable traps notification-types global configuration command.

Setting the Agent Contact and Location Information

Follow these steps to set the system contact and location of the SNMP agent so that these descriptions can be accessed through the configuration file.

Procedure

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode.

Enter your password if prompted.

Step 2

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 3

snmp-server contact text

Example:

Device(config)# snmp-server contact Dial System Operator at beeper 21555

Sets the system contact string.

Step 4

snmp-server location text

Example:

Device(config)# snmp-server location Building 3/Room 222

Sets the system location string.

Step 5

end

Example:

Device(config)# end

Returns to privileged EXEC mode.

Step 6

show running-config

Example:

Device# show running-config

Verifies your entries.

Step 7

copy running-config startup-config

Example:

Device# copy running-config startup-config

(Optional) Saves your entries in the configuration file.

Limiting TFTP Servers Used Through SNMP

Follow these steps to limit the TFTP servers used for saving and loading configuration files through SNMP to the servers specified in an access list.

Procedure

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode.

Enter your password if prompted.

Step 2

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 3

snmp-server tftp-server-list access-list-number

Example:

Device(config)# snmp-server tftp-server-list 44

Limits the TFTP servers used for configuration file copies through SNMP to the servers in the access list.

For access-list-number , enter an IP standard access list numbered from 1 to 99 and 1300 to 1999.

Step 4

access-list access-list-number { deny | permit} source [ source-wildcard]

Example:

Device(config)# access-list 44 permit 10.1.1.2

Creates a standard access list, repeating the command as many times as necessary.

For access-list-number , enter the access list number specified in Step 3.

The deny keyword denies access if the conditions are matched. The permit keyword permits access if the conditions are matched.

For source , enter the IP address of the TFTP servers that can access the device.

(Optional) For source-wildcard , enter the wildcard bits, in dotted decimal notation, to be applied to the source. Place ones in the bit positions that you want to ignore.

The access list is always terminated by an implicit deny statement for everything.

Step 5

end

Example:

Device(config)# end

Returns to privileged EXEC mode.

Step 6

show running-config

Example:

Device# show running-config

Verifies your entries.

Step 7

copy running-config startup-config

Example:

Device# copy running-config startup-config

(Optional) Saves your entries in the configuration file.

Monitoring SNMP Status

To display SNMP input and output statistics, including the number of illegal community string entries, errors, and requested variables, use the show snmp privileged EXEC command. You also can use the other privileged EXEC commands listed in the table to display SNMP information.

Commands for Displaying SNMP Information

Command

Purpose

show snmp

Displays SNMP statistics.

show snmp group

Displays information on each SNMP group on the network.

show snmp pending

Displays information on pending SNMP requests.

show snmp sessions

Displays information on the current SNMP sessions.

show snmp user

Displays information on each SNMP user name in the SNMP users table.

Note

You must use this command to display SNMPv3 configuration information for auth | noauth | priv mode. This information is not displayed in the show running-config output.

SNMP Examples

This example shows how to enable all versions of SNMP. The configuration permits any SNMP manager to access all objects with read-only permissions using the community string public . This configuration does not cause the device to send any traps.

Device(config)# snmp-server community public

This example shows how to permit any SNMP manager to access all objects with read-only permission using the community string public . The device also sends VTP traps to the hosts 192.180.1.111 and 192.180.1.33 using SNMPv1 and to the host 192.180.1.27 using SNMPv2C. The community string public is sent with the traps.

Device(config)# snmp-server community public
Device(config)# snmp-server enable traps vtp
Device(config)# snmp-server host 192.180.1.27 version 2c public
Device(config)# snmp-server host 192.180.1.111 version 1 public
Device(config)# snmp-server host 192.180.1.33 public

This example shows how to allow read-only access for all objects to members of access list 4 that use the comaccess community string. No other SNMP managers have access to any objects. SNMP Authentication Failure traps are sent by SNMPv2C to the host cisco.com using the community string public .

Device(config)# snmp-server community comaccess ro 4
Device(config)# snmp-server enable traps snmp authentication
Device(config)# snmp-server host cisco.com version 2c public

This example shows how to send Entity MIB traps to the host cisco.com . The community string is restricted. The first line enables the device to send Entity MIB traps in addition to any traps previously enabled. The second line specifies the destination of these traps and overwrites any previous snmp-server host commands for the host cisco.com .

Device(config)# snmp-server enable traps entity
Device(config)# snmp-server host cisco.com restricted entity

This example shows how to enable the device to send all traps to the host myhost.cisco.com using the community string public :

Device(config)# snmp-server enable traps
Device(config)# snmp-server host myhost.cisco.com public

This example shows how to associate a user with a remote host and to send auth (authNoPriv) authentication-level informs when the user enters global configuration mode:

Device(config)# snmp-server engineID remote 192.180.1.27 00000063000100a1c0b4011b
Device(config)# snmp-server group authgroup v3 auth
Device(config)# snmp-server user authuser authgroup remote 192.180.1.27 v3 auth md5 mypassword
Device(config)# snmp-server user authuser authgroup v3 auth md5 mypassword
Device(config)# snmp-server host 192.180.1.27 informs version 3 auth authuser config
Device(config)# snmp-server enable traps
Device(config)# snmp-server inform retries 0

Feature Information for Configuring SNMP

This table provides release and related information for features explained in this module.

These features are available on all releases subsequent to the one they were introduced in, unless noted otherwise.

Release

Feature

Feature Information

Configuring SNMP

SNMP is an application-layer protocol that provides a message format for communication between managers and agents.

Use Cisco Feature Navigator to find information about platform and software image support. To access Cisco Feature Navigator, go to http://www.cisco.com/go/cfn.

Chapter 4. Configuring Switched Port Analyzer

- Restrictions for Switched Port Analyzer

- Information about SPAN

- Switched Port Analyzer Configuration Guidelines

- How to Configure SPAN

- Monitoring Switched Port Analyzer Operations

- Configuration Examples for Switched Port Analyzer

- Feature Information for Switched Port Analyzer

Restrictions for Switched Port Analyzer

The restrictions for the Switched Port Analyzer (SPAN) are as follows:

- SPAN filtering is not supported.

- For SPAN sources, you can monitor traffic for a single port or a series or range of ports for each session.

- The destination port cannot be a source port; a source port cannot be a destination port.

- You cannot have two SPAN sessions using the same destination port.

- You cannot have two SPAN sessions using the same source port.

- When you configure a switch port as a SPAN destination port, it is no longer a normal switch port; only monitored traffic passes through the SPAN destination port.

- Entering SPAN configuration commands does not remove previously configured SPAN parameters. You must enter the no monitor session session_number global configuration command to delete configured SPAN parameters.

- You can configure a disabled port to be a source or destination port, but the SPAN function does not start until the destination port and at least one source port are enabled.

Traffic monitoring in a SPAN session has the following restrictions:

- The device supports up to four local SPAN sessions.

- SPAN sessions do not interfere with the normal operation of the device. However, an oversubscribed SPAN destination, for example, a 10-Mb/s port monitoring a 100-Mb/s port, can result in dropped or lost packets.

- When SPAN is enabled, each packet being monitored is sent twice, once as normal traffic and once as a monitored packet. Monitoring a large number of ports could potentially generate large amounts of network traffic.

- You can configure SPAN sessions on disabled ports; however, a SPAN session does not become active unless you enable the destination port and at least one source port for that session.

Information about SPAN

This section provides information about SPAN.

- Switched Port Analyzer

- Default Switched Port Analyzer Configuration

Switched Port Analyzer

You can analyze network traffic passing through ports by using SPAN to send a copy of the traffic to another port on the switch or on another switch that has been connected to a network analyzer or other monitoring or security device. SPAN copies (or mirrors) traffic received or sent (or both) on source ports to a destination port for analysis. SPAN does not affect the switching of network traffic on the source ports. You must dedicate the destination port for SPAN use. Except for traffic that is required for the SPAN session, destination ports do not receive or forward traffic.

Only traffic that enters or leaves source ports can be monitored by using SPAN.

You can use the SPAN destination port to inject traffic from a network security device. For example, if you connect a Cisco Intrusion Detection System (IDS) sensor appliance to a destination port, the IDS device can send TCP reset packets to close down the TCP session of a suspected attacker.

Note

We recommend that you do not use SPAN with multiple source ports. If there are multiple source ports, it is not guaranteed that all mirrored traffic will be captured at the destination port.

Default Switched Port Analyzer Configuration

Default SPAN Configuration

Feature

Default Setting

SPAN state

Disabled.

Source port traffic to monitor

Both received and sent traffic (both ).

Encapsulation type (destination port)

Native form (untagged packets).

Ingress forwarding (destination port)

Disabled.

Switched Port Analyzer Configuration Guidelines

To remove a source or destination port from the SPAN session, use the no monitor session session_number source interface interface-id global configuration command or the no monitor session session_number destination interface interface-id global configuration command. For destination interfaces, the encapsulation options are ignored with the no form of the command.

How to Configure SPAN

This section provides information about how to configure SPAN.

- Creating a Local Switched Port Analyzer Session

- Creating a Local Switched Port Analyzer Session and Configuring Incoming Traffic

Creating a Local Switched Port Analyzer Session

Follow these steps to create a SPAN session and specify the source (monitored) ports or VLANs and the destination (monitoring) ports.

Procedure

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode.

Enter your password if prompted.

Step 2

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 3

no monitor session session_number

Example:

Device(config)# no monitor session 1

Removes existing SPAN configuration for the specified session. The range is 1 to 4.

Step 4

monitor session session_number source {interface interface-id} [, | -] [both | rx | tx]

Example:

Device(config)# monitor session 1 source interface gigabitethernet 1/0/1

Specifies the SPAN session and the source port (monitored port).

- For session_number , the range is 1 to 4.

- For interface-id , specify the source port to monitor. Valid interfaces include physical interfaces and port-channel logical interfaces (port-channel port-channel-number ). Valid port-channel numbers are 1 to 6.

- (Optional) [, | -] : Specifies a series or range of interfaces. Enter a space before and after the comma; enter a space before and after the hyphen.

- (Optional) both | rx | tx : Specifies the direction of traffic to monitor. If you do not specify a traffic direction, the source interface sends both sent and received traffic.

- both : Monitors both received and sent traffic.

- rx : Monitors received traffic.

- tx : Monitors sent traffic.

Note

You can use the monitor session session_number source command multiple times to configure multiple source ports.

Step 5

monitor session session_number destination {interface interface-id [, | -] }

Example:

Device(config)# monitor session 1 destination interface gigabitethernet 1/0/2

Specifies the SPAN session and the destination port (monitoring port). The port LED changes to amber when the configuration changes take effect. The LED returns to its original state(green) only after removing the SPAN destination configuration.

Note

For local SPAN, you must use the same session number for the source and destination interfaces.

- For session_number , specify the session number entered in step 4.

- For interface-id , specify the destination port. The destination interface must be a physical port; it cannot be an EtherChannel, and it cannot be a VLAN.

- (Optional) [, | -] Specifies a series or range of interfaces. Enter a space before and after the comma; enter a space before and after the hyphen.

Note

You can use monitor session session_number destination command multiple times to configure multiple destination ports.

Step 6

end

Example:

Device(config)# end

Returns to privileged EXEC mode.

Creating a Local Switched Port Analyzer Session and Configuring Incoming Traffic

Follow these steps to create a SPAN session, to specify the source ports or VLANs and the destination ports, and to enable incoming traffic on the destination port for a network security device (such as a Cisco IDS Sensor Appliance).

Procedure

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode.

Enter your password if prompted.

Step 2

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 3

no monitor session session_number

Example:

Device(config)# no monitor session 1

Removes existing SPAN configuration for the specified session. The range is 1 to 4.

Step 4

monitor session session_number source {interface interface-id} [, | -] [both | rx | tx]

Example:

Device(config)# monitor session 2 source interface gigabitethernet 1/0/1 rx

Specifies the SPAN session and the source port (monitored port).

Step 5

monitor session session_number destination {interface interface-id [encapsulation replicate ingress {vlan vlan-id} | ingress {vlan vlan-id}]}

Example:

Device(config)# monitor session 2 destination interface gigabitethernet 1/0/1 ingress vlan 6

Specifies the SPAN session, the destination port, the packet encapsulation, and the ingress VLAN and encapsulation.

- For session_number , specify the session number entered in Step 4.

- For interface-id , specify the destination port. The destination interface must be a physical port; it cannot be an EtherChannel, and it cannot be a VLAN.

- (Optional) encapsulation replicate : Specifies that the destination interface replicates the source interface encapsulation method. If not selected, the default is to send packets in native form (untagged).

- ingress : Enables forwarding of incoming traffic on the destination port and to specify the encapsulation type.

Step 6

end

Example:

Device(config)# end

Returns to privileged EXEC mode.

Monitoring Switched Port Analyzer Operations

The following table describes the command used to display SPAN operations configuration and results to monitor operations:

Monitoring SPAN Operations

Command

Purpose

show monitor session

Displays the current SPAN configuration.

Enter the all keyword to show configuration for all SPAN sessions, the local keyword to show configurations for local sessions only, and the range keyword to show configurations for a range of SPAN sessions.

Configuration Examples for Switched Port Analyzer

The following section provides configuration examples for SPAN.

- Configuration Examples for Local Switched Port Analyzer

Configuration Examples for Local Switched Port Analyzer

This example shows how to set up SPAN session 1 for monitoring source port traffic to a destination port. First, any existing SPAN configuration for session 1 is deleted, and then bidirectional traffic is mirrored from source Gigabit Ethernet port 1 to destination Gigabit Ethernet port 2, retaining the encapsulation method.

Device> enable
Device# configure terminal
Device(config)# no monitor session 1
Device(config)# monitor session 1 source interface gigabitethernet 1/0/1
Device(config)# monitor session 1 destination interface
Device(config)# end

This example shows how to remove port 1 as a SPAN source for SPAN session 1:

Device> enable
Device# configure terminal
Device(config)# no monitor session 1 source interface gigabitethernet 1/0/1
Device(config)# end

This example shows how to disable received traffic monitoring on port 1, which was configured for bidirectional monitoring:

Device> enable
Device# configure terminal
Device(config)# no monitor session 1 source interface gigabitethernet 1/0/1 rx

The monitoring of traffic received on port 1 is disabled, but traffic sent from this port continues to be monitored.

This example shows how to remove any existing configuration on SPAN session 2, configure SPAN session 2 to monitor received traffic on all ports belonging to VLANs 1 through 3, and send it to destination Gigabit Ethernet port 2. The configuration is then modified to also monitor all traffic on all ports belonging to VLAN 10.

Device> enable
Device# configure terminal
Device(config)# no monitor session 2
Device(config)# monitor session 2 destination interface gigabitethernet 1/0/2
Device(config)# end

This example shows how to remove any existing configuration on SPAN session 2, configure SPAN session 2 to monitor received traffic on Gigabit Ethernet source port 1, and send it to destination Gigabit Ethernet port 2 with the same egress encapsulation type as the source port, and to enable ingress forwarding with VLAN 6 as the default ingress VLAN:

Device> enable
Device# configure terminal
Device(config)# no monitor session 2
Device(config)# monitor session 2 source gigabitethernet 1/0/1 rx
Device(config)# monitor session 2 destination interface gigabitethernet 1/0/2 encapsulation replicate ingress vlan 6
Device(config)# end

Feature Information for Switched Port Analyzer

This table provides release and related information for features explained in this module.

These features are available on all releases subsequent to the one they were introduced in, unless noted otherwise.

Release

Feature

Feature Information

Switch Port Analyzer (SPAN)

SPAN allows to analyze network traffic on ports by sending copies of the traffic to either another port on the switch or onto another switch that has been connected to a network analyzer or other monitoring or security device.

Use Cisco Feature Navigator to find information about platform and software image support. To access Cisco Feature Navigator, go to http://www.cisco.com/go/cfn.

Full Cisco Trademarks with Software License

THE SPECIFICATIONS AND INFORMATION REGARDING THE PRODUCTS IN THIS MANUAL ARE SUBJECT TO CHANGE WITHOUT NOTICE. ALL STATEMENTS, INFORMATION, AND RECOMMENDATIONS IN THIS MANUAL ARE BELIEVED TO BE ACCURATE BUT ARE PRESENTED WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED. USERS MUST TAKE FULL RESPONSIBILITY FOR THEIR APPLICATION OF ANY PRODUCTS.

THE SOFTWARE LICENSE AND LIMITED WARRANTY FOR THE ACCOMPANYING PRODUCT ARE SET FORTH IN THE INFORMATION PACKET THAT SHIPPED WITH THE PRODUCT AND ARE INCORPORATED HEREIN BY THIS REFERENCE. IF YOU ARE UNABLE TO LOCATE THE SOFTWARE LICENSE OR LIMITED WARRANTY, CONTACT YOUR CISCO REPRESENTATIVE FOR A COPY.

The Cisco implementation of TCP header compression is an adaptation of a program developed by the University of California, Berkeley (UCB) as part of UCB's public domain version of the UNIX operating system. All rights reserved. Copyright © 1981, Regents of the University of California.

NOTWITHSTANDING ANY OTHER WARRANTY HEREIN, ALL DOCUMENT FILES AND SOFTWARE OF THESE SUPPLIERS ARE PROVIDED “AS IS" WITH ALL FAULTS. CISCO AND THE ABOVE-NAMED SUPPLIERS DISCLAIM ALL WARRANTIES, EXPRESSED OR IMPLIED, INCLUDING, WITHOUT LIMITATION, THOSE OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT OR ARISING FROM A COURSE OF DEALING, USAGE, OR TRADE PRACTICE.

IN NO EVENT SHALL CISCO OR ITS SUPPLIERS BE LIABLE FOR ANY INDIRECT, SPECIAL, CONSEQUENTIAL, OR INCIDENTAL DAMAGES, INCLUDING, WITHOUT LIMITATION, LOST PROFITS OR LOSS OR DAMAGE TO DATA ARISING OUT OF THE USE OR INABILITY TO USE THIS MANUAL, EVEN IF CISCO OR ITS SUPPLIERS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.

Any Internet Protocol (IP) addresses and phone numbers used in this document are not intended to be actual addresses and phone numbers. Any examples, command display output, network topology diagrams, and other figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses or phone numbers in illustrative content is unintentional and coincidental.

All printed copies and duplicate soft copies of this document are considered uncontrolled. See the current online version for the latest version.

Cisco has more than 200 offices worldwide. Addresses and phone numbers are listed on the Cisco website at www.cisco.com/go/offices.

Cisco and the Cisco logo are trademarks or registered trademarks of Cisco and/or its affiliates in the U.S. and other countries. To view a list of Cisco trademarks, go to this URL: https://www.cisco.com/c/en/us/about/legal/trademarks.html. Third-party trademarks mentioned are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (1721R)