BFD for Static Routes

eos.arista.com/eos-4-20-1f/bfd-for-static-routes

BFD for static routes enables monitoring of directly connected next-hop reachability using a
BFD session. This is achieved by associating the next-hop of the static route with a static
BFD neighbor configuration. 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.

Contents [hide]

Platform compatibility
Configuration
Configuration example
Status
Functional details
Special cases
Reboot case
ECMP case
Troubleshooting
Limitations

Platform compatibility
BFD for Static Routes feature is supported on all platforms.

Configuration
The existing ip route command under the global configuration mode takes additional
tokens for making a static route BFD tracked.

Arista(s1)(config)#ip route 1.1.1.1/24 20.20.20.2 track bfd

The above command will

add the static route 1.1.1.1/24

will try to initiate a BFD session to the next-hop address, 20.20.20.2 from the
interface that has the particular subnet. Note that if a BFD session already exists for
the next-hop/interface pair in question, the existing BFD session will continue to be
used
track this static route with the underlying BFD session. i.e. add the route only if the
BFD status is Up

1/5
no and default versions of above command will remove the static route as well as the
underlying BFD session. To not track a static route without deleting the route,ip
route command should be reapplied without the track bfd keywords in the CLI. The
following command is available under the interface configuration mode for establishing a
static BFD session to the directly connected neighbor.

Arista(s2)(config)#interface Ethernet1
Arista(s2)(config-if-et1)#bfd static neighbor 20.20.20.1

The above command takes the IPv4/IPv6 next-hop or destination address (directly
connected peer’s address) as an input which must be a single hop away acting as the other
end of this BFD session. This command tries to initiate a BFD session to the specified next-
hop address. no and default versions of the command will be identical and will de-register
itself from the BFD session to this next-hop. Either a static BFD configuration (using the bfd
static neighbor command) or a static route with a track bfd configuration must exist on the
peer side for the BFD session to come up successfully between the two switches. For IPv6
configuration, the next-hop address could be a link-local or a global IPv6 address
depending upon the static route configuration. For a static route with a link-local address as
a next-hop, the user will also have to specify the outgoing interface. The CLI enforces this
requirement.

Configuration example
In the following example, the network consists of two devices, S1 and S2. The interface,
Ethernet1 on S1 is connected to the same network as Ethernet1 on S2. S1

Arista(s1)(config)#ip route 1.1.1.1/24 20.20.20.2 track bfd

S2

Arista(s2)(config)#interface Ethernet1
Arista(s2)(config-if-et1)#ip address 20.20.20.2/24
Arista(s2)(config-if-et1)#bfd static neighbor 20.20.20.1

As soon as the BFD configuration is applied on both the devices, a single hop BFD session
is initiated. The prefix 1.1.1.1/24 is installed on S1 only if the BFD session reaches the
state Up. Note that it is not necessary for S2 to have a static route configured via S1 for the
BFD session to establish.

Status
Existing show bfd neighbors [ vrf <vrf-name> ] [ dest-ip <dest-ip> ] detail command
which is used to display BFD session information between peers for various protocols such
as BGP, OSPF etc will now have extra two clients under the registered protocols section,
static for ‘bfd static neighbor’ configuration and static-route for the static route BFD
configuration.

2/5
Arista(s1)#show bfd neighbors dest-ip 20.20.20.2 detail
VRF name: default
-----------------
Peer Addr 20.20.20.2, Intf Ethernet1, Type normal, State Up
VRF default, LAddr 20.20.20.1, LD/RD 4207739054/2798418548
Session state is Up and not using echo function
Last Up Oct 16 00:36:26 2017
Last Down Oct 16 00:36:26 2017
Last Diag: No Diagnostic
TxInt: 300, RxInt: 300, Multiplier: 3
Received RxInt: 300, Received Multiplier: 3
Rx Count: 71, Rx Interval (ms) min/max/avg: 112/303/298 last: 895 ms ago
Tx Count: 314, Tx Interval (ms) min/max/avg: 300/5285/334 last: 895 ms ago
Detect Time: 900
Sched Delay: 1*TxInt: 0, 2*TxInt: 309, 3*TxInt: 0, GT 3*TxInt: 4
Registered protocols: static-route
Uptime: 20.90
Last packet: Version: 1 - Diagnostic: 0
State bit: Up - Demand bit: 0
Poll bit: 0 - Final bit: 0
Multiplier: 3 - Length: 24
My Discr.: 2798418548 - Your Discr.: 4207739054
Min tx interval: 300 - Min rx interval: 300
Min Echo interval: 300

Arista(s2)#show bfd neighbors dest-ip 20.20.20.1 detail

VRF name: default
-----------------
Peer Addr 20.20.20.1, Intf Ethernet1, Type normal, State Up
VRF default, LAddr 20.20.20.2, LD/RD 2798418548/4207739054
Session state is Up and not using echo function
Last Up Oct 16 00:36:26 2017
Last Down Oct 16 00:36:26 2017
Last Diag: No Diagnostic
TxInt: 300, RxInt: 300, Multiplier: 3
Received RxInt: 300, Received Multiplier: 3
Rx Count: 108, Rx Interval (ms) min/max/avg: 266/304/300 last: 240 ms ago
Tx Count: 425, Tx Interval (ms) min/max/avg: 300/3132/386 last: 1240 ms ago
Detect Time: 900
Sched Delay: 1*TxInt: 0, 2*TxInt: 423, 3*TxInt: 0, GT 3*TxInt: 1
Registered protocols: static
Uptime: 32.25
Last packet: Version: 1 - Diagnostic: 0
State bit: Up - Demand bit: 0
Poll bit: 0 - Final bit: 0
Multiplier: 3 - Length: 24
My Discr.: 4207739054 - Your Discr.: 2798418548
Min tx interval: 300 - Min rx interval: 300
Min Echo interval: 300

Functional details
For a static route (IPv4 or IPv6) to get BFD tracked, the user needs to specifytrack
bfd while configuring the static route. If there are multiple static routes via the same next-
hop each of these will need to be individually configured for BFD tracking. Consider the
3/5
following example.

Arista(s1)(config)#ip route 10.10.0.0/16 20.20.20.2 track bfd

Arista(s1)(config)#ip route 15.15.0.0/16 20.20.20.2 track bfd
Arista(s1)(config)#ip route 30.30.0.0/16 20.20.20.2

A BFD session exists between S1 and S2 on interface, Ethernet1. S1 has three static
routes with 20.20.20.2 (Et1’s interface address on S2) as the forwarding address. The first
two routes with prefixes, 10.10.0.0/16 and 15.15.0.0/16 have track bfd configured while the
last one with the prefix, 30.30.0.0/16 does not. When S1 will get a BFD Down notification,
the routes with prefixes, 10.10.0.0/16 and 15.15.0.0/16 will be uninstalled whereas the
route with prefix, 30.30.0.0/16 will not be uninstalled as this route was not being tracked by
the underlying BFD session. For a BFD session to be successfully established, BFD
configuration must exist on the interface on the peer and there must be a BFD client
registered on the peer for the address of the BFD neighbor. If there is a static route present
on the switch before the track bfd configuration is applied on this route, the route will
remain inactive until the BFD session comes Up and it will cause this route to flap for the
duration when track bfd is applied till the time when BFD session reached Up state. No
route flap shall be observed if a BFD session to the next-hop is already present and the
status for the same is Up. To summarize, for a static route to be BFD tracked the following
must be true

the BFD session must be single hopped (only directly connected neighbors)
the forwarding address specified in the static route configuration must be directly
connected and via the same interface as the outgoing interface in the route (if
specified)

Special cases
if the BFD configuration is removed from the device or from the remote peer while the
BFD session is in Up state, the route will remain installed. The static route will be
removed when there is a BFD Up to Down transition
if the BFD configuration is removed from the device while the BFD session is in the
Down state, all the tracked static routes with this BFD session will get installed now
if the BFD configuration is removed from the remote peer while the BFD session was
in Down state, all the tracked routes will remain uninstalled. To install these routes
again, either bring the remote peer and the BFD session up or remove the BFD
configuration from the device as well

Reboot case
Upon reboot, the switch shall first bring up the static BFD sessions and then install the
static routes. Some delay in route installation can be expected due to this.

ECMP case
If there are multiple static routes configured for the same destination via multiple next-hops
i.e. a static ECMP route exists and one of the next-hops for this prefix is BFD-tracked, then
only that particular next-hop will be removed from the static route when BFD signals Down.
4/5
The destination will still remain reachable via other next-hops. Consider the following
example

Arista(s2)(config)#ip route 10.10.0.0/16 10.1.1.1 track bfd

Arista(s2)(config)#ip route 10.10.0.0/16 10.1.1.2
Arista(s2)(config)#ip route 10.10.0.0/16 10.1.1.3

In this example, we have an ECMP static route to the destination,10.10.0.0/16 with next-
hops 10.1.1.1, 10.1.1.2 and 10.1.1.3. Out of the three next-hops for the ECMP route, only
one is BFD tracked – 10.1.1.1. Now if the BFD session with the next-hop 10.1.1.1 goes
down, it will result in the next-hop 10.1.1.1 being removed for the destination 10.10.0.0/16.
In this case, ECMP route 10.10.0.0/16 will now be installed with the next-hops 10.1.1.2 and
10.1.1.3. Traffic will flow through all the reachable next-hops in all the scenarios,
irrespective of the next-hop being BFD tracked, which means that traffic will flow through all
the ECMP next-hops if they are reachable.

Troubleshooting
Following points can be considered in case of unexpected results

BFD tracked next-hop should be directly connected

if an interface is specified in the track bfd CLI, then BFD tracked next-hop should be
directly connected to the specified interface
next-hop peer which needs to be BFD tracked should be configured to register itself
as a BFD client for the address of the BFD neighbor

Limitations
Tracking of a multi-hop next-hop using BFD is not supported.

5/5