Cisco IOS Software Releases 12.3 T

Table Of Contents

SNMP Support over VPNs—Context-Based Access Control

Contents

Restrictions for SNMP Support over VPNs—Context-Based Access Control

Information About SNMP Support over VPNs—Context-Based Access Control

Understanding SNMP

SNMP Notifications

SNMP Notification Support Over VPNs

VPN Aware SNMP

SNMP Contexts

How to Configure SNMP Support over VPNs—Context-Based Access Control

Configuring SNMP Support for a VPN

What to Do Next

Configuring an SNMP Context

Restrictions

SNMP Context

VPN Route Distinguishers

What to Do Next

Associating an SNMP Context for SNMPv3

SNMPv3 Security

What to Do Next

Associating an SNMP Context for SNMPv1 or SNMPv2

SNMPv1 or SNMPv2 Security

Configuration Examples for SNMP Support over VPNs—Context-Based Access Control

Configuring Context-Based Access Control for SNMPv3: Example

Configuring Context-Based Access Control for SNMPv1 or SNMP v2: Example

Configuring V2C Community ABC for VRF V3red: Example

Where to Go Next

Additional References

Related Documents

Standards

MIBs

RFCs

Technical Assistance

Command Reference

context

snmp mib community-map

snmp mib target list

snmp-server context

snmp-server enable traps snmp

snmp-server group

Glossary

SNMP Support over VPNs—Context-Based Access Control

---

First Published: October 28, 2002

Last Updated: June 29, 2007

The Simple Network Management Protocol (SNMP) Support over VPNs—Context-Based Access Control feature provides the infrastructure for multiple SNMP context support in Cisco IOS software and VPN-aware MIB infrastructure using the multiple SNMP context support infrastructure.

History for the SNMP Support over VPNs—Context-Based Access Control Feature

Release	Modification
12.0(23)S	This feature was introduced.
12.3(2)T	This feature was integrated into Cisco IOS Release 12.3(2)T.
12.2(25)S	This feature was integrated into Cisco IOS Release 12.2(25)S.
12.2(33)SRA	This feature was integrated into Cisco IOS Release 12.2(33)SRA.
12.2(31)SB2	This feature was integrated into Cisco IOS Release 12.2(31)SB2.
12.2(33)SXH	This feature was integrated into Cisco IOS Release 12.2(33)SXH.

Finding Support Information for Platforms and Cisco IOS and Catalyst OS Software Images

Use Cisco Feature Navigator to find information about platform support and Cisco IOS and Catalyst OS software image support. To access Cisco Feature Navigator, go to http://www.cisco.com/go/cfn. An account on Cisco.com is not required.

Contents

•Restrictions for SNMP Support over VPNs—Context-Based Access Control

•Information About SNMP Support over VPNs—Context-Based Access Control

•How to Configure SNMP Support over VPNs—Context-Based Access Control

•Configuration Examples for SNMP Support over VPNs—Context-Based Access Control

•Where to Go Next

•Additional References

•Command Reference

•Glossary

Restrictions for SNMP Support over VPNs—Context-Based Access Control

•If you delete an SNMP context using the no snmp-server context command, all SNMP instances in that context are deleted.

•Not all MIBs are VPN-aware.

Information About SNMP Support over VPNs—Context-Based Access Control

To configure SNMP Support over VPNs—Context-Based Access Control you must understand the following concepts:

•Understanding SNMP

•SNMP Notifications

•SNMP Notification Support Over VPNs

•VPN Aware SNMP

•SNMP Contexts

Understanding SNMP

SNMP is an application-layer protocol that provides a message format for communication between SNMP managers and agents. SNMP provides a standardized framework and a common language used for the monitoring and management of devices in a network.

The SNMP framework has three parts:

•An SNMP manager

•An SNMP agent

•A MIB

The SNMP manager is the system used to control and monitor the activities of network hosts using SNMP. The most common managing system is called a Network Management System (NMS). The term NMS can be applied to either a dedicated device used for network management or the applications used on such a device. A variety of network management applications are available for use with SNMP. These features range from simple command-line applications to feature-rich graphical user interfaces (such as the CiscoWorks2000 line of products).

The SNMP agent is the software component within the managed device that maintains the data for the device and reports these data, as needed, to managing systems. The agent and MIB reside on the routing device (router, access server, or switch). To enable the SNMP agent on a Cisco routing device, you must define the relationship between the manager and the agent.

The MIB is a virtual information storage area for network management information, which consists of collections of managed objects. Within the MIB there are collections of related objects, defined in MIB modules. MIB modules are written in the SNMP MIB module language, as defined in STD 58, RFC 2578, RFC 2579, and RFC 2580. Note that individual MIB modules are also referred to as MIBs; for example, the Interfaces Group MIB (IF-MIB) is a MIB module within the MIB on your system.

The SNMP agent contains MIB variables whose values the SNMP manager can request or change through Get or Set operations. A manager can get a value from an agent or store a value into that agent. The agent gathers data from the MIB, which is the repository for information about device parameters and network data. The agent can also respond to manager requests to Get or Set data.

Figure 1 illustrates the communications relationship between the SNMP manager and agent. A manager can send the agent requests to get and set MIB values. The agent can respond to these requests. Independent of this interaction, the agent can send unsolicited notifications (traps or informs) to the manager to notify the manager of network conditions.

Figure 1 Communication Between an SNMP Agent and Manager

SNMP Notifications

A key feature of SNMP is the ability to generate notifications from an SNMP agent. These notifications do not require that requests be sent from the SNMP manager. Unsolicited (asynchronous) notifications can be generated as traps or inform requests. Traps are messages alerting the SNMP manager to a condition on the network. Inform requests (informs) are traps that include a request for confirmation of receipt from the SNMP manager. Notifications can indicate improper user authentication, restarts, the closing of a connection, loss of connection to a neighbor router, or other significant events.

Traps are less reliable than informs because the receiver does not send any acknowledgment when it receives a trap. The sender cannot determine if the trap was received. An SNMP manager that receives an inform request acknowledges the message with an SNMP response protocol data unit (PDU). If the manager does not receive an inform request, it does not send a response. If the sender never receives a response, the inform request can be sent again. Thus, informs are more likely to reach their intended destination.

However, traps are often preferred because informs consume more resources in the router and in the network. Unlike a trap, which is discarded as soon as it is sent, an inform request must be held in memory until a response is received or the request times out. Also, traps are sent only once, while an inform may be retried several times. The retries increase traffic and contribute to a higher overhead on the network. Thus, traps and inform requests provide a trade-off between reliability and resources. If it is important that the SNMP manager receives every notification, use inform requests. However, if you are concerned about traffic on your network or memory in the router and you need not receive every notification, use traps.

SNMP Notification Support Over VPNs

