BFD for VPNv4 Static Routes

Load basic.l3vpn.fully.setup.cfg

#IOS-XE
config replace flash:basic.l3vpn.fully.setup.cfg

#IOS-XR
configure
load bootflash:basic.l3vpn.fully.setup.cfg
commit replace
y

Remove BGP between R1 and R2, and configure a static route on R2 to R1’s loopback. Ensure R8 can reach this. Run BFD between R1 and R2 so that R2 withdraws the route if R1 goes down.

Answer

#R1
no router bgp 65000
!
bfd-template multi-hop BFD_VRF_A
 interval min-tx 750 min-rx 750 multiplier 3
!
bfd map ipv4 10.1.2.2/32 10.1.2.1/32 BFD_VRF_A
ip route static bfd 10.1.2.2 10.1.2.1
ip route 0.0.0.0 0.0.0.0 10.1.2.2

#R2
router bgp 100
 add ipv4 vrf VPN_A
  no neighbor 10.1.2.2
  redistribute static
!
bfd-template multi-hop BFD_VRF_A
 interval min-tx 750 min-rx 750 multiplier 3
!
bfd map ipv4 vrf VPN_A 10.1.2.1/32 vrf VPN_A 10.1.2.2/32 BFD_VRF_A
ip route static bfd vrf VPN_A 10.1.2.1 vrf VPN_A 10.1.2.2
ip route vrf VPN_A 1.1.1.1 255.255.255.255 10.1.2.1

Explanation

BFD for IPv4 static routes in a VRF is quite complicated and unintuitive. First, you must use a BFD multi-hop session. This does not allow for the echo functionality to be used. Second, the multi-hop session cannot refer to the outgoing interface as we are used to with regular single-hop static routes.

Because we need a multi-hop session on R2, this seems to also require a multi-hop session on R1. The multi-hop session must always use a BFD template. The configuration involves first creating the template, and then manually creating the BFD session using the bfd map command. This associates a destination IP and source IP with a BFD template name.

bfd map ipv4 <destination>/32 <source>/32 <template name>

Next, we also need a static route BFD command which tells the router to form a BFD session with the nexthop. The previous command tells the router what template to use, and this command tells the router to start the BFD session when a static route to this nexthop exists.

ip route static bfd <destination> <source>

Finally, we have the static route which does not refer to an outgoing interface.

ip route 0.0.0.0 0.0.0.0 10.1.2.2

This is very confusing, because there doesn’t appear to be a good reason for a multi-hop session just because this is in a VRF.

Verification

On R2, we can confirm the BFD session is up, the registered protocol is IPv4 static, and we can see the mapping information, which tells us this is a multi-hop BFD session.

We can also see details about the static route using show ip static route vrf <name>

If we bring down Gi2.12 on R1, R2 will react by removing the static route from the table, withdrawing the VPNv4 route.

We can see on R5 that the VPNv4 route was withdrawn by R2: