The following parameters apply globally to the router's BFD process:

• ciscoBfdAdminStatus is The global administrative status of BFD in this router. The value enabled denotes that the BFD Process is active on at least one interface; disabled means it is not enabled on any interface.
• ciscoBfdVersionNumber is the current default version number of the BFD protocol.
• ciscoBfdSessNotificationsEnable enables the emission of ciscoBfdSessUp and ciscoBfdSessDown notifications when set to true (1); otherwise these notifications are not emitted.

The BFD Session Table specifies BFD session specific information and contains the following entries:

• ciscoBfdSessTable describes the BFD sessions.
• ciscoBfdSessEntry describes BFD session.
• ciscoBfdSessIndex contains an index used to represent a unique BFD session on this device. This is an Index and it does not show up in the MIB walk as an object.
• ciscoBfdSessApplicationId contains an index used to indicate a local application which owns or maintains this BFD session. This application ID provides a convenient way to segregate sessions by the applications that maintain them. The value corresponds to the ClientID in the output of the showbfdclient command.
• ciscoBfdSessDiscriminator specifies the local discriminator for this BFD session, used to uniquely identify it.
• ciscoBfdSessRemoteDiscr specifies the session discriminator chosen by the remote system for this BFD session.
• ciscoBfdSessUdpPort specifies the UDP Port for BFD. The default value is the well-known value for this port.
• ciscoBfdSessState specifies he perceived state of the BFD session. Valid values are adminDown (1), down (2), init (3), and up (4).
• ciscoBfdSessRemoteHeardFlag specifies status of BFD packet reception from the remote system. The flag is set to true (1) if the local system is actively receiving BFD packets from the remote system. The flag is set to false (0) if the local system has not received BFD packets recently (within the detection time) or if the local system is attempting to tear down the BFD session. This object is applicable only if the the session is runing at version 0. If the session is running version 1, that value will return false.
• ciscoBfdSessDiag displays a diagnostic code specifying the local system's reason for the last transition of the session from up (1) to some other state. This object is accessible only for notifications and will not display in the MIB walk for the ciscoBfdSessTable. The codes are:
  • BfdInterval--The delay in microseconds.
  • BfdDiag--A diagnostic code:
    • noDiagnostic(0)
    • controlDetectionTimeExpired(1)
    • echoFunctionFailed(2)
    • neighborSignaledSessionDown(3)
    • forwardingPlaneReset(4)
    • pathDown(5)
    • concatenatedPathDown(6)
    • administrativelyDown(7)
    • reverseConcatenatedPathDown (8)

• ciscoBfdSessOperMode specifies the current operating mode of the BFD session. The supported values are:
  • asyncModeWEchoFun (1),
  • asynchModeWOEchoFun (2),
• ciscoBfdSessDemandModeDesiredFlag indicates the local system's desire to use demand mode. It is set to true (1) if the local system wishes to use demand mode or false (0) if not. Demand Mode is not supported and therefore will always return a value of 0.
• ciscoBfdSessEchoFuncModeDesiredFlag indicates that the local system's desire to use echo mode. It is set to true (1) if the local system wishes to use Echo mode or false (0) if not.
• ciscoBfdSessControlPlanIndepFlag indicates if the local system's can function through a disruption of the control plane. It is set to true (1) if the local system BFD implementation is independent of the control plane. Otherwise, the value is set to false (0). This value will always return a value of 0.
• ciscoBfdSessAddrType specifies the IP address of the interface associated with this BFD session. Only values unknown (0), ipv4 (1) or ipv6 (2) are supported. A value of unknown (0) is allowed only when the outgoing interface is of type point-to-point, or when the BFD session is not associated with a specific interface.
• ciscoBfdSessAddr specifies the IP address of the interface associated with this BFD session. The value is set to zero when BFD session is not associated with a specific interface.
• ciscoBfdSessDesiredMinTxInterval specifies the minimum interval, in microseconds, that the local system would like to use when transmitting BFD control packets.
• ciscoBfdSessReqMinRxInterval specifies the minimum interval, in microseconds, between received BFD control packets the local system can support.
• ciscoBfdSessReqMinEchoRxInterval specifies the minimum interval, in microseconds, between received BFD Echo packets that this system can support. If echo mode is disabled for the configured interface for the session, this object will return value of 0.
• ciscoBfdSessDetectMult specifies the detect time multiplier.
• ciscoBfdSessStorType indicates the storage type for this object. The storage type for this entry is a read-only implementation that is always volatile.
• ciscoBfdSessRowStatus This object is a read-only implementation that is always active.
• ciscoBfdSessAuthPresFlag indicates the local system's desire to use Authentication. It is set to true (1) if the local system wishes the session to be authenticated or false (0) if not. Authentication is not supported and this object will always return a value of 0.
• ciscoBfdSessAuthenticationType specifies the authentication type used for this BFD session. This field is valid only when the authentication present bit is set. This object is not valid in BFD in Cisco IOS.

ciscoBfdSessPerfTable specifies BFD session performance counters and augments the ciscoBfdSessionTable. This table contains the following entries:

