Lighthouses emit a powerful, regular light that informs incoming ships of potential obstacles and dangers. If a vessel stops seeing the signal, it knows immediately that something might be blocking or obstructing the passage. The faster the ships react to the missing signal, the more likely they can find an alternate, safe route. The same principle applies to networking. We tend to rely on routing protocol heartbeats to act as the signals that indicate whether our destination is accessible. If several of them go missing in a row, it indicates the passage might be blocked. But the frequency at which they're sent is, by default, high and it sometimes takes minutes for a device to realize that its path is degraded. We need a more effective networking beacon to ensure packets are not swept away and are redirected to a safe course. With Isovalent Enterprise for Cilium 1.16, you can now enable Bidirectional Forwarding Detection (BFD) and detect link or neighbor loss faster, forcing traffic to take an alternate path and greatly reducing downtime. Introducing BFD According to its initial RFC, BFD aims at the following: The goal of Bidirectional Forwarding Detection (BFD) is to provide low-overhead, short-duration detection of failures in the path between adjacent forwarding engines, including the interfaces, data link(s), and, to the extent possible, the forwarding engines themselves.RFC5880 In other words, BFD aims at detecting network failures in order to find an alternative path for packets to take. BFD is commonly used with dynamic routing protocols such as OSPF and BGP and is ideal for scenarios where you have multiple paths: by quickly identifying a lossy link or unresponsive peer, the routing table can be updated and traffic can switch over to a healthy path instead. BFD works by establishing a peering session between two endpoints. It uses a keepalive system where each endpoint at a frequency (BFD Interval) sends heartbeats (BFD Echo packets) to verify that the path is still active. If one endpoint stops receiving these messages within a predefined time (Detection Time), it considers the path down and informs the routing protocol so that routing convergence can occur. The BFD heartbeats work similarly to BGP KEEPALIVE messages. So why would we need BFD? Firstly, the BGP timers are, by default, high (30 seconds for the keepalive interval and 90 seconds for the hold time). We previously explored in a Cilium BGP blog post how we can reduce these timers but even with the minimum values, you might still experience a ~10 second outage. BFD's lightweightness means it can detect outages faster - subsecond failure detection - without putting a strain on resources. Let's take a look at some of the benefits achievable with BFD in a demo environment. Demo Environment For this lab, we will once again use the excellent containerized networking platform containerlab, with the following: Kubernetes cluster with 2 nodes running Isovalent Enterprise for Cilium 1.16 FRR (FRRouting Project) connected to the Kubernetes cluster Cisco Cloud Services Router 1000v (CSR 1000v) connected to the Kubernetes cluster Our Kubernetes cluster is based on Kind, has 2 nodes and is running Isovalent Enterprise for Cilium. We have configured an external BGP (eBGP) session between a Cilium-managed Kubernetes cluster in Autonomous System (AS) 65001 with a Cisco CSR 1000V device in AS 65005. Cilium's BGP Daemon is advertising the Pod CIDR network 10.244.0.0/24 to the CSR, to make our pods accessible to the rest of the network. Let's now compare, without and with BFD, the observed behaviour when a link becomes degraded. Without BFD Using their default settings, the CSR and Cilium negotiate a 30-second BGP keepalive interval and a 90-second hold time - meaning they exchange keepalives every 30 seconds and if they don't receive any over a period of 90 seconds, they will conclude that their peering session has failed. It means that it could take well over a minute for the BGP peers to detect that the connection to its peer is unsuccessful: Let's introduce some packet loss on the link using containerlab's native support for netem, a network emulator that can introduce packet loss and delay. Note how I will show the current time through the tutorial so that you can see for yourself the outage with and without BFD. As soon as we start dropping all packets on the interface on the CSR device, BGP keepalives start going missing but, because of the BGP's holdtime interface, the session takes about 2 minutes to come down and back in Active state. 2 minutes of downtime is obviously not acceptable for anyone running mission critical applications. It's possible to reduce the BGP timers (as described in the Cilium docs) but timers too aggressively low can cause some unwanted instability. Let's see what we can achieve with BFD instead. With BFD Let's deploy BFD on our remote Cisco CSR end. We need to enable it on the interface and in the BGP configuration: Let's now enable the BFD feature in Cilium: BFD first requires a BFD profile to be created. You can specify how often the BFD heartbeats are sent and received (note that the timers are negotiated between the peers when the BFD session is being established). Notice how BFD support is available for both IPv4 and IPv6. We then refer to the BFD profile in the BGP configuration: After deploying the configuration, the BGP peering between the Cisco CSR and Cilium works as expected, with the CSR once again receiving the Pod CIDR: On the CSR, we can see the established BFD sessions (there's one for IPv4 and one for IPv6): On the Cilium side, we can validate that BFD is also successfully configured by logging onto the Cilium agent: When capturing the traffic with tcpdump, we can see our BFP packets being exchanged - you can see in the BFD control packets some of the timers settings specified during the negotiation: Let's now introduce some loss again. BFD immediately notices the loss of echo packets and brings down the BGP session immediately: With BFD immediately noticing the defective link and the BGP session going down, traffic can be re-routed via an alternative path and downtime can be greatly reduced. BFD immediately notices the loss of echo packets and brings down the BGP session immediately, and the traffic can take an alternate path. Final Thoughts Minimizing interruption to live traffic remains a priority for all infrastructure and platform engineers. BFD support in Isovalent Enterprise for Cilium provides another method to make platforms more robust and resilient in the event of a failure. If you'd like to learn more, don't hesitate to contact us to request a demo with our talented team of solution architects: