Cisco IOS XR Virtual Firewall Configuration Guide, Release 3.8
Configuring SNMP on the Virtual Firewall

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

MIBs
MIBs Link

Table 15 identifies the supported MIBs for the VFW application.

To locate and download MIBs using Cisco IOS XR software, use the Cisco MIB Locator found at the following URL and choose a platform under the Cisco Access Products menu: http://cisco.com/public/sw-center/netmgmt/cmtk/mibs.shtml


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