Routing Configuration Guide for Cisco 8000 Series Routers, Cisco IOS XR Release

PDF

Feature-specific integrations for BFD

Updated: June 30, 2026

Want to summarize with AI?

Describes how BFD integrates with specialized transport and forwarding environments such as MPLS TE, VXLAN, BVI, and PWHE, along with related platform-specific features and operational considerations.

Provides details on BFD integration with specific technologies, including configuration and verification procedures for fast failure detection.

BFD with MPLS Traffic Engineering (RSVP-TE)

This section describes the configuration and management of BFD for MPLS Traffic Engineering tunnels, including the adjustment of timers, dampening, and monitoring parameters.

BFD supports MPLS Traffic Engineering (TE) tunnels to enable fast failure detection for label-switched paths (LSPs). You can configure BFD for TE tunnels, including head-end and tail-end operations, and tune parameters such as timers, dampening, and monitoring.

BFD hardware offload for RSVP tail-end

BFD hardware offload for RSVP tail-end is a mechanism that

offloads BFD control packet processing from the CPU to hardware for high-scale monitoring of MPLS LSP data plane health
supports rapid failure detection for a large number of LSPs, and
reduces CPU overhead compared to traditional LSP ping-based verification.

Table 1. Feature History Table
Feature Name	Release	Description
BFD hardware offload for resource reservation protocol tail-end	Release 25.1.1	Introduced in this release on: Fixed Systems (8010 [ASIC: A100])(select variants only) This feature is supported on Cisco 8011-4G24Y4H-I routers.
BFD hardware offload for resource reservation protocol tail-end	Release 24.4.1	Introduced in this release on: Fixed Systems (8200 [ASIC: P100], 8700 [ASIC: P100, K100])(select variants only); Modular Systems (8800 [LC ASIC: P100])(select variants only) This feature is supported on: 8212-48FH-M, 8711-32FH-M, 8712-MOD-M, 88-LC1-36EH, 88-LC1-12TH24FH-E, 88-LC1-52Y8H-EM.
BFD hardware offload for resource reservation protocol tail-end	Release 7.9.1	Initial support for BFD over Tail-End LSP feature.

Use Bidirectional Forwarding Detection (BFD) to detect Multiprotocol Label Switching (MPLS) Label Switched Path (LSP) data-plane failures. Use an LSP ping request to detect MPLS data-plane failures and to verify the data plane against the control plane. BFD does not verify the data plane against the control plane. However, BFD control packets require less control-plane processing than LSP ping messages. As a result, you can use BFD for faster detection of data-plane failures across many LSPs.

This feature improves scale and reduces overall network convergence time by sending rapid failure-detection packets to routing protocols so they can recalculate the routing table.

BFD over MPLS Traffic Engineering LSPs

The BFD over MPLS TE LSPs feature provides a mechanism for detecting MPLS data plane failures using BFD, which requires less control plane processing than LSP Ping messages. This implementation is based on RFC 5884 and supports faster data plane failure detection when combined with LSP Ping.

BFD over MPLS tail-end LSPs supports these features:

BFD asynchronous mode. (BFD echo mode is not supported.)
IPv4 only, because the MPLS core uses IPv4.
BFD packets with IP DSCP 6 (Internet Control).
BFD for TE tunnel bring-up, reoptimization, and path protection, including standby and FRR.
A fast detection time of 9 ms by using a 3 ms interval and a multiplier of 3.
Optional periodic LSP ping verification after the BFD session comes up.
Dampening to hold down a BFD failed path option.

The BFD process interacts with the tail-end and LSPV processes to support the BFD over TE LSP feature, where BFD packets from tail-end to head-end are handled in two ways:

BFD packets from tail-end to head-end are IP routed .
BFD packets from tail-end to head-end are label switched if MPLS LDP is available in the core with a label path from tail-end to head-end.

Configure BFD over MPLS TE tunnels

BFD for TE tunnel is enabled at the head-end by configuring BFD parameters under the tunnel. When BFD is enabled on the already up tunnel, TE waits for the bringup timeout before bringing down the tunnel.

Note

BFD paces the creation of BFD sessions by limiting LSP ping messages to be under 50 PPS to avoid variations in CPU usage.

Procedure

	1.	Enter global configuration mode and configure MPLS OAM. Example: `Router# config Router(config)# mpls oam`
	2.	Configure MPLS TE tunnel interface and enter MPLS TE tunnel interface configuration mode. Example: `Router(config)#interface tunnel-te 65535`
	3.	Enable BFD fast detection. Example: `Router(config-if)#bfd fast-detect`
	4.	Configure hello interval in milliseconds. Example: `Router(config-if)#bfd minimum-interval 500` Note Hello interval range is 3 to 1000 milliseconds. Default hello interval is 100 milliseconds.
	5.	Configure BFD multiplier detection. Example: `Router(config-if)#bfd multiplier 5 Router(config-if)#commit` Note BFD multiplier range is 3 to 10. Default BFD multiplier is 3.

