Reliability Configuration Guide

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 configure tasks instructions index create a bfd session required creating a bfd session configure the detection multiplier for the bfd session optional configuring the detection multiplier for the bfd session configure the minimum transmit interval for bfd packets optional configuring the minimum transmit interval for bfd packets configure the bfd mode as passive optional configuring the bfd mode as passive configure the receive interval for bfd packets optional configuring the receive interval for bfd packets configure the transmit interval for bfd packets optional configuring the transmit interval for bfd packets terminate bfd session detection optional terminate bfd session detection configure the bfd session as single arm echo function optional configuring single arm echo function configure bfd policy group and bind it to the peer optional configuring bfd policy group creating a bfd session creating a bfd session operation command description enter the system configuration view configure terminal enter the bfd view bfd create a bfd session and enter the bfd peer view peer\<ip address>\[{multihop|local address\<ip address>|interface \<interface type> \<interface name>}] \<peer address> ip address of the peer device \<session name> the name of the bfd session \<local address> the desired local ip address for sourcing bfd packets \<interface type> the type of the interface \<interface number> interface number 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 operation command description enter the bfd peer view peer \<ip address> configure the detection multiplier for the bfd session detect multiplier\<value> the range of value is 2 255 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 operation command description enter the bfd peer view peer\<ip address> configure the minimum transmit interval for bfd packets minimum ttl\<value> the range of value is 1 254 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 operation command description enter the bfd peer view peer\<ip address> configure the bfd mode as passive passive mode the default value is active mode configuring the receive interval for bfd packets configuring the receive interval for bfd packets operation command description enter the bfd peer view peer\<ip address> configure the receive interval for bfd packets receive interval \<value> the range value is 10 60000 unit is ms configuring the transmit interval for bfd packets configuring the transmit interval for bfd packets operation command description enter the bfd peer view peer\<ip address> configure the transmit interval for bfd packets transmit interval \<value> the range value is 10 60000 unit is ms terminate bfd session detection terminate bfd session detection operation command description enter the bfd peer view peer\<ip address> terminate bfd session detection shutdown 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 operation command description enter the bfd peer view peer\<ip address> configure the bfd session as single arm echo function echo mode configure the receive interval for bfd packets echo intervall \<value> the range value is 10 60000 unit is ms 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 operation command description enter the bfd view bfd create a bfd policy group profile\<profile name> enter the bfd peer view peer\<ip address> bind bfd policy to peer profile\<profile name> display and maintenance display and maintenance operation command display the bfd session info show bfd peers brief display the bfd session statistics info show bfd peers counters 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 1 device a configuration \# interface configuration ip address sonic(config)# interface ethernet 4 sonic(config if 4)# ip address 20 0 0 2/30 sonic(config if 4)# exit sonic(config)# interface ethernet 5 sonic(config if 5)# ip address 30 0 0 2/30 sonic(config if 5)# 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 2 device b configuration \# interface configuration ip address sonic(config)# interface ethernet 5 sonic(config if 5)# ip address 40 0 0 1/30 sonic(config if 5)# 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 3 device c, device d configuration is similar verify configuration 1 view bgp, bfd session establishment 2 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 monitor link configuration monitor link configuration introduction introduction monitor link is an interface linkage solution that triggers changes in the up/down state of downstream interfaces based on the changes in the up/down state of a monitored device's upstream interface this triggering subsequently leads to topology protocol devices on downstream devices explanation of principles explanation of principles each monitor link group consists of two types of member interfaces upstream interfaces and downstream interfaces while a monitor link group can have multiple upstream or downstream interfaces, an interface can only belong to a single monitor link group the upstream interface is the monitored interface, and its associated link is known as the upstream link the state of the monitor link group is coordinated with the state of this interface when all the uplink interfaces in the monitor link group are down, the monitor link group is considered down conversely, when all the uplink interfaces in the monitor link group are up, the monitor link group is considered up the downstream interface is the monitoring interface, and its associated link is known as the downstream link the state of this interface is synchronized with the state of the monitor link group changes in the up/down state of the monitor link group correspondingly affect the state of the downstream interface, ensuring consistency between the two configuration example configuration example network requirements device uses ethernet ports 13,14 to connect to the uplink device and ethernet ports 1,2,3,4 to connect to the downlink device requirements when the upstream port all failure, need to promptly cut off the downstream port when the uplink port restores connection, the downlink port connection is restored with a delay of 5 seconds to prevent frequent up and down of the downlink port caused by unstable link procedure \# create linkage group 1 and specify a delay time of 5 seconds sonic(config)# monitor link group 1 5 sonic(config monitor link group 1)# \# add uplink and downlink ports, support range configuration sonic(config)# interface ethernet 13 sonic(config if 13)# monitor link 1 uplink sonic(config)# interface ethernet 14 sonic(config if 14)# monitor link 1 uplink sonic(config)# interface ethernet 1 sonic(config if 1)# monitor link 1 downlink sonic(config)# interface ethernet 2 sonic(config if 2)# monitor link 1 downlink sonic(config)# interface ethernet 3 sonic(config if 3)# monitor link 1 downlink sonic(config)# interface ethernet 4 sonic(config if 4)# monitor link 1 downlink verify configuration sonic# show monitor link + + + + + \| group name | delay | uplink members | downlink members | +==============+==========+==================+=====================+ \| 1 | 5 | ethernet13 | ethernet1 | \| | | ethernet14 | ethernet2 | \| | | | ethernet3 | \| | | | ethernet4 | + + + + +