The SNMP Notification Support Over VPNs feature allows the sending and receiving of SNMP notifications (traps and informs) using VPN routing/forwarding instance (VRF) tables. In particular, this feature adds support to Cisco IOS software for the sending and receiving of SNMP notifications (traps and informs) specific to individual Virtual Private Networks (VPNs).

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

A VPN is a network that provides high-connectivity transfers on a shared system with the same usage guidelines as a private network. A VPN can be built on the Internet over IP, Frame Relay, or ATM networks.

A VRF stores per-VPN routing data. It defines the VPN membership of a customer site attached to the network access server (NAS). A VRF consists of an IP routing table, a derived Cisco Express Forwarding (CEF) table, and guidelines and routing protocol parameters that control the information that is included in the routing table.

The SNMP Support for VPNs—Context-Based Access Control feature provides configuration commands that allow users to associate SNMP agents and managers with specific VRFs. The specified VRF is used for the sending of SNMP notifications (traps and informs) and responses between agents and managers. If a VRF is not specified, the default routing table for the VPN is used.

VPN Aware SNMP

The SNMP Support for VPNs—Context-Based Access Control feature extends the capabilities of the SNMP Notification Support for VPNs feature and enables SNMP to differentiate between incoming packets from different VPNs.

When the SNMP Support for VPNs—Context-Based Access Control feature is configured, SNMP accepts requests on any configured VRF and returns responses to the same VRF. A trap host can also be associated with a specific VRF. The configured VRF is then used for sending out traps; otherwise, the default routing table is used. You can also associate a remote user with a specific VRF. You can also configure the VRFs from which SNMP should accept requests. Any requests coming from VRFs that are not specified are dropped.

IP access lists can be configured and associated with SNMP community strings. This feature enables you to configure an association between VRF instances with SNMP community strings. When a VRF instance is associated with an SNMP community string, SNMP processes requests coming in for a particular community string are processed only if it they are received from the configured VRF. If the community string contained in the incoming packet does not have a VRF associated with it, the community string will be processed only if it came in through a non-VRF interface.

You can also enable or disable authentication traps for SNMP packets dropped due to VRF mismatches. By default if SNMP authentication traps are enabled, VRF authentication traps will also be enabled by default.

SNMP Contexts

SNMP contexts provide VPN users with a secure way of accessing MIB data. When a VPN is associated with a context, that VPN's specific MIB data exists in that context. Associating a VPN with a context enables service providers to manage networks with multiple VPNs. Creating and associating a context with a VPN enables a provider to prevent the users of one VPN from accessing information about users of other VPNs on the same networking device.

VPN-aware SNMP requires an agreement between SNMP manager and agent entities operating in a VPN environment on a mapping between the SNMP security name and the VPN ID. This mapping is created by using multiple contexts for the SNMP data of different VPNs through the configuration of the SNMP-VACM-MIB. The SNMP-VACM-MIB is configured with views so that a user on a VPN with a security name is allowed access to the restricted object space associated with a user's access type in the context associated with the user of that VPN.

SNMP request messages undergo three phases of security and access control before a response message is sent back with the object values in the context of a VPN. The first security phase is authentication of the username. This phase ensures that the user is authenticated and authorized for SNMP access. The second phase is the access control phase, where the user is authorized for the SNMP access requested to the group objects under consideration of the configured SNMP context. In the third phase, access is made to a particular instance of a table entry. With this third phase, complete retrieval can be based on the SNMP context name.

How to Configure SNMP Support over VPNs—Context-Based Access Control

To configure the SNMP Support over VPNs—Context-Based Access Control feature, perform the following tasks:

•Configuring SNMP Support for a VPN (required)

•Configuring an SNMP Context (required)

•Associating an SNMP Context for SNMPv3 (required)

•Associating an SNMP Context for SNMPv1 or SNMPv2 (required)

Configuring SNMP Support for a VPN

Perform this task to configure SNMP support for a VPN or a remote VPN:

SUMMARY STEPS

1. enable

2. configure terminal

3. snmp-server host host-address [traps | informs] [version {1 | 2c | 3 [auth | noauth | priv]}] community-string [udp-port port] [notification-type] [vrf vrf-name]

4. snmp-server engineID remote ip-address [udp-port udp-port-number] [vrf vrf-name] engineid-string]

DETAILED STEPS

	Command or Action	Purpose
Step 1	enable Example: Router> enable	Enables privileged EXEC mode. •Enter your password if prompted.
Step 2	configure terminal Example: Router# configure terminal	Enters global configuration mode.
Step 3	snmp-server host host-address [traps | informs] [version {1 | 2c | 3 [auth | noauth | priv]}] community-string [udp-port port] [notification-type] [vrf vrf-name] Example: Router(config)# snmp-server host xyz.com vrf trap-vrf	(Optional) Specifies the recipient of an SNMP notification operation and specifies the VRF table to be used for the sending of SNMP notifications.
Step 4	snmp-server engineID remote ip-address [udp-port udp-port-number] [vrf vrf-name] engineid-string] Example: Router(config)# snmp-server engineID remote 172.16.20.3 vrf traps-vrf 80000009030000B064EFE100	(Optional) Configures a name for the remote SNMP engine on a router.

What to Do Next

Proceed to the "Configuring an SNMP Context" section.

Configuring an SNMP Context

Restrictions

•Only the following MIBs are context aware and all the tables in these MIBs can be polled:

–CISCO-IPSEC-FLOW-MONITOR-MIB (Cisco IOS Release 12.4T and later)

–CISCO-IPSEC-MIB (Cisco IOS Release 12.4T and later)

–CISCO-PING-MIB

–IP-FORWARD-MIB

–MPLS-LDP-MIB

•Currently, two SNMP variables in the IP-FORWARD-MIB can be polled: 1.3.6.1.2.1.4.24.3 (ipCidrRouteNumber - Scalar) and 1.3.6.1.2.1.4.24.4.1 (ipCidrRouteEntry - Table).

Perform this task to configure an SNMP context and to associate the SNMP context with a VPN.

SNMP Context

SNMP contexts provide VPN users with a secure way of accessing MIB data. When a VPN is associated with a context, that VPN's specific MIB data exists in that context. Associating a VPN with a context enables service providers to manage networks with multiple VPNs. Creating and associating a context with a VPN enables a provider to prevent the users of one VPN from accessing information about users of other VPNs on the same networking device.

VPN Route Distinguishers

A route distinguisher (RD) creates routing and forwarding tables and specifies the default route distinguisher for a VPN. The RD is added to the beginning of the customer's IPv4 prefixes to change them into globally unique VPN-IPv4 prefixes.

The RD is either an autonomous system number (ASN)-relative RD, in which case it is composed of an autonomous system number and an arbitrary number, or it is an IP-address-relative RD, in which case it is composed of an IP address and an arbitrary number.

You can enter an RD in either of these formats:

16-bit AS number: your 16-bit number: For example, 101:3.

32-bit IP address: your 32-bit number: For example, 192.168.122.15:1.

