11. BFD

11.1. Overview

Bidirectional Forwarding Detection (BFD) is a lightweight mechanism used to monitor the liveliness of a remote neighbor. It is meant to be lightweight enough so that the ongoing sending and receiving mechanism can be implemented in the forwarding hardware. Because of this lightweight nature, BFD can send and receive messages at a much higher rate than other control plane hello mechanisms. This attribute allows connection failures to be detected faster than other hello mechanisms.

SR Linux supports BFD asynchronous mode, where BFD control packets are sent between two systems to activate and maintain BFD neighbor sessions between them.

BFD is supported for the BGP routing protocol, supporting IPv4 and IPv6 BGP peering. SR Linux supports one BFD session per port/connector, or up to 1152 sessions for an 8-slot chassis, depending on the hardware configuration.

SR Linux supports micro-BFD, where BFD sessions are established for individual members of a link aggregation group (LAG). If the BFD session for one of the links indicates a connection failure, the link is taken out of service from the perspective of the LAG.

This section describes the minimal configuration necessary to set up BFD on SR Linux. To create a BFD session, you configure BFD on both systems (or BFD peers). Once BFD has been enabled on the interfaces and at the global level for the appropriate routing protocols, a BFD session is created, BFD timers are negotiated, and the BFD peers begin to send BFD control packets to each other at the negotiated interval.

For information about all other BFD settings, see the SR Linux online help, as well as the SR Linux Data Model Reference.

11.2. BFD configuration

11.2.1. Configuring BFD for a subinterface

This procedure enables BFD with an associated subinterface, and sets values for intervals and criteria for declaring a session down.

Timer values are in microseconds. The detection interval for the BFD session is calculated by multiplying the value of the negotiated transmission interval by the value specified in this field.

Example:

The following example configures BFD for a subinterface.

--{ candidate shared }--[  ]--
info bfd
    bfd {
        subinterface ethernet-1/2.1 {
            admin-state enable
            desired-minimum-transmit-interval 250000
            required-minimum-receive 250000
            detection-multiplier 3
        }
    }

11.2.2. Configuring BFD under the BGP protocol

BFD can be configured under the BGP protocol at the global, group, or neighbor level.

Prior to enabling, BFD must first be configured for a subinterface and timer values must be set. See Configuring BFD for a subinterface.

Examples:

The following example configures BFD under the BGP protocol at the global level.

--{ candidate shared }--[  ]--
info network-instance default
    network-instance default {
        protocols {
            bgp {
                failure-detection {
                    enable-bfd true 
                    }
                }
            }
        }
    }

The following example configures BFD under the BGP protocol at a group level.

--{ candidate shared }--[  ]--
info network-instance default protocols bgp
    network-instance default {
        protocols {
            bgp {
                group test {
                    failure-detection {
                        enable-bfd true 
                        }
                    }
                }
            }
    }

The following example configures BFD under the BGP protocol at a neighbor level.

--{ candidate shared }--[  ]--
info network-instance default protocols bgp
    network-instance default {
        protocols {
            bgp {
                neighbor 192.35.1.3 {
                    failure-detection {
                        enable-bfd true
                        fast-failover true
                    }
                }
            }
        }
    }

11.2.3. Viewing the BFD state

Use the info from state command to verify the BFD state for a network-instance.

Example:

info from state bfd network-instance default peer 30 
    bfd {
        network-instance default {
            peer 30 {
                oper-state up
                local-address 192.35.1.5
                remote-address 192.35.1.3
                remote-discriminator 25
                subscribed-protocols bgp_mgr
                session-state UP
                remote-session-state UP
                last-state-transition 2020-01-24T16:22:55.224Z
                failure-transitions 0
                local-diagnostic-code NO_DIAGNOSTIC
                remote-diagnostic-code NO_DIAGNOSTIC
                remote-minimum-receive-interval 1000000
                remote-control-plane-independent false
                active-transmit-interval 250000
                active-receive-interval 250000
                remote-multiplier 3
                async {
                    last-packet-transmitted 2020-01-24T16:23:19.385Z
                    last-packet-received 2020-01-24T16:23:18.906Z
                    transmitted-packets 32
                    received-packets 32
                    up-transitions 1
                }
            }
        }
    }

