If I enable BFD, will my OSPF route go down until I complete BFD on remote end?

[keithsauer507]

We are using OSPF as our interior routing protocol with all default timers.  I've tested failover between sites and if I manually disable one WAN path, a constant ping from a Windows PC will drop for 8 cycles and then it will re-establish connectivity.  I do not think a single ping cycle in Windows is 1 second, so this is a bit of time to re-establish connectivity via an alternate path.

I was reading up on BFD and I would like to try enabling it, at least on the links between our HQ and one of our other sites for testing.  The site is connected via two links, an 802.11n wireless bridge between rooftops, and a 40mbps fiber private connection from a local cable operator.

My concern is, if I enable BFD on one side, will my OSPF adjacency be marked down because I have not completed the configuration on the other side?  If I enable BFD on this side, the other side is not yet participating in BFD, so therefore this side will never get BFD packets back and mark that OSPF path as down.  This means an 8 to 30 second network outage that would drop voice and video calls in the other building.

So what is the best way to enable BFD without accidently having it mark OSPF paths as down?

I would be doing this between Cisco and Extreme Networks gear.  On Extreme XOS, the default default transmit and receive interval is 1000ms unless specified otherwise.  I'm not sure what Cisco IOS default is, or if you must specify.  I would imagine they need to be specified the same.

[Nagendra Kumar Nainar]

Hi,

Enabling BFD in an existing OSPF environment will not bring the existing session down. BFD session will come up and then register with OSPF client. So bringing up BFD session will not impact your environment. 

If the BFD session goes down after it registers with OSPF client, the client will be immediately notified and brought down.

HTH,

Nagendra

[Joseph W. Doherty]

I recall (?) BFD first requires them to become neighbors. I.e. I don't recall it being configured on just one side will take OSPF down.

BTW, what equipment supports BFD can be limited. You might also find a use for reducing OSPF's hello interval and/or using OSPF's fast-hello feature (if supported).

[keithsauer507]

Well for our one site we have a 3750x switch stack ipbase on 12.2(55)SE12.  I know I have to upgrade this to 15.2-4 E7 so I may put in a change request to do that in a few weeks.

Otherwise we have other sites with Cisco 2901 or 2911 routers that can handle bfd.

I think I just need to enable it between these remote sites and our HQ for the primary wan link.  If that goes down, we have another route out via AT&T LTE which after the gre tunnel we are seeing latency in the 250-350 range, so while its a connection, its not really a good one.  If the main link comes back up, it should propagate the change quickly enough to get the branch office back on the primary fiber optic wan.

Now my one ISP has us in a private cloud where any site on that ISP can talk to any site.  The latency on this is around 21-24 ms.  I guess I don't need BFD on ALL sites at once, but I should be able to phase them in.  My other ISP is more like a point to multipoint metro ethernet connection, so those sites must come back to HQ first.  I don't see an issue here.  The latency on this is around 1 to 4 ms.

[Joseph W. Doherty]

Depending on the nature of your WAN link, I recall (?) BFD might not work across all WAN media. Even if you're using some form of WAN Ethernet, sometimes the vendors block certain low level frames.

"If the main link comes back up, it should propagate the change quickly enough to get the branch office back on the primary fiber optic wan."

BTW, qQuick propagation of OSPF topology changes entails more than fast detection that a link is down. You might want to peruse this white paper: https://www.cisco.com/c/en/us/td/docs/solutions/Enterprise/Campus/routed-ex.html#wp998802

[keithsauer507]

Thanks, I’m going to give that a read.

Luckally all of our sites have more than one path out.  So when tuning OSPF timers on one link at a time (you can do it per interface right), when the adjacency is torn down because the timers don’t match on the other end and I can only type so fast.... then I still have a backup path.

The backup path or LTE tunnel can remain with the default timers.  It’s just the primary high performance link that I’m concerned about.

[Joseph W. Doherty]

Yes, that can happen, but in my experience, I've often been able to make the change (decreasing hello intervals) without OSPF dropping the adjacency. Part of the trick, is to type in the final command on both router's interfaces (using different telnet sessions), then press enter on the far side router immediately followed by pressing enter on near side router.)

[Patrick.Williams · Accepted solution]

By enabling BFD this will in no way interfere with your underlying IGP as in your case OSPF, keep in mind that this is a separate process that simply indicate to your routing protocol that there is an issue , hellos etc are completely separate.

Here is an example of the config i have in my working lab.

Just for the heck of doing it despite knowing the results i  took down the BFD configurations and re enter it again , no packet loss or anything happened, only the re-establishment of the BFD neighbor relationship.

See Interface Configurations

See BFD Neighbor Relationship.

Rest assure you will have no form of interruptions.

**** Please remember to Rate this post****