• ciscoBfdSessPerfEntry includes an entry created by a BFD-enabled node for every BFD session. ciscoBfdCounterDiscontinuityTime is used to indicate potential discontinuity for all counter objects in this table.
• ciscoBfdSessPerfPktIn specifies the total number of BFD messages received for this BFD session.
• ciscoBfdSessPerfPktOut specifies the total number of BFD messages sent for this BFD session.
• ciscoBfdSessUpTime specifies the value of sysUpTime on the most recent occasion at which the session came up. If no such up event exists, the value is zero.
• ciscoBfdSessPerfLastSessDownTime specifies the value of sysUpTime on the most recent occasion at which the last time communication was lost with the neighbor. If no such down event exists, the value is zero.
• ciscoBfdSessPerfLastCommLostDiag specifies the BFD diag code for the last time communication was lost with the neighbor. This object is not supported.
• ciscoBfdSessPerfSessUpCount specifies the number of times this session has gone into the up state since the router last rebooted.
• ciscoBfdSessPerfDiscTime indicates the value of sysUpTime on the most recent occasion at which any one or more of the session counters suffered a discontinuity. The relevant counters are the specific instances associated with this BFD session of any Counter32 object contained in the BfdSessPerfTable. If no such discontinuities have occurred since the last re-initialization of the local management subsystem, then the value is zero. This object is not supported.
• ciscoBfdSessPerfPktInHC represents the total number of BFD messages received for this BFD session. It must be equal to the least significant 32 bits of ciscoBfdSessPerfPktIn if ciscoBfdSessPerfPktInHC is supported according to the rules spelled out in RFC2863.
• ciscoBfdSessPerfPktOutHC represents the total number of BFD messages transmitted for this BFD session. It must be equal to the least significant 32 bits of ciscoBfdSessPerfPktIn if ciscoBfdSessPerfPktOutHC is supported according to the rules spelled out in RFC2863.

The BFD Session Mapping Table maps the complex indexing of the BFD sessions to the flat BFDIndex used in the ciscoBfdSessionTable. If the value of the ciscoBfdSessAddr (an OID) has more that 111 sub-identifiers, then OIDs of column instances in this table have more than 128 sub-identifiers and cannot be accessed using SNMPv1, SNMPv2c, or SNMPv3. The BFD Session Mapping table contains the following entries:

• ciscoBfdSessMapEntry describes BFD session that is mapped to this index. If the value of the mplsInSegmentMapLabelPtrIndex (an OID) has more that 111 sub-identifiers, then OIDs of column instances in this table have more than 128 sub-identifiers and cannot be accessed using SNMPv1, SNMPv2c, or SNMPv3.
• ciscoBfdSessMapBfdIndex specifies the BfdIndex referred to by the indexes of this row. In essence, a mapping is provided between these indexes and the ciscoBfdSessTable. This is Index and does not show up in the MIB walk as an object.

See the MIB Walk for BFD MIB: Example in the configuration example section for an example of the mapping.

Notification contains the following entries. The range mode for this notification is not supported. Therefore, only a single notification is sent for one of the ciscoBfdSessTable entries representing this session.

• ciscoBfdSessUp generates a notfication when the ciscoBfdSessState object for one or more entries in ciscoBfdSessTable is about to enter the up (4) state from some other state. The value of ciscoBfdSessDiag is set equal to noDiagnostic(0).
• ciscoBfdSessDown generates a notification when the ciscoBfdSessState object for one or more entries in ciscoBfdSessTable is about to enter the down (2) or adminDown (1) states from some other state. The values of ciscoBfdSessDiag returns the Diag code providing the reason for this new state (that is, pathDown (5) or administrativelyDown (7)).

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 that SNMP manager and agent entities operating in a VPN environment agree on mapping between the SNMP security name and the VPN name. This mapping is created by you using different contexts for the SNMP data of different VPNs, which is accomplished through the configuration of the SNMP View-based Access Control Model MIB (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 within the context of only that VPN.

SNMP request messages undergo three phases of security and access control before a response message is sent back with the object values within a VPN context:

• The first security phase is authentication of the username. During this phase, the user is authorized for SNMP access.
• The second phase is access control. During this phase, the user is authorized for SNMP access to the group objects in the requested SNMP context.
• In the third phase, the user can access a particular instance of a table entry. With this third phase, complete retrieval can be based on the SNMP context name.

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

The VPN Aware BFD MIB feature supports an SNMP query to the BFD MIB for both global and VPN contexts. You can enter BFD queries on any VRF and on the core (global context). A query can differentiate between BFD sessions from different VPNs. BFD session information for a VPN stays in the context of that VPN. Therefore, the information from one VPN is not available to a user of a different VPN.

In an MPLS VPN, a service provider edge router (PE) might contain VRFs for several VPNs and a global routing table. To set up separate BFD processes for different VPNs on the same device, configure each VPN with a unique securityName, contextName, and View-based Access Control Model (VACM) view. The VPN securityName must be configured for the BFD MIB.

Note	To verify BFD session information for a specific VPN, use the show bfd neighbor vrfvpn-namedetail command.

The VPN Aware BFD MIB feature supports BFD notifications for multiple VPN contexts for BFD. BFD notifications can be generated for the global context and for different VPNs. You can cause notifications be sent to different NMS hosts for different BFD contexts. BFD notifications associated with a specific VRF are sent to the NMS designated for that VRF. BFD global notifications are sent to the NMS configured to receive global traps.

To enable BFD context notifications for the VPN Aware BFD MIB feature, use either the SNMP ciscoBfdSessNotificationEnable object (in the global BFD context only) or the following extended global configuration commands.

To enable BFD notifications for the global context, use the following commands on a provider edge (PE) router:

Router(config)# snmp-server host host-address traps community
Router(config)# snmp-server enable traps bfd

To enable BFD notifications for a VPN context, use the following commands:

Router(config)# snmp-server host
 host-address vrf vrf-name
 version {v1 |v2c |v3} community community-string
 udp-port upd-port bfd
Router(config)# snmp-server enable traps bfd