11.3. Micro-BFD

11.3.1. Overview

Micro-BFD refers to running BFD over the individual links in a link aggregation group (LAG) to monitor the bidirectional liveliness of the Ethernet links that make up the LAG.

A LAG member cannot be made operational within the LAG until the micro-BFD session is fully established. If a micro-BFD session fails, the corresponding Ethernet link is taken out of service from the perspective of the LAG.

Micro-BFD is supported on Ethernet LAG interfaces with an IP interface. Micro-BFD sessions are associated with each individual link. When enabled, the state of the individual links depends on the micro-BFD session state:

  1. Micro-BFD sessions must be established between both endpoints of a link before the link can be operationally up.
  2. If the micro-BFD session fails, the associated Ethernet link becomes operationally down from the perspective of the LAG.
  3. If LACP is not enabled for the LAG, if the Ethernet port is up, the system attempts to re-establish the micro-BFD session with the far end of the link.
  4. If LACP not enabled for the LAG, if the Ethernet port is up, the system attempts to re-establish the micro-BFD session with the far end of the link once LACP reaches distributing state.

If a link is not active for forwarding from the perspective of a LAG, ARP can still be performed across the link. For example, when a link is being brought up, and its micro-BFD session is not yet established, ARP can still be performed for the MAC address at the far end of the link, even though the link is not yet part of the LAG.

Micro-BFD packets bypass ingress and egress subinterface/interface ACLs, but received micro-BFD packets can be matched by CPM filters for filtering and logging.

11.3.2. Configuring micro-BFD for a LAG interface

Example:

The following example configures micro-BFD for a LAG interface. The example configures IP addresses to be used as the source address for IP packets and a remote address for the far end of the BFD session.

The example configures the minimum interval in microseconds between transmission of BFD control packets, as well as the minimum acceptable interval between received BFD control packets. The detection-multiplier setting specifies the number of packets that must be missed to declare the BFD session as down.

--{ candidate shared }--[  ]--
info micro-bfd-sessions
    micro-bfd-sessions {
        lag-interface lag1 {
            admin-state enable
            local-address 192.35.2.5
            remote-address 192.35.2.3
            desired-minimum-transmit-interval 250000
            required-minimum-receive 250000
            detection-multiplier 3
        }
    }

11.3.3. Viewing the micro-BFD state

Use the info from state command to verify the micro-BFD state for members of a LAG interface.

Example:

info from state micro-bfd-sessions lag-interface lag1 member-interface 
ethernet 2/1
    micro-bfd-sessions
        lag-interface lag1 {
            admin-state UP
            local-address 192.35.1.5
            remote-address 192.35.1.3
            desired-minimum-transmit-interval 250000
            required-minimum-receive 250000
            detection-multiplier 3
            member-interface ethernet 2/1 {
                session-state UP
                remote-session-state UP
                last-state-transition 2020-01-24T16:22:55.224Z
                last-failure-time 2020-01-24T16:22:55.224Z
                failure-transitions 0
                local-discriminator 25
                remote-discriminator 25
                local-diagnostic-code NO_DIAGNOSTIC
                remote-diagnostic-code NO_DIAGNOSTIC
                remote-minimum-receive-interval 1000000
                remote-control-plane-independent false
                active-transmit-interval 250000
                active-receive-interval 250000
                remote-multiplier 3
                async {
                   last-clear 2020-01-23T16:21:19.385Z
                   last-packet-transmitted 2020-01-24T16:23:19.385Z
                   last-packet-received 2020-01-24T16:23:18.906Z
                   transmitted-packets 32
                   received-errored-packets 3
                   received-packets 32
                   up-transitions 1
                }
            }
        }
    }