SUMMARY STEPS

1. enable

2. configure terminal

3. snmp-server context context-name

4. ip vrf vrf-name

5. rd route-distinguisher

6. context context-name

7. route-target {import | export | both} route-target-ext-community

DETAILED STEPS

	Command or Action	Purpose
Step 1	enable Example: Router> enable	Enables privileged EXEC mode. •Enter your password if prompted.
Step 2	configure terminal Example: Router# configure terminal	Enters global configuration mode.
Step 3	snmp-server context context-name Example: Router(config)# snmp-server context context1	Creates and names an SNMP context.
Step 4	ip vrf vrf-name Example: Router(config)# ip vrf vrf1	Configures a VRF routing table and enters VRF configuration mode.
Step 5	rd route-distinguisher Example: Router(config-vrf)# rd 100:120	Creates a VPN route distinguisher.
Step 6	context context-name Example: Router(config-vrf)# context context1	Associates an SNMP context with a particular VRF.
Step 7	route-target {import | export | both} route-target-ext-community Example: Router(config-vrf)# route-target export 100:1000	(Optional) Creates a route-target extended community for a VRF.

What to Do Next

Proceed to the "Associating an SNMP Context for SNMPv3" section or the "Associating an SNMP Context for SNMPv1 or SNMPv2" section.

Associating an SNMP Context for SNMPv3

Perform this task to associate an SNMP context with a VPN using SNMPv3.

SNMPv3 Security

Using SNMPv3 with the SNMP Support over VPNs—Context-Based Access Control feature provides secure MIB access in a VPN environment. Every VPN is given one or more users that belong to a group.

When using SNMPv3, the security name should always be associated with authentication or privileged passwords. Source address validation is not performed on SNMPv3 users. To ensure that a VPN's user has access only to context associated to the VPN and not to see the MIB data of other VPNs, you must configure a minimum security level of AuthNoPriv.

On a PE, a community can be associated with a VRF to provide source address validation. However, on a CE, if source address validation is to be provided, you must configure an association between a source address and the community list by using an access control list.

When using SNMPv3, the security name or security password of the users of a VPN should be unknown to users of other VPNs. It is recommended not to use SNMPv3 non-authorized users if you need security of management information.

SUMMARY STEPS

1. enable

2. configure terminal

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

4. snmp-server group group-name {v1 | v2c | v3 {auth | noauth | priv}} [context context-name] [read read-view] [write write-view] [notify notify-view] [access access-list]

5. snmp-server view view-name oid-tree {included | excluded}

6. snmp-server community string [view view-name] [ro | rw] [number]

7. snmp-server enable traps [notification-type]

8. snmp-server host host-address [traps | informs] [version {1 | 2c | 3 [auth | noauth | priv]}] community-string [udp-port port] [notification-type] [vrf vrf-name]

9. snmp-server trap authentication vrf

DETAILED STEPS

	Command or Action	Purpose
Step 1	enable Example: Router> enable	Enables privileged EXEC mode. •Enter your password if prompted.
Step 2	configure terminal Example: Router# configure terminal	Enters global configuration mode.
Step 3	snmp-server user username group-name [remote host [udp-port port]] {v1 | v2c | v3 [encrypted] [auth {md5 | sha} auth-password]} [access access-list] Example: Router(config)# snmp-server user customer1 group1 v3 auth md5 password1	Configures a new user to an SNMP group.
Step 4	snmp-server group group-name {v1 | v2c | v3 {auth | noauth | priv}} [context context-name] [read read-view] [write write-view] [notify notify-view] [access access-list] Example: Router(config)# snmp-server group customer1 v3 auth context context1 read customer1 write customer2 notify customer3	Configures a new SNMP group or a table that maps SNMP users to SNMP views. •Use the context context-name keyword/argument pair to associate the specified SNMP group with a configured SNMP context.
Step 5	snmp-server view view-name oid-tree {included | excluded} Example: Router(config)# snmp-server view view1 internet included	Creates or updates a view entry.
Step 6	snmp-server community string [view view-name] [ro | rw] [number] Example: Router(config)# snmp-server community public view view1 rw	Sets up the community access string to permit access to the SNMP.
Step 7	snmp-server enable traps [notification-type] Example: Router(config)# snmp-server enable traps	Enables all SNMP notifications (traps or informs) available on your system.
Step 8	snmp-server host host-address [traps | informs] [version {1 | 2c | 3 [auth | noauth | priv]}] community-string [udp-port port] [notification-type] [vrf vrf-name] Example: Router(config)# snmp-server host 10.0.0.0 traps version 3 auth customer1 udp-port 7002	Specifies the recipient of an SNMP notification operation.
Step 9	snmp-server trap authentication vrf Example: Router(config)# snmp-server trap authentication vrf	(Optional) Disables all authentication traps generated for packets received on VRF interfaces. •Use this command to disable authentication traps only for those packets on VRF interfaces with incorrect community associations.

What to Do Next

Proceed to the "Associating an SNMP Context for SNMPv1 or SNMPv2" section.

Associating an SNMP Context for SNMPv1 or SNMPv2

Perform this task to associate an SNMP Context with a VPN using SNMPv1 or SNMPv2.

SNMPv1 or SNMPv2 Security

The SNMP Support over VPNs—Context-Based Access Control feature supports SNMPv1 and SNMPv2. SNMPv1 and SNMPv2 are not as secure as SNMPv3. SNMP version 1 and 2 use plain text communities and do not perform the authentication or security checks that SNMP version 3 performs. To configure the SNMP Support over VPNs—Context-Based Access Control feature when using SNMP version 1 or SNMP version 2, you need to associate a community name with a VPN. This association causes SNMP to process requests coming in for a particular community string only if it comes in from the configured VRF. If the community string contained in the incoming packet does not have an associated VRF, it is processed only if it came in through a non-VRF interface. This process prevents users outside the VPN from snooping a clear text community string to query the VPN's data. These methods of source address validation are not as secure as using SNMPv3.

SUMMARY STEPS

1. enable

2. configure terminal

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

4. snmp-server group group-name {v1 | v2c | v3 {auth | noauth | priv}} [context context-name] [read read-view] [write write-view] [notify notify-view] [access acl-number | acl-name]

5. snmp-server view view-name oid-tree {included | excluded}

6. snmp-server enable traps [notification-type]

7. snmp-server host host-address [traps | informs] [version {1 | 2c | 3 [auth | noauth | priv]}] community-string [udp-port port] [notification-type] [vrf vrf-name]

8. snmp mib community-map community-name [context context-name] [engineid engine-id] [security-name security-name] [target-list upn-list-name]

9. snmp mib target list vpn-list-name {vrf vrf-name | host ip-address}

10. snmp-server trap authentication vrf

DETAILED STEPS

	Command or Action	Purpose
Step 1	enable Example: Router> enable	Enables privileged EXEC mode. •Enter your password if prompted.
Step 2	configure terminal Example: Router# configure terminal	Enters global configuration mode.
Step 3	snmp-server user username group-name [remote host [udp-port port]] {v1 | v2c | v3 [encrypted] [auth {md5 | sha} auth-password]} [access access-list] Example: Router(config)# snmp-server user customer1 group1 v1	Configures a new user to an SNMP group.
Step 4	snmp-server group group-name {v1 | v2c | v3 {auth | noauth | priv}} [context context-name] [read read-view] [write write-view] [notify notify-view] [access acl-number | acl-name] Example: Router(config)# snmp-server group group1 v1 context context1 read view1 write view1 notify view1	Configures a new SNMP group or a table that maps SNMP users to SNMP views.
Step 5	snmp-server view view-name oid-tree {included | excluded} Example: Router(config)# snmp-server view view1 ipForward included	Creates or updates a view entry.
Step 6	snmp-server enable traps [notification-type] Example: Router(config)# snmp-server enable traps	Enables all SNMP notifications (traps or informs) available on your system.
Step 7	snmp-server host host-address [traps | informs] [version {1 | 2c | 3 [auth | noauth | priv]}] community-string [udp-port port] [notification-type] [vrf vrf-name] Example: Router(config)# snmp-server host 10.0.0.1 vrf customer1 udp-port 7002	Specifies the recipient of an SNMP notification operation.
Step 8	snmp mib community-map community-name [context context-name] [engineid engine-id] [security-name security-name] [target-list vpn-list-name] Example: Router(config)# snmp mib community-maps community1 context context1 target-list commAVpn	Associates an SNMP community with an SNMP context, Engine ID, or security name.
Step 9	snmp mib target list vpn-list-name {vrf vrf-name | host ip-address} Example: Router(config)# snmp mib target list commAVpn vrf vrf1	Creates a list of target VRFs and hosts to associate with an SNMP community.
Step 10	no snmp-server trap authentication vrf Example: Router(config)# no snmp-server trap authentication vrf	(Optional) Disables all SNMP authentication notifications (traps and informs) generated for packets received on VRF interfaces. •Use this command to disable authentication traps only for those packets on VRF interfaces with incorrect community associations.

Configuration Examples for SNMP Support over VPNs—Context-Based Access Control

This section provides the following configuration examples:

•Configuring Context-Based Access Control for SNMPv3: Example

•Configuring Context-Based Access Control for SNMPv1 or SNMP v2: Example

•Configuring V2C Community ABC for VRF V3red: Example

Configuring Context-Based Access Control for SNMPv3: Example

The following configuration example shows how to configure the SNMP Support over VPNs—Context-Based Access Control feature with SNMPv1 or SNMPv2:

snmp-server context A

snmp-server context B

ip vrf Customer_A

 rd 100:110

 context A

 route-target export 100:1000

 route-target import 100:1000

!

ip vrf Customer_B

 rd 100:120

 context B

 route-target export 100:2000

 route-target import 100:2000

!

interface Ethernet3/1

 description Belongs to VPN A

 ip vrf forwarding Customer_A

 ip address 10.0.0.0 255.255.0.0

interface Ethernet3/2

 description Belongs to VPN B

 ip vrf forwarding Customer_B

 ip address 10.0.0.1 255.255.0.0

snmp-server user Customer_A_v3_authusr Customer_A_v3_grp_auth v3 auth md5 passwdA

snmp-server user Customer_B_v3_authusr Customer_B_v3_grp_auth v3 auth md5 passwdB

snmp-server group Customer_A_v3_grp_auth v3 auth context A read Customer_A_v3_view write 
Customer_A_v3_view notify Customer_A_v3_view

snmp-server group Customer_B_v3_grp_auth v3 auth context B read Customer_B_v3_view write 
Customer_B_v3_view notify Customer_B_v3_view

snmp-server view view1 internet included

snmp-server view view1 internet.6.3.16 included

snmp-server view view1 internet.6.3.17 included

snmp-server view view1 internet.6.3.18 included

snmp-server view Customer_A_v3_view ipForward included

snmp-server view Customer_A_v3_view ciscoPingMIB included

snmp-server view Customer_B_v3_view ipForward included

snmp-server view Customer_B_v3_view ciscoPingMIB included

snmp-server community public view view1 RW

snmp-server enable traps 

snmp-server host 10.0.0.3 vrf Customer_A version 3 auth Customer_A_v3_authusr udp-port 
7002 

snmp-server host 10.0.0.4 vrf Customer_B version 3 auth Customer_B_v3_authusr udp-port 
7002 

Configuring Context-Based Access Control for SNMPv1 or SNMP v2: Example

The following configuration example shows how to configure the SNMP Support over VPNs—Context-Based Access Control feature with SNMPv1 or SNMPv2:

snmp-server context A

snmp-server context B

ip vrf Customer_A

 rd 100:110

 context A

 route-target export 100:1000

 route-target import 100:1000

!

ip vrf Customer_B

 rd 100:120

 context B

 route-target export 100:2000

 route-target import 100:2000

!

interface Ethernet3/1

 description Belongs to VPN A

 ip vrf forwarding Customer_A

 ip address 10.0.0.0 255.255.0.0

interface Ethernet3/2

 description Belongs to VPN B

 ip vrf forwarding Customer_B

 ip address 10.0.0.1 255.255.0.0

snmp-server user commA grp1A v1 

snmp-server user commA grp2A v2c 

snmp-server user commB grp1B v1 

snmp-server user commB grp2B v2c 

snmp-server group grp1A v1 context A read viewA write viewA notify viewA

snmp-server group grp1B v1 context B read viewB write viewB notify viewB 

snmp-server view viewA ipForward included

snmp-server view viewA ciscoPingMIB included

snmp-server view viewB ipForward included

snmp-server view viewB ciscoPingMIB included

snmp-server enable traps

snmp-server host 10.0.0.3 vrf Customer_A commA udp-port 7002

snmp-server host 10.0.0.4 vrf Customer_B commB udp-port 7002

snmp mib community-map commA context A target-list commAvpn

! Configures source address validation

snmp mib community-map commB context B target-list commBvpn

! Configures source address validation

snmp mib target list commAvpn vrf Customer_A 

! Configures a list of VRFs or from which community commA is valid

snmp mib target list commBvpn vrf Customer_B

! Configures a list of VRFs or from which community commB is valid

Configuring V2C Community ABC for VRF V3red: Example

snmp-server group abc v2c context V3red_context read view_V3 

snmp-server view view_V3 iso included 

snmp-server community abc RO 

snmp-server community public RO 

snmp-server context V3red_context 

!

!

snmp mib community-map  abc context V3red_context 

ip vrf V3red

 rd 198102

 context V3red_context  <-----

Where to Go Next

To configure other VPN features using the VPN Device Manager, refer to the following URL for more information:

http://www.cisco.com//univercd/cc/td/doc/product/rtrmgmt/vdm/

