fun with bi-directional forwarding (BFD)

So I was tasked to provide a failover mechanism for a customer with Juniper equipment without using OSPF.

With the L2 providers we use there is always a link from the CPE to the provider equipment and then it breaks out to their backbone.  Now, this means that there could be a break in the provider network and the customer CPE would still see the link as up.  We would then be blindly forwarding traffic into a black hole.

In order to prevent this we would need to track the upstream reachability.  Now normally I would use object tracking if I was on a Cisco but Juniper does not have this function.  After a quick look around there were 2 options open to me.

1)  Use RPM and event scripts to trigger commands to be used

2) Use BFD to withdraw a static route when the upstream reachability failed.

As I have the coding ability of a cheese sandwich, BFD was the one to use.  Now the difference between object tracking and BFD is that BFD is a 2way process meaning your neighbor will need to respond to your BFD hello packets in order for the CPE to judge if the neighbor is reachable.

This means means that the upstream router will need BFD enabled as well.  Thankfully the other part of the failover process was for me to withdraw some public addresses that were statically routed to the CPE.  If this is not open you you then it’s possible to route a bogus address to the CPE for BFD to come up.

Our failover set up meant that if our main router could not reach the default gateway it would withdraw the primary route which would leave a weighted default gateway to head to a secondary router.

Config for the router as per below and for obvious reasons the ip addresses have been changed with RFC1918’s 🙂

route 0.0.0.0/0 {

qualified-next-hop 192.168.1.1 {

preference 200;

}

qualified-next-hop 172.16.10.1 {

bfd-liveness-detection {

minimum-interval 1000;

}

}

}

Qualified-next-hop had to be used over next hop to the 2 default routes could be treated seperately so we can set prefences individually.  If we did not do this BFD would try to confirm upstream reachability with both next-hop’s which would fail.

Hope this helps someone in the same situation

A big thanks to @fail_over and @showlette for pointing me in the right direction.

Advertisements

2 thoughts on “fun with bi-directional forwarding (BFD)

    • Yeah I was bashing my head against a wall trying to get the default route to have a seperate metric for one of them and BFD on the other. Junos seems to combine whereas Cisco is seperate

      Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s