Configure BFD bring up timeout

Procedure

	1.	Enter global configuration mode and configure MPLS OAM. Example: `Router# config Router(config)# mpls oam`
	2.	Configure MPLS TE tunnel interface and enter MPLS TE tunnel interface configuration mode. Example: `Router(config)#interface tunnel-te 65535`
	3.	Configure the time interval in seconds to wait for the BFD session to come up. Example: `Router(config-if)#bfd bringup-timeout 2400 Router(config-if)#commit` Note The timeout range is 6 to 3600 seconds. Default bring up timeout interval is 60 seconds.

Configure BFD dampening for TE tunnels

When BFD session fails to come up, TE exponentially backs off using the failed path-option to avoid signaling churn in the network.

Procedure

	1.	Enter global configuration mode and configure MPLS OAM. Example: `Router# config Router(config)# mpls oam`
	2.	Configure MPLS TE tunnel interface and enter MPLS TE tunnel interface configuration mode. Example: `Router(config)#interface tunnel-te 65535`
	3.	Configure the initial delay interval before bringing up the tunnel. Example: `Router(config-if)#bfd dampening initial-wait 360000` Note The initial-wait bring-up delay range is 1 to 518,400,000 milliseconds. The default initial-wait interval is 16,000 milliseconds.
	4.	Configure the maximum delay interval before bringing up the tunnel. Example: `Router(config-if)#bfd dampening maximum-wait 700000` Note The maximum-wait bring-up delay range is 1 to 518,400,000 milliseconds. The default maximum-wait interval is 600,000 milliseconds.
	5.	Configure the secondary delay interval before bringing up the tunnel. Example: `Router(config-if)#bfd dampening secondary-wait 30000 Router(config-if)#commit` Note The secondary-wait bring-up delay range is 1 to 518,400,000 milliseconds. The default secondary-wait interval is 20,000 milliseconds.

Configure periodic LSP ping requests

Procedure

	1.	Configure MPLS TE tunnel interface and enter MPLS TE tunnel interface configuration mode. Example: `Router# config Router(config)#interface tunnel-te 65535`
	2.	Set the periodic interval for LSP ping requests in seconds. Example: `Router(config-if)#bfd lsp-ping interval 300 Router(config-if)#commit` Note The interval range is 60 to 3,600 seconds. Default interval is 120 seconds.

Configure BFD at the tail-end

The ranges and default values are the same as the BFD head-end configuration values.

Procedure

	1.	Enter global configuration mode and configure MPLS OAM. Example: `Router# config Router(config)# mpls oam`
	2.	Configure hello interval in milliseconds. Example: `Router(config)#mpls traffic-eng bfd lsp tail minimum-interval 500` Note Hello interval range is 3 to 1,000 milliseconds. The default hello interval is 100 milliseconds.
	3.	Configure BFD multiplier detection. Example: `Router(config)#mpls traffic-eng bfd lsp tail multiplier 5 Router(config-if)#commit` Note BFD multiplier detect range is 3 to 10. The default BFD multiplier is 3.

Configure BFD over LSP sessions on line cards

BFD over LSP sessions, including head-end and tail-end sessions, are hosted on line cards with this configuration enabled.

Note

On fixed and centralized platforms, there are no line cards (LCs) in the data path. BFD sessions run on the routing processors (RPs). On fixed platforms, specify the RP location in the configuration. On centralized platforms, RP locations cannot be used in the configuration even though BFD runs on the RPs. Instead, you must specify a valid MPA location, such as 0/1, for BFD multipath configuration. LC locations, such as 0/1/CPU0, are not supported and must not be used.

Procedure

In BFD configuration mode, configure BFD multiple path on a specific line card.

Example:

Router# configure
Router(config)# bfd
Router(config-bfd)# multipath include location 0/1/CPU0
Router(config-if)#commit

Configure BFD over MPLS TE tunnel tail-end

Procedure

	1.	Enter global configuration mode. Example: `Router# configure terminal`
	2.	Configure the BFD minimum interval for the MPLS TE LSP tail-end. Example: `Router(config)# mpls traffic-eng bfd lsp tail minimum-interval 3 Router(config)# commit`
	3.	Run the show bfd session command to verify the configuration on the tail-end. Example: `Router# show bfd session Src Addr Dest Addr VRF Name Type Specific Data Local det time(intmult) State H/W NPU Echo Async ------------------- --------------- ---------------- ---------------- ---------- 1.1.1.1 2.2.2.2 default TT32768 (LSP:2) n/a 1500ms(500ms3) UP`
	4.	Run the show bfd label session command to verify the configuration on the head-end. Example: `Router# show bfd label session Interface Label Local det time(intmult) State Echo Async H/W NPU ------------------- --------------- ---------------- ---------------- ---------- tt1 (LSP:103) 24001 n/a 150ms(50ms3) UP Yes 0/1/CPU0 tt2 (LSP:102) 24002 n/a 150ms(50ms3) UP Yes 0/1/CPU0 tt3 (LSP:101) 24004 n/a 150ms(50ms3) UP Yes 0/1/CPU0 tt4 (LSP:103) 24005 n/a 150ms(50ms3) UP Yes 0/1/CPU0 tt5 (L P:104) 24006 n/a 150ms(50ms3) UP Yes 0/1/CPU0`

BFD over VXLAN deployments

This topic provides configuration details, restrictions, and examples for deploying BFD in VXLAN environments.

Bidirectional forwarding detection over VXLAN tunnels

Bidirectional forwarding detection over VXLAN is a monitoring mechanism that

detects failures in VXLAN tunnels to improve network reliability
provides rapid detection of Layer 2 data plane failures, and
supports integration with BGP or static routes for path management and fast rerouting.

Table 2. Feature History Table
Feature Name	Release Information	Feature Description
Bidirectional forwarding detection over VXLAN tunnel	Release 25.1.1	Introduced in this release on: Fixed Systems (8700 [ASIC: K100], 8010 [ASIC: A100])(select variants only) This feature is supported on: 8712-MOD-M 8011-4G24Y4H-I
Bidirectional forwarding detection over VXLAN tunnel	Release 24.4.1	Introduced in this release on: Fixed Systems (8200 [ASIC: P100], 8700 [ASIC: P100])(select variants only); Modular Systems (8800 [LC ASIC: P100])(select variants only) *This feature is supported on: 8212-48FH-M 8711-32FH-M 88-LC1-36EH 88-LC1-12TH24FH-E 88-LC1-52Y8H-EM
Bidirectional forwarding detection over VXLAN tunnel	Release 24.2.11	You can now monitor the health of VXLAN tunnel and detect failures in the tunnel rapidly which ensures faster rerouting of traffic, resulting in high availability of networks.

Note

BFD over VXLAN with BGP supports up to 2000 BFD sessions (IPv4 and IPv6 combined), while BFD over VXLAN on static routes supports up to 10,000 BFD sessions (up to 10 percent IPv6 and 90 percent IPv4).

How VXLAN network traffic management works

A VXLAN network encapsulates network traffic to form secure tunnels across the Layer 3 physical infrastructure. These tunnels maintain traffic privacy and security by isolating data from the internal domain network.

Summary

These are the key components involved in the process:

VXLAN: Encapsulates traffic and performs load balancing to maintain performance.
BGP or static routes: Facilitates the sharing of route information.
BFD: Monitors tunnels to detect link failures and trigger rerouting.

Workflow

These stages describe the operational flow of VXLAN traffic management.

Traffic distribution and routing configuration.
- VXLAN load balancing distributes data packets to maintain performance as traffic volume increases.
- Route information is shared using either BGP for dynamic learning or static routes for predefined paths.

Failure detection and recovery.


When...	And...	Then...	And...
A link failure occurs	BFD is integrated	BFD detects the failure	Traffic is rerouted to minimize downtime

Restrictions for BFD over VXLAN

Use multihop BFD sessions to achieve the maximum supported scale. Maintain a distribution ratio of 90 percent IPv4 sessions to 10 percent IPv6 sessions to ensure the maximum supported scale is attainable.

The maximum supported scale is 10,000 BFD sessions, supported only on Cisco 8100 and 8200 series routers.
The maximum supported scale may not be attainable if the configuration includes other types of BFD sessions or if the proportion of IPv6 sessions exceeds 10 percent.

Operate BFD over VXLAN exclusively in BFD asynchronous mode; echo mode is not supported.
Avoid the parallel operation of BFD over VXLAN with static routes at a scale of up to 10,000 sessions alongside BFD over VXLAN with BGP, as this configuration is not supported.
Configure a minimum-interval value greater than 300 milliseconds for software-based BFD sessions to maintain stability at higher scales.
Keep the maximum rate in packets-per-second (PPS) for BFD sessions below 80% to ensure session stability.

Exceeding the 80% PPS threshold may result in unstable sessions.
Use the show bfd summary command to monitor the current PPS percentage.

Configure BFD over VXLAN

This topic provides the configuration scenarios for implementing BFD over VXLAN.

The BFD over VXLAN feature can be configured for these scenarios:

BFD over VXLAN with BGP
BFD over VXLAN with static routes

