Showing results for 
Search instead for 
Did you mean: 

BFD on interface

Dear all,

Can we configure bfd on interface level for the purpose that if remote IP address is unreachable, bring down the interface.


Nagendra Kumar Nainar
Cisco Employee

Hi Yasir,

I dont think BFD can do this. Currently BFD clients are routing protcols like OSPF/BGP etc and is extended for PIM if I remember it right.

You may have to use Ethernet OAM which can shut the interface incase of remote failure detection.



Correct, in XR BFD runs as part of an application. The application can be ospf, isis or static.

Tying BFD onto an interface will make you send alerts, traps, syslogs etc, but that is about it.

You can trigger on the syslog message and have EEM shut or unshut an interface if that is the desire, but tying it to an application is more powerful.

For instance, advertising max metric, or bring the routing ADJ down is more graceful in terms of fast convergence routing.



Hi Xander,


Wouldn’t it be for the best if you would allow operators to actually spin up BFD as a standalone process (much like ISIS or OSPF)?

Under the “router bfd” we could then have options like:

- Specify which interfaces we want the process to run on

- Select which addresses should the BFD session run on primary/secondary or v6 link-local/global etc..

- Select whether the BFD session status would then tie with the interface line protocol status (affects all protocols on the link).

And we’d still have the option to register individual protocols with BFD process.


Having a standalone BFD process/config would be beneficial during scale testing where we need to figure out how many BFD sessions at what timers we can run on a particular NPU.



::carrier-class solutions for the telecommunications industry::


Good question !


While revisiting our now legacy configurations, I am looking at moving away from BFD on interface config and instead configure BFD per IGP/BGP.


So from 


interface Bundle-Ether100

bfd address-family ipv4 timers start 60
bfd address-family ipv4 timers nbr-unconfig 60
bfd address-family ipv4 multiplier 3
bfd address-family ipv4 destination x.x.x.x
bfd address-family ipv4 fast-detect
bfd address-family ipv4 minimum-interval 15



router bgp 1

neighbor x.x.x.x
remote-as 100
bfd fast-detect
bfd multiplier 3
bfd minimum-interval 15


I think the protocol based BFD is more efficient that one the Bundle interface. But what is gained remains to be tested.


Not sure which platform you are planning to ,


Please refer to BLB for more details in the above link




Thanks Sathish,


Documents are still not clear of the best design approach. Should it be BFD per logical interface or per IGP ?



On IOS XR the only scenario where you configure BFD on an interface is BoB. In all other scenarios BFD is configured under the application, i.e. in your case IGP.

You can use BoB if the directly connected peer supports BoB and the bundle-ether interface is L3 on both ends. In that case BoB protects the bundle itself and all applications inherit the state.


Thanks for the reply Aleksandar,


I am aware of that, but even with directly connected peers I could chose to enable BFD per process instead of BOB. With BOB, it is also clear BFD per process is not design wise and apart from scalability limitations, which is better ? 



BFD over Bundle effectively runs a micro-BFD session on each bundle member so protects against partial LAG failures.

A conventional BFD session configured under the routing protocol doesn't.


Before this, people had to use 100ms 802.3ah EOAM or Cisco-proprietary 100ms LACP for this, but they don't interoperate so well, often don't scale to as high a number of interfaces and typical of IEEE defined protocols, don't negotiate timers so don't support things like ISSU.

Good answer which makes sense !

In this case, it is best to use min bundle for the total number of members in the bundle. 



Content for Community-Ad