Monitoring MPLS VPNs with MIBs

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).

The table below lists the MIB objects and their functions for this table.

Router(config)# ip vrf
 vrf-name
Router(config-vrf)# description
 
vrf-description

Router(config)# ip vrf 
vrf-name
Router(config-vrf)# rd
 
route-distinguisher

Router(config)# ip vrf vpn1
Router(config-vrf)# maximum routes
 1000 50

Router(config-vrf)# maximum routes
 1000 warn-only

Router(config)# ip vrf vpn2

In Cisco software, 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. The figure below 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

The table below lists the MIB objects and their functions for this table.

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.

The figure below 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 the figure, 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

The table below lists the MIB objects and their functions for this table.

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

The table below lists the MIB objects and their functions for this table.

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 augmentsthe mplsVpnVrfTable and has the same indexing.

The table below lists the MIB objects and their functions for this table.

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.

The table below lists the MIB objects and their functions for this table.

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 the figure above:

• With the show ip route vrf vpn1 command, you would see results like the following:

Router# show ip route vrf vpn1
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area 
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
i - 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 subnets
B       10.3.0.0 [200/0] via 192.168.2.1, 04:36:33
C       10.1.0.0/16 is directly connected, Ethernet1
C       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 vpn2
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area 
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
i - 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 subnets
B       172.16.2.0 [200/0] via 192.168.2.1, 04:36:33
C       172.16.1.0 is directly connected, ATM 3/0

The figure below 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 and, therefore, are always 0.

The table below 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.

The following notifications of the PPVPN-MPLS-VPN MIB are supported:

• 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-name
Router(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-only

This notification is sent to the NMS only at the time the threshold is exceeded. (See the figure below 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 routescommands:

Router(config)# ip vrf
 vrf-name
Router(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 mplsNumVrfRouteMaxThreshExceedednotification is not sent until the number of routes falls below the maximum threshold and reaches the maximum threshold again. (See the figure below 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-thresholdcommand. 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.

The following notification of the CISCO-IETF-PPVPN-MPLS-VPN MIB is supported in Cisco IOS Release 12.0(30)S:

• cMplsNumVrfRouteMaxThreshCleared--Generated and sent when the number of routes on a VRF attempts to exceed the maximum number of routes and then drops below the maximum number of routes. If youattempt to create a route on a VRF that already contains the maximum number of routes, the mplsNumVrfRouteMaxThreshExceeded notification is sent (if enabled). When you remove routes from the VRF so that the number of routes falls below the set limit, the cMplsNumVrfRouteMaxThreshCleared notification is sent. You can clear all routes from the VRF by using the clear ip route vrf command. (See the figure below to see when the cMplsNumVrfRouteMaxThreshCleared notification is sent.)

Figure 5

Comparison of Warning and Maximum Thresholds

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
  • 6 for cMplsNumVrfRouteMaxThreshCleared

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.

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 software 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.