Additional References

The following sections provide references related to the SNMP Support over VPNs—Context-Based Access Control feature.

Related Documents

Related Topic	Document Title
SNMP commands	•Cisco IOS Network Management Command Reference, Release 12.4T •Cisco IOS Network Management Command Reference, Release 12.2SB •Cisco IOS Network Management Command Reference, Release 12.2SR
SNMP configuration	"Configuring SNMP Support" chapter in the Cisco IOS Network Management Configuration Guide, Release 12.4
SNMP Support for VPNs	SNMP Notification Support for VPNs

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
•SNMP-VACM-MIB, The View-based Access Control Model (ACM) MIB for SNMP •CISCO-PING-MIB •IP-FORWARD-MIB	To locate and download MIBs for selected platforms, Cisco IOS releases, and feature sets, use Cisco MIB Locator found at the following URL: http://www.cisco.com/go/mibs

RFCs

RFCs	Title
RFC 1441	Introduction to version 2 of the Internet-standard Network Management Framework
RFC 1442	Structure of Management Information for version 2 of the Simple Network Management Protocol (SNMPv2)
RFC 1443	Textual Conventions for version 2 of the Simple Network Management Protocol (SNMPv2)
RFC 1444	Conformance Statements for version 2 of the Simple Network Management Protocol (SNMPv2)
RFC 1445	Administrative Model for version 2 of the Simple Network Management Protocol (SNMPv2)
RFC 1446	Security Protocols for version 2 of the Simple Network Management Protocol (SNMPv2)
RFC 1447	Party MIB for version 2 of the Simple Network Management Protocol (SNMPv2)
RFC 1448	Protocol Operations for version 2 of the Simple Network Management Protocol (SNMPv2)
RFC 1449	Transport Mappings for version 2 of the Simple Network Management Protocol (SNMPv2)
RFC 1450	Management Information Base for version 2 of the Simple Network Management Protocol (SNMPv2)
RFC 2571	An Architecture for Describing SNMP Management Frameworks
RFC 2576	Coexistence between Version 1, Version 2, and Version 3 of the Internet-standard Network Management Framework

Technical Assistance

Description

Link

The Cisco Support website provides extensive online resources, including documentation and tools for troubleshooting and resolving technical issues with Cisco products and technologies. To receive security and technical information about your products, you can subscribe to various services, such as the Product Alert Tool (accessed from Field Notices), the Cisco Technical Services Newsletter, and Really Simple Syndication (RSS) Feeds. Access to most tools on the Cisco Support website requires a Cisco.com user ID and password.

http://www.cisco.com/techsupport

Command Reference

This section documents only commands that are new or modified.

•context

•snmp mib community-map

•snmp mib target list

•snmp-server context

•snmp-server enable traps snmp

•snmp-server group

context

To associate a Simple Network Management Protocol (SNMP) context with a particular virtual private network (VPN) routing/forwarding instance (VRF), use the context command in VRF configuration mode. To disassociate an SNMP context from a VPN, use the no form of this command.

context context-name

no context context-name

Syntax Description

context-name

Name of the SNMP VPN context, up to 32 characters.

Command Default

No SNMP contexts are associated with VPNs.

Command Modes

VRF configuration (config-vrf)

Command History

Release	Modification
12.0(23)S	This command was introduced.
12.3(2)T	This command was integrated into Cisco IOS Release 12.3(2)T.
12.2(25)S	This command was integrated into Cisco IOS Release 12.2(25)S.
12.2(33)SRA	This command was integrated into Cisco IOS Release 12.2(33)SRA.
12.2(31)SB2	This command was integrated into Cisco IOS Release 12.2(31)SB2.
12.2(33)SRB	Support for IPv6 was added.
12.2(33)SXH	This command was integrated into Cisco IOS Release 12.2(33)SXH.

Usage Guidelines

Before you use this command to associate an SNMP context with a VPN, you must do the following:

•Issue the snmp-server context command to create an SNMP context

•Associate a VPN with a context so that the specific MIB data for that VPN exists in that context.

•Associate a VPN group with the context of the VPN using the snmp-server group command with the context context-name keyword and argument.

SNMP contexts provide VPN users with a secure way of accessing MIB data. When a VPN is associated with a context, MIB data for that VPN exists in that context. Associating a VPN with a context helps enable service providers to manage networks with multiple VPNs. Creating and associating a context with a VPN enables a provider to prevent the users of one VPN from accessing information about users of other VPNs on the same networking device.

A route distinguisher (RD) is required when you configure an SNMP context. An RD creates routing and forwarding tables and specifies the default route distinguisher for a VPN. The RD is added to the beginning of a IPv4 prefix to make it globally unique. An RD is either ASN relative, which means it is composed of an autonomous system number and an arbitrary number, or it is IP address relative and composed of an IP address and an arbitrary number.

Examples

The following example shows how to create an SNMP context named context1 and associate the context with the VRF named vrf1:

Router(config)# snmp-server context1

Router(config)# ip vrf vrf1

Router(config-vrf)# rd 100:120

Router(config-vrf)# context context1

Related Commands

Command	Description
ip vrf	Enters VRF configuration mode for the configuration of a VRF.
snmp mib community-map	Associates an SNMP community with an SNMP context, engine ID, or security name.
snmp mib target list	Creates a list of target VRFs and hosts to associate with an SNMP v1 or v2c community.
snmp-server context	Creates an SNMP context.
snmp-server group	Configures a new SNMP group, or a table that maps SNMP users to SNMP views.
snmp-server trap authentication vrf	Controls VRF-specific SNMP authentication failure notifications.
snmp-server user	Configures a new user to an SNMP group.

snmp mib community-map

To associate a Simple Network Management Protocol (SNMP) community with an SNMP context, engine ID, or security name, use the snmp mib community-map command in global configuration mode. To change an SNMP community mapping to its default mapping, use the no form of this command.

snmp mib community-map community-name [context context-name] [engineid engine-id] [security-name security-name] [target-list vpn-list-name]

no snmp mib community-map community-name [context context-name] [engineid engine-id] [security-name security-name] [target-list vpn-list-name]

Syntax Description

community-name	String that identifies the SNMP community.
context	(Optional) Specifies that an SNMP context name is mapped to the SNMP community.
context-name	(Optional) String that identifies the name of the SNMP context.
engineid	(Optional) Specifies that an SNMP engine ID is mapped to the SNMP community.
engine-id	(Optional) String that identifies the SNMP engine ID. Default is the local engine ID
security-name	(Optional) Specifies that a security name is mapped to the SNMP community.
security-name	(Optional) String that identifies the SNMP security name. Default is the community name
target-list	(Optional) Specifies that a VPN routing and forwarding (VRF) list is mapped to the SNMP community.
vpn-list-name	(Optional) String value that should correspond to the list name used in the snmp mib target list command.

Command Default

No SNMP communities and contexts are associated.

