topic RE: BFD Not Working For Withdrawal of Static Route in ExtremeSwitching (EXOS/Switch Engine)

BFD Not Working For Withdrawal of Static Route

Ed_McGuigan1 — Thu, 26 Feb 2015 22:16:00 GMT

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.

RE: BFD Not Working For Withdrawal of Static Route

PARTHIBAN_CHINN — Thu, 26 Feb 2015 22:59:00 GMT

What's the exos version ? I have seen this issue many times

RE: BFD Not Working For Withdrawal of Static Route

Ed_McGuigan1 — Fri, 27 Feb 2015 01:08:00 GMT

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.

RE: BFD Not Working For Withdrawal of Static Route

PARTHIBAN_CHINN — Fri, 27 Feb 2015 09:24:00 GMT

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.

RE: BFD Not Working For Withdrawal of Static Route

Ed_McGuigan1 — Fri, 27 Feb 2015 21:36:00 GMT

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.

RE: BFD Not Working For Withdrawal of Static Route

Ed_McGuigan1 — Sat, 28 Feb 2015 03:19:00 GMT

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.