MPLS/BGP Layer 3 Virtual Private Network (VPN) Management Information Base
Extracted elements (26)
mplsL3VpnNotificationEnable defaults to false so that notifications are not generated until an operator explicitly enables them, matching the recommendation in RFC 3413 that notifications are under the ultimate control of the MIB module.
mplsL3VpnVrfConfRteMxThrshTime defaults to 0, meaning the agent issues only a single max-threshold notification and suppresses re-notification until routes fall below the threshold. This prevents continuous notification storms when routes are repeatedly added to a full VRF.
Each entry in mplsL3VpnIfConfTable is meant to correspond to an entry in the Interfaces MIB (RFC 2863). Traffic counters are deliberately absent from this MIB to avoid overlap with IF-MIB counters.
The mplsL3VpnVrfRteTable contains both BGP and IGP routes, as both may appear in the same VRF. The table references RFC 2096 (IP Forwarding Table MIB) for its routing entry model.
Deployment of SNMP versions prior to SNMPv3 is NOT RECOMMENDED. Instead, SNMPv3 with cryptographic security (authentication and privacy) is RECOMMENDED.
For mplsL3VpnVrfRouteMidThreshExceeded, a single notification MUST be generated when the mid-level route threshold is exceeded, and no further notifications of this type should be issued until mplsL3VpnVrfPerfCurrNumRoutes falls below mplsL3VpnVrfConfMidRteThresh.
If mplsL3VpnIfConfRowStatus row creation succeeds the interface will have been associated with the specified VRF; otherwise the agent MUST not allow the association. When a row is in active(1) state, only mplsL3VpnIfConfStorageType and mplsL3VpnIfConfRowStatus may be modified.
mplsL3VpnVrfConfMaxRoutes MUST be less than or equal to mplsL3VpnVrfConfMaxPossRts unless it is set to 0.
mplsL3VpnVrfName SHOULD be unique throughout the MPLS domain. It is strongly recommended that all sites supporting VRFs that are part of the same VPN use the same naming convention.
SNMPv3 VACM and USM MUST be used with any SNMPv3 agent that implements this MIB module, per the security considerations of RFC 3410.
When a label stack is created for a VRF route, the implementation MUST establish the associated cross-connect entry in mplsXCTable and then set mplsL3VpnVrfRteXCPointer to that index. Changes to the cross-connect object MUST automatically be reflected in this pointer.
mplsL3VpnIfVpnRouteDistProtocol is a BITS object encoding the PE-CE routing protocol(s) in use: none(0), bgp(1), ospf(2), rip(3), isis(4), static(5), other(6). Multiple bits may be set simultaneously.
mplsL3VpnVrfOperStatus reports VRF operational state as up(1) when at least one associated interface has ifOperStatus up(1), and down(2) when no such interface exists or no interfaces are associated.
mplsL3VpnVrfRteTable indexes route entries by VRF name, destination address type, destination, prefix length, policy OID, next-hop type, and next-hop address. Implementers must ensure OIDs of column instances do not exceed 128 sub-identifiers to maintain SNMPv1/v2c/v3 accessibility.
mplsL3VpnVrfRteXCPointer links a VRF route entry to its label stack by indexing into the mplsXCTable in MPLS-LSR-STD-MIB. The value 0x00 indicates no label stack is currently associated with the route.
Six SNMP notifications are defined: mplsL3VpnVrfUp, mplsL3VpnVrfDown, mplsL3VpnVrfRouteMidThreshExceeded, mplsL3VpnVrfNumVrfRouteMaxThreshExceeded, mplsL3VpnNumVrfSecIllglLblThrshExcd, and mplsL3VpnNumVrfRouteMaxThreshCleared. All are gated by mplsL3VpnNotificationEnable.
The MPLS-L3VPN-STD-MIB defines five core tables: mplsL3VpnVrfTable (VRF instances), mplsL3VpnIfConfTable (VRF-enabled interfaces), mplsL3VpnVrfPerfTable (performance counters), mplsL3VpnVrfRouteTable (VRF routing entries), and mplsL3VpnVrfRTTable (route target associations). Together these tables provide full configuration and monitoring of MPLS L3VPN on an LSR.
The MplsL3VpnName textual convention defines a VRF identifier as an OCTET STRING of SIZE(0..31). It SHOULD be unique throughout the MPLS domain and MAY be set to the VPN ID as defined in RFC 2685.
The MplsL3VpnRouteDistinguisher textual convention encodes a route distinguisher or route target as an OCTET STRING of SIZE(0..256), as defined in RFC 4364.
The MplsL3VpnRtType textual convention classifies route target usage as import(1), export(2), or both(3), providing the type index for entries in mplsL3VpnVrfRTTable.
The mplsL3VpnVrfSecTable augments mplsL3VpnVrfTable with two security counters per VRF: mplsL3VpnVrfSecIllegalLblVltns (count of illegally received labels) and mplsL3VpnVrfSecDiscontinuityTime (sysUpTime of last counter discontinuity).
IANA assigned the OID { mplsStdMIB 11 } to the MPLS-L3VPN-STD-MIB module. New assignments under mplsStdMIB require a Standards Action as specified in RFC 2434.
Read access to mplsL3VpnVrfTable and mplsL3VpnIfConfTable exposes VRF topology, interface linkages, and performance statistics. Administrators should consider these objects sensitive, control GET/NOTIFY access, and consider encrypting values in transit.
The mplsL3VpnVrfSecIllegalLblVltns counter and mplsL3VpnNumVrfSecIllglLblThrshExcd notification provide per-VRF detection of illegal label violations; the threshold is configurable via mplsL3VpnIllLblRcvThrsh.
Unauthorized write access to mplsL3VpnVrfTable, mplsL3VpnIfConfTable, and mplsL3VpnVrfRouteTable could disrupt traffic on provisioned VPNs. SNMPv3 with VACM and USM MUST be used; SET operations in non-secure environments without protection can have disastrous network effects.
VRF operational status transitions between up(1) and down(2). It enters up(1) when at least one associated interface has ifOperStatus up(1); it enters down(2) when all associated interfaces are down or when no interfaces are associated. Transitions trigger mplsL3VpnVrfUp and mplsL3VpnVrfDown notifications.