SD WAN : BFD + OSPF

[RS19]

In Cisco SD-WAN want to understand how BFD & OSPF co-work together.

I understand that BFD is used to monitor the underlay. If it find that the remote end point is not responding it brings down the bfd session. Want to understand how this works along with the OSPF. OSPF as routing protocol has it own timers to bring up and bring down the OSPF neighbourship. Wanted to understand how this both works together ?

[RS19]

Thanks. How to check the underlay ?

[RS19]

any help or input ? Under interface I found the below.  (Hello interval & hello tolerance) Is this the bfd timer ?
Also in the end it has the command no allow-service bfd. Does this means bfd is not enabled in this interface ?

interface GigabitEthernet0/0/4
tunnel-interface
encapsulation ipsec weight 1
no border
color metro-ethernet restrict
no last-resort-circuit
no low-bandwidth-link
max-control-connections 0
no vbond-as-stun-server
vmanage-connection-preference 0
port-hop
carrier default
nat-refresh-interval 5
hello-interval 1000
hello-tolerance 12
no allow-service bfd

[RS19]

Even though the below is configured since no allow-service bfd is configured does it mean underlay bfd is not enabled ?

hello-interval 1000
hello-tolerance 12

[RS19]

What could be the reason no allow-service bfd is configured

[RS19]

Need help

[MHM Cisco World]

MHM

[RS19]

Thanks. Mine it shows as below. no allow-service bfd is configured.

interface GigabitEthernet0/0/4
tunnel-interface
encapsulation ipsec weight 1
no border
color metro-ethernet restrict
no last-resort-circuit
no low-bandwidth-link
max-control-connections 0
no vbond-as-stun-server
vmanage-connection-preference 0
port-hop
carrier default
nat-refresh-interval 5
hello-interval 1000
hello-tolerance 12
no allow-service bfd

Does it means, bfd is not running on this interface ?

[RS19]

no allow-service bfd

Any reason for the above command ?

[MHM Cisco World]

As I mention there is SDWAN BFD run in the overly tunnel and it by default enable can be disable 

there is BFD legacy use in transport and service 

Enable BFD for Service-Side BGP

This example shows that BGP is configured, BFD is enabled on the interface under VRF 1, and then on service-side BGP.

interface GigabitEthernet5
bfd template t1
!                 
router bgp 10005
  bgp log-neighbor-changes
  distance bgp 20 200 20
  !
  address-family ipv4 vrf 1
  bgp router-id 10.20.24.15
  redistribute connected
  neighbor 10.20.24.17 remote-as 10007
  neighbor 10.20.24.17 activate
  neighbor 10.20.24.17 send-community both
  neighbor 10.20.24.17 maximum-prefix 2147483647 100
  neighbor 10.20.24.17 fall-over bfd
  exit-address-family
  !
  address-family ipv6 vrf 1
  bgp router-id 10.20.24.15
  neighbor 2001::7 remote-as 10007
  neighbor 2001::7 activate
  neighbor 2001::7 send-community both
  neighbor 2001::7 maximum-prefix 2147483647 100
  neighbor 2001::7 fall-over bfd
  exit-address-family

Enable BFD for Transport-Side BGP

interface GigabitEthernet1
bfd template t1
!                 
router bgp 10005
bgp router-id   10.1.15.15
bgp log-neighbor-changes
distance bgp 20 200 20
neighbor 10.1.15.13 remote-as 10003
neighbor 10.1.15.13 fall-over bfd
address-family ipv4 unicast
neighbor 10.1.15.13 remote-as 10003
neighbor 10.1.15.13 activate
neighbor 10.1.15.13 maximum-prefix 2147483647 100
neighbor 10.1.15.13 send-community both
redistribute connected
exit-address-family
!
timers bgp 60 180

sdwan
interface GigabitEthernet1
tunnel-interface
allow-service bgp
allow-service bfd <<- NEED SURE FOR transport 

[Kanan Huseynli]

Let me explain this..

In SD-WAN, BFD is one of the mandatory protocols which runs over IPSec or GRE, so point-to-point tunnel between routers are established and BFD runs inside tunnel. Purpose of BFD is health check i.e is BFDs are missing tunnel is considered down. Also, based on BFD requests/responses it is calculated point-to-point loss % , jitter, delay which is important for application aware routing.

