BFD-ISIS multiple links same address IPV4

[Mathlp]

Hi team,
Version
FRR : Download here : https://deb.frrouting.org/ (7.5.1 version)
Operating System : LXC Container using Debian10 (buster) / kernel version : 5.8.0-48-generic

Describe the bug
I tried to configure BFD with ISIS routing protocol and using IP unnumbered.
It seems to be one BFD session per interface but seems to be managed by the same process.
I explain, if I shutdown the link between my router 1 (sat1) and my router 2 (sat2), the time before using the other link is around 3 seconds (ISIS timer) instead of 900ms (BFD timer).

Also, during the failure, the two sessions that were UP, have changed their state, the first one is deleted from the database and the second one is down (whereas it should be UP).

If I want to have the BFD back, I have to delete the configuration, restart frr, and configure routers again..

You will find below my configuration :

frr version 7.5.1
frr defaults traditional
hostname sat1
log syslog informational
no ipv6 forwarding
service integrated-vtysh-config
!
interface lo
 ip address10.0.0.1/32
 ip router isis 1
 isis hello-interval 1
 isis hello-multiplier 3
 isis passive
!
interface eth0
 ip address10.0.0.1/32
 ip router isis 1
 isis hello-interval 1
 isis hello-multiplier 3
 isis bfd
 isis metric 5
 isis network point-to-point
!
interface eth1
 ip address10.0.0.1/32
 ip router isis 1
 isis hello-interval 1
 isis hello-multiplier 3
 isis bfd
 isis metric 30
 isis network point-to-point
!
router isis 1
 net 49.0010.1111.1111.1111.1111.0
!
bfd
!

[x] Did you check if this is a duplicate issue?
[x] Did you test it on the latest FRRouting/frr master branch?

To Reproduce

1. Install FRR with https://deb.frrouting.org/ procedure on lxc container
2. Active isisd and bfdd
3. Reboot frr service
4. Go on the router with vtysh.
5. Configure two routers base on the example ->

On sat2 : show bfd peer

For the moment, everything is good, there are bfd packets on all interfaces

6. Shutdown interface between SWITCH (vETH10) and SAT2 (ETH0)
7. BFD has the strange behavior describe above..
   

As you see above, the peer on the ETH0 is deleted from the database and ETH1 is down whereas it has to be UP. Therefore, BFD doesn't work as expected and I have to wait the isis timer.

Sorry for my english :)
Hope you will understand the issue.

[donaldsharp]

@rzalamena can you take a look at this?

[jlearman]

I ran into a related issue, running BFD on OSPF unnumbered interfaces. The problem that I see is that the packets aren't sent on the specific interface, but rather are routed. So, if there is an alternate path with lower cost, the packets take that path. This (understandably) confuses BFD, and in some cases I get no BFD peer ever coming up, and in other cases I get peers flapping.

I'm not sure my issue is the same as above, but in my case it's clear that for unnumbered interfaces, BFD has to send the packet on the specific interface, rather than allowing it to be routed.

Please let me know if I should open a new issue.

My results are easily obtained on a 3-router network (all FRR.) Configure one link with more than double the cost of the other. You can see using tcpdump that all BFD packets are transmitted on the low-cost path.

PS: In my case, the interface is on a non-default VRF, and that might be a factor. My teammate did a topotest that did not show this issue, but was using the default VRF.