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.
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.
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
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 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 necessary...so 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.