BFD Not Working For Withdrawal of Static Route

  • 0
  • 1
  • Problem
  • Updated 4 years ago
  • Solved
  • (Edited)
We are looking to introduce some static routing to address OSPF instability issues ( long story about multicast traffic over AT&T Switched Ethernet service ).

Basically, I want a static route from a hub router out to a spoke router but I want the route to be withdrawn if the hub loses connectivity to the spoke router because there is an alternative path.

So on the hub router I have:

enable iproute bfd 10.254.101.2 vr VR-Default
configure iproute add 10.1.0.0 255.255.0.0 10.254.101.2 bfd

on the spoke router I just enable the BFD client:

enable iproute bfd 10.254.101.1 vr VR-Default

With this done I can see the route as follows:

Ori  Destination        Gateway         Mtr  Flags         VLAN       Duration
#s   10.1.0.0/16        10.254.101.2    1    UG---Spum--f- MetroA     0d:20h:50m:38s

Flags: (b) BFD protection requested, (B) BlackHole, (c) Compressed, (D) Dynamic,       (f) Provided to FIB, (G) Gateway, (H) Host Route, (l) Calculated LDP LSP,
       (L) Matching LDP LSP, (m) Multicast, (p) BFD protection active, (P) LPM-routing,
       (R) Modified, (s) Static LSP, (S) Static, (t) Calculated RSVP-TE LSP,
       (T) Matching RSVP-TE LSP, (u) Unicast, (U) Up, (3) L3VPN Route.


The "p" flag indicate that BDF protection is active and the "f" that the route is in the FIB.

If I actually pull the cable out between the devices:

Ori  Destination        Gateway         Mtr  Flags         VLAN       Duration 
 s   10.1.0.0/16        10.254.101.2    1    -G---Spum---- MetroA     0d:20h:54m:19s

The route is Down and not in the forwarding database. If I disable the BFD client on the spoke router so as to bring down the BFD session, I get the following on the spoke router:

#s   10.1.0.0/16        10.254.101.2    1    UG---Sbum--f- MetroA     0d:20h:58m:51s

The "b" flag indicates that BFD protection is requested ( but not active ). The "f" flag is set so the route is still in the FIB.

This seems to be wrong. BFD is working in terms of detecting a loss of connectivity to the remote client:

 show bfd session
Neighbor       Interface      Clients  Detection  Status       VR 
=====================================================================
10.254.101.2   MetroA         ----s      3000     Down         VR-Default     
=====================================================================
Clients Flag: m - MPLS, o - OSPF, s - Static

but the expected route withdrawal does not occur.
Photo of Ed McGuigan

Ed McGuigan

  • 500 Points 500 badge 2x thumb
  • frustrated

Posted 4 years ago

  • 0
  • 1
Photo of PARTHIBAN CHINNAYA

PARTHIBAN CHINNAYA, Alum

  • 4,382 Points 4k badge 2x thumb
What's the exos version ?
I have seen this issue many times
Photo of Ed McGuigan

Ed McGuigan

  • 500 Points 500 badge 2x thumb
Thanks for replying.

===

15.5.3.4 v1553b4-patch1-5

and I downgraded to:

15.4.1.3 v1541b3-patch1-13

===

Do you know a version the feature works on Parthiban? Would like to satisfy myself that I am configuring it correctly and that the features does work on some version or other.

I know the dropped BFD session is seen but it just won't do what it should.
Photo of PARTHIBAN CHINNAYA

PARTHIBAN CHINNAYA, Alum

  • 4,382 Points 4k badge 2x thumb
15.3.14latest patch used to be the best.
But i dont think there should be any problem with 15.4.1.3patch1-13

https://community.extremenetworks.com/extreme/topics/remote-site-dual-link-using-ip-route-sharing
The above link can help you confirm BFD works for many other customers.
Photo of Ed McGuigan

Ed McGuigan

  • 500 Points 500 badge 2x thumb
I ended up down at "version 15.3.1.4 v1531b4-patch1-40" and got it working.

It concerns me that features just stop working as you move to more recent versions.

I did change the way I generate the BFD outage ( actually cable through an intermediate switch and removed VLAN membership from a port on that switch ), so I am going to go back to my latest version and test again just to be sure it is not working.

Thanks again Parthiban.
Photo of Ed McGuigan

Ed McGuigan

  • 500 Points 500 badge 2x thumb
Well it turns out I made a mistake at the outset. My method of triggering the BFD outage on my hub router was to do "disable bfd vlan MetroA" on the spoke router.

I assumed that the BFD client would go down on the spoke router and that the hub router would just assume that it lost contact.

When I made the outage more realistic by connecting the routers through an intermediate switch and just cutting off the vlan on one of the switch ports, BFD behaved as I expected and withdrew the route.

I haven't done a packet capture but I am guessing that when you disable the BFD client ona vlan and there is an active session, the local BFD client signals the remote to say "Hey they are turning me off over here so you better just assume that BFD isn't working and just don't mess with your routing table."

So the "b" flag means - I have requested BFD protection but I don't think the other end is cooperating, whereas the "p" flag means I have talked to the other end and we have agreed to be in BFD protection mode so I will withdraw the route if I lose contact.