Downloads |
 Feedback
|
Table Of Contents
Bidirectional Forwarding Detection
Prerequisites for Bidirectional Forwarding Detection
Restrictions for Bidirectional Forwarding Detection
Information About Bidirectional Forwarding Detection
BFD Support on Cisco 12000 Routers
BFD Support for Nonbroadcast Media Interfaces
BFD Support for VPN Routing and Forwarding Interfaces
BFD Support for Nonstop Forwarding with Stateful Switchover
BFD Support for Stateful Switchover
BFD Support for Static Routing
BFD Control Channel over VCCV—Support for ATM Pseudowire
Benefits of Using BFD for Failure Detection
How to Configure Bidirectional Forwarding Detection
Configuring BFD Session Parameters on the Interface
Configuring BFD Support for Dynamic Routing Protocols
Configuring BFD Support for BGP
Configuring BFD Support for EIGRP
Configuring BFD Support for IS-IS
Configuring BFD Support for OSPF
Configuring BFD Support for HSRP
Configuring BFD Support for Static Routing
Configuring the BFD Slow Timer
Disabling BFD Echo Mode Without Asymmetry
Creating and Configuring BFD Templates
Configuring BFD Control Channel over VCCV—Support for ATM Pseudowire
Monitoring and Troubleshooting BFD
Monitoring and Troubleshooting BFD for Cisco 7600 Series Routers
Monitoring and Troubleshooting BFD for Cisco 12000 Series Routers
Monitoring and Troubleshooting BFD for Cisco 10720 Internet Routers
Configuration Examples for Bidirectional Forwarding Detection
Example: Configuring BFD in an EIGRP Network with Echo Mode Enabled by Default
Example: Configuring BFD in an OSPF Network
Example: Configuring BFD in a BGP Network
Example: Configuring BFD in an IS-IS Network
Example: Configuring BFD in an HSRP Network
Example: Configuring BFD Support for Static Routing
Example: Configuring BFD Control Channel over VCCV—Support for ATM Pseudowire
Feature Information for Bidirectional Forwarding Detection
Bidirectional Forwarding Detection
First Published: January 14, 2008Last Updated: March 18, 2011This document describes how to enable the Bidirectional Forwarding Detection (BFD) protocol. BFD is a detection protocol designed to provide fast forwarding path failure detection times for all media types, encapsulations, topologies, and routing protocols. In addition to fast forwarding path failure detection, BFD provides a consistent failure detection method for network administrators. Because the network administrator can use BFD to detect forwarding path failures at a uniform rate, rather than the variable rates for different routing protocol hello mechanisms, network profiling and planning will be easier, and reconvergence time will be consistent and predictable.
Finding Feature Information
Your software release may not support all the features documented in this module. For the latest feature information and caveats, see the release notes for your platform and software release. To find information about the features documented in this module, and to see a list of the releases in which each feature is supported, see the "Feature Information for Bidirectional Forwarding Detection" section.
Use Cisco Feature Navigator to find information about platform support and Cisco 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
•
Prerequisites for Bidirectional Forwarding Detection
•
•
•
•
•
Prerequisites for Bidirectional Forwarding Detection
•
•
•
•
•
–
–
–
See the "Configuring Synchronous Ethernet on the Cisco 7600 Router with ES+ Line Card" section of the Cisco 7600 Series Ethernet Services Plus (ES+) and Ethernet Services Plus T (ES+T) Line Card Configuration Guide for more information about prerequisites for hardware offload.
Restrictions for Bidirectional Forwarding Detection
•
•
•
•
•
•
•
•
•
•
•
•
•
Cisco IOS software release notes for your software version.•
•
•
•
00:01:24: %OSPF-5-ADJCHG: Process 100, Nbr 10.0.0.0 on RPR-IEEE1/1 from LOADING to FULL, Loading Done 00:01:24: %BFD-5-SESSIONLIMIT: Attempt to exceed session limit of 100 neighbors.•
–
–
–
•
•
•
BFD Control Channel over VCCV—Support for ATM Pseudowire
•
•
•
•
•
Cisco IOS Release 12.2(33)SXI2 and Cisco Catalyst 6500 Series Switches
•
•
–
–
–
–
•
•
•
Cisco IOS Release 15.1(2)S and ES+ Line Cards for Cisco 7600 Series Routers
Cisco IOS Release 15.1(2)S, supports offloading BFD sessions to ES+ line cards on Cisco 7600 series routers. See the "Configuring Synchronous Ethernet on the Cisco 7600 Router with ES+ Line Card" section of the Cisco 7600 Series Ethernet Services Plus (ES+) and Ethernet Services Plus T (ES+T) Line Card Configuration Guide for more information about restrictions for hardware offload.
Note
Information About Bidirectional Forwarding Detection
•
BFD Operation
BFD provides a low-overhead, short-duration method of detecting failures in the forwarding path between two adjacent routers, including the interfaces, data links, and forwarding planes.
BFD is a detection protocol that you enable at the interface and routing protocol levels. Cisco supports the BFD asynchronous mode, which depends on the sending of BFD control packets between two systems to activate and maintain BFD neighbor sessions between routers. Therefore, in order for a BFD session to be created, you must configure BFD on both systems (or BFD peers). Once BFD has been enabled on the interfaces and at the router level for the appropriate routing protocols, a BFD session is created, BFD timers are negotiated, and the BFD peers will begin to send BFD control packets to each other at the negotiated interval.
This section includes the following subsections:
•
•
•
•
•
•
•
Neighbor Relationships
BFD provides fast BFD peer failure detection times independently of all media types, encapsulations, topologies, and routing protocols BGP, EIGRP, IS-IS, and OSPF. By sending rapid failure detection notices to the routing protocols in the local router to initiate the routing table recalculation process, BFD contributes to greatly reduced overall network convergence time. Figure 1 shows a simple network with two routers running OSPF and BFD. When OSPF discovers a neighbor (1) it sends a request to the local BFD process to initiate a BFD neighbor session with the OSPF neighbor router (2). The BFD neighbor session with the OSPF neighbor router is established (3).
Figure 1 Establishing a BFD Neighbor Relationship
Figure 2 shows what happens when a failure occurs in the network (1). The BFD neighbor session with the OSPF neighbor router is torn down (2). BFD notifies the local OSPF process that the BFD neighbor is no longer reachable (3). The local OSPF process tears down the OSPF neighbor relationship (4). If an alternative path is available, the routers will immediately start converging on it.
Figure 2 Tearing Down an OSPF Neighbor Relationship
A routing protocol needs to register with BFD for every neighbor it acquires. Once a neighbor is registered, BFD initiates a session with the neighbor if a session does not already exist.
OSPF registers with BFD when:
•
•
On broadcast interfaces, OSPF establishes a BFD session only with the designated router (DR) and backup designated router (BDR), but not between any two routers in DROTHER state.
BFD Detection of Failures
Once a BFD session has been established and timer negations are complete, BFD peers send BFD control packets that act in the same manner as an IGP hello protocol to detect liveliness, except at a more accelerated rate. The following information should be noted:
•
•
•
•
BFD Version Interoperability
Cisco IOS Release 12.4(9)T supports BFD Version 1 as well as BFD Version 0. All BFD sessions come up as Version 1 by default and will be interoperable with Version 0. The system automatically performs BFD version detection, and BFD sessions between neighbors will run in the highest common BFD version between neighbors. For example, if one BFD neighbor is running BFD Version 0 and the other BFD neighbor is running Version 1, the session will run BFD Version 0. The output from the show bfd neighbors [details] command will verify which BFD version a BFD neighbor is running.
See the "Example: Configuring BFD in an EIGRP Network with Echo Mode Enabled by Default" section for an example of BFD version detection.
BFD Support on Cisco 12000 Routers
The Cisco 12000 series routers support distributed BFD to take advantage of its distributed Route Processor (RP) and line card (LC) architecture. The BFD tasks will be divided and assigned to the BFD process on the RP and LC, as described in the following sections:
BFD Process on the RP
Client Interaction
The BFD process on the RP will handle the interaction with clients, which create and delete BFD sessions.
Session Management for the BFD Process on the RP
The BFD RP process will primarily own all BFD sessions on the router. It will pass the session creation and deletion requests to the BFD processes on all LCs. BFD LC sessions will have no knowledge of sessions being added or deleted by the clients. Only the BFD RP process will send session addition and deletion commands to the BFD LC process.
Session Database Management
The BFD RP process will maintain a database of all the BFD sessions on the router. This database will contain only the minimum required information.
Process EXEC Commands
The BFD RP process services the BFD show commands.
BFD Process on the LC
Session Management for the BFD Process on the LC
The BFD LC process manages sessions, adds and deletes commands from the BFD RP process, and creates and deletes new sessions based on the commands. In the event of transmit failure, receive failure, or session-down detection, the LC BFD instance will immediately notify the BFD RP process. It will also update transmit and receive counters. The BFD session is maintained completely on the LC. BFD control packets are received and processed, as well as sent, from the LC itself.
Session Database Management
The BFD LC process maintains a database of all the BFD sessions hosted on the LC.
Receive and Transmit
The BFD LC process is responsible for transmitting and receiving BFD packets for the sessions on the LC.
BFD Session Limits
In Cisco IOS Release 12.2(33)SRC, the number of BFD sessions that can be created has been increased to 128.
BFD Support for Nonbroadcast Media Interfaces
In Cisco IOS Release 12.2(33)SRC, the BFD feature is supported on nonbroadcast media interfaces including ATM, POS, serial, and VLAN interfaces. BFD support also extends to ATM, Frame Relay (FR), POS, and serial subinterfaces.
The bfd interval command must be configured on the interface to initiate BFD monitoring.
BFD Support for VPN Routing and Forwarding Interfaces
The BFD feature is extended in Cisco IOS Release 12.2(33)SRC to be VPN Routing and Forwarding (VRF) aware to provide fast detection of routing protocol failures between provider edge (PE) and customer edge (CE) routers.
BFD Support for Nonstop Forwarding with Stateful Switchover
Typically, when a networking device restarts, all routing peers of that device detect that the device went down and then came back up. This transition results in a routing flap, which could spread across multiple routing domains. Routing flaps caused by routing restarts create routing instabilities, which are detrimental to the overall network performance. Nonstop forwarding (NSF) helps to suppress routing flaps in devices that are enabled with stateful switchover (SSO), thereby reducing network instability.
NSF allows for the forwarding of data packets to continue along known routes while the routing protocol information is being restored after a switchover. With NSF, peer networking devices do not experience routing flaps. Data traffic is forwarded through intelligent line cards or dual forwarding processors while the standby RP assumes control from the failed active RP during a switchover. The ability of line cards and forwarding processors to remain up through a switchover and to be kept current with the Forwarding Information Base (FIB) on the active RP is key to NSF operation.
In devices that support dual RPs, SSO establishes one of the RPs as the active processor; the other RP is designated as the standby processor, and then synchronizes information between them. A switchover from the active to the standby processor occurs when the active RP fails, when it is removed from the networking device, or when it is manually taken down for maintenance.
In Cisco IOS Release 12.2(33)SRC, BFD sessions are placed in an "Admin Down" state during a planned switchover. The BFD configuration is synched from the active to standby processor, and all BFD clients re-register with the BFD process on the standby processor.
In Cisco IOS Release 12.2(33)SB, BFD is not SSO-aware, and it is not supported with NSF/SSO. These features should not be used together. Enabling BFD along with NSF/SSO causes the nonstop forwarding capability to break during failover because BFD adjacencies are not maintained and the routing clients are forced to mark down adjacencies and reconverge.
BFD Support for Stateful Switchover
The BFD protocol provides short-duration detection of failures in the path between adjacent forwarding engines. In network deployments that use dual RP routers or switches (to provide redundancy), the routers have a graceful restart mechanism that protects the forwarding state during a switchover between the active RP and the standby RP.
The dual RPs have variable switchover times that depend on the ability of the hardware to detect a communication failure. When BFD is running on the RP, some platforms are not able to detect a switchover before the BFD protocol times out; these platforms are referred to as slow switchover platforms.
Stateful BFD on the Standby RP
To ensure a successful switchover to the standby RP, the BFD protocol uses checkpoint messages to send session information from the active RP Cisco IOS instance to the standby RP Cisco IOS instance. The session information includes local and remote discriminators, adjacent router timer information, BFD setup information, and session-specific information such as the type of session and the session version. In addition, the BFD protocol sends session creation and deletion checkpoint messages to create or delete a session on the standby RP.
The BFD sessions on the standby RP do not receive or send packets and do not process expired timers. These sessions wait for a switchover to occur and then send packets for any active sessions so that sessions do not time out on adjacent routers.
When the BFD protocol on the standby RP is notified of a switchover it changes its state to active, registers itself with Cisco Express Forwarding so that it can receive packets, and then sends packets for any elements that have expired.
BFD also uses checkpoint messages to ensure that sessions created by clients on the active RP are maintained during a switchover. When a switchover occurs, BFD starts an SSO reclaim timer. Clients must reclaim their sessions within the duration specified by the reclaim timer or else the session is deleted.
Timer values are different based on the number of BFD sessions and the platform.
Table 1 describes the timer values on Cisco 7600 series routers.
Note
Note
Table 2 describes the timer values on Cisco ASR 1000 Series Aggregation Services Routers.
Note
Table 3 describes the timer values on Cisco 6500 series routers.
Note
Table 4 describes the timer values on a Cisco 10000 series routers.
Note
BFD Support for Static Routing
Unlike dynamic routing protocols, such as OSPF and BGP, static routing has no method of peer discovery. Therefore, when BFD is configured, the reachability of the gateway is completely dependent on the state of the BFD session to the specified neighbor. Unless the BFD session is up, the gateway for the static route is considered unreachable, and therefore the affected routes will not be installed in the appropriate Routing Information Base (RIB).
For a BFD session to be successfully established, BFD must be configured on the interface on the peer and there must be a BFD client registered on the peer for the address of the BFD neighbor. When an interface is used by dynamic routing protocols, the latter requirement is usually met by configuring the routing protocol instances on each neighbor for BFD. When an interface is used exclusively for static routing, this requirement must be met by configuring static routes on the peers.
If a BFD configuration is removed from the remote peer while the BFD session is in the up state, the updated state of the BFD session is not signaled to IPv4 static. This will cause the static route to remain in the RIB. The only workaround is to remove the IPv4 static BFD neighbor configuration so that the static route no longer tracks BFD session state. Also, if you change the encapsulation type on a serial interface to one that is unsupported by BFD, BFD will be in a down state on that interface. The workaround is to shut down the interface, change to a supported encapsulation type, and then reconfigure BFD.
A single BFD session can be used by an IPv4 static client to track the reachability of next hops through a specific interface. You can assign a BFD group for a set of BFD-tracked static routes. Each group must have one active static BFD configuration, one or more passive BFD configurations, and the corresponding static routes to be BFD-tracked. Nongroup entries are BFD-tracked static routes for which a BFD group is not assigned. A BFD group must accommodate static BFD configurations that can be part of different VRFs. Effectively, the passive static BFD configurations need not be in the same VRF as that of the active configuration.
For each BFD group, there can be only one active static BFD session. You can configure the active BFD session by adding a static BFD configuration and a corresponding static route that uses the BFD configuration. The BFD session in a group is created only when there is an active static BFD configuration and the static route that uses the static BFD configuration. When the active static BFD configuration or the active static route is removed from a BFD group, all the passive static routes are withdrawn from the RIB. Effectively, all the passive static routes are inactive until an active static BFD configuration and a static route to be tracked by the active BFD session are configured in the group.
Similarly, for each BFD group, there can be one or more passive static BFD configurations and their corresponding static routes to be BFD-tracked. Passive static session routes take effect only when the active BFD session state is reachable. Though the active BFD session state of the group is reachable, the passive static route is added to the RIB only if the corresponding interface state is up. When a passive BFD session is removed from a group, it will not affect the active BFD session if one existed, or the BFD group reachability status.
BFD Control Channel over VCCV—Support for ATM Pseudowire
Multiprotocol Label Switching (MPLS) pseudowires enable L2 traffic to be carried over an IP/MPLS core network. The BFD control channel over VCCV—Support for ATM Pseudowires feature provides operations and management (OAM) functions for MPLS pseudowires.
Note
The BFD detection protocol can be used to provide OAM functionality to the MPLS protocol. VCCV provides a control channel associated with the pseudowire to provide OAM functions over that pseudowire. BFD can use the VCCV control channel as a pseudowire fault mechanism to detect dataplane failures. BFD can also use the VCCV control channel to carry the fault status of an attachment circuit (AC).
MPLS pseudowires can dynamically signal or statically configure virtual circuit (VC) labels. In dynamically signaled pseudowires, the control channel (CC) types and connection verification (CV) types are also signaled. In statically configured pseudowires, the CC and CV types must be configured on both ends of the pseudowire.
The CC types define whether VCCV packets are in-band or out-of-band for the pseudowire. The CV types define whether BFD monitoring is required for the pseudowire. If BFD monitoring is required for the pseudowire, the CV types also define how the BFD packets are encapsulated and whether BFD provides status signaling functionality.
Any protocol that requires BFD monitoring must register with BFD as a client. For example, the Xconnect protocol registers as a BFD client, and BFD assigns a client ID to Xconnect. Xconnect uses this client ID to create the BFD sessions that monitor the pseudowire.
BFD can detect forwarding failures (end-to-end) in the pseudowire path. When BFD detects a failure in the pseudowire forwarding path it notifies the Xconnect client that created the session. In addition, BFD can signal the status in any concatenated path, or AC, to the remote device where the BFD session is terminated.
Figure 3 shows a dynamically signaled MPLS pseudowire carrying an ATM payload. In this example, BFD monitoring of the pseudowire occurs from the Node B device to the PE device. BFD also monitors the signal status of the ACs between the PE and CE2 device, and between the Node B and CE1 device.
Figure 3
MPLS ATM Pseudowire
Benefits of Using BFD for Failure Detection
When you deploy any feature, it is important to consider all the alternatives and be aware of any trade-offs being made.
The closest alternative to BFD in conventional EIGRP, IS-IS, and OSPF deployments is the use of modified failure detection mechanisms for EIGRP, IS-IS, and OSPF routing protocols.
If you set EIGRP hello and hold timers to their absolute minimums, the failure detection rate for EIGRP falls to within a one- to two-second range.
If you use fast hellos for either IS-IS or OSPF, these Interior Gateway Protocol (IGP) protocols reduce their failure detection mechanisms to a minimum of one second.
There are several advantages to implementing BFD over reduced timer mechanisms for routing protocols:
•
•
•
How to Configure Bidirectional Forwarding Detection
You start a BFD process by configuring BFD on the interface. When the BFD process is started, no entries are created in the adjacency database; in other words, no BFD control packets are sent or received. BFD echo mode, which is supported in BFD Version 1 for Cisco IOS Release 12.4(9)T, is enabled by default. BFD echo packets are sent and received, in addition to BFD control packets. The adjacency creation takes places once you have configured BFD support for the applicable routing protocols. This section contains the following procedures:
•
•
•
•
•
•
•
Configuring BFD Session Parameters on the Interface
The steps in this procedure show how to configure BFD on the interface by setting the baseline BFD session parameters on an interface. Repeat the steps in this procedure for each interface over which you want to run BFD sessions to BFD neighbors.
SUMMARY STEPS
1.
2.
3.
4.
5.
DETAILED STEPS
Configuring BFD Support for Dynamic Routing Protocols
You can enable BFD support for dynamic routing protocols at the router level to enable BFD support globally for all interfaces or you can configure BFD on a per-interface basis at the interface level.
For Cisco IOS Release 12.2(18)SXE, you may configure BFD support for one or more of the following routing protocols: EIGRP, IS-IS, and OSPF.
For Cisco IOS Releases 12.2(33)SRA, you may configure BFD support for one or more of the following routing protocols: EIGRP, IS-IS, and OSPF.
For Cisco IOS Releases 12.2(33)SRB, you may configure BFD support for one or more of the following routing protocols: BGP, EIGRP, IS-IS, and OSPF.
For Cisco IOS Release 12.2(33)SRC, you may configure BFD support for static routing.
For Cisco IOS Releases 12.0(31)S and 12.4(4)T, you may configure BFD support for one or more of the following routing protocols: BGP, IS-IS, and OSPF.
For Cisco IOS Release 12.0(32)S, for the Cisco 10720 platform, you may configure BFD for one or more of the following routing protocols: BGP, IS-IS, and OSPF.
For Cisco IOS Release 12.4(11)T, BFD support for HSRP was introduced.
This section describes the following procedures:
•
•
•
•
•
Configuring BFD Support for BGP
This section describes the procedure for configuring BFD support for BGP so that BGP is a registered protocol with BFD and will receive forwarding path detection failure messages from BFD.
Prerequisites
BGP must be running on all participating routers.
The baseline parameters for BFD sessions on the interfaces over which you want to run BFD sessions to BFD neighbors must be configured. See the "Configuring BFD Session Parameters on the Interface" section for more information.
Note
SUMMARY STEPS
1.
2.
3.
4.
5.
6.
7.
DETAILED STEPS
What to Do Next
See the "Monitoring and Troubleshooting BFD" section for more information on monitoring and troubleshooting BFD. If you want to configure BFD support for another routing protocol, see the following sections:
•
•
•
•
Configuring BFD Support for EIGRP
This section describes the procedure for configuring BFD support for EIGRP so that EIGRP is a registered protocol with BFD and will receive forwarding path detection failure messages from BFD. There are two methods for enabling BFD support for EIGRP:
•
•
Prerequisites
EIGRP must be running on all participating routers.
The baseline parameters for BFD sessions on the interfaces over which you want to run BFD sessions to BFD neighbors must be configured. See the "Configuring BFD Session Parameters on the Interface" section for more information.
Note
Restrictions
BFD for EIGRP is not supported on the Cisco 12000 series routers for Cisco IOS Releases 12.0(31)S, 12.0(32)S, 12.4(4)T, and 12.2(33)SRA.
SUMMARY STEPS
1.
2.
3.
4.
or
bfd interface type number5.
6.
7.
DETAILED STEPS
What to Do Next
See the "Monitoring and Troubleshooting BFD" section for more information on monitoring and troubleshooting BFD. If you want to configure BFD support for another routing protocol, see the following sections:
•
•
•
•
Configuring BFD Support for IS-IS
This section describes the procedures for configuring BFD support for IS-IS so that IS-IS is a registered protocol with BFD and will receive forwarding path detection failure messages from BFD. There are two methods for enabling BFD support for IS-IS:
•
•
To configure BFD support for IS-IS, perform the steps in one of the following sections:
•
•
Prerequisites
IS-IS must be running on all participating routers.
The baseline parameters for BFD sessions on the interfaces that you want to run BFD sessions to BFD neighbors over must be configured. See the "Configuring BFD Session Parameters on the Interface" section for more information.
Note
Configuring BFD Support for IS-IS for All Interfaces
To configure BFD on all IS-IS interfaces that support IPv4 routing, perform the steps in this section.
SUMMARY STEPS
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
DETAILED STEPS
What to Do Next
See the "Monitoring and Troubleshooting BFD" section for more information on monitoring and troubleshooting BFD. If you want to configure only for a specific subset of interfaces, perform the tasks in the "Configuring BFD Support for IS-IS for One or More Interfaces" section.
Configuring BFD Support for IS-IS for One or More Interfaces
To configure BFD for only one or more IS-IS interfaces, perform the steps in this section.
Note
SUMMARY STEPS
1.
2.
3.
4.
5.
6.
7.
8.
DETAILED STEPS
What to Do Next
See the "Monitoring and Troubleshooting BFD" section for more information on monitoring and maintaining BFD. If you want to configure BFD support for another routing protocol, see one of the following sections:
•
•
•
•
Configuring BFD Support for OSPF
This section describes the procedures for configuring BFD support for OSPF so that OSPF is a registered protocol with BFD and will receive forwarding path detection failure messages from BFD. You can either configure BFD support for OSPF globally on all interfaces or configure it selectively on one or more interfaces.
There are two methods for enabling BFD support for OSPF:
•
•
See the following sections for tasks for configuring BFD support for OSPF:
•
•
Configuring BFD Support for OSPF for All Interfaces
To configure BFD for all OSPF interfaces, perform the steps in this section.
If you do not want to configure BFD on all OSPF interfaces and would rather configure BFD support specifically for one or more interfaces, see the "Configuring BFD Support for OSPF for One or More Interfaces" section.
Prerequisites
OSPF must be running on all participating routers.
The baseline parameters for BFD sessions on the interfaces over which you want to run BFD sessions to BFD neighbors must be configured. See the "Configuring BFD Session Parameters on the Interface" section for more information.
Note
SUMMARY STEPS
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
DETAILED STEPS
What to Do Next
See the "Monitoring and Troubleshooting BFD" section for more information on monitoring and troubleshooting BFD. If you want to configure BFD support for another routing protocol, see the following sections:
•
•
•
•
Configuring BFD Support for OSPF for One or More Interfaces
To configure BFD on one or more OSPF interfaces, perform the steps in this section.
Prerequisites
OSPF must be running on all participating routers.
The baseline parameters for BFD sessions on the interfaces over which you want to run BFD sessions to BFD neighbors must be configured. See the "Configuring BFD Session Parameters on the Interface" section for more information.
Note
SUMMARY STEPS
1.
2.
3.
4.
5.
6.
7.
DETAILED STEPS
What to Do Next
See the "Monitoring and Troubleshooting BFD" section for more information on monitoring and troubleshooting BFD. If you want to configure BFD support for another routing protocol, see the following sections:
•
•
•
•
Configuring BFD Support for HSRP
Perform this task to enable BFD support for Hot Standby Router Protocol (HSRP.) Repeat the steps in this procedure for each interface over which you want to run BFD sessions to HSRP peers.
HSRP supports BFD by default. If HSRP support for BFD has been manually disabled, you can reenable it at the router level to enable BFD support globally for all interfaces or on a per-interface basis at the interface level.
Prerequisites
•
•
SUMMARY STEPS
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
DETAILED STEPS
What to Do Next
See the "Monitoring and Troubleshooting BFD" section for more information on monitoring and troubleshooting BFD. If you want to configure BFD support for another routing protocol, see the following sections:
•
•
•
•
Configuring BFD Support for Static Routing
Perform this task to configure BFD support for static routing. Repeat the steps in this procedure on each BFD neighbor. For more information, see the "Example: Configuring BFD Support for Static Routing" section.
SUMMARY STEPS
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
DETAILED STEPS
Configuring BFD Echo Mode
BFD echo mode is enabled by default, but you can disable it such that it can run independently in each direction. Before you configure echo mode, you should be familiar with the following concepts:
BFD Echo Mode
Benefits of Running BFD Echo Mode
BFD echo mode works with asynchronous BFD. Echo packets are sent by the forwarding engine and forwarded back along the same path in order to perform detection—the BFD session at the other end does not participate in the actual forwarding of the echo packets. The echo function and the forwarding engine are responsible for the detection process; therefore, the number of BFD control packets that are sent out between two BFD neighbors is reduced. In addition, because the forwarding engine is testing the forwarding path on the remote (neighbor) system without involving the remote system, there is an opportunity to improve the interpacket delay variance, thereby achieving quicker failure detection times than when using BFD Version 0 with BFD control packets for the BFD session.
Echo Mode Without Asymmetry
Echo mode is described as without asymmetry when it is running on both sides (both BFD neighbors are running echo mode).
Prerequisites
BFD must be running on all participating routers.
Before using BFD echo mode, you must disable the sending of Internet Control Message Protocol (ICMP) redirect messages by entering the no ip redirects command, in order to avoid high CPU utilization.
The baseline parameters for BFD sessions on the interfaces over which you want to run BFD sessions to BFD neighbors must be configured. See the "Configuring BFD Session Parameters on the Interface" section for more information.
Restrictions
BFD echo mode which is supported in BFD Version 1, is available only in Cisco IOS Releases 12.4(9)T, and 12.2(33)SRA.
This section contains the following configuration tasks for BFD echo mode:
•
•
Note
Configuring the BFD Slow Timer
The steps in this procedure show how to change the value of the BFD slow timer. Repeat the steps in this procedure for each BFD router.
SUMMARY STEPS
1.
2.
3.
4.
DETAILED STEPS
Disabling BFD Echo Mode Without Asymmetry
The steps in this procedure show how to disable BFD echo mode without asymmetry —no echo packets will be sent by the router, and the router will not forward BFD echo packets that are received from any neighbor routers.
Repeat the steps in this procedure for each BFD router.
SUMMARY STEPS
1.
2.
3.
4.
DETAILED STEPS
Creating and Configuring BFD Templates
Perform this task to create a BFD template, enter BFD configuration mode, and configure BFD interval timers.
Note
SUMMARY STEPS
1.
2.
3.
4.
5.
DETAILED STEPS
What to Do Next
The BFD templates that you create can be applied to pseudowire classes to enable BFD control channel over VCCV on ATM pseudowire networks. For more information, see the "Configuring BFD Control Channel over VCCV—Support for ATM Pseudowire" section.
Configuring BFD Control Channel over VCCV—Support for ATM Pseudowire
Perform this task to configure BFD over VCCV—Support for ATM Pseudowire networks.
Prerequisites
You must create and configure the BFD template before you assign it to the pseudowire class. For more information, see the "Creating and Configuring BFD Templates" section.
Before VCCV BFD can be run on pseudowires, pseudowires must be configured on the network.
SUMMARY STEPS
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
DETAILED STEPS
Monitoring and Troubleshooting BFD
This section describes how to retrieve BFD information for maintenance and troubleshooting. The commands in these tasks can be entered as needed, in any order desired.
For more information about BFD session initiation and failure, refer to the "BFD Operation" section.
This section contains information for monitoring and troubleshooting BFD for the following Cisco platforms:
•
•
•
Monitoring and Troubleshooting BFD for Cisco 7600 Series Routers
To monitor or troubleshoot BFD on Cisco 7600 series routers, perform one or more of the steps in this section.
Note
SUMMARY STEPS
1.
2.
3.
DETAILED STEPS
Monitoring and Troubleshooting BFD for Cisco 12000 Series Routers
To monitor or troubleshoot BFD on Cisco 12000 series routers, perform one or more of the steps in this section.
SUMMARY STEPS
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
DETAILED STEPS
Monitoring and Troubleshooting BFD for Cisco 10720 Internet Routers
To monitor or troubleshoot BFD on Cisco 10720 Internet routers, perform one or more of the steps in this section.
SUMMARY STEPS
1.
2.
3.
4.
DETAILED STEPS
Configuration Examples for Bidirectional Forwarding Detection
This section provides the following configuration examples:
•
•
•
•
•
•
•
Example: Configuring BFD in an EIGRP Network with Echo Mode Enabled by Default
The following example shows how to configure BFD in an EIGRP network with echo mode enabled by default in Cisco IOS Release 12.4(9)T. In the following example, the EIGRP network contains RouterA, RouterB, and RouterC. FastEthernet interface 1/0 on RouterA is connected to the same network as FastEthernet interface 1/0 on Router B. FastEthernet interface 1/0 on RouterB is connected to the same network as FastEthernet interface 1/0 on RouterC.
RouterA and RouterB are running BFD Version 1, which supports echo mode, and RouterC is running BFD Version 0, which does not support echo mode. The BFD sessions between RouterC and its BFD neighbors are said to be running echo mode with asymmetry because echo mode will run on the forwarding path for RouteA and RouterB, and their echo packets will return along the same path for BFD sessions and failure detections, while their BFD neighbor RouterC runs BFD Version 0 and uses BFD controls packets for BFD sessions and failure detections.
Figure 4 shows a large EIGRP network with several routers, three of which are BFD neighbors that are running EIGRP as their routing protocol.
Figure 4 EIGRP Network with Three BFD Neighbors Running V1 or V0
The example, starting in global configuration mode, shows the configuration of BFD.
Configuration for RouterA
interface FastEthernet0/0no shutdownip address 10.4.9.14 255.255.255.0duplex autospeed auto!interface FastEthernet1/0ip address 172.16.1.1 255.255.255.0bfd interval 50 min_rx 50 multiplier 3no shutdownduplex autospeed auto!router eigrp 11network 172.16.0.0bfd all-interfacesauto-summary!ip default-gateway 10.4.9.1ip default-network 0.0.0.0ip route 0.0.0.0 0.0.0.0 10.4.9.1ip route 172.16.1.129 255.255.255.255 10.4.9.1!no ip http server!logging alarm informational!control-plane!line con 0exec-timeout 30 0stopbits 1line aux 0stopbits 1line vty 0 4login!!endConfiguration for RouterB
!interface FastEthernet0/0no shutdownip address 10.4.9.34 255.255.255.0duplex autospeed auto!interface FastEthernet1/0ip address 172.16.1.2 255.255.255.0bfd interval 50 min_rx 50 multiplier 3no shtdownduplex autospeed auto!router eigrp 11network 172.16.0.0bfd all-interfacesauto-summary!ip default-gateway 10.4.9.1ip default-network 0.0.0.0ip route 0.0.0.0 0.0.0.0 10.4.9.1ip route 172.16.1.129 255.255.255.255 10.4.9.1!no ip http server!logging alarm informational!control-plane!line con 0exec-timeout 30 0stopbits 1line aux 0stopbits 1line vty 0 4login!!endConfiguration for RouterC
!!interface FastEthernet0/0no shutdownip address 10.4.9.34 255.255.255.0duplex autospeed auto!interface FastEthernet1/0ip address 172.16.1.2 255.255.255.0bfd interval 50 min_rx 50 multiplier 3no shutdownduplex autospeed auto!router eigrp 11network 172.16.0.0bfd all-interfacesauto-summary!ip default-gateway 10.4.9.1ip default-network 0.0.0.0ip route 0.0.0.0 0.0.0.0 10.4.9.1ip route 172.16.1.129 255.255.255.255 10.4.9.1!no ip http server!logging alarm informational!control-plane!line con 0exec-timeout 30 0stopbits 1line aux 0stopbits 1line vty 0 4login!!endThe output from the show bfd neighbors details command from RouterA verifies that BFD sessions have been created among all three routers and that EIGRP is registered for BFD support. The first group of output shows that RouterC with the IP address 172.16.1.3 runs BFD Version 0 and therefore does not use the echo mode. The second group of output shows that RouterB with the IP address 172.16.1.2 does run BFD Version 1, and the 50 millisecond BFD interval parameter had been adopted. The relevant command output is shown in bold in the output.
RouterARouterA# show bfd neighbors detailsOurAddr NeighAddr LD/RD RH/RS Holdown(mult) State Int172.16.1.1 172.16.1.3 5/3 1(RH) 150 (3 ) Up Fa1/0Session state is UP and not using echo function.Local Diag: 0, Demand mode: 0, Poll bit: 0MinTxInt: 50000, MinRxInt: 50000, Multiplier: 3Received MinRxInt: 50000, Received Multiplier: 3Holdown (hits): 150(0), Hello (hits): 50(1364284)Rx Count: 1351813, Rx Interval (ms) min/max/avg: 28/64/49 last: 4 ms agoTx Count: 1364289, Tx Interval (ms) min/max/avg: 40/68/49 last: 32 ms agoRegistered protocols: EIGRPUptime: 18:42:45Last packet: Version: 0 - Diagnostic: 0I Hear You bit: 1 - Demand bit: 0Poll bit: 0 - Final bit: 0Multiplier: 3 - Length: 24My Discr.: 3 - Your Discr.: 5Min tx interval: 50000 - Min rx interval: 50000Min Echo interval: 0OurAddr NeighAddr LD/RD RH/RS Holdown(mult) State Int172.16.1.1 172.16.1.2 6/1 Up 0 (3 ) Up Fa1/0Session state is UP and using echo function with 50 ms interval.Local Diag: 0, Demand mode: 0, Poll bit: 0MinTxInt: 1000000, MinRxInt: 1000000, Multiplier: 3Received MinRxInt: 1000000, Received Multiplier: 3Holdown (hits): 3000(0), Hello (hits): 1000(317)Rx Count: 305, Rx Interval (ms) min/max/avg: 1/1016/887 last: 448 ms agoTx Count: 319, Tx Interval (ms) min/max/avg: 1/1008/880 last: 532 ms agoRegistered protocols: EIGRPUptime: 00:04:30Last packet: Version: 1 - Diagnostic: 0State bit: Up - Demand bit: 0Poll bit: 0 - Final bit: 0Multiplier: 3 - Length: 24My Discr.: 1 - Your Discr.: 6Min tx interval: 1000000 - Min rx interval: 1000000Min Echo interval: 50000The output from the show bfd neighbors details command on Router B verifies that BFD sessions have been created and that EIGRP is registered for BFD support. As previously noted, RouterA runs BFD Version 1, therefore echo mode is running, and RouterC runs BFD Version 0, so echo mode does not run. The relevant command output is shown in bold in the output.
Router BRouterB# show bfd neighbors detailsOurAddr NeighAddr LD/RD RH/RS Holdown(mult) State Int172.16.1.2 172.16.1.1 1/6 Up 0 (3 ) Up Fa1/0Session state is UP and using echo function with 50 ms interval.Local Diag: 0, Demand mode: 0, Poll bit: 0MinTxInt: 1000000, MinRxInt: 1000000, Multiplier: 3Received MinRxInt: 1000000, Received Multiplier: 3Holdown (hits): 3000(0), Hello (hits): 1000(337)Rx Count: 341, Rx Interval (ms) min/max/avg: 1/1008/882 last: 364 ms agoTx Count: 339, Tx Interval (ms) min/max/avg: 1/1016/886 last: 632 ms agoRegistered protocols: EIGRPUptime: 00:05:00Last packet: Version: 1 - Diagnostic: 0State bit: Up - Demand bit: 0Poll bit: 0 - Final bit: 0Multiplier: 3 - Length: 24My Discr.: 6 - Your Discr.: 1Min tx interval: 1000000 - Min rx interval: 1000000Min Echo interval: 50000OurAddr NeighAddr LD/RD RH/RS Holdown(mult) State Int172.16.1.2 172.16.1.3 3/6 1(RH) 118 (3 ) Up Fa1/0Session state is UP and not using echo function.Local Diag: 0, Demand mode: 0, Poll bit: 0MinTxInt: 50000, MinRxInt: 50000, Multiplier: 3Received MinRxInt: 50000, Received Multiplier: 3Holdown (hits): 150(0), Hello (hits): 50(5735)Rx Count: 5731, Rx Interval (ms) min/max/avg: 32/72/49 last: 32 ms agoTx Count: 5740, Tx Interval (ms) min/max/avg: 40/64/50 last: 44 ms agoRegistered protocols: EIGRPUptime: 00:04:45Last packet: Version: 0 - Diagnostic: 0I Hear You bit: 1 - Demand bit: 0Poll bit: 0 - Final bit: 0Multiplier: 3 - Length: 24My Discr.: 6 - Your Discr.: 3Min tx interval: 50000 - Min rx interval: 50000Min Echo interval: 0Figure 5 shows that FastEthernet interface 1/0 on RouterB has failed. When FastEthernet interface 1/0 on RouterB is shut down, the BFD statistics of the corresponding BFD sessions on RouterA and RouterB are reduced.Figure 5 FastEthernet Interface 1/0 Failure
When FastEthernet interface 1/0 on RouterB fails, BFD will no longer detect Router B as a BFD neighbor for RouterA or for RouterC. In this example, FastEthernet interface 1/0 has been administratively shut down on RouterB.
The following output from the show bfd neighbors command on RouterA now shows only one BFD neighbor for RouterA in the EIGRP network. The relevant command output is shown in bold in the output.
RouterA# show bfd neighborsOurAddr NeighAddr LD/RD RH/RS Holdown(mult) State Int172.16.1.1 172.16.1.3 5/3 1(RH) 134 (3 ) Up Fa1/0The following output from the show bfd neighbors command on RouterC also now shows only one BFD neighbor for RouterC in the EIGRP network. The relevant command output is shown in bold in the output.
RouterC# show bfd neighborsOurAddr NeighAddr LD/RD RH Holdown(mult) State Int172.16.1.3 172.16.1.1 3/5 1 114 (3 ) Up Fa1/0Example: Configuring BFD in an OSPF Network
The following example shows how to configure BFD in an OSPF network in Cisco IOS Release 12.0(31)S. In the following example, the simple OSPF network consists of Router A and Router B. FastEthernet interface 0/1 on Router A is connected to the same network as FastEthernet interface 6/0 in Router B. The example, starting in global configuration mode, shows the configuration of BFD. For both Routers A and B, BFD is configured globally for all interfaces associated with the OSPF process.
Configuration for Router A
!interface FastEthernet 0/1ip address 172.16.10.1 255.255.255.0bfd interval 50 min_rx 50 multiplier 3!interface FastEthernet 3/0.1ip address 172.17.0.1 255.255.255.0!router ospf 123log-adjacency-changes detailnetwork 172.16.0.0 0.0.0.255 area 0network 172.17.0.0 0.0.0.255 area 0bfd all-interfacesConfiguration for Router B
!interface FastEthernet 6/0ip address 172.16.10.2 255.255.255.0bfd interval 50 min_rx 50 multiplier 3!interface FastEthernet 6/1ip address 172.18.0.1 255.255.255.0!router ospf 123log-adjacency-changes detailnetwork 172.16.0.0 0.0.255.255 area 0network 172.18.0.0 0.0.255.255 area 0bfd all-interfacesThe output from the show bfd neighbors details command verifies that a BFD session has been created and that OSPF is registered for BFD support. The relevant command output is shown in bold in the output.
Router A
RouterA# show bfd neighbors detailsOurAddr NeighAddr LD/RD RH Holdown(mult) State Int172.16.10.1 172.16.10.2 1/2 1 532 (3 ) Up Fa0/1Local Diag: 0, Demand mode: 0, Poll bit: 0MinTxInt: 200000, MinRxInt: 200000, Multiplier: 5Received MinRxInt: 1000, Received Multiplier: 3Holdown (hits): 600(22), Hello (hits): 200(84453)Rx Count: 49824, Rx Interval (ms) min/max/avg: 208/440/332 last: 68 ms agoTx Count: 84488, Tx Interval (ms) min/max/avg: 152/248/196 last: 192 ms agoRegistered protocols: OSPF
Uptime: 02:18:49Last packet: Version: 0 - Diagnostic: 0I Hear You bit: 1 - Demand bit: 0Poll bit: 0 - Final bit: 0Multiplier: 3 - Length: 24My Discr.: 2 - Your Discr.: 1Min tx interval: 50000 - Min rx interval: 1000Min Echo interval: 0The output from the show bfd neighbors details command from the line card on Router B verifies that a BFD session has been created:
Note
Router B
RouterB# attach 6Entering Console for 8 Port Fast Ethernet in Slot: 6Type "exit" to end this sessionPress RETURN to get started!Router> show bfd neighbors detailsCleanup timer hits: 0OurAddr NeighAddr LD/RD RH Holdown(mult) State Int172.16.10.2 172.16.10.1 8/1 1 1000 (5 ) Up Fa6/0Local Diag: 0, Demand mode: 0, Poll bit: 0MinTxInt: 50000, MinRxInt: 1000, Multiplier: 3Received MinRxInt: 200000, Received Multiplier: 5Holdown (hits): 1000(0), Hello (hits): 200(5995)Rx Count: 10126, Rx Interval (ms) min/max/avg: 152/248/196 last: 0 ms agoTx Count: 5998, Tx Interval (ms) min/max/avg: 204/440/332 last: 12 ms agoLast packet: Version: 0 - Diagnostic: 0I Hear You bit: 1 - Demand bit: 0Poll bit: 0 - Final bit: 0Multiplier: 5 - Length: 24My Discr.: 1 - Your Discr.: 8Min tx interval: 200000 - Min rx interval: 200000Min Echo interval: 0Uptime: 00:33:13SSO Cleanup Timer called: 0SSO Cleanup Action Taken: 0Pseudo pre-emptive process count: 239103 min/max/avg: 8/16/8 last: 0 ms agoIPC Tx Failure Count: 0IPC Rx Failure Count: 0Total Adjs Found: 1The output of the show ip ospf command verifies that BFD has been enabled for OSPF. The relevant command output is shown in bold in the output.
Router A
RouterA# show ip ospfRouting Process "ospf 123" with ID 172.16.10.1Supports only single TOS(TOS0) routesSupports opaque LSASupports Link-local Signaling (LLS)Initial SPF schedule delay 5000 msecsMinimum hold time between two consecutive SPFs 10000 msecsMaximum wait time between two consecutive SPFs 10000 msecsIncremental-SPF disabledMinimum LSA interval 5 secsMinimum LSA arrival 1000 msecsLSA group pacing timer 240 secsInterface flood pacing timer 33 msecsRetransmission pacing timer 66 msecsNumber of external LSA 0. Checksum Sum 0x000000Number of opaque AS LSA 0. Checksum Sum 0x000000Number of DCbitless external and opaque AS LSA 0Number of DoNotAge external and opaque AS LSA 0Number of areas in this router is 1. 1 normal 0 stub 0 nssaExternal flood list length 0BFD is enabled
Area BACKBONE(0)Number of interfaces in this area is 2 (1 loopback)Area has no authenticationSPF algorithm last executed 00:00:08.828 agoSPF algorithm executed 9 timesArea ranges areNumber of LSA 3. Checksum Sum 0x028417Number of opaque link LSA 0. Checksum Sum 0x000000Number of DCbitless LSA 0Number of indication LSA 0Number of DoNotAge LSA 0Flood list length 0Router B
RouterB# show ip ospfRouting Process "ospf 123" with ID 172.18.0.1Supports only single TOS(TOS0) routesSupports opaque LSASupports Link-local Signaling (LLS)Supports area transit capabilityInitial SPF schedule delay 5000 msecsMinimum hold time between two consecutive SPFs 10000 msecsMaximum wait time between two consecutive SPFs 10000 msecsIncremental-SPF disabledMinimum LSA interval 5 secsMinimum LSA arrival 1000 msecsLSA group pacing timer 240 secsInterface flood pacing timer 33 msecsRetransmission pacing timer 66 msecsNumber of external LSA 0. Checksum Sum 0x0Number of opaque AS LSA 0. Checksum Sum 0x0Number of DCbitless external and opaque AS LSA 0Number of DoNotAge external and opaque AS LSA 0Number of areas in this router is 1. 1 normal 0 stub 0 nssaNumber of areas transit capable is 0External flood list length 0BFD is enabled
Area BACKBONE(0)Number of interfaces in this area is 2 (1 loopback)Area has no authenticationSPF algorithm last executed 02:07:30.932 agoSPF algorithm executed 7 timesArea ranges areNumber of LSA 3. Checksum Sum 0x28417Number of opaque link LSA 0. Checksum Sum 0x0Number of DCbitless LSA 0Number of indication LSA 0Number of DoNotAge LSA 0Flood list length 0The output of the show ip ospf interface command verifies that BFD has been enabled for OSPF on the interfaces connecting Router A and Router B. The relevant command output is shown in bold in the output.
Router A
RouterA# show ip ospf interface fastethernet 0/1show ip ospf interface fastethernet 0/1FastEthernet0/1 is up, line protocol is upInternet Address 172.16.10.1/24, Area 0Process ID 123, Router ID 172.16.10.1, Network Type BROADCAST, Cost: 1Transmit Delay is 1 sec, State BDR, Priority 1, BFD enabledDesignated Router (ID) 172.18.0.1, Interface address 172.16.10.2Backup Designated router (ID) 172.16.10.1, Interface address 172.16.10.1Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5oob-resync timeout 40Hello due in 00:00:03Supports Link-local Signaling (LLS)Index 1/1, flood queue length 0Next 0x0(0)/0x0(0)Last flood scan length is 1, maximum is 1Last flood scan time is 0 msec, maximum is 0 msecNeighbor Count is 1, Adjacent neighbor count is 1Adjacent with neighbor 172.18.0.1 (Designated Router)Suppress hello for 0 neighbor(s)Router B
RouterB# show ip ospf interface fastethernet 6/1FastEthernet6/1 is up, line protocol is upInternet Address 172.18.0.1/24, Area 0Process ID 123, Router ID 172.18.0.1, Network Type BROADCAST, Cost: 1Transmit Delay is 1 sec, State DR, Priority 1, BFD enabledDesignated Router (ID) 172.18.0.1, Interface address 172.18.0.1No backup designated router on this networkTimer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5oob-resync timeout 40Hello due in 00:00:01Supports Link-local Signaling (LLS)Index 1/1, flood queue length 0Next 0x0(0)/0x0(0)Last flood scan length is 0, maximum is 0Last flood scan time is 0 msec, maximum is 0 msecNeighbor Count is 0, Adjacent neighbor count is 0Suppress hello for 0 neighbor(s)Example: Configuring BFD in a BGP Network
The following example shows how to configure BFD in a BGP network in Cisco IOS Release 12.0(31)S. In the following example, the simple BGP network consists of Router A and Router B. FastEthernet interface 0/1 on Router A is connected to the same network as FastEthernet interface 6/0 in Router B. The example, starting in global configuration mode, shows the configuration of BFD.
Configuration for Router A
!interface FastEthernet 0/1ip address 172.16.10.1 255.255.255.0bfd interval 50 min_rx 50 multiplier 3!interface FastEthernet 3/0.1ip address 172.17.0.1 255.255.255.0!!router bgp 40000bgp log-neighbor-changesneighbor 172.16.10.2 remote-as 45000neighbor 172.16.10.2 fall-over bfd!address-family ipv4neighbor 172.16.10.2 activateno auto-summaryno synchronizationnetwork 172.18.0.0 mask 255.255.255.0exit-address-family!Configuration for Router B
!interface FastEthernet 6/0ip address 172.16.10.2 255.255.255.0bfd interval 50 min_rx 50 multiplier 3!interface FastEthernet 6/1ip address 172.18.0.1 255.255.255.0!router bgp 45000bgp log-neighbor-changesneighbor 172.16.10.1 remote-as 40000neighbor 172.16.10.1 fall-over bfd!address-family ipv4neighbor 172.16.10.1 activateno auto-summaryno synchronizationnetwork 172.17.0.0 mask 255.255.255.0exit-address-family!The output from the show bfd neighbors details command from Router A verifies that a BFD session has been created and that BGP is registered for BFD support. The relevant command output is shown in bold in the output.
Router A
RouterA# show bfd neighbors detailsOurAddr NeighAddr LD/RD RH Holdown(mult) State Int172.16.10.1 172.16.10.2 1/8 1 332 (3 ) Up Fa0/1Local Diag: 0, Demand mode: 0, Poll bit: 0MinTxInt: 200000, MinRxInt: 200000, Multiplier: 5Received MinRxInt: 1000, Received Multiplier: 3Holdown (hits): 600(0), Hello (hits): 200(15491)Rx Count: 9160, Rx Interval (ms) min/max/avg: 200/440/332 last: 268 ms agoTx Count: 15494, Tx Interval (ms) min/max/avg: 152/248/197 last: 32 ms agoRegistered protocols: BGPUptime: 00:50:45Last packet: Version: 0 - Diagnostic: 0I Hear You bit: 1 - Demand bit: 0Poll bit: 0 - Final bit: 0Multiplier: 3 - Length: 24My Discr.: 8 - Your Discr.: 1Min tx interval: 50000 - Min rx interval: 1000Min Echo interval: 0The output from the show bfd neighbors details command from the line card on Router B verifies that a BFD session has been created:
Note
Router B
RouterB# attach 6Entering Console for 8 Port Fast Ethernet in Slot: 6Type "exit" to end this sessionPress RETURN to get started!Router> show bfd neighbors detailsCleanup timer hits: 0OurAddr NeighAddr LD/RD RH Holdown(mult) State Int172.16.10.2 172.16.10.1 8/1 1 1000 (5 ) Up Fa6/0Local Diag: 0, Demand mode: 0, Poll bit: 0MinTxInt: 50000, MinRxInt: 1000, Multiplier: 3Received MinRxInt: 200000, Received Multiplier: 5Holdown (hits): 1000(0), Hello (hits): 200(5995)Rx Count: 10126, Rx Interval (ms) min/max/avg: 152/248/196 last: 0 ms agoTx Count: 5998, Tx Interval (ms) min/max/avg: 204/440/332 last: 12 ms agoLast packet: Version: 0 - Diagnostic: 0I Hear You bit: 1 - Demand bit: 0Poll bit: 0 - Final bit: 0Multiplier: 5 - Length: 24My Discr.: 1 - Your Discr.: 8Min tx interval: 200000 - Min rx interval: 200000Min Echo interval: 0Uptime: 00:33:13SSO Cleanup Timer called: 0SSO Cleanup Action Taken: 0Pseudo pre-emptive process count: 239103 min/max/avg: 8/16/8 last: 0 ms agoIPC Tx Failure Count: 0IPC Rx Failure Count: 0Total Adjs Found: 1The output of the show ip bgp neighbors command verifies that BFD has been enabled for the BGP neighbors:
Router A
RouterA# show ip bgp neighborsBGP neighbor is 172.16.10.2, remote AS 45000, external linkUsing BFD to detect fast fallover..Router B
RouterB# show ip bgp neighborsBGP neighbor is 172.16.10.1, remote AS 40000, external linkUsing BFD to detect fast fallover..Example: Configuring BFD in an IS-IS Network
The following example shows how to configure BFD in an IS-IS network in Cisco IOS Release 12.0(31)S. In the following example, the simple IS-IS network consists of Router A and Router B. FastEthernet interface 0/1 on Router A is connected to the same network as FastEthernet interface 6/0 for Router B. The example, starting in global configuration mode, shows the configuration of BFD.
Configuration for Router A
!interface FastEthernet 0/1ip address 172.16.10.1 255.255.255.0ip router isisbfd interval 50 min_rx 50 multiplier 3!interface FastEthernet 3/0.1ip address 172.17.0.1 255.255.255.0ip router isis!router isisnet 49.0001.1720.1600.1001.00bfd all-interfaces!Configuration for Router B
!interface FastEthernet 6/0ip address 172.16.10.2 255.255.255.0ip router isisbfd interval 50 min_rx 50 multiplier 3!interface FastEthernet 6/1ip address 172.18.0.1 255.255.255.0ip router isis!router isisnet 49.0000.0000.0002.00bfd all-interfaces!The output from the show bfd neighbors details command from Router A verifies that a BFD session has been created and that IS-IS is registered for BFD support:
Router ARouterA# show bfd neighbors detailsOurAddr NeighAddr LD/RD RH Holdown(mult) State Int172.16.10.1 172.16.10.2 1/8 1 536 (3 ) Up Fa0/1Local Diag: 0, Demand mode: 0, Poll bit: 0MinTxInt: 200000, MinRxInt: 200000, Multiplier: 5Received MinRxInt: 1000, Received Multiplier: 3Holdown (hits): 600(0), Hello (hits): 200(23543)Rx Count: 13877, Rx Interval (ms) min/max/avg: 200/448/335 last: 64 ms agoTx Count: 23546, Tx Interval (ms) min/max/avg: 152/248/196 last: 32 ms agoRegistered protocols: ISISUptime: 01:17:09Last packet: Version: 0 - Diagnostic: 0I Hear You bit: 1 - Demand bit: 0Poll bit: 0 - Final bit: 0Multiplier: 3 - Length: 24My Discr.: 8 - Your Discr.: 1Min tx interval: 50000 - Min rx interval: 1000Min Echo interval: 0The output from the show bfd neighbors details command from the line card on Router B verifies that a BFD session has been created:
Note
Router BRouterB# attach 6Entering Console for 8 Port Fast Ethernet in Slot: 6Type "exit" to end this sessionPress RETURN to get started!Router> show bfd neighbors detailsCleanup timer hits: 0OurAddr NeighAddr LD/RD RH Holdown(mult) State Int172.16.10.2 172.16.10.1 8/1 1 1000 (5 ) Up Fa6/0Local Diag: 0, Demand mode: 0, Poll bit: 0MinTxInt: 50000, MinRxInt: 1000, Multiplier: 3Received MinRxInt: 200000, Received Multiplier: 5Holdown (hits): 1000(0), Hello (hits): 200(5995)Rx Count: 10126, Rx Interval (ms) min/max/avg: 152/248/196 last: 0 ms agoTx Count: 5998, Tx Interval (ms) min/max/avg: 204/440/332 last: 12 ms agoLast packet: Version: 0 - Diagnostic: 0I Hear You bit: 1 - Demand bit: 0Poll bit: 0 - Final bit: 0Multiplier: 5 - Length: 24My Discr.: 1 - Your Discr.: 8Min tx interval: 200000 - Min rx interval: 200000Min Echo interval: 0Uptime: 00:33:13SSO Cleanup Timer called: 0SSO Cleanup Action Taken: 0Pseudo pre-emptive process count: 239103 min/max/avg: 8/16/8 last: 0 ms agoIPC Tx Failure Count: 0IPC Rx Failure Count: 0Total Adjs Found: 1Example: Configuring BFD in an HSRP Network
In the following example, the HSRP network consists of Router A and Router B. FastEthernet interface 2/0 on Router A is connected to the same network as FastEthernet interface 2/0 on Router B. The example, starting in global configuration mode, shows the configuration of BFD.
Note
Router A
ip cefinterface FastEthernet2/0no shutdownip address 10.0.0.2 255.0.0.0ip router-cache cefbfd interval 200 min_rx 200 multiplier 3standby 1 ip 10.0.0.11standby 1 preemptstandby 1 priority 110standby 2 ip 10.0.0.12standby 2 preemptstandby 2 priority 110Router B
interface FastEthernet2/0ip address 10.1.0.22 255.255.0.0no shutdownbfd interval 200 min_rx 200 multiplier 3standby 1 ip 10.0.0.11standby 1 preemptstandby 1 priority 90standby 2 ip 10.0.0.12standby 2 preemptstandby 2 priority 80The output from the show standby neighbors command verifies that a BFD session has been created:
RouterA# show standby neighborsHSRP neighbors on FastEthernet2/010.1.0.22No active groupsStandby groups: 1BFD enabled !RouterB# show standby neighborsHSRP neighbors on FastEthernet2/010.0.0.2Active groups: 1No standby groupsBFD enabled !Example: Configuring BFD Support for Static Routing
In the following example, the network consists of Router A and Router B. Serial interface 2/0 on
Router A is connected to the same network as serial interface 2/0 on Router B. In order for the BFD session to come up, Router B must be configured.Router A
configure terminalinterface Serial 2/0ip address 10.201.201.1 255.255.255.0bfd interval 500 min_rx 500 multiplier 5ip route static bfd Serial 2/0 10.201.201.2ip route 10.0.0.0 255.0.0.0 Serial 2/0 10.201.201.2Router B
configure terminalinterface Serial 2/0ip address 10.201.201.2 255.255.255.0bfd interval 500 min_rx 500 multiplier 5ip route static bfd Serial 2/0 10.201.201.1ip route 10.1.1.1 255.255.255.255 Serial 2/0 10.201.201.1Note that the static route on Router B exists solely to enable the BFD session between 10.201.201.1 and 10.201.201.2. If there is no useful static route that needs to be configured, select a prefix that will not affect packet forwarding, for example, the address of a locally configured loopback interface.
In the following example, there is an active static BFD configuration to reach 209.165.200.225 through Ethernet interface 0/0 in the BFD group testgroup. As soon as the static route is configured that is tracked by the configured static BFD, a single hop BFD session is initiated to 209.165.200.225 through Ethernet interface 0/0. The prefix 10.0.0.0/8 is added to the RIB if a BFD session is successfully established.
configure terminalip route static bfd Ethernet 0/0 209.165.200.225 group testgroupip route 10.0.0.0 255.255.255.224 Ethernet 0/0 209.165.200.225In the following example, a BFD session to 209.165.200.226 through Ethernet interface 0/0.1001 is marked to use the group testgroup. That is, this configuration is a passive static BFD. Though there are static routes to be tracked by the second static BFD configuration, a BFD session is not triggered for 209.165.200.226 through Ethernet interface 0/0.1001. The existence of the prefixes 10.1.1.1/8 and 10.2.2.2/8 is controlled by the active static BFD session (Ethernet interface 0/0 209.165.200.225).
configure terminalip route static bfd Ethernet 0/0 209.165.200.225 group testgroupip route 10.0.0.0 255.255.255.224 Ethernet 0/0 209.165.200.225ip route static bfd Ethernet 0/0.1001 209.165.200.226 group testgroup passiveip route 10.1.1.1 255.255.255.224 Ethernet 0/0.1001 209.165.200.226ip route 10.2.2.2 255.255.255.224 Ethernet 0/0.1001 209.165.200.226Example: Configuring BFD Control Channel over VCCV—Support for ATM Pseudowire
Figure 6 shows a typical ATM pseudowire configuration. The network consists of a MPLS pseudowire carrying an ATM payload between two terminating provider edge (T-PE) devices: T-PE1 and T-PE2. BFD monitoring of the pseudowire occurs between the T-PE1 device and the switching providing edge (S-PE) device, and between the S-PE device and the T-PE2 device. BFD also monitors the signal status of the ACs between the customer edge (CE) devices and the T-PE devices.
Note
Figure 6
Sample ATM Pseudowire with BFD Control Channel over VCCV
CE1
interface ATM 0/0 description connect to mfi6 atm9/0/0 no ip address no ip directed-broadcast atm clock INTERNAL atm sonet stm-1 no atm enable-ilmi-trap no atm ilmi-keepalive!interface ATM 0/0.2 point-to-point ip address 10.25.1.1 255.255.255.0 no ip directed-broadcast no atm enable-ilmi-trap pvc 0/100 encapsulation aal5snapT-PE1
interface Loopback 0ip address 10.0.0.6 255.255.255.255bfd-template single-hop nsninterval min-tx 500 min-rx 500 multiplier 3pseudowire-class vccv-bfd1encapsulation mplsvccv bfd template nsn raw-bfdvccv bfd status signalinginterface ATM 9/0/0description connect mfr4 atm0/0no ip addressatm asynchronousatm clock INTERNALno atm ilmi-keepaliveno atm enable-ilmi-trappvc 0/100 l2transportxconnect 10.0.0.7 100 pw-class vccv-bfd1T-PE2
interface Loopback 0ip address 10.54.0.1 255.255.255.255bfd-template single-hop nsninterval min-tx 500 min-rx 500 multiplier 3!pseudowire-class vccv-bfd1encapsulation mplsvccv bfd template nsn raw-bfdvccv bfd status signalinginterface ATM 2/0no ip address atm asynchronousno atm ilmi-keepaliveno atm enable-ilmi-trappvc 0/100 l2transportxconnect 10.0.0.7 102 pw-class vccv-bfd1!CE2
interface ATM 4/0.2 point-to-pointip address 10.25.1.2 255.255.255.0no snmp trap link-statuspvc 0/100encapsulation aal5snapAdditional References
Related Documents
Cisco IOS commands
Configuring and monitoring BGP
Cisco BGP Overview" module of the Cisco IOS IP Routing Protocols Configuration Guide
BFD hardware offload
"Configuring Synchronous Ethernet on the Cisco 7600 Router with ES+ Line Card" section of the Cisco 7600 Series Ethernet Services Plus (ES+) and Ethernet Services Plus T (ES+T) Line Card Configuration Guide
Configuring and monitoring EIGRP
"Configuring EIGRP" module of the Cisco IOS IP Routing Protocols Configuration Guide
Configuring and monitoring HSRP
"Configuring HSRP" module of the Cisco IOS IP Application Services Configuration Guide
Configuring and monitoring IS-IS
"Configuring Integrated IS-IS" module of the Cisco IOS IP Routing Protocols Configuration Guide
Configuring and monitoring OSPF
"Configuring OSPF" module of the Cisco IOS IP Routing Protocols Configuration Guide
BFD commands: complete command syntax, command mode, command history, defaults, usage guidelines, and examples
Cisco IOS IP Routing: Protocol-Independent Command Reference
BGP commands: complete command syntax, command mode, command history, defaults, usage guidelines, and examples
Cisco IOS IP Routing: Protocol-Independent Command Reference
EIGRP commands: complete command syntax, command mode, command history, defaults, usage guidelines, and examples
Cisco IOS IP Routing: Protocol-Independent Command Reference
HSRP commands: complete command syntax, command mode, command history, defaults, usage guidelines, and examples
IS-IS commands: complete command syntax, command mode, command history, defaults, usage guidelines, and examples
Cisco IOS IP Routing: Protocol-Independent Command Reference
OSPF commands: complete command syntax, command mode, command history, defaults, usage guidelines, and examples
Cisco IOS IP Routing: Protocol-Independent Command Reference
Standards
MIBs
RFCs
No new or modified RFCs are supported by this feature, and support for existing RFCs has not been modified by this feature.
—
Technical Assistance
Feature Information for Bidirectional Forwarding Detection
Table 5 lists the features in this module and provides links to specific configuration information.
Use Cisco Feature Navigator to find information about platform support and software image support. Cisco Feature Navigator enables you to determine which software images support a specific software release, feature set, or platform. To access Cisco Feature Navigator, go to http://www.cisco.com/go/cfn. An account on Cisco.com is not required.
Note
Table 5 Feature Information for Bidirectional Forwarding Detection
BFD Control Channel over VCCV—Support for ATM Pseudowire
15.0(1)S
VCCV provides a control channel that is associated with an ATM pseudowire to perform operations and management functions over the pseudowire. BFD uses the VCCV control channel to detect dataplane failures for pseudowires.
In Cisco IOS Release 15.0(1)S the BFD control channel over VCCV Support for ATM Pseudowire feature is supported for VCCV type-1 (without an IP/UDP header) only.
The following sections provide information about this feature:
•
•
•
The following commands were introduced or modified by this feature: bfd-template, debug mpls l2transport vc vccv, interval (BFD), vccv, vccv bfd template, vccv bfd status signaling.
BFD Echo Mode
12.2(33)SRB
12.4(9)T
15.0(1)SBFD echo mode works with asynchronous BFD. Echo packets are sent by the forwarding engine and forwarded back along the same path in order to perform detection—the BFD session at the other end does not participate in the actual forwarding of the echo packets. The echo function and the forwarding engine are responsible for the detection process, therefore the number of BFD control packets that are sent out between two BFD neighbors is reduced. And since the forwarding engine is testing the forwarding path on the remote (neighbor) system without involving the remote system, there is an opportunity to improve the interpacket delay variance, thereby achieving quicker failure detection times than when using BFD Version 0 with BFD control packets for the BFD session.
The following sections provide information about this feature:
BFD—EIGRP Support
12.0(31)S
12.2(18)SXE
12.2(33)SRA
12.2(33)SRB
12.4(4)T
BFD support for EIGRP can be configured so that EIGRP is a registered protocol with BFD and will receive forwarding path detection failure messages from BFD.
BFD for EIGRP is not supported on the Cisco 12000 series routers for Cisco IOS Releases 12.0(31)S, 12.0(32)S, 12.4(4)T, and 12.2(33)SRA.
The following sections provide information about this feature:
•
•
•
BFD—VRF Support
12.2(33)SRC 15.0(1)M
15.0(1)SThe BFD feature support is extended to be VPN Routing and Forwarding (VRF) aware to provide fast detection of routing protocol failures between provider edge (PE) and customer edge (CE) routers.
The following section provides information about this feature:
BFD—WAN Interface Support
12.2(33)SRC 15.0(1)M
15.0(1)SThe BFD feature is supported on nonbroadcast media interfaces including ATM, POS, serial, and VLAN interfaces. BFD support also extends to ATM, FR, POS, and serial subinterfaces.
The bfd interval command must be configured on the interface to initiate BFD monitoring.
The following section provides information about this feature:
Bidirectional Forwarding Detection (standard implementation, Version 1)
12.0(31)S
12.0(32)S
12.2(33)SRB
12.2(33)SRC
12.2(18)SXE
12.2(33)SXH
12.4(9)T
12.4(11)T
12.4(15)T
15.0(1)SThis document describes how to enable the Bidirectional Forwarding Detection (BFD) protocol. BFD is a detection protocol designed to provide fast forwarding path failure detection times for all media types, encapsulations, topologies, and routing protocols. In addition to fast forwarding path failure detection, BFD provides a consistent failure detection method for network administrators. Because the network administrator can use BFD to detect forwarding path failures at a uniform rate, rather than the variable rates for different routing protocol hello mechanisms, network profiling and planning will be easier, and reconvergence time will be consistent and predictable.
In Release 12.0(31)S, support was added for the
Cisco 12000 series Internet router.In Release 12.0(32)S, support was added for the
Cisco 10720 Internet router and IP Services Engine (Engine 3) and Engine 5 shared port adapters (SPAs) and SPA interface processors (SIPs) on the Cisco 12000 series Internet router.HSRP Support for BFD
12.2(33)SRC
12.4(11)T
12.4(15)TIn Release 12.4(11)T, support for HSRP was added.
In Release 12.4(15)T, BFD is supported on the Integrated Services Router (ISR) family of Cisco routers, for example, the Cisco 3800 ISR series routers.
In Release 12.2(33)SRC, the number of BFD sessions that can be created has been increased, BFD support has been extended to ATM, FR, POS, and serial subinterfaces, the BFD feature has been extended to be VRF-aware, BFD sessions are placed in an "Admin Down" state during a planned switchover, and BFD support has been extended to static routing.
The following section provides information about this feature:
IS-IS Support for BFD over IPv4
12.0(31)S
12.2(18)SXE
12.2(33)SRA
12.4(4)T
15.0(1)SBFD support for OSPF can be configured globally on all interfaces or configured selectively on one or more interfaces. When BFD support is configured with IS-IS as a registered protocol with BFD, IS-IS receives forwarding path detection failure messages from BFD.
The following sections provide information about this feature:
•
•
OSPF Support for BFD over IPv4
12.0(31)S
12.2(18)SXE
12.2(33)SRA
12.4(4)T
15.0(1)SBFD support for OSPF can be configured globally on all interfaces or configured selectively on one or more interfaces. When BFD support is configured with OSPF as a registered protocol with BFD, OSPF receives forwarding path detection failure messages from BFD.
The following sections provide information about this feature:
•
•
SSO—BFD
12.2(33)SRE
12.2(33)SXI2
12.2(33)XNE
15.0(1)SNetwork deployments that use dual RP routers and switches have a graceful restart mechanism to protect forwarding states across a switchover. This feature enables BFD to maintain sessions in a up state across switchovers.
The following section provides information about this feature:
SSO—BFD (Admin Down)
12.2(33)SRC
15.0(1)STo support SSO, BFD sessions are placed in an "Admin Down" state during a planned switchover. The BFD configuration is synched from the active to standby processor, and all BFD clients re-register with the BFD process on the standby processor.
The following section provides information about this feature:
•
Static Routes for BFD
12.2(33)SRC 15.0(1)M
15.0(1)S
15.1(2)SUnlike dynamic routing protocols, such as OSPF and BGP, static routing has no method of peer discovery. Therefore, when BFD is configured, the reachability of the gateway is completely dependent on the state of the BFD session to the specified neighbor. Unless the BFD session is up, the gateway for the static route is considered unreachable, and therefore the affected routes will not be installed in the appropriate RIB.
A single BFD session can be used by an IPv4 static client to track the reachability of next hops through a specific interface. A BFD group can be assigned for a set of BFD-tracked static routes.
The following sections provide information about this feature:
•
•
•
The following commands were introduced or modified: ip route static bfd and show ip static route bfd.
BFD Hardware Offload for 7600
15.1(2)S
This feature supports offloading BFD sessions to ES+ line cards on Cisco 7600 series routers. The following commands were introduced or modified: show bfd neighbors details.
Cisco and the Cisco Logo are trademarks of Cisco Systems, Inc. and/or its affiliates in the U.S. and other countries. A listing of Cisco's trademarks can be found at www.cisco.com/go/trademarks. Third party trademarks mentioned 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. (1005R)
Any Internet Protocol (IP) addresses and phone numbers used in this document are not intended to be actual addresses and phone numbers. Any examples, command display output, network topology diagrams, and other figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses or phone numbers in illustrative content is unintentional and coincidental.
© 2008-2011 Cisco Systems, Inc. All rights reserved.
