Introduction
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 OR routing protocol levels. Cisco IOS-XR supports both asynchronous and ECHO 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 (and BFD peers). Once BFD has been enabled on the interfaces OR 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 if echo mode can be used, then after the session has transitioned to UP state, echo mode will begin.
BFD payload control packets are encapsulated in UDP packets, using destination port 3784 and source port 49152. On shared media, like Ethernet, BFD control packets are always sent as unicast packets to the BFD peer.
Echo packets are encapsulated in UDP packets, as well, using destination port 3785 and source port 3785.
In a nutshell, BFD provides fast BFD peer failure detection times independently of all media types, encapsulations, topologies, and routing protocols BGP, IS-IS, MPLS-TE and OSPF. By sending rapid failure detection notices to the routing protocols in the local router to initiate the routing table recalculation process, BFD reduces overall network convergence time. IOS-XR ASR9000 BFD implementation supports both Asynchronous and ECHO mode.
Note: IOS-XR does not support BFD Demand mode and also does not support BFD authentication as of this writing.)
Asynchronous Mode:
Asynchronous mode is the primary mode of operation and is mandatory. Asynchronous mode without echo will engage various pieces of packet switching paths on local and remote systems. However, asynchronous mode with echo is usually known to provide slightly wider test coverage as echo packets are self-destined packets which traverse same packet switching paths as normal traffic on the remote system.
BFD with Echo Packets
- For IPv4 on member links of BFD bundle interfaces.
- For IPv4 on other physical interfaces whose minimum interval is less than two seconds.
The control packets contain 2 interval values which we can tune in asynchronous mode
- Desired Minimum Transmit Interval. This is the minimum interval that the local system would like to use when transmitting BFD Control packets. When echo mode is in use or when the session is not up, the desired minimum transmit interval is set to the slow interval (hard-coded at 2 secs), this is because there is then no point in sending control packets at a fast rate. When the session is up and echo mode is not in use, the desired minimum transmit interval is set to the session’s desired interval but it cannot be smaller than 15 ms (hard-coded)
- Required Minimum Receive Interval. This is the minimum interval between received BFD Control packets that this system is capable of supporting. Set to the same value as the desired minimum transmit interval, this is mainly for session rate-limiting . One side-effect of using a low interval for control packets is that a BFD agent process restart may lead to a session flap.
Hence the actual tx interval for a control packets in a particular session is set to the maximum of:
Local Desired Minimum Transmit Interval and Remote Required Minimum Receive Interval.
This means that even if a node can transmit control packets at very small interval, it must transmit at an interval which the other end can tolerate.
BFD without Echo Packets
When BFD is running asynchronously without echo packets, here is the underlying process:
- Each system periodically sends BFD control packets to one another. Packets sent by BFD router "Peer A" to BFD router "Peer B" have a source address from Peer A and a destination address for Peer B.
- Control packet streams are independent of each other and do not work in a request/response model.
- If a number of packets in a row are not received by the other system, the session is declared down.
Echo Mode:
The echo mode, which is optional, is designed to test only the forwarding path (and not e.g. the host stack) on the remote system. It is used only when the session is up. IOS-XR Release 3.3.2 had added CLI to disable echo mode (to enable users to disable echo mode on routers or interfaces where BFS is used in conjunction with uRPF).
A node indicates whether it is willing or not to participate in echo mode via the “Required Min Echo RX Interval” field of control packets. A zero value indicates that the node is not willing to participate in echo mode and adjacent systems must not send echo packets to that node. The value of “Required Min Echo Receive Interval” is hard-coded to 1 milli-second. If echo mode is supported at each end, the actual echo tx interval for a session is the maximum of:
- Local Desired Echo Tx Interval. This value is not advertised in any packets, it is set to the session’s desired interval
- Remote Required Min Echo RX Interval. This is obtained from incoming control packets.
The echo failure detection interval for a session is set to the product of:
Actual echo tx interval for the session and Session detection multiplier
BFD echo packets are sent with the destination address set to the local interface address. This causes the other end to just loop back the echo packets through its forwarding path (just like any other “normal” data packet). Echo packets do not require any BFD or host-stack processing at the remote end, therefore the echo mode is truly testing only the forwarding path on the remote system. Since the sender of echo packets has (nearly) complete control of the response time, the echo mode can be used for more aggressive detection times. The payload of the echo packet is not specified since only the sender of the packet has to interpret the contents. Echo packets will contain the local discriminator and a sequence number (for stats).
BFD Peers on Routers Running Cisco IOS and Cisco IOS XR Software: Example
To configure BFD on a router interface on Router 1 that is running Cisco IOS software, and use the bfd neighbor command to designate the IP address 192.0.2.1 of an interface as its BFD peer on Router 2. Router 2 is running Cisco IOS XR software and uses the router static command and address-family ipv4 unicast command to designate the path back to Router 1's interface with IP address 192.0.2.2.
Router 1 (Cisco IOS software)
Router# configure
Router(config)# interface GigabitEthernet8/1/0
Router(config-if)# description to-TestBed1 G0/0/0/0
Router(config-if)# ip address 192.0.1.1 255.255.255.0
Router(config-if)# bfd interval 100 min_rx 100 multiplier 3
Router(config-if)# bfd neighbor 192.0.1.1
Router 2 (Cisco IOS XR Software)
RP/0/RSP0/CPU0:router# configure
RP/0/RSP0/CPU0:router(config)# router static
RP/0/RSP0/CPU0:router(config-static)# address-family ipv4 unicast
RP/0/RSP0/CPU0:router(config-static-afi)# 10.10.10.10/32 192.0.2.2 bfd fast-detect
RP/0/RSP0/CPU0:router(config-static-afi)# exit
RP/0/RSP0/CPU0:router(config-static)# exit
RP/0/RSP0/CPU0:router(config)# interface GigabitEthernet0/0/0/0
RP/0/RSP0/CPU0:router(config-if)# ipv4 address 192.0.1.1 255.255.255.0
Comparison with IOS
- IOS only supports ASYNC mode with 50 ms minimum interval with a multiplier of 3, up to 100 sessions per LC and 200 sessions per box.
- IOX can turn off ECHO mode once negotiated in case neighbor only supports ASYNC mode (Like JUNOS/IOS and HUAWEI)
- IOS-XR BFD implementation is hitless and field upgradable.
- In Cisco IOS XR software, BFD is an application that is configured under a dynamic routing protocol, such as an OSPF or BGP instance. This is not the case for BFD in Cisco IOS software, where BFD is only configured on an interface.
- In Cisco IOS XR software, a BFD neighbor is established through routing. The Cisco IOS bfd neighbor interface configuration command is not supported in Cisco IOS XR software.
- Instead of using a dynamic routing protocol to establish a BFD neighbor, you can establish a specific BFD peer or neighbor for BFD responses in Cisco IOS XR software using a method of static routing to define that path. In fact, you must configure a static route for BFD if you do not configure BFD under a dynamic routing protocol in Cisco IOS XR software
- A router running BFD in Cisco IOS software can designate a router running BFD in Cisco IOS XR software as its peer using the bfd neighbor command; the Cisco IOS XR router must use dynamic routing or a static route back to the Cisco IOS router to establish the peer relationship.
Restrictions for Configuring BFD
The following restrictions apply to BFD:
- Demand mode is not supported in Cisco IOS XR software.
- BFD echo mode is not supported for the following applications:
- BFD for IPv4 on bundled VLANs.
- BFD for IPv6 (global and link-local addressing)
- BFD with uRPF (IPv4 or IPv6)
- Rack reload and online insertion and removal (OIR) when a BFD bundle interface has member links that span multiple racks.
- BFD for IPv6 has the following restrictions:
- BFD for IPv6 is not supported on bundled VLAN interfaces.
- BFD for IPv6 is supported only in asynchronous non-echo mode.
- BFD for IPv6 static routes are only supported by the client.
- Only the static, OSPF, and IS-IS applications are supported on BFD over bundled VLANs.
- BFD under BGP with IPv4 over Ethernet VLAN bundle subinterfaces is not supported.
- For BFD on bundle member links, only a single BFD session for each bundle member link is created, monitored, and maintained for the IPv4 addressing type only. IPv6 and VLAN links in a bundle have the following restrictions:
- IPv6 states are not explicitly monitored on a bundle member and they inherit the state of the IPv4 BFD session for that member interface.
- VLAN subinterfaces on a bundle member also inherit the BFD state from the IPv4 BFD session for that member interface. VLAN subinterfaces are not explicitly monitored on a bundle member.
- Echo latency detection and echo validation are not supported on bundle interfaces.
BFD on Bundled VLANs
BFD is supported on bundled VLANS using static routing, IS-IS, and OSPF. When running a BFD session on a bundled VLAN interface, the BFD session is active as long as the VLAN bundle is up.
As long as the VLAN bundle is active, the following events do not cause the BFD session to fail:
- Failure of a component link.
- Online insertion and removal (OIR) of a line card which hosts one or more of the component links.
- Addition of a component link (by configuration) to the bundle.
- Removal of a component link (by configuration) from the bundle.
- Shutdown of a component link.
- RP switchover.
For information on how to configure VLAN bundle visit the below url:
BFD Over Member Links on Link Bundles (new feature)
From Cisco IOS XR Release 4.0.1 onwards, the BFD feature supports BFD sessions on individual physical bundle member links to monitor Layer 3 connectivity on those links, rather than just at a single bundle member as in prior releases
When you run BFD on link bundles, you can run an independent BFD session on each underlying physical interface that is part of that bundle.
When BFD is running on a link bundle member, the following layers of connectivity are effectively tested as part of the interface state monitoring for BFD:
- Layer 1 physical state
- Layer 2 Link Access Control Protocol (LACP) state
- Layer 3 BFD state
The BFD agent on each bundle member link monitors state changes on the link. BFD agents for sessions running on bundle member links communicate with a bundle manager. The bundle manager determines the state of member links and the overall availability of the bundle. The state of the member links contributes to the overall state of the bundle based on the threshold of minimum active links or minimum active bandwidth that is configured for that bundle.
BFD on Bundle Member Links: Example :
bfd
interface Bundle-Ether4
echo disable
!
interface GigabitEthernet0/0/0/2.3
echo disable
!
!
interface GigabitEthernet0/0/0/3 bundle id 1 mode active
interface GigabitEthernet0/0/0/4 bundle id 2 mode active
interface GigabitEthernet0/1/0/2 bundle id 3 mode active
interface GigabitEthernet0/1/0/3 bundle id 4 mode active
interface Bundle-Ether1
ipv4 address 192.168.1.1/30
bundle minimum-active links 1
!
interface Bundle-Ether1.1
ipv4 address 192.168.100.1/30
dot1q vlan 1001
!
interface Bundle-Ether2
bfd address-family ipv4 destination 192.168.2.2
bfd address-family ipv4 fast-detect
bfd address-family ipv4 min 83
bfd address-family ipv4 mul 3
ipv4 address 192.168.2.1/30
bundle minimum-active links 1
!
interface Bundle-Ether3
bfd address-family ipv4 destination 192.168.3.2
bfd address-family ipv4 fast-detect
bfd address-family ipv4 min 83
bfd address-family ipv4 mul 3
ipv4 address 192.168.3.1/30
bundle minimum-active links 1
!
interface Bundle-Ether4
bfd address-family ipv4 destination 192.168.4.2
bfd address-family ipv4 fast-detect
bfd address-family ipv4 min 83
bfd address-family ipv4 mul 3
ipv4 address 192.168.4.1/30
bundle minimum-active links 1
!
interface GigabitEthernet 0/0/0/2
ipv4 address 192.168.10.1/30
!
interface GigabitEthernet 0/0/0/2.1
ipv4 address 192.168.11.1/30
dot1q vlan 2001
!
interface GigabitEthernet 0/0/0/2.2
ipv4 address 192.168.12.1/30
dot1q vlan 2002
!
interface GigabitEthernet 0/0/0/2.3
ipv4 address 192.168.13.1/30
dot1q vlan 2003
!
router static
address-family ipv4 unicast
10.10.11.2/32 192.168.11.2 bfd fast-detect minimum-interval 250 multiplier 3
10.10.12.2/32 192.168.12.2 bfd fast-detect minimum-interval 250 multiplier 3
10.10.13.2/32 192.168.13.2 bfd fast-detect minimum-interval 250 multiplier 3
10.10.100.2/32 192.168.100.2 bfd fast-detect minimum-interval 250 multiplier 3
!
Overview of BFD State Change Behavior on Member Links and Bundle Status
This section describes when bundle member link states are characterized as active or down, and their effect on the overall bundle status:
- Description: You can configure BFD on a bundle member interface that is already active or one that is inactive. For the BFD session to be up using LACP on the interface, LACP must have reached the distributing state.
Note:
- A BFD member link is "IIR Active" if the link is in LACP distributing state and the BFD session is up.
- A BFD member link is "IIR Attached" when the BFD session is down, unless a LACP state transition is received.
- You can configure timers for up to 3600 seconds (1 hour) to allow for delays in receipt of BFD state change notifications (SCNs) from peers before declaring a link bundle BFD session down.
The configurable timers apply to the following situations:
- Description: BFD session startup (bfd address-family ipv4 timers start command)—Number of seconds to allow after startup of a BFD member link session for the expected notification from the BFD peer to be received to declare the session up. If the SCN is not received after that period of time, the BFD session is declared down.
- Description: Notification of removal of BFD configuration by a neighbor (bfd address-family ipv4 timers nbr-unconfig command)—Number of seconds to allow after receipt of notification that BFD configuration has been removed by a BFD neighbor so that any configuration inconsistency between the BFD peers can be fixed. If the BFD configuration issue is not resolved before the specified timer is reached, the BFD session is declared down.
- Description: A BFD session sends a DOWN notification when one of the following occurs:
- Description: The BFD configuration is removed on the local member link.
The BFD system notifies the peer on the neighbor router that the configuration is removed. The BFD session is removed from the bundle manager without affecting other bundle member interfaces or the overall bundle state.
- Description: The BFD configuration is removed on a neighboring router and the neighbor configuration timer (if configured) expires.
The BFD system notifies the bundle manager that the BFD configuration has been removed on the neighboring router and, if bfd timers nbr-unconfig is configured on the link, the timer is started. If the BFD configuration is removed on the local router before the timer expires, then the timer is stopped and the behavior is as expected for BFD configuration removal on the local router.
If the timer expires, then the behavior is the same as for a BFD session DOWN notification.
- Description: The session startup timer expires before notification from the BFD peer is received.
- Description: A member link is removed from the bundle.
Removing a member link from a bundle causes the bundle member to be removed ungracefully. The BFD session is deleted and BFD on the neighboring router marks the session DOWN rather than NBR_CONFIG_DOWN.
- Description: The BFD session on a bundle member sends BFD state change notifications to the bundle manager. Once BFD state change notifications for bundle member interfaces are received by the bundle manager, the bundle manager determines whether or not the corresponding bundle interface is usable.
- Description: A threshold for the minimum number of active member links on a bundle is used by the bundle manager to determine whether the bundle remains active or is down based on the state of its member links. When BFD is started on a bundle that is already active, the threshold is set according to all active members that are in an active BFD state. Otherwise, the threshold is set by the user-configurable bundle minimum-active links command.
Whenever a member's state changes, the bundle manager determines if the number of active members is less than the minimum number of active links threshold. If so, then the bundle is placed, or remains, in DOWN state. Once the number of active links reaches the minimum threshold then the bundle returns to UP state.
- Description: Another threshold is configurable on the bundle and is used by the bundle manager to determine the minimum amount of active bandwidth to be available before the bundle goes to DOWN state. This is configured using the bundle minimum-active bandwidth command.
- Description: The bundle server responds to information from the bundle manager about state changes for the bundle interface and notifies applications on that interface while also sending system messages and MIB traps.
- Description: The BFD bundle manager also supports fast-protect events on the bundle interface (not the member interface). When enough bundle member links go to DOWN state to take the bundle interface out of service, the bundle manager generates a PROT_IF_DOWN fast-protect event. This fast-protect event quickly notifies the Forwarding Information Base (FIB) to update the forwarding tables. The BFD server can also generate a PROT_BFD_SESSION_DOWN fast-protect event for the bundle interface.
Note:
Description: PROT_IF_DOWN messages are generated before PROT_BFD_SESSION_DOWN fast-protect messages. Therefore, on bundle interfaces with applications that have registered both PROT_IF_DOWN and PROT_BFD_SESSION_DOWN fast-protect events, you should plan to trigger necessary actions based on receipt of PROT_IF_DOWN fast-protect events.
BFD Timer Values on a Cisco 7600 Series Router as a comparison
Related Information
Cisco IOS XR Link bundle Guide, Cisco IOS XR Release 4.0
Cisco IOS XR Software Release 4.0 : Configuring BFD on Dynamic RP, Static Routes, Bundles VLAN’s
Cisco IOS XR Software Release 4.0- Command reference
http://www.cisco.com/en/US/products/ps5845/prod_command_reference_list.html
---------------------------------------------------------------------------------------------------------------------------------
Written By-
Network Consulting Engineer
Advanced Services
Cisco Systems
