<div dir="ltr">Dear FRR community members,<br><br>I am a user of FRR and I am now using it to build a small-scale experiment network. I ran into a problem regarding the interaction between BFD and BGP in the recent days. My BGP configuration specifies BFD dependencies for BGP neighbors using "neighbor X.X.X.X bfd". And the FRR will create some BFD peer sessions (marked as dynamic in FRR) immediately when it reads the BGP configuration. Then after FRR reads the BFD configuration, it seems that FRR will deregister the previous "dynamic" peer sessions and register those peer sessions (marked as configured) specified in the BFD configuration.<br><br>I learn this from the debugging log and such mechanisms work in most cases. But in some situations, it does not work. Specifically, the FRR will have two duplicate BFD peer sessions for the same peer at last. I found that restarting FRR can solve the problem. Yet, I wonder whether there is a more elegant solution.<br><br>The example configuration of the problematic peer is as follows:<br>router #1, with IP address 10.3.0.1<br><i>router bgp 1<br> no bgp ebgp-requires-policy<br> neighbor 10.0.0.2 remote-as 2<br> neighbor 10.0.0.2 bfd<br> neighbor 10.1.0.2 remote-as 3<br> neighbor 10.1.0.2 bfd<br> neighbor 10.4.0.1 remote-as 1<br> neighbor 10.4.0.1 bfd<br> neighbor 10.4.0.1 update-source 10.3.0.1<br> neighbor 10.5.0.1 remote-as 1<br> neighbor 10.5.0.1 bfd<br> neighbor 10.5.0.1 update-source 10.3.0.1<br> !<br> address-family ipv4 unicast<br>  network <a href="http://10.0.0.0/24">10.0.0.0/24</a><br>  network <a href="http://10.1.0.0/24">10.1.0.0/24</a><br>  network <a href="http://10.3.0.0/24">10.3.0.0/24</a><br>  network <a href="http://10.4.0.0/24">10.4.0.0/24</a><br>  network <a href="http://10.5.0.0/24">10.5.0.0/24</a><br>  network <a href="http://10.12.0.0/24">10.12.0.0/24</a><br>  network <a href="http://10.13.0.0/24">10.13.0.0/24</a><br>  network <a href="http://10.18.0.0/24">10.18.0.0/24</a><br> exit-address-family<br>exit<br><br>bfd<br> peer 10.0.0.2<br>  transmit-interval 100<br>  receive-interval 100<br> exit<br> !<br> peer 10.1.0.2<br>  transmit-interval 100<br>  receive-interval 100<br> exit<br> !<br> peer 10.4.0.1 multihop local-address 10.3.0.1<br>  transmit-interval 100<br>  receive-interval 100<br> exit<br> !<br> peer 10.5.0.1 multihop local-address 10.3.0.1<br>  transmit-interval 100<br>  receive-interval 100<br> exit<br> !<br>exit<br></i><br>router #2, with IP address 10.5.0.1<br><i>router bgp 1<br> no bgp ebgp-requires-policy<br> neighbor 10.3.0.1 remote-as 1<br> neighbor 10.3.0.1 bfd<br> neighbor 10.3.0.1 update-source 10.5.0.1<br>exit<br><br>bfd<br> peer 10.3.0.1 multihop local-address 10.5.0.1<br>  transmit-interval 100<br>  receive-interval 100<br> exit<br> !<br>exit<br></i><br>The router #1 get two duplicate BFD peer sessions as follows: (the interface s0-eth2 has the IP address 10.3.0.1)<br>        <i>peer 10.5.0.1 local-address 10.3.0.1 vrf default interface s0-eth2<br>                ID: 2040029068<br>                Remote ID: 0<br>                Active mode<br>                Status: down<br>                Downtime: 11 minute(s), 51 second(s)<br>                Diagnostics: ok<br>                Remote diagnostics: ok<br>                Peer Type: dynamic<br>                Local timers:<br>                        Detect-multiplier: 3<br>                        Receive interval: 300ms<br>                        Transmission interval: 300ms<br>                        Echo receive interval: 50ms<br>                        Echo transmission interval: disabled<br>                Remote timers:<br>                        Detect-multiplier: 3<br>                        Receive interval: 1000ms<br>                        Transmission interval: 1000ms<br>                        Echo receive interval: disabled</i><br><br>      <i>  peer 10.5.0.1 multihop local-address 10.3.0.1 vrf default<br>                ID: 1516906735<br>                Remote ID: 2466577291<br>                Active mode<br>                Minimum TTL: 254<br>                Status: up<br>                Uptime: 11 minute(s), 51 second(s)<br>                Diagnostics: ok<br>                Remote diagnostics: ok<br>                Peer Type: configured<br>                Local timers:<br>                        Detect-multiplier: 3<br>                        Receive interval: 100ms<br>                        Transmission interval: 100ms<br>                        Echo receive interval: 50ms<br>                        Echo transmission interval: disabled<br>                Remote timers:<br>                        Detect-multiplier: 3<br>                        Receive interval: 100ms<br>                        Transmission interval: 100ms<br>                        Echo receive interval: 50ms</i><br><br>Can anyone give me a hint of a clean solution?<br><br>Thanks!<br><br>Changrong Wu<br></div>