Configure BFD over VXLAN with BGP

The configuration of BFD over VXLAN with BGP includes these steps:

VRF configuration
Multipath BFD sessions configuration
Interfaces configuration
Interface NVE configuration
BGP configuration
BFD configuration

Procedure

	1.	Configure the VRF. Example: `Router# configure Router(config)# vrf vrf1 Router(config-vrf)# exit`
	2.	Configure the multipath BFD sessions. Example: `Router# configure Router(config)# bfd Router(config-bfd)# multipath include location 0/0/CPU0 Router(config-bfd)# exit`
	3.	Configure the interfaces. Example: `Router(config)# interface Loopback 0 Router(config-if)# ipv4 address 10.10.10.10 255.0.0.0 Router(config-if)# exit Router(config)# interface Loopback 1 Router(config-if)# vrf vrf1 Router(config-if)# ipv4 address 192.168.0.0 255.255.0.0 Router(config-if)# exit`
	4.	Configure interface NVE for decapsulation. Example: `Router(config)# interface nve1 Router(config-if)# member vni 2 Router(config-nve-vni)# vrf vrf1 Router(config-nve-vni)# host-reachability protocol static Router(config-nve-vni)# exit Router(config-if)# overlay-encapsulation vxlan outer(config-nve-encap-vxlan)# peer-ip lookup disable Router(config-nve-encap-vxlan)# exit Router(config-if)# source-interface Loopback1 Router(config-if)# commit`
	5.	Configure BGP. Example: Router(config)# router bgp 1 Router(config-bgp)# bgp router-id 10.10.10.10 Router(config-bgp)# address-family ipv4 unicast Router(config-bgp-af)# redistribute connected Router(config-bgp-af)# exit Router(config-bgp)# address-family ipv4 unicast Router(config-bgp)# exit Router(config)# router bgp 1 Router(config-bgp)# vrf vrf1 Router(config-bgp-vrf)# rd auto Router(config-bgp-vrf)# address-family ipv4 unicast Router(config-bgp-vrf-af)# redistribute connected Router(config-bgp-vrf-af)# redistribute static Router(config-bgp-vrf-af)# exit
	6.	Configure BFD over BGP. Example: Router(config)# router bgp 1 Router(config-bgp)# neighbor 10.6.6.1 Router(config-bgp-nbr)# bfd fast-detect Router(config-bgp-nbr)# bfd multiplier 7 Router(config-bgp-nbr)# bfd minimum-interval 1200 Router(config-bgp-nbr)# remote-as 300 Router(config-bgp-nbr)# ebgp-multihop 255 Router(config-bgp-nbr)# update-source loopback 1 Router(config-bgp-nbr)# address-family ipv4 unicast Router(config-bgp-nbr-af)# route-policy pass-all in Router(config-bgp-nbr-af)# route-policy pass-all out Router(config-bgp-nbr-af)# commit

Configure BFD over VXLAN with static routes

The configuration of BFD over VXLAN with static routes includes these steps:

VRF configuration
Multipath BFD sessions configuration
Interfaces configuration
Interface NVE configuration
Static routing configuration

