BGP using BFD over IPSEC to hub

[bamather]

I currently have ADVPN setup with BFD enabled on my VPN interfaces and BGP keeps flapping a bit. I have adjust the times to fix the flapping issue by settings the following commands and left the retries to 3. I might be able to lower the times, but wanted to set them high to see if that worked.Hub set bfd-required-min-rx 2000Spoke with the issues (Not all spokes are having the issues) set bfd-desired-min-tx 2000 set bfd-required-min-rx 2000 My question is do I really need BFD enabled, as reg ibgp convergence rate is 5 seconds by default? Does BFD give me any other benifit other then faster convergence rate? Is anyone else doing BFD over IPSEC links and have you had to adjust the times?

[emnoc]

I would not do BFD over a ipsec-vpn , you flapping is cause by path between vpn gateway and packet lost, it's to sensitive.

Question you should be asking and considering;

Is the IPSEC vpn backing up a 2nd bgp ipsec-vpn or mpls? Do you need 2sec interval? Can you risk premature failure detection?

Ken Felix

[bamather]

Thank you so much emnoc for the reply.  I am very new to fortigate and BGP so learning as I go.  

My SE helped me create the config and he said BFD was for faster convergence rate but I'm starting to think I should remove it.  What is the default convergence rate of iBGP on the fortigates?  Are there timers I can adjust to make sure BGP doesn't flap?  How does iBGP know if a link is down?  

[emnoc]

BGP uses a KeepAlive and hold-down , you can adjust these but if you set a low value  the link is prone to "flaps" premature.

About convergence, bgp does not work like other dynamic-protocols. When a neighbor goes down the next BGP open connect message is NOT done immediately. So you can see convergence takes anywhere from 40 sec to 240 sec. Full load times can be upwards to 5 or more minutes depending on 1> bgp table size 2> hardware ( cpu intensive to load a 700k+ plus table ) 3> bgp scanner has to verify the next-hops ( again cpu intensive ) 4>

And finally any route withdraws takes time to move thru the public bgp backbone. You can't control what your eBGP peer neighbor does  ;) The last guy in the bgp-path is obviously going to get the advertisement and withdraws last. This is what bgp blackholes exists when routes are withdrawn btw.

As far as default timers you can see what is set via cli get bgp neighbor and look at the associate timers, theirs's no such thing as default convergence rate for iBGP or eBGP.

If you adjust the BGP KA to a longer timer, then yes the link might not flap but it can cause other issues if the bgp-peer is really not available. If your adjust the timers to fix a under laying issues, you are only fooling yourself and masking another problem. if the BGP link flap, a reason exist as to why it flapped.

I personally would leave things at 30sec KA and 90sec holddown imho. If it's over BGP GRE maybe 60/180 seconds.

Ken Felix