Feedback
|
Table Of Contents
Prerequisites for MPLS VPN—MIB Support
Restrictions for MPLS VPN—MIB Support
Information About MPLS VPN—MIB Support
Capabilities Supported by PPVPN-MPLS-VPN MIB
Functional Structure of the PPVPN-MPLS-VPN MIB
Supported Objects in PPVPN-MPLS-VPN MIB
How to Configure MPLS VPN—MIB Support
Configuring the SNMP Community
Configuring the Router to Send SNMP Traps
Configuring Threshold Values for MPLS VPN-MIB Notifications
Configuration Examples for MPLS VPN—MIB Support
Configuring the SNMP Community Examples
Configuring the Router to Send SNMP Traps Example
Configuring Threshold Values for MPLS VPN-MIB Notifications Examples
snmp-server enable traps mpls vpn
MPLS VPN—MIB Support
This document describes the Simple Network Management Protocol (SNMP) agent support in Cisco IOS for Multiprotocol Label Switching (MPLS) Virtual Private Network (VPN) management, as implemented in the draft MPLS/BGP Virtual Private Network Management Information Base Using SMIv2 (draft-ietf-ppvpn-mpls-vpn-mib-03.txt).
The MPLS VPN technology allows service providers to offer intranet and extranet VPN services that directly connect their customers' remote offices to a public network with the same security and service levels that a private network offers. Each VPN is associated with one or more VPN routing/forwarding instances (VRFs). A VRF is created for each VPN defined on a router and contains most of the information needed to manage and monitor MPLS VPNs: an IP routing table, a derived Cisco Express Forwarding (CEF) table, a set of interfaces that use this forwarding table, and a set of rules and routing protocol parameters that control the information that is included into the routing table. The Provider-Provisioned VPN (PPVPN)-MPLS-VPN MIB provides access to this VRF information, as well as interfaces included in the VRF, and other configuration and monitoring information.
The PPVPN-MPLS-VPN MIB provides the following benefits:
•
A standards-based SNMP interface for retrieving information about critical MPLS VPN events.
•
VRF information to assist in the management and monitoring of MPLS VPNs.
•
Information, in conjunction with the Interfaces MIB, about interfaces assigned to VRFs.
•
Performance statistics for all VRFs on a router.
•
The generation and queuing of notifications that call attention to major changes in the operational status of MPLS VPN enabled interfaces; the forwarding of notification messages to a designated NMS for evaluation and action by network administrators.
•
Advanced warning when VPN routing tables are approaching or exceed their capacity.
•
Warnings about the reception of illegal labels on a VRF-enabled interface. Such receptions may indicate misconfiguration or an attempt to violate security.
This document describes both the PPVPN-MPLS-VPN MIB notification and the tables.
Feature Specifications for the MPLS VPN—MIB Support
Finding Support Information for Platforms and Cisco IOS Software Images
Use Cisco Feature Navigator to find information about platform support and Cisco IOS software image support. Access Cisco Feature Navigator at http://www.cisco.com/go/fn. You must have an account on Cisco.com. If you do not have an account or have forgotten your username or password, click Cancel at the login dialog box and follow the instructions that appear.
Contents
•
Prerequisites for MPLS VPN—MIB Support
•
Restrictions for MPLS VPN—MIB Support
•
Information About MPLS VPN—MIB Support
•
How to Configure MPLS VPN—MIB Support
•
Configuration Examples for MPLS VPN—MIB Support
Prerequisites for MPLS VPN—MIB Support
The MPLS VPN MIB agent requires the following:
•
SNMP is installed and enabled on the label switching routers.
•
MPLS is enabled on the label switching routers.
•
Multiprotocol Border Gateway Protocol (BGP) is enabled on the label switching routers.
•
Cisco Express Forwarding is enabled on the label switching routers.
Restrictions for MPLS VPN—MIB Support
The following restrictions apply to the PPVPN-MPLS-VPN MIB for this release:
•
Configuration of the MIB using the SNMP SET command is not supported in this release, except for trap-related objects, such as mplsVpnNotificationEnable and mplsVpnVrfSecIllegalLabelRcvThresh.
•
The mplsVpnVrfBgpNbrPrefixTable is not supported in this version.
Information About MPLS VPN—MIB Support
SNMP agent code operating in conjunction with the PPVPN-MPLS-VPN MIB enables a standardized, SNMP-based approach to managing MPLS VPNs in Cisco IOS.
The PPVPN-MPLS-VPN MIB is based on the IETF draft MIB specification draft-ietf-ppvpn-mpls-vpn-mib-03.txt, which includes objects describing features that support MPLS VPN events. This IETF draft MIB, which undergoes revisions from time to time, is being evolved toward becoming a standard. Accordingly, the Cisco implementation of the PPVPN-MPLS-VPN MIB is expected to track the evolution of the IETF draft MIB, and may change accordingly.
Some slight differences between the IETF draft MIB and the actual implementation of MPLS VPNs within Cisco IOS require some minor translations between the PPVPN-MPLS-VPN MIB and the internal data structures of Cisco IOS. These translations are accomplished by means of the SNMP agent code. Also, while running as a low priority process, the SNMP agent provides a management interface to Cisco IOS. SNMP adds little overhead on the normal functions of the device.
The SNMP objects defined in the PPVPN-MPLS-VPN MIB can be viewed by any standard SNMP utility. The network administrator can retrieve information in the PPVPN-MPLS-VPN MIB using standard SNMP get and getnext operations for SNMP v1, v2, and v3.
All PPVPN-MPLS-VPN MIB objects are based on the IETF draft MIB; thus, no Cisco specific SNMP application is required to support the functions and operations pertaining to the PPVPN-MPLS-VPN MIB features.
This section contains the following topics:
•
Capabilities Supported by PPVPN-MPLS-VPN MIB
•
Functional Structure of the PPVPN-MPLS-VPN MIB
•
Supported Objects in PPVPN-MPLS-VPN MIB
Capabilities Supported by PPVPN-MPLS-VPN MIB
The following functionality is supported for the PPVPN-MPLS-VPN MIB. The PPVPN-MPLS-VPN MIB provides you with the ability to do the following:
•
Gather routing and forwarding information for MPLS VPNs on a router.
•
Expose information in the VRF routing table.
•
Gather information on BGP configuration related to VPNs and VRF interfaces and statistics.
•
Emit notification messages that signal changes when critical MPLS VPN events occur.
•
Enable, disable, and configure notification messages for MPLS VPN events by using extensions to existing SNMP CLI commands.
•
Specify the IP address of a network management system (NMS) in the operating environment to which notification messages are sent.
•
Write notification configurations into nonvolatile memory.
Functional Structure of the PPVPN-MPLS-VPN MIB
The SNMP agent code supporting the PPVPN-MPLS-VPN MIB follows the existing model for such code in Cisco IOS and is, in part, generated by the Cisco IOS tool set, based on the MIB source code.
The SNMP agent code, which has a layered structure that is common to MIB support code in Cisco IOS, consists of four layers:
•
Platform-independent layer—This layer is generated primarily by the MIB development Cisco IOS tool set and incorporates platform- and implementation-independent functions. The Cisco IOS MIB development tool set creates a standard set of files associated with a MIB.
•
Application interface layer—The functions, names, and template code for MIB objects in this layer are also generated by the MIB development Cisco IOS tool set.
•
Application-specific layer—This layer provides an interface between the application interface layer and the API and data structures layer below and performs tasks needed to retrieve required information from Cisco IOS, such as searching through data structures.
•
API and data structures layer—This layer contains the data structures or APIs within Cisco IOS that are retrieved or called in order to set or retrieve SNMP management information.
Supported Objects in PPVPN-MPLS-VPN MIB
The PPVPN-MPLS-VPN MIB contains numerous tables and object definitions that provide read-only SNMP management support for the MPLS VPN feature in Cisco IOS. The PPVPN-MPLS-VPN MIB conforms to Abstract Syntax Notation One (ASN.1), thus reflecting an idealized MPLS VPN database.
Using any standard SNMP network management application, you can retrieve and display information from the PPVPN-MPLS-VPN MIB using GET operations; similarly, you can traverse information in the MIB database for display using GETNEXT operations.
The PPVPN-MPLS-VPN MIB tables and objects supported in this Cisco IOS release are described briefly in the following sections:
Objects that are not supported in this Cisco IOS release are listed in the "MIB Objects Not Supported" section.
Figure 1 shows a simple MPLS VPN configuration. This configuration includes two customer MPLS VPNs, labeled VPN1 and VPN2, and a simple provider network that consists of two provider edge routers, labeled PE1 and PE2, and a provider core router labeled P. Figure 1 shows the following sample configuration:
•
VRF names—VPN1 and VPN2
•
Interfaces associated with VRFs—Et1, Et2, and At3/0
•
Routing protocols—OSPF, RIP, and IBGP
•
Routes associated with VPN1—10.1.0.0, 10.2.0.0, and 10.3.0.0
•
Routes associated with VPN2—172.16.1.0 and 172.16.2.0
•
Routes associated with the provider network—192.168.1.0, 192.168.2.0, and 192.168.3.0
This configuration is used in this document to explain MPLS VPN events that are monitored and managed by the PPVPN-MPLS-VPN MIB.
Figure 1 Sample MPLS VPN Configuration
Scalar Objects
Table 1 shows the PPVPN-MPLS-VPN MIB scalar objects supported for this release.
MIB Tables
The PPVPN-MPLS-VPN MIB implementation for this release supports the following tables described in this section:
mplsVpnVrfTable
Entries in the VRF configuration table (mplsVpnVrfTable) represent the VRFs that are defined on the router. This includes recently deleted VRFs. The information in this table is also displayed with the show ip vrf command.
Each VRF is referenced by its VRF name (mplsVpnVrfName).
Table 2 lists the MIB objects and their functions for this table.
mplsVpnInterfaceConfTable
In Cisco IOS, a VRF is associated with one MPLS VPN. Zero or more interfaces can be associated with a VRF. A VRF uses an interface that is defined in the ifTable of the Interfaces Group of MIB II (IFMIB). The IFMIB defines objects for managing interfaces. The ifTable of this MIB contains information on each interface in the network. The mplsVpnInterfaceConfTable associates a VRF from the mplsVpnVrfTable with a forwarding interface from the ifTable. Figure 2 shows the relationship between VRFs and interfaces defined in the ifTable and the mplsVpnInterfaceConfTable.
Figure 2 VRFs, the Interfaces MIB, and the mplsVpnInterfaceConfTable
Entries in the VPN interface configuration table (mplsVpnInterfaceConfTable) represent the interfaces that are assigned to each VRF. The information available in this table is also displayed with the show ip vrf command.
The mplsVpnInterfaceConfTable shows how interfaces are assigned to VRFs. A label switch router (LSR) creates an entry in this table for every interface capable of supporting MPLS VPNs.
The mplsVpnInterfaceConfTable is indexed by the following:
•
mplsVpnVrfName—The VRF name
•
mplsVpnInterfaceConfIndex—An identifier that is the same as the ifIndex from the Interface MIB of the interface assigned to the VRF
Table 3 lists the MIB objects and their functions for this table.
mlsVpnVrfRouteTargetTable
The route target table (mplsVpnVrfRouteTargetTable) describes the route target communities that are defined for a particular VRF. An LSR creates an entry in this table for each target configured for a VRF supporting an MPLS VPN instance.
The distribution of VPN routing information is controlled through the use of VPN route target communities, implemented by Border Gateway Protocol (BGP) extended communities. Distribution of VPN routing information works as follows:
•
When a VPN route learned from a CE router is injected into BGP, a list of VPN route target extended community attributes are associated with it. Typically the list of route target community values is set from an export list of route targets associated with the VRF from which the route was learned.
•
An import list of route target extended communities is associated with each VRF. The import list defines route target extended community attributes a route must have for the route to be imported into the VRF. For example, if the import list for a particular VRF includes route target communities A, B, and C, then any VPN route that carries any of those route target extended communities—A, B, or C—is imported into the VRF.
Figure 3 shows a sample configuration and its relationship to an mplsVpnVrfRouteTargetTable. A route target table exists on each PE router. Routers with route distinguishers (RDs) 100:1, 100:2, and 100:3 are shown in the sample configuration. Routers with RDs 100:4 and 100:5 are not shown in Figure 3, but are included in the route targets for PE2 and in the mplsVpnVrfRouteTargetTable.
Figure 3 Sample Configuration and the mplsVpnVrfRouteTargetTable
The mplsVpnVrfRouteTargetTable shows the import and export route targets for each VRF. The table is indexed by the following:
•
mplsVpnVrfName—The VRF name
•
mplsVpnVrfRouteTargetIndex—The route target entry identifier
•
mplsVpnVrfRouteTargetType—A value specifying whether the entry is an import route target, export route target, or is defined as both
Table 4 lists the MIB objects and their functions for this table.
mplsVpnVrfBgpNbrAddrTable
The BGP neighbor address table (mplsVpnVrfBgpNbrAddrTable) represents the MPLS eBGP neighbors that are defined for a particular VRF. An LSR creates an entry for every BGP neighbor that is defined in the VRF's address-family.
The mplsVpnVrfBgpNbrAddrTable is indexed by the following:
•
mplsVpnVrfName—The VRF name
•
mplsVpnInterfaceConfIndex—An identifier that is the same as the ifIndex from the Interface MIB of the interface assigned to the VRF
•
mplsVpnVrfBgpNbrIndex—The IP address of the neighbor
Table 5 lists the MIB objects and their functions for this table.
mplsVpnVrfSecTable
The VRF security table (mplsVpnVrfSecTable) provides information about security for each VRF. An LSR creates an entry in this table for every VRF capable of supporting MPLS VPN.
The mplsVpnVrfSecTable augments the mplsVpnVrfTable and has the same indexing.
Table 6 lists the MIB objects and their functions for this table.
mplsVpnVrfPerfTable
The VRF performance table (mplsVpnVrfPerfTable) provides statistical performance information for each VRF. An LSR creates an entry in this table for every VRF capable of supporting MPLS VPN.
The mplsVpnVrfPerfTable augments the mplsVpnVrfTable and has the same indexing.
Table 7 lists the MIB objects and their functions for this table.
mplsVpnVrfRouteTable
The VRF routing table (mplsVpnVrfRouteTable) provides the IP routing table information for each VRF. The information available in this table can also be accessed with the show ip route vrf vrf-name command. For example, for PE1 in Figure 1:
•
With the show ip route vrf vpn1 command, you would see results like the following:
Router# show ip route vrf vpn1Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGPD - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter areaN1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGPi - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area* - candidate default, U - per-user static route, o - ODR P - periodic downloaded static route !Gateway of last resort is not set!10.0.0.0/32 is subnetted, 3 subnetsB 10.3.0.0 [200/0] via 192.168.2.1, 04:36:33C 10.1.0.0/16 is directly connected, Ethernet1C 10.2.0.0/16 [200/0] directly connected Ethernet2, 04:36:33•
With the show ip route vrf vpn2 command, you would see results like the following:
Router# show ip route vrf vpn2Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGPD - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter areaN1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGPi - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area* - candidate default, U - per-user static route, o - ODR P - periodic downloaded static route !Gateway of last resort is not set!172.16.0.0/32 is subnetted, 2 subnetsB 172.16.2.0 [200/0] via 192.168.2.1, 04:36:33C 172.16.1.0 is directly connected, ATM 3/0Figure 4 shows the relationship of the routing tables, the VRFs, and the mplsVpnVrfRouteTable. You can view information about the VPN1 and VPN2 route tables using the show ip route vrf vrf-name command. The global route table is the same as ipCidrRouteTable in the IP-FORWARD-MIB. You can view information about the global route table with the show ip route command.
Figure 4 Route Table, VRFs, and the mplsVpnVrfRouteTable
An LSR creates an entry in this table for every route that is configured, either dynamically or statically, within the context of a specific VRF capable of supporting MPLS VPN.
The mplsVpnVrfRouteTable is indexed by the following:
•
mplsVpnVrfName—The VRF name, which provides the VRF routing context
•
mplsVpnVrfRouteDest—The IP destination address
•
mplsVpnVrfRouteMask—The IP destination mask
•
mplsVpnVrfRouteTos—The IP header ToS bits
•
mplsVpnVrfRouteNextHop—The IP address of the next hop for each route entry
Note
The ToS bits are not supported in this Cisco IOS release and, therefore, are always 0.
Table 8 lists the MIB objects and their functions for the mplsVpnVrfRouteTable. This table represents VRF-specific routes. The global routing table is the ipCidrRouteTable in the IP-FORWARD-MIB.
Notifications
This section provides the following information about PPVPN-MPLS-VPN MIB notifications supported in this release:
•
Notification Generation Events
•
Monitoring the PPVPN-MPLS-VPN MIB Notifications
Notification Generation Events
The following notifications of the PPVPN-MPLS-VPN MIB are implemented for this release:
•
mplsVrfIfUp—Sent to an NMS when an interface comes up and is assigned a VPN routing/forwarding table instance (VRF).
•
mplsVrfIfDown—Generated and sent to the NMS when a VRF is removed from an interface or the interface transitions from an operationally "up" state to a "down" state.
•
mplsNumVrfRouteMidThreshExceeded—Generated and sent when the middle (warning) threshold is crossed. You can configure this threshold in the CLI by using the following commands:
Router(config)# ip vrf vrf-nameRouter(config-vrf)# maximum routes limit warn-threshold (% of max)The warn-threshold argument is a percentage of the maximum routes specified by the limit argument. You can also configure a middle threshold with the following command, in which the limit argument represents the warning threshold:
Router(config-vrf)# maximum routes limit warn-onlyThis notification is sent to the NMS only at the time the threshold is exceeded. (See Figure 5 for a comparison of the warning and maximum thresholds.) Whenever the number of routes falls below this threshold and exceeds the threshold again, a notification is sent to the NMS.
•
mplsNumVrfRouteMaxThreshExceeded—Generated and sent when you attempt to create a route on a VRF that already contains the maximum number of routes as defined by the limit argument of the maximum routes commands:
Router(config)# ip vrf vrf-nameRouter(config-vrf)# maximum routes limit warn-threshold (% of max)A trap notification is sent to the NMS when you attempt to exceed the maximum threshold. Another notification is not sent until the number of routes falls below the maximum threshold and reaches the maximum threshold again. (See Figure 5 for an example of how this notification works and for a comparison of the maximum and warning thresholds.)
Note
The maximum routes command sets the number of routes for a VRF. You cannot exceed the number of routes in the VRF that you set with the maximum routes limit warn-threshold command.
Prior to this implementation of the PPVPN-MPLS-VPN MIB, you were not notified when this threshold (or the warning threshold) was reached.•
mplsNumVrfSecIllegalLabelThreshExceeded—Generated and sent when the amount of illegal labels received on a VRF interface exceeds the threshold mplsVpnVrfSecIllegalLabelRcvThresh. This threshold is defined with a value of 0. Therefore, a notification is sent when the first illegal label is received on a VRF. Labels are considered illegal if they are outside of the valid label range, do not have a Label Forwarding Information Base (LFIB) entry, or the table ID of the message does not match the table ID for the label in the LFIB.
Figure 5 Comparison of Warning and Maximum Thresholds
For information on the Cisco IOS CLI commands for configuring PPVPN-MPLS-VPN MIB notifications that are to be sent to an NMS, see the "How to Configure MPLS VPN—MIB Support" section and the "Command Reference" section.
Notification Specification
In an SNMPv1 notification, each VPN notification has a generic type identifier and an enterprise-specific type identifier for identifying the notification type.
•
The generic type for all VPN notifications is "enterpriseSpecific" as this is not one of the generic notification types defined for SNMP.
•
The enterprise-specific type is identified as follows:
–
1 for mplsVrfIfUp
–
2 for mplsVrfIfDown
–
3 for mplsNumVrfRouteMidThreshExceeded
–
4 for mplsNumVrfRouteMaxThreshExceeded
–
5 for mplsNumVrfSecIllegalLabelThreshExceeded
In SNMPv2, the notification type is identified by an SnmpTrapOID varbind (variable binding consisting of an object identifier [OID] type and value) included within the notification message.
Each notification also contains two additional objects from the PPVPN-MPLS-VPN MIB. These objects provide additional information about the event, as follows:
•
The VRF interface up/down notifications provide additional variables—mplsVpnInterfaceConfIndex and mplsVpnVrfName—in the notification. These variables describe the SNMP interface index and the VRF name, respectively.
•
The mid and max threshold notifications include the mplsVpnVrfName variable (VRF name) as well as the mplsVpnVrfPerfCurrNumRoutes variable that indicates the current number of routes within the VRF.
•
The illegal label notification includes the mplsVpnVrfName variable (VRF name) and the mplsVpnVrfSecIllegalLabelViolations variable that maintains the current count of illegal labels on a VPN.
Monitoring the PPVPN-MPLS-VPN MIB Notifications
When PPVPN-MPLS-VPN MIB notifications are enabled (see the snmp-server enable traps mpls vpn command), notification messages relating to specific MPLS VPN events within Cisco IOS are generated and sent to a specified NMS in the network. Any utility that supports SNMPv1 or SNMPv2 notifications can receive notification messages.
To monitor PPVPN-MPLS-VPN MIB notification messages, log in to an NMS that supports a utility that displays SNMP notifications, and start the display utility.
MIB Objects Not Supported
The following objects from the mplsVpnVrfBgpPathAttrTable are not supported for this release:
•
mplsVpnVrfBgpPathAttrPeer
•
mplsVpnVrfBgpPathAttrIpAddrPrefixLen
•
mplsVpnVrfBgpPathAttrIpAddrPrefix
•
mplsVpnVrfBgpPathAttrOrigin
•
mplsVpnVrfBgpPathAttrASPathSegment
•
mplsVpnVrfBgpPathAttrNextHop
•
mplsVpnVrfBgpPathAttrMultiExitDisc
•
mplsVpnVrfBgpPathAttrLocalPref
•
mplsVpnVrfBgpPathAttrAtomicAggregate
•
mplsVpnVrfBgpPathAttrAggregatorAS
•
mplsVpnVrfBgpPathAttrAggregatorAddr
•
mplsVpnVrfBgpPathAttrCalcLocalPref
•
mplsVpnVrfBgpPathAttrBest
•
mplsVpnVrfBgpPathAttrUnknown
How to Configure MPLS VPN—MIB Support
This section describes configuration tasks for MPLS VPN—MIB Support. Each task in the list is identified as either required or optional.
•
Configuring the SNMP Community (required)
•
Configuring the Router to Send SNMP Traps (required)
•
Configuring Threshold Values for MPLS VPN-MIB Notifications (required)
The MPLS VPN notifications are enabled or disabled using the extended CLI commands (see the "Command Reference" section).
Configuring the SNMP Community
An SNMP community string defines the relationship between the SNMP manager and the agent. The community string acts like a password to regulate access to the agent on the router.
Perform this task to configure an SNMP community.
SUMMARY STEPS
1.
enable
2.
show running-config
3.
configure terminal
4.
snmp-server community string [view view-name] [ro | rw] [acl-number]
5.
do copy running-config startup-config
6.
exit
7.
show running config [interface | map-class]
DETAILED STEPS
Configuring the Router to Send SNMP Traps
Perform this task to configure the router to send traps to a host.
The snmp-server host command specifies which hosts receive traps. The snmp-server enable traps command globally enables the trap production mechanism for the specified traps.
For a host to receive a trap, an snmp-server host command must be configured for that host, and, generally, the trap must be enabled globally through the snmp-server enable traps command.
Note
Although you can set the community-string argument using the snmp-server host command by itself, we recommend you define this string using the snmp-server community command prior to using the snmp-server host command.
SUMMARY STEPS
1.
enable
2.
configure terminal
3.
snmp-server host host-addr [traps | informs] [version {1 | 2c | 3 [auth | noauth | priv]}] community-string [udp-port port] [notification-type] [vrf vrf-name]
4.
snmp-server enable traps mpls vpn [vrf-up] [vrf-down] [mid-threshold] [max-threshold] [illegal-label]
5.
end
DETAILED STEPS
Configuring Threshold Values for MPLS VPN-MIB Notifications
Perform this task to configure threshold values for MPLS VPN-MIB notifications.
The mplsNumVrfRouteMidThreshExceeded notification event is generated and sent when the middle (warning) threshold is crossed. You can configure this threshold in the CLI by using the maximum routes command in VRF configuration mode. This notification is sent to the NMS only at the time the threshold is exceeded. Whenever the number of routes falls below this threshold and exceeds the threshold again, a notification is sent to the NMS.
The mplsNumVrfRouteMaxThreshExceeded notification event is generated and sent when you attempt to create a route on a VRF that already contains the maximum number of routes as defined by the maximum routes command in VRF configuration mode. A trap notification is sent to the NMS when you attempt to exceed the maximum threshold. Another notification is not sent until the number of routes falls below the maximum threshold and reaches the maximum threshold again.
(See Figure 5 for an example of how this notification works and for a comparison of the maximum and warning thresholds.)
Note
The maximum routes command sets the number of routes for a VRF. You cannot exceed the number of routes in the VRF that you set with the maximum routes limit warn-threshold command.
Prior to this implementation of the PPVPN-MPLS-VPN MIB, you were not notified when this threshold (or the warning threshold) was reached.
SUMMARY STEPS
1.
enable
2.
configure terminal
3.
ip vrf vrf-name
4.
maximum routes limit {warn-threshold | warn-only}
5.
end
DETAILED STEPS
Configuration Examples for MPLS VPN—MIB Support
This section contains the following configuration examples for the MPLS VPN—MIB Support feature:
•
Configuring the SNMP Community Examples
•
Configuring the Router to Send SNMP Traps Example
•
Configuring Threshold Values for MPLS VPN-MIB Notifications Examples
Configuring the SNMP Community Examples
The following example shows enabling a simple SNMP community group. This configuration permits any SNMP client to access all PPVPN-MPLS-VPN MIB objects with read-only access using the community string comaccess.
Router# config terminalRouter(config)# snmp-server community comaccess roVerify that the SNMP master agent is enabled for the MPLS VPN—MIB Support feature:
Router# show running-config | include snmp-serverBuilding configuration.......snmp-server community comaccess RO....
Note
If you do not see any "snmp-server" statements, SNMP is not enabled on the router.
Configuring the Router to Send SNMP Traps Example
The following example shows you how to enable the router to send MPLS VPN notifications to host 172.20.2.160 using the comaccess community string if a VRF transitions from a down state to an up state or from an up state to a down state.
Router# config terminalRouter(config)# snmp-server host 172.20.2.160 traps comaccess mpls-vpnRouter(config)# snmp-server enable traps mpls vpn vrf-up vrf-downConfiguring Threshold Values for MPLS VPN-MIB Notifications Examples
The following example shows how to set a maximum threshold of 10000 routes and a warning threshold that is 80 percent of the maximum threshold for a VRF named vpn1 on a router:
Router(config)# ip vrf vpn1Router(config)# maximum routes 10000 80The following example shows how to set a warning threshold of 10000 routes for a VRF named vpn2 on a router. An error message is generated; however, additional routes are still allowed because a maximum route threshold is not set with this command.
Router(config)# ip vrf vpn2Router(config)# maximum routes 10000 warn-onlyAdditional References
For additional information related to the MPLS VPN—MIB Support feature, refer to the following references:
•
MIBs
•
RFCs
Related Documents
Related Topic Document TitleMultiprotocol Label Switching (MPLS) Label Distribution Protocol (LDP) configuration tasks
A description of SNMP agent support in Cisco IOS for the MPLS Label Switching Router MIB (MPLS-LSR-MIB)
MPLS Virtual Private Network (VPN) configuration tasks
Configuration tasks for MPLS ATM network enhancements
MPLS automatic bandwidth adjustment configuration tasks
MPLS Traffic Engineering (TE)—Automatic Bandwidth Adjustment for TE Tunnels
MPLS traffic engineering scalability enhancements configuration tasks
A description of SNMP agent support in Cisco IOS for the MPLS Traffic Engineering MIB (MPLS TE MIB)
Basic MPLS VPN Carrier Supporting Carrier configuration tasks
Overview and configuration tasks for the Multiprotocol Label Switching (MPLS) distribution protocol
"Multiprotocol Label Switching" chapter in the
Cisco IOS Switching Services Configuration Guide, Release 12.2
Standards
MIBs
MIBs1 MIBs LinkMPLS/BGP Virtual Private Network Management Information Base Using SMIv2 (draft-ietf-ppvpn-mpls-vpn-mib-03.txt)
To obtain lists of supported MIBs by platform and Cisco IOS release, and to download MIB modules, go to the Cisco MIB website on Cisco.com at the following URL:
http://www.cisco.com/public/sw-center/netmgmt/cmtk/mibs.shtml
1 Not all supported MIBs are listed.
To locate and download MIBs for selected platforms, Cisco IOS releases, and feature sets, use Cisco MIB Locator found at the following URL:
http://tools.cisco.com/ITDIT/MIBS/servlet/index
If Cisco MIB Locator does not support the MIB information that you need, you can also obtain a list of supported MIBs and download MIBs from the Cisco MIBs page at the following URL:
http://www.cisco.com/public/sw-center/netmgmt/cmtk/mibs.shtml
To access Cisco MIB Locator, you must have an account on Cisco.com. If you have forgotten or lost your account information, send a blank e-mail to cco-locksmith@cisco.com. An automatic check will verify that your e-mail address is registered with Cisco.com. If the check is successful, account details with a new random password will be e-mailed to you. Qualified users can establish an account on Cisco.com by following the directions found at this URL:
RFCs
RFCs1 TitleRFC 2233
The Interfaces Group MIB using SMIv2
RFC 2547bis
BGP/MPLS VPNs
1 Not all supported RFCs are listed.
Technical Assistance
Command Reference
This section documents new and modified commands for this feature. All other commands used with this feature are documented in the Cisco IOS Release 12.2 command reference publications.
•
snmp-server enable traps mpls vpn
snmp-server enable traps mpls vpn
To enable the router to send Multiprotocol Label Switching (MPLS) Virtual Private Network (VPN) specific Simple Network Management Protocol (SNMP) notifications (traps and informs), use the snmp-server enable traps mpls vpn command in global configuration mode. To disable MPLS VPN specific SNMP notifications, use the no form of this command.
snmp-server enable traps mpls vpn [vrf-up] [vrf-down] [mid-threshold] [max-threshold] [illegal-label]
no snmp-server enable traps mpls vpn [vrf-up] [vrf-down] [mid-threshold] [max-threshold] [illegal-label]
Syntax Description
Defaults
This command is disabled by default.
Command Modes
Global configuration
Command History
Usage Guidelines
If this command is used without any of the optional keywords, all MPLS VPN notification types are enabled.
The values for mid-threshold and max-threshold are set using the maximum routes limit {warn-threshold | warn-only} command in VRF configuration mode.
Note
The warn-only keyword in the maximum routes command sets the mid-threshold only and imposes no limit for the maximum threshold.
The notification types described above are defined in the following MIB objects of the PPVPN-MPLS-VPN-MIB as follows:
•
mplsVrfIfUp
•
mplsVrfIfDown
•
mplsNumVrfRouteMidThreshExceeded
•
mplsNumVrfRouteMaxThreshExceeded
•
mplsNumVrfSecIllegalLabelThreshExceeded
Examples
In the following example, MPLS VPN trap notifications are sent to the host specified as 172.31.156.34 using the community string public if a VRF transitions from a down state to an up state or from an up state to a down state:
Router(config)# snmp-server enable traps mpls vpn vrf-up vrf-downRouter(config)# snmp-server host 172.31.156.34 traps public mpls-vpnRelated Commands
snmp-server host
To specify the recipient of a Simple Network Management Protocol (SNMP) notification, use the snmp-server host command in global configuration mode. To remove the specified host from the configuration, use the no form of this command.
snmp-server host host-addr [traps | informs] [version {1 | 2c | 3 [auth | noauth | priv]}] community-string [udp-port port] [notification-type] [vrf vrf-name]
no snmp-server host host [traps | informs]
Syntax Description
Defaults
This command is disabled by default. No notifications are sent.
If you enter this command with no keywords, the default is to send all trap types to the host. No informs will be sent to this host.
If no version keyword is present, the default is version 1. If version 3 is specified, but the security level is not specified, the default security level is noauth.
The no snmp-server host command with no keywords will disable traps, but not informs, to the host. In order to disable informs, use the no snmp-server host informs command.
The default UDP port is 162.
Note
If the community-string is not defined using the snmp-server community command prior to using this command, the default form of the snmp-server community command will automatically be inserted into the configuration. The password (community-string) used for this automatic configuration of the snmp-server community will be the same as specified in the snmp-server host command. This is the default behavior for Cisco IOS Release 12.0(3) and later.
Command Modes
Global configuration
Command History
Usage Guidelines
SNMP notifications can be sent as traps or inform requests. Traps are unreliable because the receiver does not send acknowledgments when it receives traps. The sender cannot determine if the traps were received. However, an SNMP entity that receives an inform request acknowledges the message with an SNMP response protocol data unit (PDU). If the sender never receives the response, the inform request can be sent again. Thus, informs are more likely to reach their intended destination.
However, informs consume more resources in the agent 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.
If you do not enter an snmp-server host command, no notifications are sent. To configure the router to send SNMP notifications, you must enter at least one snmp-server host command. If you enter the command with no keywords, all trap types are enabled for the host.
To enable multiple hosts, you must issue a separate snmp-server host command for each host. You can specify multiple notification types in the command for each host.
When multiple snmp-server host commands are given for the same host and kind of notification (trap or inform), each succeeding command overwrites the previous command. Only the last snmp-server host command will be in effect. For example, if you enter an snmp-server host informs command for a host and then enter another snmp-server host informs command for the same host, the second command will replace the first.
The snmp-server host command is used in conjunction with the snmp-server enable command. Use the snmp-server enable command to specify which SNMP notifications are sent globally. For a host to receive most notifications, at least one snmp-server enable command and the snmp-server host command for that host must be enabled.
However, some notification types cannot be controlled with the snmp-server enable command. For example, some notification types are always enabled. Other notification types are enabled by a different command. For example, the linkUpDown notifications are controlled by the snmp trap link-status command. These notification types do not require an snmp-server enable command.
The availability of a notification-type option depends on the router type and Cisco IOS software features supported on the router. For example, the envmon notification-type is available only if the environmental monitor is part of the system. To see what notification types are available on your system, use the command help ? at the end of the snmp-server host command.
The vrf keyword allows you to specify the notifications being sent to a specified IP address over a specific VRF. The VRF defines a VPN membership of a customer so data is stored using the VPN.
Regarding Notification Type Keywords
The notification-type keywords used in the snmp-server host command do not always match the keywords used in the corresponding snmp-server enable traps command. For example, the notification keyword applicable to MPLS traffic engineering tunnels is specified as mpls-traffic-eng (containing two dashes and no intervening spaces). The corresponding parameter in the snmp-server enable traps command is specified as mpls traffic-eng (containing an intervening space and a dash).
This syntax difference is necessary to ensure that the CLI interprets the notification type keyword of the snmp-server host command as a unified, single-word construct, which preserves the capability of the snmp-server host command to accept multiple notification-type keywords in the CLI command line. The snmp-server enable traps commands, however, often use two word constructs in order to provide hierarchical configuration options and to maintain consistency with the command syntax of related commands. Table 9 maps snmp-server enable traps commands to the keywords used in the snmp-server host command.
Table 9 Notification Keywords and Corresponding SNMP Enable Traps Commands
snmp enable traps Command snmp host command Keywordsnmp-server enable traps mpls ldp
mpls-ldp
snmp-server enable traps mpls traffic-eng1
mpls-traffic-eng
snmp-server enable traps mpls vpn
mpls-vpn
1 See the Cisco IOS Switching Services Command Reference for documentation of this command.
Examples
If you want to configure a unique SNMP community string for notifications, but you want to prevent SNMP polling access with this string, the configuration should include an access-list. In the following example, the community string is named comaccess and the access list is numbered 10:
Router(config)# snmp-server community comaccess ro 10Router(config)# snmp-server host 172.20.2.160 comaccessRouter(config)# access-list 10 deny anyThe following example shows how to send RFC 1157 SNMP traps to the host specified by the name myhost.cisco.com. Other traps are enabled, but only SNMP traps are sent because only snmp is specified in the snmp-server host command. The community string is defined as comaccess.
Router(config)# snmp-server enable trapsRouter(config)# snmp-server host myhost.cisco.com comaccess snmpThe following example shows how to send SNMP and Cisco environmental monitor enterprise-specific notifications to IP address 172.30.2.160:
Router(config)# snmp-server enable trapsRouter(config)# snmp-server host 172.30.2.160 public snmp envmonThe following example shows how to enable the router to send all notifications to the host identified as myhost.cisco.com using the community string public:
Router(config)# snmp-server enable trapsRouter(config)# snmp-server host myhost.cisco.com publicIn the following example, notifications will not be sent to any host. The BGP notifications are enabled for all hosts, but only the ISDN notifications are enabled for sending to a host.
Router(config)# snmp-server enable traps bgpRouter(config)# snmp-server host bob public isdnThe following example shows how to enable the router to send all inform requests to the host specified as myhost.cisco.com using the community string public:
Router(config)# snmp-server enable trapsRouter(config)# snmp-server host myhost.cisco.com informs version 2c publicThe following example shows how to send HSRP MIB notifications to the host specified as myhost.cisco.com. The community string is defined as public.
Router(config)# snmp-server enable hsrpRouter(config)# snmp-server host myhost.cisco.com traps version 2c public hsrpThe following example shows how to send all SNMP notifications to xyz.com over the VRF named trap-vrf:
Router(config)# snmp-server host xyz.com vrf trap-vrfRelated Commands
Glossary
AS—autonomous system. A collection of networks that share the same routing protocol and that are under the same system administration.
ASN.1—Abstract Syntax Notation One. OSI language for describing data types independent of particular computer structures and representation techniques. Described by ISO International Standard 8824.
BGP—Border Gateway Protocol. The exterior Border Gateway Protocol used to exchange routing information between routers in separate autonomous systems. BGP uses Transmission Control Protocol (TCP). Because TCP is a reliable protocol, BGP does not experience problems with dropped or fragmented data packets.
BGP prefixes—A route announcement using the BGP. A prefix is composed of a path of autonomous system (AS) numbers, indicating which networks the packet must pass through, and the IP block that is being routed. A BGP prefix would look something like: 701 1239 42 206.24.14.0/24. (The /24 part is referred to as a CIDR mask.) The /24 indicates that there are 24 ones in the netmask for this block starting from the left side. A /24 corresponds to the natural mask 255.255.255.0.
CEF—Cisco Express Forwarding. An advanced Layer 3 IP switching technology. CEF optimizes network performance and scalability for networks with large and dynamic traffic patterns.
CE router—customer edge router. A router on the border between a VPN provider and a VPN customer that belongs to the customer.
CIDR—classless interdomain routing. Technique supported by BGP4 and based on route aggregation. CIDR allows routers to group routes together to reduce the quantity of routing information carried by the core routers. With CIDR, several IP networks appear to networks outside the group as a single, larger entity. With CIDR, IP addresses and their subnet masks are written as four octets, separated by periods, followed by a forward slash and a two-digit number that represents the subnet mask.
community—In SNMP, a logical group of managed devices and NMSs in the same administrative domain.
community name—See community string.
community string—Text string that acts as a password and is used to authenticate messages sent between a managed station and a router containing an SNMP agent. The community string is sent in every packet between the manager and the client. Also called a community name.
IETF—Internet Engineering Task Force. Task force consisting of over 80 working groups responsible for developing Internet standards. The IETF operates under the auspices of ISOC. See also ISOC.
informs—A type of notification message that is more reliable than a conventional trap notification message, because the informs message notification requires acknowledgment, and a trap notification does not.
ISOC—Internet Society. International nonprofit organization, founded in 1992, that coordinates the evolution and use of the Internet. In addition, ISOC delegates authority to other groups related to the Internet, such as the IAB. ISOC is headquartered in Reston, Virginia (United States).
label—A short, fixed-length data construct that tells switching nodes how to forward data (packets or cells).
LDP—Label Distribution Protocol. A standard protocol between MPLS-enabled routers that is used for the negotiation of the labels (addresses) used to forward packets.
LFIB—Label Forwarding Information Base. In the Cisco Label Switching system, the data structure for storing information about incoming and outgoing tags (labels) and associated equivalent packets suitable for labeling.
LSR—label switching router. A device that forwards MPLS packets based on the value of a fixed-length label encapsulated in each packet.
MIB—Management Information Base. Database of network management information that is used and maintained by a network management protocol such as SNMP or CMIP. The value of a MIB object can be changed or retrieved using SNMP or CMIP commands, usually through a GUI network management system. MIB objects are organized in a tree structure that includes public (standard) and private (proprietary) branches.
MPLS—Multiprotocol Label Switching. A method for forwarding packets (frames) through a network. It enables routers at the edge of a network to apply labels to packets (frames). ATM switches or existing routers in the network core can switch packets according to the labels with minimal lookup overhead.
MPLS interface—An interface on which MPLS traffic is enabled.
MPLS VPN—Multiprotocol Label Switching Virtual Private Network. An IP network infrastructure delivering private network services over a public infrastructure using a layer 3 backbone. Using MPLS VPNs in a Cisco IOS network provides the capability to deploy and administer scalable Layer 3 VPN backbone services including applications, data hosting network commerce, and telephony services to business customers.
For an MPLS VPN Solution, an MPLS VPN is a set of provider edge routers that are connected by means of a common "backbone" network to supply private IP interconnectivity between two or more customer sites for a given customer. Each VPN has a set of provisioning templates and policies and can span multiple provider administrative domains (PADs).
notification—A message sent by an SNMP agent to a network management station, console, or terminal to indicate that a significant event within Cisco IOS has occurred. See also trap.
NMS—network management system. A powerful, well-equipped computer (typically an engineering workstation) that is used by a network administrator to communicate with other devices in the network. An NMS is typically used to manage network resources, gather statistics, and perform a variety of network administration and configuration tasks.
PE router—provider edge router. A router on the border between a VPN provider and a VPN customer that belongs to the provider.
PPVPN—Provider-Provisioned VPN. The name of the IETF working group that is developing the PPVPN-MPLS-VPN MIB.
QoS—quality of service. Measure of performance for a transmission system that reflects its transmission quality and service availability.
RSVP—Resource Reservation Protocol. Protocol for reserving network resources to provide quality of service guarantees to application flows.
RT—route target. An extended community attribute that identifies a group of routers and, in each router of that group, a subset of forwarding tables maintained by the router that can be populated with a BGP route carrying that extended community attribute. The RT is a 64-bit value by which Cisco IOS discriminates routes for route updates in VRFs.
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. See also SNMP2.
SNMP2—SNMP Version 2. Version 2 of the popular network management protocol. SNMP2 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. See also SNMP.
traffic engineering—The techniques and processes used to cause routed traffic to travel through the network on a path other than the one that would have been chosen if standard routing methods had been used.
trap—A message sent by an SNMP agent to a network management station, console, or terminal, indicating that a significant event occurred. Traps (notifications) are less reliable than inform requests, because the receiver does not send an acknowledgment when it receives a trap. The sender cannot determine if the trap was received. See also notification.
VPN—Virtual Private Network. A group of sites that, as the result of a set of administrative policies, are able to communicate with each other over a shared backbone network. A VPN is a secure IP-based network that shares resources on one or more physical networks. A VPN contains geographically dispersed sites that can communicate securely over a shared backbone. See also MPLS VPN.
VPN ID—A mechanism that identifies a VPN based on RFC 2685. A VPN ID consists of an Organizational Unique Identifier (OUI), a three-octet hex number assigned by the IEEE Registration Authority, and a VPN index, a four-octet hex number, which identifies the VPN within the company.
VRF—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.
Note
Refer to the Internetworking Terms and Acronyms for terms not included in this glossary.
Feedback




