Tag :: BFD

As of EOS 4.17.0F, BFD support has been enhanced with support for configuring BFD within VRFs, improved scalability

Feature provides a way to set the Passive role in BFD session initialization. A system taking the Passive role does not begin sending BFD control packets for a particular session until it has received a BFD packet for that session, and thus has learned the remote system's discriminator value.

This document describes BFD RFC7130 mode on EOS. RFC7130 defines a mechanism to run BFD protocol over port channels with an independent asynchronous BFD session on every port channel member link. With RFC7130 support, the port channel member link will be removed from forwarding if the BFD session state transitions from UP to DOWN on the member link. This is useful for quickly detecting failures where L1 stays connected but the interface is unable to forward traffic.

BFD (Bidirectional Forwarding Detection) session telemetry allows for the collection of per session statistics as

This is achieved by using the next-hop of the static route as the peer IP address for the BFD session. The static route is either installed or removed based on the status of the underlying BFD session. A static route whose next-hop is configured to be tracked by BFD is referred to as a ‘BFD tracked static route’ in the context of this document. This feature is supported for both IPv4 and IPv6 static routes.

BFD Stateful Switchover (SSO) allows for a switchover from an active supervisor to a standby supervisor where BFD

This feature adds support for offloading BFD Transmit path to hardware (ASIC) for specific types of BFD sessions. This will improve accuracy of transmit timer implementations for BFD (especially with fast timers like 50 ms) and relieve pressure on the main CPU in scenarios of scale.

This feature adds support for offloading BFD Transmit path to hardware (ASIC) for specific types of BFD sessions.

A new configuration model for the BFD (Bidirectional Forwarding Detection) agent was added in order to more

EOS 4.17.0F adds support for BFD in OSPFv3. BFD provides a faster convergence in scaled deployments where using

This feature provides the capability to specify the label stack of the return path from the S-BFD reflector to the S-BFD initiator on the S-BFD initiator, which can be a different path from the shortest/best IGP path from the S-BFD reflector back to the S-BFD initiator, in order that the forwarding of the S-BFD packets would not be impacted by IP routing convergence, i.e., the stability of S-BFD session is not impacted by the IP routing convergence time. 

Bidirectional Forwarding Detection (BFD) is a protocol that provides low-overhead, short-duration detection of failures of arbitrary paths between two systems.

Prior to 4.25.2F, support for BGP PIC was restricted to locally identifiable failures such as link failures. If a

This document describes the Bgp Peer Flap Damping feature which allows session damping for peers with bfd enabled.

This feature allows customers to configure BFD intervals on a per BGP neighbor basis. We also have existing support for the configuration of BFD intervals on a per interface basis and the configuration of BFD intervals globally on the entire device.

EOS 4.15.0F added support for a CLI knob to determine whether the L3 forwarding agent (responsible for programming FECs and routes into hardware) would react to BFD status events for an interface to update next-hop programming for FECs programmed in hardware. This required two events, one for the BFD session to transition to an “Up” status and a subsequent transition to a “Down” status. This is identical to how various protocols in EOS (i.e. BGP, IS-IS) leverage BFD for faster down detection, and is useful to allow the L3 forwarding agent to preemptively remove next hops that would later be deprogrammed due to protocol session status state.