this KB documents the unexpected behavior of BFD protocol on certain JUNOS release and this KB covers remediation for this issue,
Issue is seen when Customer has below VPLS configuration with BFD running on top of BGP with outgoing IRB interface. for issue to be seen, VPLS configuration should not have CE facing physical interface and it is only attached to MPLS core interface
RI-NAME { instance-type vpls; protocols { vpls { mesh-group <GROUP-NAME>{ neighbor 172.16.161.1; vpls-id X; } encapsulation-type ethernet-vlan; no-tunnel-services; mtu 2000; connectivity-type irb; } } vlan-id X; routing-interface irb.X;
bgp configuration on VRF instance for routing between different subnet through IRB gateway.
neighbor 172.16.16.11 {
local-address 172.16.16.10;
peer-as <AS-NUMBER>;
bfd-liveness-detection {
minimum-interval 100;
}
ping 172.16.16.11 source 172.16.16.10 routing-instance <instance-name> Nov 10 00:53:42 PING 172.16.16.11 (172.24.255.11): 56 data bytes 64 bytes from 172.16.16.11: icmp_seq=22 ttl=64 time=2.037 ms 64 bytes from 172.16.16.11: icmp_seq=23 ttl=64 time=0.857 ms ^C --- 172.16.16.11 ping statistics --- 28 packets transmitted, 24 packets received, 14% packet loss round-trip min/avg/max/stddev = 0.857/1.178/2.846/0.510 ms show bgp summary | match 172.24.255.11 | refresh Nov 10 00:54:15 ---(refreshed at 2024-11-10 00:54:15 AEDT)--- 172.16.16.11 65032 3 4 0 2 47 Establ ---(*more 100%)---[abort] Connection is made down however BGP / BFD Stays up ping 172.16.16.11 source 172.16.16.10 routing-instance <instance-name> Nov 10 00:54:20 PING 172.16.16.11 (172.24.255.11): 56 data bytes ^C --- 172.16.16.11 ping statistics --- 6 packets transmitted, 0 packets received, 100% packet loss show bgp summary | match 172.16.16.11 | refresh Nov 10 00:54:28 ---(refreshed at 2024-11-10 00:54:28 AEDT)--- 172.16.16.11 65032 3 4 0 2 1:00 Establ ---(refreshed at 2024-11-10 00:54:33 AEDT)--- ping 172.16.16.11 source 172.16.16.10 routing-instance <instance-core> Nov 10 00:54:38 PING 172.16.16.11 (172.16.16.11): 56 data bytes ^C --- 172.16.16.11 ping statistics --- 5 packets transmitted, 0 packets received, 100% packet loss show bgp summary | match 172.16.16.11 | refresh Nov 10 00:54:57 ---(refreshed at 2024-11-10 00:54:57 AEDT)--- 172.16.16.11 65032 3 4 0 2 1:29 Establ ---(refreshed at 2024-11-10 00:55:02 AEDT)--- > ping 172.16.16.11 source 172.16.16.10 routing-instance <instance-name> Nov 10 00:55:14 PING 172.16.16.11 (172.16.16.11): 56 data bytes ^C --- 172.16.16.11 ping statistics --- 5 packets transmitted, 0 packets received, 100% packet loss show bgp summary | match 172.16.16.11 | refresh Nov 10 00:55:20 ---(refreshed at 2024-11-10 00:55:20 AEDT)--- 172.16.16.11 65032 3 4 0 2 1:52 Establ and BGP does down due to hold dow time expiry show bgp summary | match 172.16.16.11 | refresh Nov 10 00:55:34 ---(refreshed at 2024-11-10 00:55:34 AEDT)--- 172.16.16.11 65032 0 0 0 3 8 Connect ---(*more 100%)---[abort] and BFD stays up in entire process. show bfd session Nov 10 01:08:23 Detect Transmit Address State Interface Time Interval Multiplier 172.16.16.11 Up irb.X 0.300 0.100 3 172.24.255.11 Up irb.5 0.300 0.100 3 Client BGP, TX interval 0.100, RX interval 0.100 Session up time 00:08:03 Local diagnostic None, remote diagnostic None Remote state Up, version 1 Session type: Single hop BFD Min async interval 0.100, min slow interval 1.000 Adaptive async TX interval 0.100, RX interval 0.100 Local min TX interval 0.100, minimum RX interval 0.100, multiplier 3 Remote min TX interval 0.100, min RX interval 0.100, multiplier 3 Local discriminator 73, remote discriminator 65 Echo TX interval 0.000, echo detection interval 0.000 Echo mode disabled/inactive Session ID: 0x5f4
This issue is seen when device boots up for first time after the upgrade to problematic release and we observed that issue is resolved once router is reboot or PPMD process restarted in downtime MW. once issue is cleared then it is not seen until device is again upgraded to problematic release.
This is BUG which is identified on release 21.2R3-S2 however issue is not seen on newer as mentioned below.
23.2R2-S3.8
How issue is fixed in newer release is unidentified