Command Modes

Global configuration (config)

Command History

Release	Modification
12.0(23)S	This command was introduced.
12.3(2)T	This command was integrated into Cisco IOS Release 12.3(2)T.
12.2(25)S	This command was integrated into Cisco IOS Release 12.2(25)S.
12.2(33)SRA	This command was integrated into Cisco IOS Release 12.2(33)SRA.
12.2(31)SB2	This command was integrated into Cisco IOS Release 12.2(31)SB2.
12.2(33)SXH	This command was integrated into Cisco IOS Release 12.2(33)SXH.

Usage Guidelines

Use this command to create a mapping between an SNMP community and an SNMP context, engine ID, or security name that is different from the default settings.

Use the snmp-server community command to configure an SNMP community. When an SNMP community is associated with an SNMP context and a request is made from this community, the request is applied to the context. You also can use the snmp mib community-map command to specify the source address validation for an SNMP community by associating a list of target VRFs. The target VRF list specifies the valid host or hosts for this SNMP community.

Examples

The following example shows how to create an SNMP community named community1 and associate it with an SNMP context named context1:

Router(config)# snmp-server community community1

Router(config)# snmp mib community-map community1 context context1

The following example shows a mapping of community A (commA) to VPN list commAvpn and community B (commB) to VPN list commBvpn:

Router(config)# snmp mib community-map commA context A target-list commAvpn

Router(config)# snmp mib community-map commB context B target-list commBvpn

Router(config)# snmp mib target list commAvpn vrf CustomerA

Router(config)# snmp mib target list commBvpn vrf CustomerB

Related Commands

Command	Description
context	Associates an SNMP context with a particular VPN.
snmp-server community	Sets up the community access string to permit access to the SNMP.

snmp mib target list

To create a list of target virtual private network (VPN) routing and forwarding (VRF) instance and hosts to associate with a Simple Network Management Protocol (SNMP) community, use the snmp mib target list command in global configuration mode. To delete the list of VRF instances and hosts or to delete a particular VRF or host from the list, use the no form of this command.

snmp mib target list vpn-list-name {vrf vrf-name | host ip-address}

no snmp mib target list vpn-list-name {vrf vrf-name | host ip-address}

Syntax Description

vpn-list-name	Name of the target list.
vrf	Adds a specified VRF to the target list.
vrf-name	Name of a VRF to include in the list.
host	Adds a specified host to the target list.
ip-address	IP address of the host.

Command Default

No target list is created.

Command Modes

Global configuration (config)

Command History

Release	Modification
12.0(23)S	This command was introduced.
12.3(2)T	This command was integrated into Cisco IOS Release 12.3(2)T.
12.2(25)S	This command was integrated into Cisco IOS Release 12.2(25)S.
12.2(33)SRA	This command was integrated into Cisco IOS Release 12.2(33)SRA.
12.2(31)SB2	This command was integrated into Cisco IOS Release 12.2(31) SB2.
12.2(33)SXH	This command was integrated into Cisco IOS Release 12.2(33)SXH.

Usage Guidelines

Use this command when using SNMPv1 or SNMPv2 in a VPN environment to configure a list of VRFs or hosts for source address validation. Configuring the target list ensures that the community is valid only if the incoming packet is received from a VRF or host on the target list.

•Only the following MIBs are context aware and all the tables in these MIBs can be polled:

–CISCO-IPSEC-FLOW-MONITOR-MIB (Cisco IOS Release 12.4T and later)

–CISCO-IPSEC-MIB (Cisco IOS Release 12.4T and later)

–CISCO-PING-MIB

–IP-FORWARD-MIB

–MPLS-LDP-MIB

•Currently, two SNMP variables in the IP-FORWARD-MIB can be polled: 1.3.6.1.2.1.4.24.3 (ipCidrRouteNumber - Scalar) and 1.3.6.1.2.1.4.24.4.1 (ipCidrRouteEntry - Table).

---

Note It is recommended that you use SNMPv3 with the authNoPriv or higher level of security when using SNMP in a VPN environment.

---

Examples

The following example shows how to add a target list named target1 and add a VRF named vrf1 to the newly created target list:

Router(config)# snmp mib target list target1 vrf vrf1

Related Commands

Command	Description
snmp mib community-map	Associates an SNMP community with an SNMP context, engine ID, or security name.

snmp-server context

To create a Simple Network Management Protocol (SNMP) context, use the snmp-server context command in global configuration mode. To delete an SNMP context, use the no form of this command.

snmp-server context context-name

no snmp-server context context-name

Syntax Description

context-name

Name of the SNMP context being created.

Command Default

No SNMP contexts are configured.

Command Modes

Global configuration (config)

Command History

Release	Modification
12.0(23)S	This command was introduced.
12.3(2)T	This command was integrated into Cisco IOS Release 12.3(2)T.
12.2(25)S	This command was integrated into Cisco IOS Release 12.2(25)S.
12.2(33)SRA	This command was integrated into Cisco IOS Release 12.2(33)SRA.
12.2(31)SB2	This command was integrated into Cisco IOS Release 12.2(31)SB2.
12.2(33)SXH	This command was integrated into Cisco IOS Release 12.2(33)SXH.

Usage Guidelines

When you use the no snmp-server context command, all SNMP instances in that context are deleted.

A route distinguisher (RD) is required when you configure an SNMP context. An RD creates routing and forwarding tables and specifies the default route distinguisher for a VPN. The RD is added to the beginning of a IPv4 prefix to make it globally unique. An RD is either ASN relative, which means it is composed of an autonomous system number and an arbitrary number, or it is IP address relative and composed of an IP address and an arbitrary number.

Examples

The following example shows how to create an SNMP context named contextA and associate it with a virtual private network (VPN) routing and forwarding (VRF) instance named CustomerA:

Router(config)# snmp-server context contextA

Router(config)# ip vrf CustomerA

Router(config-vrf)# rd 100:120

Router(config-vrf)# context contextA

Related Commands

Command	Description
context	Associates an SNMP context with a particular VRF.

snmp-server enable traps snmp

To enable the sending of RFC 1157 Simple Network Management Protocol (SNMP) notifications, use the snmp-server enable traps snmp command in global configuration mode. To disable RFC 1157 SNMP notifications, use the no form of this command.

snmp-server enable traps snmp [authentication] [linkup] [linkdown] [coldstart] [warmstart]

no snmp-server enable traps snmp [authentication] [linkup] [linkdown] [coldstart] [warmstart]

Syntax Description

authentication	(Optional) Controls the sending of SNMP authentication failure notifications.
linkup	(Optional) Controls the sending of SNMP linkUp notifications.
linkdown	(Optional) Controls the sending of SNMP linkDown notifications.
coldstart	(Optional) Controls the sending of SNMP coldStart notifications.
warmstart	(Optional) Controls the sending of SNMP warmStart notifications.

Command Default

