Detect link or neighbor loss faster, forcing traffic to take an alternate path and greatly reducing downtime in your Kubernetes platform using Cilium and Bi-directional Forwarding (BFD). Introduction Welcome to a short demo of BFD with Isovalent Enterprise for Cilium. BFD stands for Bidirectional Forwarding Detection. It's a protocol defined in RFC 5880 that detects network failures quickly so packets can switch over to an alternative healthy path. It works alongside dynamic routing protocols like OSPF and BGP, and it helps identify a degraded or unresponsive link much faster than relying on default BGP timers alone. In this demo we're going to compare the behavior without BFD and then with BFD enabled. BFD for BGP overview In the demo environment I have a Kubernetes cluster running Isovalent Enterprise for Cilium 1.16. It is connected over BGP to an FRR virtual device and also to a Cisco CSR1000v. On the left-hand side I have Cilium BGP running, and on the right-hand side I have the CSR terminal. I'm advertising the pod CIDR to the CSR device, and at this stage we are not yet running BFD between Cilium and the CSR. Validate BFD for BGP The first thing we're going to do is introduce packet loss with Containerlab and netem. Once we inject 100 percent packet loss on the CSR interface, the link becomes defective, but Cilium still assumes that the BGP session is working because of the default keepalive and hold timers. Even though the link is lossy, the session still shows as established, so traffic is effectively being black-holed instead of moving to the alternate path. It takes roughly a minute and a half to two minutes before the session finally goes inactive, which is just too long. Configure BGP peering Once we remove the packet loss, the session comes back, and then we enable BFD on both Cilium and the Cisco CSR1000v. We apply the BGP peering configuration so that it refers to a BFD profile, and in that profile we tune the transmit interval, the receive interval, and the detection multiplier so we can detect failures much more aggressively than with the default BGP behavior. Peering policy configuration If we reintroduce packet loss now, the BFD session detects the failure very quickly and the route can move away from the broken path instead of waiting for the regular BGP timers to expire. That's really the key point of BFD for BGP in Cilium: faster convergence, less traffic black-holing, and a much more resilient cluster when links become degraded or unresponsive. Thanks for watching.