Table Of Contents
Configuring SNMP on the Virtual Firewall
Contents
Information About Configuring SNMP
Managers and Agents
SNMP Manager and Agent Communication
SNMP Traps and Informs
SNMPv3 CLI User Management and AAA Integration
CLI and SNMP User Synchronization
Supported MIBs and Notifications
SNMP Limitations
How to Configure SNMP
Configuring SNMP
Prerequisites
Configuring SNMP Management Traffic Services
Prerequisites
Troubleshooting Tips
Additional References
Related Documents
Standards
MIBs
RFCs
Technical Assistance
Configuring SNMP on the Virtual Firewall
This module describes how to configure Simple Network Management Protocol (SNMP) to query the VFW application for Cisco Management Information Bases (MIBs) and to send event notifications to a network management system (NMS).
Feature History for Configuring SNMP on the VFW Application
Release
|
Modification
|
Release 3.5.0
|
This feature was introduced on the multiservice blade (MSB) for the Cisco XR 12000 Series Router.
|
Release 3.6.0
|
No modification.
|
Release 3.7.0
|
No modification.
|
Release 3.8.0
|
The ability to configure the engine ID was added.
|
Contents
•
Information About Configuring SNMP
•
How to Configure SNMP
•
Additional References
Information About Configuring SNMP
SNMP is an application-layer protocol that facilitates the exchange of management information between an NMS, SNMP agents, and managed devices such as the VFW application. You can configure the VFW application to send traps (event notifications) to an NMS, or you can use the NMS to browse the Management Information Bases (MIBs) residing on the VFW application.
The VFW application contains an SNMP agent that provides support for network monitoring. The VFW application supports SNMP Version 1 (SNMPv1), SNMP Version 2c (SNMPv2c), and SNMP Version 3 (SNMPv3).
SNMPv1 and SNMPv2c use a community string match for user authentication. Community strings provide a weaker form of access control. SNMPv3 provides improved access control by using strong authentication and should be used over SNMPv1 and SNMPv2c wherever possible.
SNMPv3 is an interoperable standards-based protocol for network management. SNMPv3 provides secure access to devices by using a combination of authenticating and encrypting frames over the network. The security features provided in SNMPv3 include:
•
Message integrity—Ensures that a packet has not been tampered with in transit.
•
Authentication—Determines that the message is from a valid source.
•
Encryption—Scrambles the packet contents to prevent it from being seen by unauthorized sources.
This section includes the following topics:
•
Managers and Agents
•
SNMP Manager and Agent Communication
•
SNMP Traps and Informs
•
SNMPv3 CLI User Management and AAA Integration
•
Supported MIBs and Notifications
•
SNMP Limitations
Managers and Agents
SNMP uses software entities called managers and agents to manage network devices:
•
The manager monitors and controls all other SNMP-managed devices (network nodes) in the network. There must be at least one SNMP manager in a managed network. The manager is installed on a workstation somewhere in the network.
•
An agent resides in a managed device (a network node). An agent is a specialized software module that receives instructions from the SNMP manager and sends management information back to the SNMP manager as events occur. For example, an agent might report such data as the number of bytes and packets in and out of the device, or the number of broadcast messages sent and received.
There are many different SNMP management applications, but they all perform the same basic task. These applications allow SNMP managers to communicate with agents to monitor, configure, and receive alerts from the network devices.The VFW application supports traps and SNMP get requests, but does not support SNMP set requests to configure values on the device. You can use any SNMP-compatible NMS to monitor the VFW application.
In SNMP, each variable is referred to as a managed object. A managed object is anything that an agent can access and report back to the NMS. All managed objects are contained in the MIB, which is a database of the managed objects called MIB objects. Each MIB object controls one specific function, such as counting how many bytes are transmitted through an agent's port. The MIB object consists of MIB variables, which define the MIB object name, description, and default value. The VFW application maintains a database of values for each definition.
Browsing a MIB entails issuing an SNMP get request from the NMS. You can use any SNMPv3, MIB-II compliant browser to receive SNMP traps and browse MIBs.
SNMP Manager and Agent Communication
There are several ways that the SNMP manager and the agent communicate. The protocol data unit (PDU) is the message format that SNMP managers and agents use to send and receive information.
•
The SNMP manager can:
–
Retrieve a value (a get operation) from an agent. The SNMP manager requests information from the agent, such as the number of users logged on to the agent device, or the status of a critical process on that device. The agent gets the value of the requested MIB object and sends the value back to the manager (a get-response operation). The variable binding (varbind) is a list of MIB objects that allows a request recipient to see what the originator wants to know. Variable bindings can be thought of as OID=value pairs that make it easy for the NMS to identify the information it needs when the recipient fills the request and sends back a response.
–
Retrieve the value immediately after the variable you name (a get-next operation). A get-next operation retrieves a group of values from a MIB by issuing a sequence of commands. Performing a get-next operation, you do not need to know the exact MIB object instance you are looking for; the SNMP manager takes the variable you name and then uses a sequential search to find the desired variables.
–
Retrieve a number of values (a get-bulk operation). The get-bulk operation retrieves large blocks of data, such as multiple rows in a table, which would otherwise require the transmission of many small blocks of data. The SNMP manager performs the number of get-next operations that you specify.
•
An agent can send an unsolicited message to the SNMP manager at any time if a significant, predetermined event takes place on the agent. This message is called an event notification. SNMP event notifications (traps or inform requests) are included in many MIBs and help to alleviate the need for the NMS to frequently poll (gather information through a get operation) the managed devices. For details about MIB objects and SNMP notifications supported by the VFW application, see the "Supported MIBs and Notifications" section.
SNMP Traps and Informs
You can configure the VFW application to send traps or inform requests notifications to SNMP managers when particular events occur. In some instances, traps can be unreliable, because the receiver does not send any acknowledgment when it receives a trap and the sender cannot determine if the trap was received. However, an SNMP manager that receives inform requests acknowledges the message with an SNMP Response PDU. If the sender never receives a Response, the inform request is normally retransmitted. Inform requests are more likely to reach their intended destination.
Notifications may contain a list of MIB variable bindings that clarify the status being relayed by the notification. The list of variable bindings associated with a notification is included in the notification definition in the MIB. In the case of standard MIBs, Cisco has enhanced some notifications with additional variable bindings that further clarify the cause of the notification.
Note
The clogOriginID and clogOriginIDType variable bindings appended with each notification can be used by the NMS application to uniquely identify the device originating the trap. The values for clogOriginID and clogOriginIDType varbinds can be configured by the user to uniquely identify the device by using the logging device-id configuration mode command.
Use the SNMP-TARGET-MIB to obtain more information on trap destinations and inform requests.
For details on SNMP notifications supported by the VFW application, see the "Supported MIBs and Notifications" section.
SNMPv3 CLI User Management and AAA Integration
The VFW application implements RFC 3414 and RFC 3415, including user-based security model (USM) and role-based access control. SNMP v3 user management can be centralized at the authentication, authorization and accounting (AAA) server level (as described in the "Configuring Authentication and Accounting Services on the Virtual Firewall" module). This centralized user management allows the SNMP agent running on the VFW application to leverage the user authentication service of AAA server. When user authentication is verified, the SNMP protocol data units (PDUs) are processed further. Additionally, the AAA server is also used to store user group names. SNMP uses the group names to apply the user access and role policy that is locally available in the VFW application.
CLI and SNMP User Synchronization
Any configuration changes made to the user group, role, or password, results in the database synchronization for both SNMP and AAA. To create an SNMP or CLI user, use the username command or the snmp-server user command. The password specified in the username command is synchronized as the auth and priv passwords for the SNMP user.
Users are synchronized as follows:
•
Deleting a user by using the no form of the username command results in the user being deleted from both SNMP and CLI. However, deleting a user by using the no form of the snmp-server user command results in the user being deleted only from SNMP and not from the CLI.
•
User-role mapping changes are synchronized in SNMP and CLI.
Note
When you specify the password in localized key or encrypted format for security encryption, the password is not synchronized.
•
Existing SNMP users continue to retain the auth and priv information without any changes.
•
If a new user that is not present in the SNMP database is created using the username command but without a password, the SNMP user is created with the noAuthNoPriv security level.
Supported MIBs and Notifications
Table 15 identifies the supported MIBs for the VFW application.
Table 15 SNMP MIB Support
MIB Support
|
Capability MIB
|
Description
|
Supervisor Module MIBs
|
CISCO-ENTITY-FRU- CONTROL-MIB
|
CISCO-ENTITY- FRU-CONTROL- CAPABILITY
|
This MIB is an extension to the ENTITY-MIB. It monitors the operational state of the VFW application.
The CISCO-ENTITY-FRU-CONTROL-MIB is supported only in the Admin context.
|
CISCO-ENTITY-VENDORTYPE-OID-MIB
|
N/A
|
This MIB defines the object identifiers (OIDs) assigned to various VFW application components. The OIDs in this MIB are used by the entPhysicalTable of the ENTITY-MIB as values for the entPhysicalVendorType field in entPhysicalTable. Each OID uniquely identifies a type of physical entity, such as a chassis, line cards, or port adapters. The entPhysicalVendorType OID values are listed below:
Product Name (PID) entPhysicalVendorType
ACE10-6500-K9 cevCat6kAce10K9 (cevModuleCat6000Type 120)
Inlet Temperature cevSensorModuleInletTemp (cevSensor 36)
Outlet Temperature cevSensorModuleOutletTemp (cevSensor 35)
Other device temperature sensors cevSensorModuleDeviceTemp (cevSensor 31)
|
ENTITY-MIB
|
CISCO-ENTITY- CAPABILITY
|
Provides basic management and identification of physical and logical entities within a network device. Software support for the ENTITY-MIB focuses on the physical entities within the VFW application. This MIB provides details on each module, power supply, and fan tray within a switch chassis. It gives enough information to correctly map the containment of these entities within the VFW application, building up a chassis view.
The ENTITY-MIB is supported only in the Admin context.
The ENTITY-MIB is described in RFC 4133.
|
ENTITY-SENSOR-MIB
|
CISCO-ENTITY- SENSOR-RFC- CAPABILITY
|
This MIB contains a single group called the entitySensorValueGroup, which allows objects to convey the current value and status of a physical sensor. The entitySensorValueGroup contains a single table, called the entPhySensorTable, which provides a small number of read-only objects that identify the type of data units, scaling factor, precision, current value, and operational status of the sensor.
The ENTITY-SENSOR-MIB is supported only in the Admin context.
The ENTITY-SENSOR-MIB is described in RFC 3433.
|
SNMPv3 Agent MIBs
|
SNMP-COMMUNITY- MIB
|
CISCO-SNMP- COMMUNITY- CAPABILITY
|
Contains objects for mapping between community strings and version-independent SNMP message parameters. In addition, this MIB provides a mechanism for performing source address validation on incoming requests and for selecting community strings based on target addresses for outgoing notifications.
The SNMP-COMMUNITY-MIB is described in RFC 3584.
Note SNMP communities are applicable only for SNMPv1 and SNMPv2c. SNMPv3 requires user configuration information such as specifying the role group that the user belongs to, authentication parameters for the user, authentication password, and message encryption parameters.
|
SNMP-FRAMEWORK- MIB
|
CISCO-SNMP- FRAMEWORK- CAPABILITY
|
Defines the elements of SNMP Management Frameworks, including an SNMP engine and Access Control Subsystem.
The SNMP-FRAMEWORK-MIB is described in RFC 3411.
|
SNMP-MPD-MIB
|
CISCO-SNMP- MPD- CAPABILITY
|
Describes Message Processing Subsystem and Dispatcher for SNMP. The Dispatcher in the SNMP engine sends and receives SNMP messages. It also dispatches SNMP PDUs to SNMP applications. A Message Processing Model is responsible for processing an SNMP version-specific message and for coordinating the interaction with the Security Subsystem to ensure that proper security is applied to the SNMP message being handled.
The SNMP-MPD-MIB is described in RFC 3412.
|
SNMP-NOTIFICATION-MIB
|
CISCO-SNMP- NOTIFICATION- CAPABILITY
|
Defines MIB objects that provide a mechanism to remotely configure the parameters used by an SNMP entity for the generation of notifications.
The SNMP-NOTIFICATION-MIB is described in RFC 3413.
|
SNMP-TARGET-MIB
|
CISCO-SNMP- TARGET- CAPABILITY
|
Contains a table for the Destination information and SNMP parameters in the management target message. There can be a many-to-many relationship in the MIB between these two types of information. There may be multiple transport endpoints associated with a particular set of SNMP parameters, or a particular transport endpoint may be associated with several sets of SNMP parameters.
The SNMP-TARGET-MIB is described in RFC 3413.
|
SNMP-USER-BASED- SM-MIB
|
CISCO-SNMP- USM-CAPABILITY
|
Provides management information definitions for the User-Based Security Model (USM) for SMNPv3. The SNMPv3 architecture introduces the User-based Security Model (USM) for message security.
The USM module decrypts incoming messages. The module then verifies authentication data and creates the PDUs. For outgoing messages, the USM module encrypts PDUs and generates authentication data. The module then passes the PDUs to the message processor, which then invokes the dispatcher.
The USM module's implementation of the SNMP-USER-BASED-SM-MIB enables the SNMP manager to issue commands to manage users and security keys. The MIB also enables the agent to ensure that a requesting user exists and has the proper authentication information. When authentication is done, the request is carried out by the agent.
The SNMP-USER-BASED-SM- MIB is described in RFC 3414.
Note User configuration is applicable only for SNMPv3; SNMPv1 and SNMPv2c use a community string match for user authentication.
|
SNMP-VIEW-BASED- ACM-MIB
|
CISCO-SNMP- VACM- CAPABILITY
|
Provides the View-Based Access Control Model (VACM) for SNMPv3. The SNMPv3 architecture introduces VACM for access control.
The SNMP-VIEW-BASED-ACM-MIB specifies objects that are needed to control access to all MIB data that is accessible through the SNMP agent. Upon initialization, the VACM module registers as the access control module with the agent infrastructure. The VACM module implements access control checks according to several parameters that are derived from the SNMP message.
The SNMP-VIEW-BASED-ACM-MIB is described in RFC 3415.
|
Other MIBs
|
CISCO-AAA-SERVER- EXT-MIB
|
CISCO-AAA- SERVER-EXT- CAPABILITY
|
This MIB is an extension to CISCO-AAA-SERVER-MIB. It enhances the casConfigTable of the CISCO-AAA-SERVER-MIB to include other types of server addresses. The CISCO-AAA-SERVER-EXT-MIB manages the following configuration functions:
• Generic configurations as applied on the authentication and accounting module.
• Configuration settings; that is, settings for all the AAA servers instrumented in one instance of this MIB.
• AAA server group configuration.
• Application-to-AAA function-to-server group mapping configuration.
|
CISCO-AAA-SERVER- MIB
|
CISCO-AAA- SERVER- CAPABILITY
|
Provides configuration and statistics reflecting the state of an AAA server operation within the device and AAA communications with external servers. The CISCO-AAA-SERVER-MIB provides the following information:
• A table for configuring AAA servers.
• Identities of external AAA servers.
• Distinct statistics for each AAA function.
• Status of servers providing AAA functions.
A server is defined as a logical entity that provides any of the AAA functions. The VFW application can use a Remote Access Dial-In User Service (RADIUS), Terminal Access Controller Access Control System Plus (TACACS+), or Lightweight Directory Access Protocol (v3) (LDAP) protocols for remote authentication and designation of access rights.
|
CISCO-FILTER-GROUP-MIB
|
N/A
|
Used for creating and configuring object groups that support packet filtering and access control on IP and other protocols.
This MIB is used in conjunction with CISCO-IP-PROTOCOL-FILTER-MIB.
|
CISCO-IF-EXTENSION-MIB
|
CISCO-IF- EXTENSION- CAPABILITY
|
Provides a table that returns ifName to ifIndex mapping as an easier method of assigning ifIndex to interfaces.
The CISCO-IF-EXTENSION-MIB is described in RFC 2863.
|
CISCO-IP-PROTOCOL- FILTER-MIB
|
CISCO-IP- PROTOCOL- FILTER- CAPABILITY
|
Manages information to support packet filtering on IP protocols (RFC 791).
The cippfIpProfileTable allows users to create, delete, and get information about filter profiles. Filter profiles are uniquely identified by the profile names. Filter profiles can be either simple or extended usage types. The usage type cannot be changed once it has been created. The cippfIfIpProfileTable applies the filtering profiles to device interfaces running IP. A filter profile can be applied to multiple interfaces.
The cippfIpFilterTable contains ordered lists of IP filters for all filtering profiles. Filters and profiles are related if they have the same filter profile name. Filters can be created only if their associated filter profiles already exist in the cippfIpProfileTable. Filters of the same profile name belong to a common profile.
The interface-based cippfIfIpProfileTable can be configured with information independent of the other tables. However, if the profile name in this table matches any profile name in the cippfIpProfileTable and the profile name of any filter entry in the cippfIpFilterTable, the profile is active and the filter entry is being applied to IP traffic passing through the attached device interfaces. Any change to the filters in the cippfIpFilterTable or the profile itself in the cippfIpProfileTable affects all the attached interfaces.
The IP protocol is described in RFC 791.
|
CISCO-L4L7RESOURCE-LIMIT-MIB
|
CISCO- L4L7MODULE- RESOURCE- LIMIT- CAPABILITY
|
Manages resource classes and configuring minimum/maximum limits to different resources. The resources referenced in this MIB are in addition to resource information available in other MIBs. This MIB is applicable to Layer 4 through Layer 7 modules that support managing resource limits using a centralized approach. A few of the resources configured include categories such as: TCP/IP connections, MAC addresses, syslog buffer, ACL memory, and NAT translations.
The value of entPhysicalIndex is always one.
|
CISCO-MODULE- VIRTUALIZATION-MIB
|
CISCO- MODULE- VIRTUALIZATION- CAPABILITY
|
Provides a way to create and manage virtual contexts. A virtual context is a logical partition of a physical device (the VFW application). A virtual context provides different types of services that can be managed independently. Each virtual context is an independent entity with its own configuration. A user-created context supports the majority of the options that you can configure in the Admin context (the default VFW application context). Each context can have a separate management IP address that allows the user to establish a remote connection to the VFW application using the Secure Shell (SSH) or Telnet protocols and send other requests (such as SNMP or FTP).
This MIB contains tables for creating or deleting virtual contexts and assigning interfaces and interface ranges to virtual contexts.
|
CISCO-PROCESS-MIB
|
CISCO-PROCESS- CAPABILITY
|
Displays memory and process CPU utilization on Cisco devices. This information should be used only as an estimate. The value of cpmCPUTotalPhysicalIndex always one.
The displayed system processes information is at the CPU system level (the total CPU usage) and is not on a per-context level.
|
CISCO-PRODUCTS-MIB
|
N/A
|
Contains the OIDs that can be reported in the sysObjectID object in SNMPv2-MIB. The sysObjectID OID value is listed below:
Product Name (PID) sysObjectID
ACE10-6500-K9 ciscoACE10K9 (ciscoProducts 730)
|
CISCO-SYSLOG-EXT-MIB
|
CISCO-SYSLOG- EXT-CAPABILITY
|
Configures and monitors system log (syslog) management parameters for the VFW application. Use this MIB to set up syslog servers and set logging severity levels.
Syslog is defined by RFC 3164.
|
CISCO-SYSLOG-MIB
|
CISCO-SYSLOG- CAPABILITY
|
Describes and stores the system messages (syslog messages) generated by the VFW application. The CISCO-SYSLOG-MIB provides access to the syslog messages through SNMP. The MIB also contains a history of syslog messages and objects to enable or disable the transmission of syslog notifications.
Note The MIB does not keep track of messages generated from debug commands entered through the command-line interface (CLI).
Syslog is defined by RFC 3164.
|
IF-MIB
|
CISCO-IF- CAPABILITY
|
Reports generic information on interfaces.
The IF-MIB is described in RFC 2863.
|
IP-MIB
|
CISCO-IP- CAPABILITY
|
Defines managed objects for managing implementations of the Internet Protocol (IP) and its associated Internet Control Message Protocol (ICMP), but excludes their management of IP routes.
The IP-MIB is described in RFC 4293.
|
SNMPv2-MIB
|
CISCO-SNMPv2- CAPABILITY
|
Provides the Management Information Base for SNMPv2. The management protocol, SNMPv2, provides for the exchange of messages that convey management information between the agents and the management stations.
The SNMPv2-MIB is described in RFC 3418.
|
TCP-MIB
|
CISCO-TCP-STD- CAPABILITY
|
Defines managed objects for managing the implementation of the Transmission Control Protocol (TCP).
The TCP MIB is described in RFC 4022.
|
UDP-MIB
|
CISCO-UDP-STD- CAPABILITY
|
Defines managed objects for managing implementation of the User Datagram Protocol (UDP).
The UDP MIB is described in RFC 4113.
|
Table 16 identifies the supported SNMP notifications (traps) for the VFW application.
Note
The clogOrigin ID and clogOriginIDType variable bindings are appended to each notification listed in Table 16 to identify from which chassis, slot, and context combination the event trap has originated.
Table 16 SNMP Trap Support
Notification Name
|
Location of the Notification
|
Description
|
authenticationFailure
|
SNMPv2-MIB
|
An SNMP request failed because the NMS did not authenticate with the correct community string.
|
clogMessageGenerated
|
CISCO-SYSLOG-MIB
|
The VFW application generated one or more syslog messages.
|
clmLicenseExpiryNotify
|
CISCO-LICENSE- MGR-MIB
|
The VFW application sends this notification when an installed feature license expires.
|
clmLicenseFileMissing Notify
|
CISCO-LICENSE- MGR-MIB
|
The VFW application sends this notification when the system detects that one or more installed license files are missing.
|
clmLicenseExpiryWarningNotify
|
CISCO-LICENSE- MGR-MIB
|
The VFW application sends this notification as a warning that an installed feature license is about to expire.
|
clmNoLicenseForFeature Notify
|
CISCO-LICENSE- MGR-MIB
|
The VFW application sends this notification when the system detects that there is no license installed for a specific feature.
|
cmVirtContextAdded, cmVirtContextRemoved
|
CISCO-MODULE- VIRTUALIZATION- MIB
|
The VFW application sends one of these notifications when you create or delete a virtual context.
|
coldStart
|
SNMPv2-MIB
|
The SNMP agent started after a cold restart (full power cycle) of the VFW application.
|
linkUp, linkDown
|
SNMPv2-MIB
|
An interface is up or down. An interface can be down, for example, if you specified the shut command followed by the no shut command, or the interface was removed from the switch configuration.
|
SNMP Limitations
For any SNMP MIB table that has more than one string index and if the length of these indices are greater than 48 characters, it may not show up in the MIB table when you perform an SNMP walk. This behavior occurs because, according to SNMP standards, SNMP requests, responses, or traps cannot have more than 128 subidentifiers.
The list of object names includes:
•
Context Name
•
HTTP Header Name
•
ACL Name
•
Class Map Name
•
Policy Map Name
•
Resource Class Name
How to Configure SNMP
This section describes the following tasks:
•
Configuring SNMP
•
Configuring SNMP Management Traffic Services
Configuring SNMP
The following task describes the steps required to configure SNMP on the VFW application.
Prerequisites
You must attach from the route processor to the VFW application before you can perform this task. See the "Attaching to the VFW Application" section.
SUMMARY STEPS
1.
changeto context-name
2.
configure
3.
snmp-server user user-name [user-group] auth {md5 | sha} password
4.
snmp-server community community-string group community-group
5.
snmp-server contact contact-name
6.
snmp-server location location
7.
snmp-server host host-address traps version {1 | 2c | 3} community-string udp-port port-number
8.
snmp-server enable traps [notification_type] [notification_option]
9.
snmp-server trap link ietf
10.
snmp-server engineid number
11.
exit
12.
copy running-config startup-config
DETAILED STEPS
| |
Command or Action
|
Purpose
|
Step 1
|
changeto context-name
Example:
firewall/Admin# changeto C1
firewall/C1#
|
Logs into the correct context. If you are operating in multiple contexts, observe the CLI prompt to verify that you are operating in the desired context.
Note The rest of the examples in this task use the Admin context. For details on creating contexts, see the "Configuring Virtualization on the Virtual Firewall" module.
|
Step 2
|
configure
Example:
firewall/Admin# configure
Enter configuration commands, one per line.
End with CNTL/Z.
firewall/Admin(config)#
|
Enters global configuration mode. You are now within configuration mode of the VFW application.
|
Step 3
|
snmp-server user user_name [group_name] auth
{md5 | sha} password
Example:
firewall/Admin(config)# snmp-server user joe
Network-Monitor auth sha abcd1234
firewall/Admin(config)# snmp-server user sam
Network-Monitor auth md5 abcdefgh
firewall/Admin(config)# snmp-server user Bill
Network-Monitor auth sha abcd1234 priv
abcdefgh
|
Configures one or more SNMP users from the VFW application CLI. You can use either md5 or sha authentication:
• md5—Specifies the HMAC Message Digest 5 (MD5) encryption algorithm for user authentication.
• sha—Specifies the HMAC Secure Hash Algorithm (SHA) encryption algorithm for user authentication.
Note Configuring SNMP users through the snmp-server user command is applicable only for SNMPv3.
|
Step 4
|
snmp-server community community_name group
group_name
Example:
firewall/Admin(config)# snmp-server community
SNMP_Community1 group Network-Monitor
|
Creates an SNMP community and identifies access privileges.
Note SNMP communities are applicable only for SNMPv1 and SNMPv2c.
|
Step 5
|
snmp-server contact contact_information
Example:
firewall/Admin(config)# snmp-server contact
User1
|
Specifies the contact name for the SNMP system. The contact_information argument is a text string with a maximum of 240 characters including spaces.
|
Step 6
|
snmp-server location location
Example:
firewall/Admin(config)# snmp-server location
Boxborough,MA
|
Specifies the SNMP system location.
|
Step 7
|
snmp-server host host_address traps version {1
| 2c | 3} community-string udp-port
port-number
Example:
firewall/Admin(config)# snmp-server host
192.168.1.1 traps version 2c SNMP_Community1
udp-port 500
|
Specifies which host is to receive SNMP notifications.
|
Step 8
|
snmp-server enable traps [notification_type]
[notification_option]
Example:
firewall/Admin(config)# snmp-server enable
traps
|
Configures the VFW application to send SNMP notifications. If not enabled, no notifications are defined or issued. If you use this command with no specified notification_type, the VFW application enables all notification types and traps. Possible values for notification_type are:
• snmp—Sends SNMP notifications. When you specify the snmp keyword, you can specify the notification_option value to be authentication, coldstart, linkdown, or linkup.
• syslog—Sends error message notifications (Cisco Syslog MIB). Specify the level of messages to be sent with the logging history level command.
Note To enable system messages to be sent as traps to the NMS, you can specify the logging history command. You must also enable syslog traps using the snmp-server enable traps command.
• virtual-context—Sends virtual context change notifications. This keyword appears only in the Admin context.
|
Step 9
|
snmp-server trap link ietf
Example:
firewall/Admin(config)# snmp-server trap link
ietf
|
(Optional) Configures the VFW application to send the linkUp and linkDown traps with the IETF standard IF-MIB (RFC 2863) variable bindings, consisting of ifIndex, ifAdminStatus, and ifOperStatus. By default, the VFW application sends the Cisco implementation of linkUp and linkDown traps to the NMS.
|
Step 10
|
snmp-server engineid number
Example:
firewall/Admin(config)# snmp-server engineid
88439573498573888843957349857388
|
(Optional) Configures an SNMP engine ID for an Admin or user context. The number argument is the SNMPv3 engine ID that you want to configure. Enter a number ranging from 10 to 64 hexadecimal digits.
|
Step 11
|
exit
Example:
firewall/Admin(config)# exit
firewall/Admin#
|
Exits global configuration mode.
|
Step 12
|
copy running-config startup-config
Example:
firewall/Admin# copy running-config
startup-config
|
(Optional) Saves your configuration changes to flash memory.
|
Configuring SNMP Management Traffic Services
You configure SNMP management traffic to and from the VFW application through the use of class maps, policy maps, and service policies. The following items summarize the role of each function in configuring remote network management access to the VFW application:
•
Class map—Provides the remote network traffic match criteria to permit SNMP management traffic based on:
–
SNMP management protocol
–
Client source IP address
•
Policy map—Enables remote network management access for a traffic classification that matches the criteria listed in the class map.
•
Service policy—Activates the policy map and attaches the traffic policy to a single interface or globally on all interfaces.
This task illustrates the steps required to configure SNMP management traffic services.
Prerequisites
You must attach from the route processor to the VFW application before you can perform this task. See the "Attaching to the VFW Application" section.
SUMMARY STEPS
1.
changeto context-name
2.
configure
3.
class-map type management [match-all | match-any] map_name
4.
[line_number] match protocol snmp {any | source-address ip_address mask}
5.
exit
6.
policy-map type management first-match map_name
7.
class map_name
8.
permit
9.
exit
10.
interface management interface_name
11.
ip address ip_address mask
12.
service-policy input policy_name
13.
exit
14.
copy running-config startup-config
DETAILED STEPS
| |
Command or Action
|
Purpose
|
Step 1
|
changeto context-name
Example:
firewall/Admin# changeto C1
firewall/C1#
|
Logs into the correct context. If you are operating in multiple contexts, observe the CLI prompt to verify that you are operating in the desired context.
Note The rest of the examples in this task use the Admin context. For details on creating contexts, see the "Configuring Virtualization on the Virtual Firewall" module.
|
Step 2
|
configure
Example:
firewall/Admin# configure
Enter configuration commands, one per line.
End with CNTL/Z.
firewall/Admin(config)#
|
Enters global configuration mode. You are now within configuration mode of the VFW application.
|
Step 3
|
class-map type management [match-all |
match-any] map_name
Example:
firewall/Admin (config)# class-map type
management match-all SNMP-ALLOW_CLASS
|
Creates a class map that permits network management traffic to be received by the VFW application based on SNMP management protocol and client source IP address.
|
Step 4
|
[line_number] match protocol {http | https}
{any | source-address ip_address mask}
Example:
firewall/Admin(config-cmap-mgmt)# match
protocol snmp source-address 172.16.10.0
255.255.255.254
|
Identifies SNMP as the network management protocol that is matched by the class map.
|
Step 5
|
exit
Example:
firewall/Admin(config-cmap-mgmt)# exit
firewall/Admin#
|
Exits class map configuration mode.
|
Step 6
|
policy-map type management first-match
map_name
Example:
firewall/Admin(config)# policy-map type
management first-match SNMP-ALLOW_POLICY
|
Configures a policy map that activates the SNMP management protocol classifications.
|
Step 7
|
class map_name
Example:
firewall/Admin(config-pmap-mgmt)# class
SNMP-ALLOW_CLASS
|
Associates a class map defined in Step 3 with the policy map, and enters policy map class configuration mode.
|
Step 8
|
permit
Example:
firewall/Admin(config-pmap-mgmt-c)# permit
|
Specifies to permit the traffic defined by the class.
|
Step 9
|
exit
Example:
firewall/Admin(config-if-mgmt)# exit
firewall/Admin#
|
Exits policy map class configuration mode.
|
Step 10
|
interface management interface_name
Example:
firewall/Admin(config)# interface management
m1
|
Enters interface configuration mode for a management interface.
|
Step 11
|
ip address ip_address mask
Example:
firewall/Admin(config-if-mgmt)# ip address
172.16.1.100 255.255.0.0
|
Specifies the IP address of the firewall interface.
|
Step 12
|
service-policy input policy_name
Example:
firewall/Admin(config-if-mgmt)# service-policy
input SNMP-ALLOW_POLICY
|
Attaches the traffic policy to the firewall interface.
|
Step 13
|
exit
Example:
firewall/Admin(config-if-mgmt)# exit
firewall/Admin#
|
Exits interface configuration mode.
|
Step 14
|
copy running-config startup-config
Example:
firewall/Admin# copy running-config
startup-config
|
(Optional) Saves your configuration changes to flash memory.
|
Troubleshooting Tips
Use the show snmp commands in EXEC mode to display SNMP statistics and configured SNMP information. By default, this command displays the VFW application contact, VFW application location, packet traffic information, community strings, and user information. You can instruct the VFW application to display specific SNMP information by including the appropriate keyword.
Additional References
The following sections provide references related to SNMP.
Related Documents
Related Topic
|
Document Title
|
Virtual firewall SNMP command syntax
|
SNMP Commands on the Virtual Firewall module in Cisco IOS XR Virtual Firewall Command Reference
|
Standards
Standards
|
Title
|
No new or modified standards are supported by this feature, and support for existing standards has not been modified by this feature.
|
—
|
MIBs
RFCs
RFCs
|
Title
|
No new or modified RFCs are supported by this feature, and support for existing RFCs has not been modified by this feature.
|
—
|
Technical Assistance
Description
|
Link
|
The Cisco Technical Support website contains thousands of pages of searchable technical content, including links to products, technologies, solutions, technical tips, and tools. Registered Cisco.com users can log in from this page to access even more content.
|
http://www.cisco.com/techsupport
|