2024/7/19 21:08 SDWAN 10.1.1.13 bfd-state-change major BFD host-name=SDWAN; src-ip=10.2.255.2; dst-ip=10.3.255.1; proto=ipsec; src-port=12386; dst-port=12386; local-system-ip=10.1.1.13; local-color=metro-ethernet; remote-system-ip=10.1.254.1; remote-color=metro-ethernet; new-state=down; deleted=false; flap-reason=timeout

This alert means that between 10.2.255.2 and 10.3.255.1 (udp 12386/12386) is went down due to timeout (no response within timeout timer).

Parameters of this BFD function can be changed via feature template in vManage GUI.

***

One the other than after 17.3/20.3 classic/legacy BFD is introduced to quickly detect failure for routing protocols - OSPF/BGP/EIGRP for service-side (VPN X)

Since BGP can be on transport side, BFD is also supported for transport side BGP. This is optional feature, you may or may not enable it. It optimizes routing protocols so fast neighbor failure is detected. This function is configured via CLI Add-on template (pure CLI configuration). This does not have any relation to your mentioned alert.

[RS19]

Thanks @Kanan Huseynli 

Let me ask few more questions for clarifications.
After the above logs shared, I got the below message after2 seconds that the state is up.

remote-color=metro-ethernet; new-state=up; deleted=false; flap-reason=na

So the BFD went down and came up in 2 seconds.

What I am trying to find out what is the BFD timers. What is the hello interval ? How frequently BFD are sent and when it is decided that the session is down. Basically I want to know the timers.

When I checked my SD-WAN configuration, I found 2 things.

1. There is a feature template for BFD and it is applied to all devices.
The feature template has the below configurations.

Multiplier - 6
Poll Intervals (milliseconds) - 120000

2. Under the transport interface found the below configuration.
Is  hello-interval 1000 & hello-tolerance 12 related to BFD timers. Also there is command no allow-service bfd. Does this mean bfd is not allowed in this interfaace ?
---------------------------------------------------------------------
interface GigabitEthernet0/0/4
tunnel-interface
encapsulation ipsec weight 1
no border
color metro-ethernet restrict
no last-resort-circuit
no low-bandwidth-link
max-control-connections 0
no vbond-as-stun-server
vmanage-connection-preference 0
port-hop
carrier default
nat-refresh-interval 5
hello-interval 1000
hello-tolerance 12
allow-service all
allow-service bgp
no allow-service dhcp
allow-service dns
no allow-service icmp
no allow-service sshd
no allow-service netconf
no allow-service ntp
no allow-service ospf
no allow-service stun
allow-service https
no allow-service snmp
no allow-service bfd

[RS19]

In addition my cEdge version is 17.09.03.0.15
So in this version does it runs both the type of BFDs.

[MHM Cisco World]

vEdge-2# show bfd sessions 

this give you interval and multiplier
NOTE:- if command not work add ""sdwan"" word after show  

I think by default the BFD have same value for all color but you can change that.

 

[Kanan Huseynli]

Hi,

hello-interval and hello-tolerance interface are for interface control packets (DTLS or TLS). This is not related to BFD.

https://www.cisco.com/c/en/us/td/docs/routers/sdwan/configuration/system-interface/ios-xe-17/systems-interfaces-book-xe-sdwan/configure-interfaces.html#id_113927

BFD has other commands as timers:

show sdwan running-config bfd - command that shows configuration.

By default, BFD packets are send every 1 sec (the same value of interface DTLS/TLS hello-interface).

Multiplier is 7 which means, if 7 consecutive hellos are lost, then tunnel is down.

https://www.cisco.com/c/en/us/td/docs/solutions/CVD/SDWAN/cisco-sdwan-design-guide.html#BidirectionalForwardingDetectionBFD

Coming back to your case:

tunnel went down

tunnel comes up after 2 seconds

> this is normal, because BFD hellos are sent every 1 sec by default (configurable per color using global config mode, note interface).

If you had default values but tunnel comes up and immediately after 2 seconds goes down then this would be not normal, since router should wait 7 seconds.

[RS19]

Thanks. I understand that hello-interval and hello-tolerance are not related to bfd timers.
But my question still continues with respect to BFD timers regarding below point.

1. There is a feature template for BFD and it is applied to all devices.
The feature template has the below configurations.
Multiplier - 6
Poll Intervals (milliseconds) - 120000

Does this means BFD will be polled only after every 2 minutes ?
My understanding is that it will poll for every 2 minutes. If so how the below log is there in 2 seconds after it went down.

remote-color=metro-ethernet; new-state=up; deleted=false; flap-reason=na

In additon once the bfd state change is detected by when OSPF wil try to recalculate the path.