BFD Configuration

bfd configuration bfd configuration introduction introduction bidirectional forwarding detection (bfd) is a unified network wide detection mechanism used to quickly monitor the forwarding connectivity status of links or ip routes within a network when certain links do not provide hardware detection, applications rely on the upper layer protocol's own hello message mechanism for fault detection however, the fault detection time of upper layer protocols is usually above 1 second, which is unacceptable for some applications the bfd protocol was developed in this context bfd provides a standardized, media independent, and protocol independent fast fault detection mechanism, enabling rapid detection and monitoring of the forwarding connectivity status of links or ip routes in the network this improves network performance by quickly detecting communication failures between neighboring systems, users can establish backup channels more quickly to recover communication and ensure network reliability explanation of principles explanation of principles bfd (bidirectional forwarding detection) is used to establish sessions between two network devices to detect bidirectional forwarding paths and provide services to upper layer applications bfd itself does not have a discovery mechanism; instead, it relies on upper layer protocols to notify it of new neighbor relationships when an upper layer protocol establishes a new neighbor relationship, it informs bfd of the neighbor's parameters, and bfd establishes a session based on the received parameters once the session is established, both parties periodically send bfd packets to each other quickly if no bfd packets are received from the peer within the detection time, the bidirectional forwarding path is considered to have failed the failure information is then communicated to the upper layer application served by the session, which takes appropriate action bfd configuration bfd configuration true 482,180 left #4283c7 unhandled content type left #4283c7 unhandled content type left unhandled content type left unhandled content type left #d8e5f5 unhandled content type left #d8e5f5 unhandled content type left unhandled content type left unhandled content type left #d8e5f5 unhandled content type left #d8e5f5 unhandled content type left unhandled content type left unhandled content type left #d8e5f5 unhandled content type left #d8e5f5 unhandled content type left unhandled content type left unhandled content type left #d8e5f5 unhandled content type left #d8e5f5 unhandled content type left unhandled content type left unhandled content type left #d8e5f5 unhandled content type left #d8e5f5 unhandled content type creating a bfd session creating a bfd session true 182,146 91402714932127,333 08597285067873 left #4283c7 unhandled content type left #4283c7 unhandled content type left #4283c7 unhandled content type left unhandled content type left unhandled content type left unhandled content type left #d8e5f5 unhandled content type left #d8e5f5 unhandled content type left #d8e5f5 unhandled content type left unhandled content type left unhandled content type left unhandled content type configuring the detection multiplier for the bfd session configuring the detection multiplier for the bfd session the detection time of a bfd session is determined by the local detection multiplier configured for that session users can adjust the local detection multiplier based on the actual network conditions to increase or decrease the detection time of the bfd session for example, for a relatively stable link where frequent detection of link status is not necessary, you can increase the local detection multiplier the formula to calculate the bfd detection time is bfd detection time = local detection multiplier x transmission interval true 249,196 5656108597285,216 4343891402715 left #4283c7 unhandled content type left #4283c7 unhandled content type left #4283c7 unhandled content type left unhandled content type left unhandled content type left unhandled content type left #d8e5f5 unhandled content type left #d8e5f5 unhandled content type left #d8e5f5 unhandled content type configuring the minimum transmit interval for bfd packets configuring the minimum transmit interval for bfd packets bfd (bidirectional forwarding detection) protocol relies on the time to live (ttl) field in its packets to play a crucial role in network operations used for swiftly detecting the availability of network paths, bfd monitors link status by sending probing packets the ttl field specifies the maximum time or hop count that a packet can exist in the network here's how the ttl field functions limiting packet propagation the ttl field restricts the scope of bfd probing packets within the network when a packet reaches its designated ttl, it is discarded, preventing it from indefinitely propagating across the network rapid fault detection ttl assists bfd in swiftly detecting link failures if a probing packet fails to reach its destination within the specified ttl, bfd promptly concludes a link failure and notifies network devices to take appropriate actions, such as switching to alternate paths conserving network resources by setting an appropriate ttl value, unnecessary network traffic can be minimized setting a ttl too high might waste bandwidth and processing resources, while setting it too low could burden network devices with frequent bfd packet processing true 262,165 0950226244344,234 9049773755656 left #4283c7 unhandled content type left #4283c7 unhandled content type left #4283c7 unhandled content type left unhandled content type left unhandled content type left unhandled content type left #d8e5f5 unhandled content type left #d8e5f5 unhandled content type left #d8e5f5 unhandled content type configuring the bfd mode as passive configuring the bfd mode as passive in passive mode, bfd (bidirectional forwarding detection) operates by waiting for probe packets from the peer device and responding to them, rather than periodically sending its own probe packets here's how passive mode works waiting for peer probe packets in passive mode, the device continuously listens for bfd probe packets from the peer device these probe packets are typically sent at regular intervals responding to peer probe packets upon receiving bfd probe packets from the peer device, the device promptly responds the response can be a simple acknowledgment or may include additional information such as packet sequence numbers detecting link status the device determines the link status by responding to the peer's probe packets if no probe packets are received from the peer for a period of time, the device assumes that a link failure may have occurred and triggers the appropriate fault handling mechanism the advantage of passive mode is that it conserves bandwidth and processing resources since the device does not need to periodically send probe packets it is suitable for scenarios where the link is stable, bandwidth is limited, or sensitivity to network resource consumption is high however, passive mode may not promptly detect link failures because it relies on probe packets from the peer device true 296,148 90182805429865,217 09817194570135 left #4283c7 unhandled content type left #4283c7 unhandled content type left #4283c7 unhandled content type left unhandled content type left unhandled content type left unhandled content type left #d8e5f5 unhandled content type left #d8e5f5 unhandled content type left #d8e5f5 unhandled content type configuring the receive interval for bfd packets configuring the receive interval for bfd packets true 229,197 88687782805428,235 11312217194572 left #4283c7 unhandled content type left #4283c7 unhandled content type left #4283c7 unhandled content type left unhandled content type left unhandled content type left unhandled content type left #d8e5f5 unhandled content type left #d8e5f5 unhandled content type left #d8e5f5 unhandled content type configuring the transmit interval for bfd packets configuring the transmit interval for bfd packets true 220,199,243 left #4283c7 unhandled content type left #4283c7 unhandled content type left #4283c7 unhandled content type left unhandled content type left unhandled content type left unhandled content type left #d8e5f5 unhandled content type left #d8e5f5 unhandled content type left #d8e5f5 unhandled content type terminate bfd session detection terminate bfd session detection true 293,183 66515837104072,185 33484162895928 left #4283c7 unhandled content type left #4283c7 unhandled content type left #4283c7 unhandled content type left unhandled content type left unhandled content type left unhandled content type left #d8e5f5 unhandled content type left #d8e5f5 unhandled content type left #d8e5f5 unhandled content type configuring single arm echo function configuring single arm echo function by configuring a unidirectional echo mode bfd session on the bfd capable device, it can send bfd control packets to the non bfd capable device when the non bfd capable device receives these packets, it simply loops them back at the ip layer this loopback allows the bfd capable device to detect link failures more quickly, as it can receive and process the echoed packets without waiting for a response from the non bfd capable device this approach helps improve the efficiency of link failure detection in scenarios where only one device supports bfd true 250,205 06787330316743,206 93212669683257 left #4283c7 unhandled content type left #4283c7 unhandled content type left #4283c7 unhandled content type left unhandled content type left unhandled content type left unhandled content type left #d8e5f5 unhandled content type left #d8e5f5 unhandled content type left #d8e5f5 unhandled content type left unhandled content type left unhandled content type left unhandled content type configuring bfd policy group configuring bfd policy group configuring bfd sessions individually can be time consuming and inefficient, especially when dealing with a large number of sessions by creating bfd policy groups, you can define common parameters for multiple bfd sessions and then simply bind the policy group to each peer, reducing the configuration workload and ensuring consistency across multiple sessions this approach streamlines the configuration process and makes it more manageable, particularly in environments with numerous bfd sessions true 242,222 0497737556561,197 9502262443439 left #4283c7 unhandled content type left #4283c7 unhandled content type left #4283c7 unhandled content type left unhandled content type left unhandled content type left unhandled content type left #d8e5f5 unhandled content type left #d8e5f5 unhandled content type left #d8e5f5 unhandled content type left unhandled content type left unhandled content type left unhandled content type left #d8e5f5 unhandled content type left #d8e5f5 unhandled content type left #d8e5f5 unhandled content type configuring bfd session as data plane mode configuring bfd session as data plane mode software bfd refers to the process where packet transmission and reception during bfd detection, as well as the maintenance of bfd session state machines, rely entirely on the cpu for processing software bfd consumes a significant amount of cpu resources, so it can be used in conjunction with hardware bfd hardware bfd offloads tasks such as packet transmission, reception, and fault detection to dedicated hardware chips, thereby improving cpu utilization the device supports a maximum of eight data plane bfd sessions true 220,220,222 left #4283c7 unhandled content type left #4283c7 unhandled content type left #4283c7 unhandled content type left unhandled content type left unhandled content type left unhandled content type left #d8e5f5 unhandled content type left #d8e5f5 unhandled content type left #d8e5f5 unhandled content type display and maintenance display and maintenance true 331,331 left #4283c7 unhandled content type left #4283c7 unhandled content type left unhandled content type left unhandled content type left #d8e5f5 unhandled content type left #d8e5f5 unhandled content type bfd and bgp linkage configuration example bfd and bgp linkage configuration example network requirements in the network, device a and device d establish ebgp neighbors on device b and device c respectively, device a can receive the route announced by bgp on device d in the form of ecmp, and the next hops are device b and device c respectively cut off device a's ethernet 49 port the bfd can detect the link break quickly and converge the route quickly procedure device a configuration \# interface configuration ip address sonic(config)# interface ethernet 49 sonic(config if 49)# ip address 20 0 0 2/30 sonic(config if 49)# exit sonic(config)# interface ethernet 50 sonic(config if 50)# ip address 30 0 0 2/30 sonic(config if 50)# exit sonic(config)# interface loopback 0 sonic(config if lo0)# ip address 10 1 15 10/32 \# configuring ebgp connections sonic(config)# router bgp 65003 sonic(config router)# bgp router id 10 1 15 10 sonic(config router)# no bgp ebgp requires policy sonic(config router)# neighbor 20 0 0 1 remote as 65003 sonic(config router)# neighbor 20 0 0 1 bfd sonic(config router)# neighbor 20 0 0 1 description deviceb sonic(config router)# neighbor 30 0 0 1 remote as 65003 sonic(config router)# neighbor 30 0 0 1 bfd sonic(config router)# neighbor 30 0 0 1 description devicec device b configuration \# interface configuration ip address sonic(config)# interface ethernet 50 sonic(config if 50)# ip address 40 0 0 1/30 sonic(config if 50)# exit sonic(config)# interface loopback 0 sonic(config if lo0)# ip address 10 1 15 20/32 \# configuring ebgp connections sonic(config)# router bgp 65003 sonic(config router)# bgp router id 10 1 15 20 sonic(config router)# no bgp ebgp requires policy sonic(config router)# neighbor 20 0 0 2 remote as 65001 sonic(config router)# neighbor 20 0 0 2 bfd sonic(config router)# neighbor 20 0 0 2 description devicea sonic(config router)# neighbor 40 0 0 2 remote as 65002 sonic(config router)# neighbor 40 0 0 2 bfd sonic(config router)# neighbor 40 0 0 2 description deviced device c, device d configuration is similar verify configuration view bgp, bfd session establishment device on line speed forwarding can hit the traffic declared route on device d, cut the link, verify the convergence time verify that the convergence time meets the millisecond requirements