Procedure

	1.	Configure the VRF. Example: `Router# configure Router(config)# vrf vrf1 Router(config-vrf)# exit`
	2.	Configure the multipath BFD sessions. Example: `Router# configure Router(config)# bfd Router(config-bfd)# multipath include location 0/0/CPU0 Router(config-bfd)# exit`
	3.	Configure the interfaces. Example: `Router(config)# interface Loopback 0 Router(config-if)# ipv4 address 10.10.10.10 255.0.0.0 Router(config-if)# ipv6 address 2001:DB8:1::1/32 Router(config-if)# exit Router(config)# interface Loopback 1 Router(config-if)# vrf vrf1 Router(config-if)# ipv4 address 192.168.0.0 255.255.0.0 Router(config-if)# exit Router(config)# interface TenGigE0/0/0/0/0 Router(config-if)# ipv4 address 10.12.13.10 255.0.0.0 Router(config-if)# ipv6 address 2001:DB8:13::11/16 Router(config-if)# exit`
	4.	Configure the interface NVE for decapsulation. Example: `Router(config)# interface nve1 Router(config-if)# member vni 2 Router(config-nve-vni)# vrf vrf1 Router(config-nve-vni)# host-reachability protocol static Router(config-nve-vni)# exit Router(config-if)# overlay-encapsulation vxlan Router(config-nve-encap-vxlan)# exit Router(config-if)# source-interface Loopback1 Router(config-if)# commit`
	5.	Configure the static routes. Example: Router# configure Router(config)# router static Router(config-static)# address-family ipv4 unicast Router(config-static-afi)# 10.10.10.10/32 10.151.11.2 Router(config-static-afi)# exit Router(config-static)# address-family ipv6 unicast Router(config-static-afi)# 2001:DB8:1::12/32 2001:DB8:17::122 Router(config-static-afi)# exit Router(config-static)# vrf VRF1 Router(config-static-vrf)# address-family ipv4 unicast Router(config-static-vrf-afi)# 10.1.1.1/32 remote-next-hop 10.13.19.10 tunnel VXLAN index 1 nve 1 evni 1 src-mac aaa1.bbb1.ccc1 -> IPv4 over IPv4 Router(config-static-vrf-afi)# 209.165.201.0/27 10.1.1.1 bfd fast-detect minimum-interval 1000 multihop 192.168.0.0 Router(config-static-vrf-afi)# 10.12.12.12/32 remote-next-hop 10.13.19.10 tunnel VXLAN index 2 nve 1 evni 2 src-mac aaa1.bbb1.ccc2 -> IPv4 over IPv4 Router(config-static-vrf-afi)# 209.165.202.129/27 10.12.12.12 bfd fast-detect minimum-interval 1000 multihop 192.168.12.24 Router(config-static-vrf-afi)# exit
	6.	Verify the BFD session details using these commands. `Router# show bfd all Tue Dec 12 10:07:03.395 UTC IPv4: ----- IPV4 Sessions Up: 7200, Down: 0, Unknown/Retry: 2000, Total: 9200 IPv6: ----- IPV6 Sessions Up: 800, Down: 0, Unknown/Retry: 0, Total: 800 Label: ------ Label Sessions Up: 0, Down: 0, Unknown/Retry: 0, Total: 0` Router# show bfd ipv6 multihop session Tue Mar 26 19:32:14.851 UTC Src Addr Dest Addr VRF Name Local det time(intmult) State Echo Async H/W NPU ------------------- --------------- ---------------- ---------------- ---------- 2001:DB8:0000::1 2001:DB8:FFF::1 vrf5001 0s(0s0) 3s(1s3) UP Yes 0/RP0/CPU0 2001:DB8:0000::2 2001:DB8:FFF::2 vrf5002 0s(0s0) 3s(1s3) UP Yes 0/RP0/CPU0 2001:DB8:0000::3 2001:DB8:FFF::3 vrf5003 0s(0s0) 3s(1s3) UP Yes 0/RP0/CPU0 2001:DB8:0000::4 2001:DB8:FFF::4 vrf5004 0s(0s0) 3s(1s3) UP Yes 0/RP0/CPU0 2001:DB8:0000::5 2001:DB8:FFF::5 vrf5005 0s(0s0) 3s(1s3) UP Yes 0/RP0/CPU0 2001:DB8:0000::6 2001:DB8:FFF::6 vrf5006 0s(0s0) 3s(1s3) UP Yes 0/RP0/CPU0 2001:DB8:0000::7 2001:DB8:FFF::7 vrf5007 0s(0s0) 3s(1s3) UP Yes 0/RP0/CPU0 2001:DB8:0000::8 2001:DB8:FFF::8 vrf5008 0s(0s0) 3s(1s3) UP Router# show bfd session Tue Mar 26 19:32:00.554 UTC Src Addr Dest Addr VRF Name H/W NPU Local det time(intmult) State Echo Async ------------------- --------------- ---------------- ---------------- ---------- 209.165.201.1 10.0.0.1 vrf5001 Yes 0/RP0/CPU0 n/a 3s(1s3) UP 209.165.201.2 10.0.0.2 vrf5002 Yes 0/RP0/CPU0 n/a 3s(1s3) UP 209.165.201.3 10.0.0.3 vrf5003 Yes 0/RP0/CPU0 n/a 3s(1s3) UP 209.165.201.4 10.0.0.4 vrf5004 Yes 0/RP0/CPU0 n/a 3s(1s3) UP 209.165.201.5 10.0.0.5 vrf5005 Yes 0/RP0/CPU0 n/a 3s(1s3) UP 209.165.201.6 10.0.0.6 vrf5006 Yes 0/RP0/CPU0 n/a 3s(1s3) UP 209.165.201.7 10.0.0.7 vrf5007 Yes 0/RP0/CPU0 n/a 3s(1s*3) UP

BFD on BVI interfaces

Provides configuration and platform-specific considerations for implementing BFD on BVI interfaces.

Bidirectional forwarding detection on BVI

Bidirectional forwarding detection on Bridge Group Virtual Interface (BVI) is a network protocol enhancement that

detects path failures between routers in an integrated routing and bridging deployment
provides low-overhead path failure detection, and
supports multipath single-hop sessions over virtual interfaces or interfaces multiple hops away.

Table 3. Feature History Table
Feature Name	Release Information	Feature Description
Bidirectional forwarding detection on BVI	Release 25.4.1	Introduced in this release on: Fixed Systems (8700 [ASIC: K100])(select variants only) This feature is supported on: 8711-48Z-M 8712-MOD-M
Bidirectional forwarding detection on BVI	Release 25.3.1	Introduced in this release on: Fixed Systems (8200 [ASIC: P100], 8700 [ASIC: P100]; Modular Systems (8800 [LC ASIC: P100]) This feature is supported on: 8212-48FH-M 8711-32FH-M 88-LC1-36EH 88-LC1-12TH24FH-E 88-LC1-52Y8H-EM
Bidirectional forwarding detection on BVI	Release 7.10.1	Now you can extend the advantage of low-overhead and short-duration detection of path failures between routers to an Integrated Routing and Bridging (IRB) deployment scenario by configuring Bidirectional Forwarding Detection (BFD) on multipath single-hop sessions using Bridge-Group Virtual Interface (BVI). By configuring BFD on a multipath session, you can apply BFD over virtual interfaces or between interfaces that are multiple hops away.

BVI routing context

To establish a VLAN that extends across a router, the router actively forwards frames between interfaces while maintaining the integrity of the VLAN header. When configured for Layer 3 routing, the router terminates the VLAN and MAC layers at the arrival interface. BFD on BVI allows the maintenance of MAC layer header information by bridging the network layer protocol.

Role of IRB in VLAN spanning

VLANs segment a network by creating separate broadcast domains. To carry traffic for multiple VLANs over a single link, enable VLAN trunking. This capability lets the network extend VLAN connectivity across the link.

In VLAN deployments that include multiple routers, preserve the VLAN tags so the VLANs can extend across the network. Routers usually replace the VLAN header with a new header, whether they route or bridge the traffic. This behavior can prevent VLAN extension and reduce support for trunking and traffic bridging between VLANs.

Integrated Routing and Bridging (IRB) lets a router interface route and bridge traffic at the same time while preserving VLAN header information across routers. This behavior helps maintain VLAN extension in more complex networks.

Integrated routing and bridging

Use Integrated Routing and Bridging (IRB) to configure a router to route and bridge a network layer protocol on the same interface. This configuration preserves the VLAN header as the frame passes through the router. IRB uses a Bridge Group Virtual Interface (BVI) to route traffic between bridged and routed domains. The BVI is a virtual routed interface that represents the bridge group in the router. The BVI number matches the bridge group number.

To use the BVI as a routed interface, configure only Layer 3 attributes on it, such as network layer addresses. Do not configure Layer 3 attributes on interfaces that you use for protocol bridging.

BFD over IRB

BFD over IRB uses a Bridge Group Virtual Interface (BVI) to establish a multipath single-hop BFD session. In a BFD multipath session, BFD can monitor virtual interfaces and interfaces that are multiple hops away. This feature follows RFC 5883, Bidirectional Forwarding Detection (BFD) for Multihop Paths. It extends BFD low overhead and fast path-failure detection to IRB deployments.

BFD over BVI supports IPv4 addresses and IPv6 global addresses. This feature supports only asynchronous mode. Echo mode is not supported.

Restrictions of BFD over BVI

BFD over BVI does not support IS-IS or OSPFv3 clients because these protocols require IPv6 link-local addresses, which this feature does not support.
BFD over BVI does not support bundles or bundle subinterfaces. It supports only physical interfaces and physical subinterfaces.
BFD over BVI does not support the HSRP client.
On P100, K100, and A100 systems, BFD over BVI supports only two-pass mode. Single-pass mode is not supported, including Q200 compatibility mode.

Configure BFD over BVI

Procedure

	1.	Configure the line cards to allow hosting of Multipath BFD sessions. Example: `Router# configure Router(config)# bfd Router(config-bfd)# multipath include location 0/0/CPU0 Router(config-bfd)# multipath include location 0/2/CPU0`
	2.	Configure the Layer 2 domain that includes the corresponding l2transport and BVIs. Example: `Router(config)# interface HundredGigE0/0/0/6 Router(config-if)no shut Router(config-if)exit Router(config)# interface HundredGigE0/0/0/6.3001 Router(config-if)# l2transport Router(config-if)# encapsulation dot1q 3001 Router(config-if)# rewrite ingress tag pop 1 symmetric Router(config-if)# exit`
	3.	Configure a BVI interface and assign an IP address. You can configure the BVI interface with either IPv4 or IPv6 address or both. Example: `Router(config)# interface bvi3001 Router(config-if)# ipv4 address 192.168.1.1 255.255.255.0 Router(config-if)# exit`
	4.	Configure BVI on the peer nodes. Example: `Router(config-if)# l2vpn Router(config-l2vpn)# bridge group bvi100 Router(config-l2vpn-bg)# bridge domain bfd-bvi Router(config-l2vpn-bg-bd)# interface HundredGigE0/0/0/6.3001 Router(config-l2vpn-bg-bd-ac)# exit Router(config-l2vpn-bg-bd)# routed interface bvi bvi3001`
	5.	Configure OSPF as the routing protocol. Example: `Router(config)# router ospf bfd-bvi Router(config-ospf)# router-id 192.168.1.1 Router(config-ospf)# area 0`
	6.	Configure BFD on BVI. Example: `Router(config-ospf-ar)# interface bvi3001 Router(config-ospf-ar-if)# bfd fast-detect Router(config-ospf-ar-if)# bfd multiplier 3 Router(config-ospf-ar-if)#commit`
	7.	Verify the status of L2VPN bridge domain. Example: `Router# show l2vpn bridge-domain brief Mon Apr 24 11:31:04.314 UTC Legend: pp = Partially Programmed. Bridge Group:Bridge-Domain Name ID State Num ACs/up Num PWs/up Num PBBs/up Num VNIs/up -------------------------------- -- ----- ----------- --------- ----------- ----------- bvi100:bfd-bvi 0 up 2/2 0/0 0/0 0/0` Verify the status of OSPF connectivity. The creation of a BFD session requires the neighbor to be in the FULL/BDR state. Example: `Router# show ospf neighbor Mon Apr 24 11:40:41.900 UTC * Indicates MADJ interface # Indicates Neighbor awaiting BFD session up Neighbors for OSPF bfd-bvi Neighbor ID Pri State Dead Time Address Interface 192.168.1.1 1 FULL/BDR 00:00:33 192.168.1.1 BVI3001 Neighbor is up for 1d22h Total neighbor count: 1` Verify the status of the BFD session. The output indicates the state of the BFD session is UP. Example: `show bfd session interface bvi3001 Mon Apr 24 11:42:50.582 UTC Interface Dest Addr Local det time(intmult) State Echo Async H/W NPU --------- ------------ -------- -------------- ----- ---- ----- ----- ----- BVI3001 192.168.1.1 0s(0s0) 750ms(250ms*3) UP Yes 0/2/CPU0`

BFD over pseudowire headend (PWHE)

This section describes the configuration and usage of BFD over pseudowire headend (PWHE) interfaces to support service availability.

BFD over pseudowire headend

Bidirectional forwarding detection over pseudowire headend is a BFD feature that

provides fast failure detection over customer edge to pseudowire headend provider edge links between eBGP neighbors
supports BFD sessions per pseudowire for end-to-end fault detection between the customer edge and pseudowire headend provider edge, and
supports BFDv4 for IPv4, BFDv6 for IPv6, and BFD asynchronous mode over PWHE and pseudowire VC types 4 and 5.

Table 4. Feature History Table
Feature Name	Release Information	Feature Description
BFD over pseudowire headend	Release 25.4.1	Introduced in this release on: Fixed Systems (8010 [ASIC: A100], 8700 [ASIC: K100])(select variants only) This feature is supported on: 8011-32Y8L2H2FH 8711-48Z-M
BFD over pseudowire headend	Release 25.1.1	Introduced in this release on: Fixed Systems (8700 [ASIC: K100], 8010 [ASIC: A100])(select variants only) This feature is supported on: 8712-MOD-M 8011-4G24Y4H-I
BFD over pseudowire headend	Release 24.3.1	Introduced in this release on: Fixed Systems (8200 [ASIC: P100], 8700 [ASIC: P100])(select variants only); Modular Systems (8800 [LC ASIC: P100])(select variants only) You can now rapidly detect failures in pseudowires, minimizing downtime and ensuring service reliability. This feature continuously monitors the pseudowire end-to-end, providing quick responses to maintain the integrity of Layer 2 VPNs and Ethernet services. *This feature is supported on: 8212-48FH-M 8711-32FH-M 88-LC1-36EH 88-LC1-12TH24FH-E 88-LC1-52Y8H-EM

BFD over PWHE supports:

BFD sessions per pseudowire for end-to-end fault detection between the CE and the PWHE PE
BFDv4 for IPv4 and BFDv6 for IPv6
BFD asynchronous mode over PWHE, and
Pseudowire VC type 4 and type 5.

Limitations of BFD over PWHE

BFD over PWHE feature is supported only on 88-LC1-12TH24FH-E line card.

Configure only these supported session types:

Static routes for IPv4 and IPv6.
Single-hop BFD sessions for IPv4 and IPv6.

Additional BFD integrations

This topic provides an overview of supplementary BFD functionalities and interoperability enhancements available for network configuration.

The BFD implementation includes support for IPv6 within Bundle Manager domains and introduces BGP BFD strict mode to enhance protocol interoperability and control.

BGP BFD strict-mode capabilities

BGP BFD strict-mode is a configuration capability that

makes BGP session establishment depend on BFD session state
ensures BGP sessions start only when BFD sessions are active, and
can enforce strict-mode requirements even when a peer does not natively support strict-mode.

Strict-mode negotiate: Ensures BGP sessions start only when BFD sessions are active.
Strict-mode negotiate override: Enforces strict-mode requirements even when a peer device does not natively support strict-mode.

Table 5. Feature History Table
Feature Name	Release Information	Feature Description
BGP BFD Strict-Mode Capabilities for Improved Interoperability	Release 25.4.1	Introduced in this release on: Fixed Systems (8700 [ASIC: K100])(select variants only). This feature is now supported on Cisco 8711-48Z-M routers.
BGP BFD Strict-Mode Capabilities for Improved Interoperability	Release 25.1.1	Introduced in this release on: Fixed Systems (8700 [ASIC: K100], 8010 [ASIC: A100])(select variants only) This feature is supported on: 8712-MOD-M 8011-4G24Y4H-I
BGP BFD Strict-Mode Capabilities for Improved Interoperability	Release 24.4.1	Introduced in this release on: Fixed Systems (8200 [ASIC: P100], 8700 [ASIC: P100])(select variants only); Modular Systems (8800 [LC ASIC: P100])(select variants only) You now have the ability to upgrade your network using Cisco's BGP BFD strict-mode negotiate and strict-mode negotiate override modes. These modes improve stability and cooperation between Cisco IOS XR and Cisco IOS XE devices. They ensure BGP sessions start only when BFD sessions are active. The override option enforces this even if a peer device does not support strict-mode. The feature ensures that a BGP session is established between neighbors only after the BFD session is established and stable. This ensures that the BFD functions as intended during a failure, promoting network stability and reliability. This feature introduces these changes: CLI: The bfd-state keyword is introduced in the show bgp sessions command. The BFDmode and BFDState fields are added to the show bgp neighbors command output. YANG Data Models: New XPaths for `Cisco-IOS-XR-um-router-bgp-cfg.yang` (See GitHub, YANG Data Models Navigator) *This feature is supported on: 8212-48FH-M 8711-32FH-M 88-LC1-36EH 88-LC1-12TH24FH-E 88-LC1-52Y8H-EM

BGP and BFD interoperability modes for routing resilience

Cisco provides two modes to improve BGP and BFD interoperability between Cisco IOS XR and Cisco IOS XE devices: BGP BFD strict-mode negotiate and BGP BFD strict-mode negotiate override. These modes bring up a BGP session only when the corresponding BFD session is up. The override mode continues to enforce this requirement even if the peer does not support strict mode. This behavior aligns with IETF standards and improves routing resilience.

Addressing interoperability challenges

Without these BGP BFD strict-mode capabilities, interoperability issues between Cisco IOS XR and Cisco IOS XE devices can prevent BGP sessions from coming up. These failures occur because of nonstandard strict-mode implementations. As a result, BGP routes might be advertised before the underlying BFD session is up, which can reduce routing stability.

BGP BFD strict-mode negotiate

Devices advertise BFD strict-mode capability and check whether the peer also advertises it. If the peer advertises the capability, the devices operate in IETF mode and bring up BGP only when the corresponding BFD session is up. If the peer does not advertise strict-mode, the devices operate without enforcing strict mode. The show bgp neighbor detail command displays the capabilities sent and received.

Devices advertise BFD strict-mode capability and check whether the peer also advertises it. If the peer advertises the capability, the devices operate in IETF mode. If the peer does not advertise the capability, the devices continue to operate in IETF strict mode and wait for BFD to come up before moving past the Open BFD state. If the peer resets the session because it does not support strict-mode, the device logs the event for that neighbor, stops advertising the capability in later Open messages, and continues to operate in IETF strict mode.

Verify peer advertisement for BFD strict-mode capability

This topic provides the logic for verifying peer advertisement of strict mode capability and the resulting device behavior for BGP session establishment.

Table 6. BFD strict-mode negotiate capability
If	Then
The peer advertises strict mode capability	The device brings up the BGP sessions only if the BFD session is up; this is in compliance with the IETF standard.
The peer does not advertise strict mode capability	The device starts operation without enforcing any strict mode.

Table 7. BFD strict-mode negotiate override mode
If	Then
The peer advertises strict mode capability	The device brings up the BGP sessions only if the BFD session is up.
The peer advertises that it does not support strict mode capability	The device overrides the neighbor’s capability notification and start operation in strict mode.

Need help?

Open a support case

(Requires a Cisco Service Contract)

The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.