SNMP notifications are disabled by default.

When you enter this command without any optional keywords, all RFC 1157 SNMP notifications are enabled (or disabled, if using the no form of the command).

Command Modes

Global configuration (config)

Command History

Release	Modification
11.3	The snmp-server enable traps snmp authentication command was introduced. This command replaced the snmp-server trap-authentication command.
12.1(3)T	The following keywords were added: •linkup •linkdown •coldstart
12.1(5)T	The warmstart keyword was added.
12.2(28)SB	This command was integrated into Cisco IOS Release 12.2(28)SB.
12.2(33)SRA	This command was integrated into Cisco IOS Release 12.2(33)SRA.
12.2(31)SB2	This command was integrated into Cisco IOS Release 12.2(31)SB2.
12.2(33)SXH	This command was integrated into Cisco IOS Release 12.2(33)SXH.

Usage Guidelines

SNMP notifications can be sent as traps or inform requests. This command enables both traps and inform requests for the specified notification types.

If you do not enter an snmp-server enable traps snmp command, no notifications controlled by this command are sent. To configure the router to send these SNMP notifications, you must enter at least one snmp-server enable traps snmp command. When you enter the command with no keywords, all notification types are enabled. When you enter the command with a keyword, only the types of notifications related to that keyword are enabled.

When the optional authentication keyword is used, the authenticationFailure(4) trap signifies that the sending device is the addressee of a protocol message that is not properly authenticated. The authentication method depends on the version of SNMP being used. For SNMPv1 or SNMPv2c, authentication failure occurs for packets with an incorrect community string. For SNMPv3, authentication failure occurs for packets with an incorrect SHA/MD5 authentication key or for a packet that is outside the authoritative SNMP engine's window (for example, outside configured access lists or time ranges).

When the optional linkup keyword is used, the linkUp(3) trap signifies that the sending device recognizes that one of the communication links represented in the agent's configuration has come up.

When the optional linkdown keyword is used, the linkDown(2) trap signifies that the sending device recognizes a failure in one of the communication links represented in the agent's configuration.

The snmp-server enable traps snmp [linkup] [linkdown] form of this command globally enables or disables SNMP linkUp and linkDown traps. After enabling either of these traps globally, you can disable them on specific interfaces using the no snmp trap link-status command in interface configuration mode. On the interface level, linkUp and linkDown traps are enabled by default, which means that these notifications do not have to be enabled on a per-interface basis. However, linkUp and linkDown notifications will not be sent unless you enable them globally using the snmp-server enable traps snmp command.

When the optional coldstart keyword is used, the coldStart(0) trap signifies that the sending device is reinitializing itself such that the agent's configuration or the protocol entity implementation may be altered.

When the optional warmstart keyword is used, the warmStart(1) trap signifies that the sending device is reinitializing itself such that neither the agent configuration nor the protocol entity implementation is altered.

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

For a host to receive a notification controlled by this command, both the snmp-server enable traps command and the snmp-server host command for that host must be enabled. If the notification type is not controlled by this command, just the appropriate snmp-server host command must be enabled.

Examples

The following example shows how to enable the router to send all traps to the host myhost.cisco.com, using the community string defined as public:

Router(config)# snmp-server enable traps snmp

Router(config)# snmp-server host myhost.cisco.com public snmp

The following example shows how to enable the router to send all inform notifications to the host myhost.cisco.com using the community string defined as public:

Router(config)# snmp-server enable traps snmp

Router(config)# snmp-server host myhost.cisco.com informs version 2c public snmp

The following example shows the enabling all SNMP trap types, then the disabling of only the linkUp and linkDown trap:

Router> enable

Router# configure terminal

Router(config)# snmp-server enable traps snmp

Router(config)# end

Router# more system:running-config | include traps snmp

snmp-server enable traps snmp authentication linkup linkdown coldstart warmstart

Router# configure terminal

Router(config)# no snmp-server enable traps snmp linkup linkdown

Router(config)# end

Router# more system:running-config | include traps snmp

snmp-server enable traps snmp authentication coldstart warmstart

Related Commands

Command	Description
snmp-server enable traps	Enables all available SNMP notifications on your system.
snmp-server host	Specifies the recipient of an SNMP notification operation.
snmp-server informs	Specifies inform request options.
snmp-server trap authentication vrf	Disables or reenables SNMP authentication notifications specific to VPN context mismatches.
snmp-server trap-source	Specifies the interface that an SNMP trap should originate from.

snmp-server group

To configure a new Simple Network Management Protocol (SNMP) group, use the snmp-server group command in global configuration mode. To remove a specified SNMP group, use the no form of this command.

snmp-server group group-name {v1 | v2c | v3 {auth | noauth | priv}} [context context-name] [read read-view] [write write-view] [notify notify-view] [access [ipv6 named-access-list] [acl-number | acl-name]]

no snmp-server group group-name {v1 | v2c | v3 {auth | noauth | priv}} [context context-name]

Syntax Description

group-name	Name of the group.
v1	Specifies that the group is using the SNMPv1 security model. SNMPv1 is the least secure of the possible SNMP security models.
v2c	Specifies that the group is using the SNMPv2c security model. The SNMPv2c security model allows informs to be transmitted and supports 64-character strings.
v3	Specifies that the group is using the SNMPv3 security model. SMNPv3 is the most secure of the supported security models. It allows you to explicitly configure authentication characteristics.
auth	Specifies authentication of a packet without encrypting it.
noauth	Specifies no authentication of a packet.
priv	Specifies authentication of a packet with encryption.
context	(Optional) Specifies the SNMP context to associate with this SNMP group and its views.
context-name	(Optional) Context name.
read	(Optional) Specifies a read view for the SNMP group. This view enables you to view only the contents of the agent.
read-view	(Optional) String of a maximum of 64 characters that is the name of the view. The default is that the read-view is assumed to be every object belonging to the Internet object identifier (OID) space (1.3.6.1), unless the read option is used to override this state.
write	(Optional) Specifies a write view for the SNMP group. This view enables you to enter data and configure the contents of the agent.
write-view	(Optional) String of a maximum of 64 characters that is the name of the view. The default is that nothing is defined for the write view (that is, the null OID). You must configure write access.
notify	(Optional) Specifies a notify view for the SNMP group. This view enables you to specify a notify, inform, or trap.
notify-view	(Optional) String of a maximum of 64 characters that is the name of the view. By default, nothing is defined for the notify view (that is, the null OID) until the snmp-server host command is configured. If a view is specified in the snmp-server group command, any notifications in that view that are generated will be sent to all users associated with the group (provided a SNMP server host configuration exists for the user). Cisco recommends that you let the software autogenerate the notify view. See the "Configuring Notify Views" section in this document.
access	(Optional) Specifies a standard access control list (ACL) to associate with the group.
ipv6	(Optional) Specifies an IPv6 named access list. If both IPv6 and IPv4 access lists are indicated, the IPv6 named access list must appear first in the list.
named-access-list	(Optional) Name of the IPv6 access list.
[acl-number | acl-name]	(Optional) The acl-number argument is an integer from 1 to 99 that identifies a previously configured standard access list. The acl-name argument is a string of a maximum of 64 characters that is the name of a previously configured standard access list.

