BFD for Static Routes
Last updated
Last updated
Load base.ipv4.and.ipv6.cfg
Configure static routes between R4 and R6 to their IPv4/IPv6 loopbacks via their directly connected interfaces.
If this link goes down, they should use R5.
Use BFD for failure detection.
Simply configure R5 with static routes to the IPv4/IPv6 loopbacks of R4 and R6.
BFD can also be used for static routes. This is an attractive alternative to using IP SLA, tracking, and associating the tracking with a static route. In this lab, R4 and R6 are directly connected (single-hop), so the echo can be used, which provides for hardware offloading as well.
To use BFD with a static route we need three things:
We need the static route to have both an outgoing interface and nexthop address.
We need a second command that instructs the router to use BFD for static routes with the matching outgoing interface and nexthop. Essentially, the following commands state “for static routes that have a specified outgoing interface of gi2.46 and nexthop of 20.4.6.6/2001:20:4:6::6, use BFD.” You can also think of this command as replacing the activation of BFD for a given protocol (i.e. “ip ospf bfd”).
We need to activate BFD on the interface as usual, with either the bfd interval command or using a BFD template.
Finally, in this lab we need a floating static route via R5. This will replace the static route to R4/R6 when BFD detects that the neighbor has failed.
When using BFD for static routes, there is a sort of “reverse logic” compared to when using BFD with a routing protocol. For instance, OSPF first discovers the neighbor and then tells BFD to form a session with this neighbor. With a static route, the neighbor is essentially maunally specified via the ip route static bfd interface next-hop command. BFD first forms the session, and if it comes up, the static route is installed in the RIB.
On R4 we should see two BFD sessions, one for R6’s IPv4 address and one for R6’s IPv6 address:
As we saw previously for OSPFv3, IPv6 does not support BFD echos:
A handy command to verify the static route is show ip static route. This displays all known static routes, and many more flags than are available in the normal show ip route static command.
Above, we see that 6.6.6.6/32 via Gi2.46 20.4.6.6 is a manually specified static route, is tracked using BFD, and is active. The route via 20.4.5.5 is current not active. If we shut gi2.46 on R6, R4 will remove the static BFD-tracked route, and the floating static will appear in the RIB.
In the show ip static route table, we can now see that the BFD-tracked route is not active.
Similar information is available for IPv6 static routes using show ipv6 static detail:
It is worth spending a moment to examine the BFD groups feature for static routes. This allows you to group together multiple BFD peers that share the same fate. If one peer goes down, you may want to mark routes reachable via the other peer as down as well. By grouping these peers together, you only need to run a single BFD session to one peer. If desired, you can run BFD with multiple peers in the group. The passive keyword controls whether you run BFD with the nexthop. When all BFD peers are down in that group, then all routes associated with the group are withdrawn from the RIB.
For example, let’s join R3 and R5 to the VLAN 46 LAN.
On R4, we’ll add two more static routes via Gi2.46. We’ll consider R3, R5, and R6 all in the same BFD group. We will not run BFD with R3 or R5. You can only have one peer in the BFD group as active.
When BFD is up with R6, all static routes are present in the RIB. Note that R4 only has one single BFD IPv4 session.
When Gi2.46 goes down on R6, all static routes with nexthops in the BFD group go down as well.
Note that this feature appears to only be available for IPv4.
Both IPv4 and IPv6 BFD static route commands have the keyword unassociate available. This appears to just disable BFD for the static route peer.
For example, currently the route to R6’s loopback is via R5 because the BFD peer is down.
If we change the R6 IPv6 BFD peer to be “unassociated” then the static route appears again in the table. I don’t quite understand why you wouldn’t just remove the BFD static route statement in the first place.