Command Default

No SNMP server groups are configured.

Command Modes

Global configuration (config)

Command History

Release	Modification
11.(3)T	This command was introduced.
12.0(23)S	The context context-name keyword and argument pair was added.
12.3(2)T	The context context-name keyword and argument pair was integrated into Cisco IOS Release 12.3(2)T, and support for standard named access lists (acl-name) was added.
12.0(27)S	The ipv6 named-access-list keyword and argument pair was added.
12.2(25)S	This command was integrated into Cisco IOS Release 12.2(25)S.
12.3(14)T	The ipv6 named-access-list keyword and argument pair was integrated into Cisco IOS Release 12.3(14)T.
12.2(33)SRA	This command was integrated into Cisco IOS Release 12.2(33)SRA.
12.2(31)SB2	This command was integrated into Cisco IOS Release 12.2(31)SB2.
12.2(33)SXH	This command was integrated into Cisco IOS Release 12.2(33)SXH.

Usage Guidelines

When a community string is configured internally, two groups with the name public are autogenerated, one for the v1 security model and the other for the v2c security model. Similarly, deleting a community string will delete a v1 group with the name public and a v2c group with the name public.

No default values exist for authentication or privacy algorithms when you configure the snmp-server group command. Also, no default passwords exist. For information about specifying a Message Digest 5 (MD5) password, see the documentation of the snmp-server user command.

Configuring Notify Views

The notify-view option is available for two reasons:

•If a group has a notify view that is set using SNMP, you may need to change the notify view.

•The snmp-server host command may have been configured before the snmp-server group command. In this case, you must either reconfigure the snmp-server host command, or specify the appropriate notify view.

Specifying a notify view when configuring an SNMP group is not recommended, for the following reasons:

•The snmp-server host command autogenerates a notify view for the user, and then adds it to the group associated with that user.

•Modifying the group's notify view will affect all users associated with that group.

Instead of specifying the notify view for a group as part of the snmp-server group command, use the following commands in the order specified:

1. snmp-server user—Configures an SNMP user.

2. snmp-server group—Configures an SNMP group, without adding a notify view.

3. snmp-server host—Autogenerates the notify view by specifying the recipient of a trap operation.

SNMP Contexts

SNMP contexts provide VPN users with a secure way of accessing MIB data. When a VPN is associated with a context, that VPN's specific MIB data exists in that context. Associating a VPN with a context enables service providers to manage networks with multiple VPNs. Creating and associating a context with a VPN enables a provider to prevent the users of one VPN from accessing information about users of other VPNs on the same networking device.

Use this command with the context context-name keyword and argument to associate a read, write, or notify SNMP view with an SNMP context.

Examples

Create an SNMP Group

The following example shows how to create the SNMP server group "public," allowing read-only access for all objects to members of the standard named access list "lmnop":

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

Remove an SNMP Server Group

The following example shows how to remove the SNMP server group "public" from the configuration:

Router(config)# no snmp-server group public v2c 

Associate an SNMP Server Group with Specified Views

The following example shows SNMP context "A" associated with the views in SNMPv2c group "GROUP1":

Router(config)# snmp-server context A

Router(config)# snmp mib community commA

Router(config)# snmp mib community-map commA context A target-list commAVpn

Router(config)# snmp-server group GROUP1 v2c context A read viewA write viewA notify viewB

Related Commands

Command	Description
show snmp group	Displays the names of groups on the router and the security model, the status of the different views, and the storage type of each group.
snmp mib community-map	Associates a SNMP community with an SNMP context, engine ID, security name, or VPN target list.
snmp-server host	Specifies the recipient of a SNMP notification operation.
snmp-server user	Configures a new user to a SNMP group.

Glossary

MPLS VPN—Multiprotocol Label Switching Virtual Private Network

NMS—Network Management System. System responsible for managing at least part of a network. An NMS is generally a reasonably powerful and well-equipped computer, such as an engineering workstation. NMSs communicate with agents to help keep track of network statistics and resources.

SNMP—Simple Network Management Protocol. Network management protocol used almost exclusively in TCP/IP networks. SNMP provides a means to monitor and control network devices and to manage configurations, statistics collection, performance, and security.

SNMP communities—Authentication scheme that enables an intelligent network device to validate SNMP requests.

SNMPv2c—Version 2c of the Simple Network Management Protocol. SNMPv2c supports centralized as well as distributed network management strategies and includes improvements in the Structure of Management Information (SMI), protocol operations, management architecture, and security.

SNMPv3—Version 3 of the Simple Network Management Protocol. Interoperable standards-based protocol for network management. SNMPv3 provides secure access to devices by a combination of authenticating and encrypting packets over the network.

UDP—User Datagram Protocol. Connectionless transport layer protocol in the TCP/IP protocol stack. UDP is a simple protocol that exchanges datagrams without acknowledgments or guaranteed delivery, requiring that error processing and retransmission be handled by other protocols. UDP is defined in RFC 768.

VRF—A VPN routing/forwarding instance. A VRF consists of an IP routing table, a derived forwarding table, a set of interfaces that use the forwarding table, and a set of rules and routing protocols that determine what goes into the forwarding table. In general, a VRF includes the routing information that defines a customer VPN site that is attached to a PE router.

CCVP, the Cisco logo, and the Cisco Square Bridge logo are trademarks of Cisco Systems, Inc.; Changing the Way We Work, Live, Play, and Learn is a service mark of Cisco Systems, Inc.; and Access Registrar, Aironet, BPX, Catalyst, CCDA, CCDP, CCIE, CCIP, CCNA, CCNP, CCSP, Cisco, the Cisco Certified Internetwork Expert logo, Cisco IOS, Cisco Press, Cisco Systems, Cisco Systems Capital, the Cisco Systems logo, Cisco Unity, Enterprise/Solver, EtherChannel, EtherFast, EtherSwitch, Fast Step, Follow Me Browsing, FormShare, GigaDrive, HomeLink, Internet Quotient, IOS, iPhone, IP/TV, iQ Expertise, the iQ logo, iQ Net Readiness Scorecard, iQuick Study, LightStream, Linksys, MeetingPlace, MGX, Networking Academy, Network Registrar, Packet, PIX, ProConnect, ScriptShare, SMARTnet, StackWise, The Fastest Way to Increase Your Internet Quotient, and TransPath are registered trademarks of Cisco Systems, Inc. and/or its affiliates in the United States and certain other countries.

All other trademarks mentioned in this document or Website 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. (0705R)

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

© 2002-2004, 2006-2007 Cisco Systems, Inc. All rights reserved.