Iproute sharing enabled, static routes with BFD is in FIB even if BFD peer is not yet seen

  • 0
  • 1
  • Problem
  • Updated 3 years ago
  • Solved
Hi,
We have a situation where we have identified an interesting issue.

We are using Summit X670s (tested both G1 and G2) and want to use static routing with BFD protection, and we also enable iproute sharing to 4 different destinations. However, when preparing this setup, initially we have only two destinations configured from start. The other two destinations are not up yet, but anyway we see an output from "show iproute" like below:

* (vr VR70c07e9d-5261-4028-a90c-36df) SWA_X670V.7 # show iproute
Ori  Destination        Gateway         Mtr  Flags         VLAN       Duration
#s   Default Route      172.17.21.137   1    UG---S-um--f- tenant_3796 0d:20h:51m:11s
#s   10.35.57.101/32    192.168.216.4   1    UG---Sbum--f- tenant_3005 0d:20h:51m:11s
#s   10.35.57.101/32    192.168.216.6   1    UG---Sbum--f- tenant_3005 0d:20h:51m:11s
#s   10.35.57.101/32    192.168.216.8   1    UG---Spum--f- tenant_3005 0d:20h:51m:11s
#s   10.35.57.101/32    192.168.216.10  1    UG---Spum--f- tenant_3005 0d:20h:51m:11s
       (mo) MOSPF (o) OSPF, (o1) OSPFExt1, (o2) OSPFExt2,
       (oa) OSPFIntra, (oe) OSPFAsExt, (or) OSPFInter, (pd) PIM-DM, (ps) PIM-SM,
       (r) RIP, (ra) RtAdvrt, (s) Static, (sv) SLB_VIP, (un) UnKnown,
       (*) Preferred unicast route (@) Preferred multicast route,
       (#) Preferred unicast and multicast route.
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.
BFD session status:
* (vr VR70c07e9d-5261-4028-a90c-36df) SWA_X670V.8 # show bfd session
Neighbor       Interface      Clients  Detection  Status       VR
=============================================================================
192.168.216.4  tenant_3005    ----s      0        Down         VR70c07e9d-5261-4028-a90c-36df
192.168.216.6  tenant_3005    ----s      0        Down         VR70c07e9d-5261-4028-a90c-36df
192.168.216.8  tenant_3005    ----s      900      Up           VR70c07e9d-5261-4028-a90c-36df
192.168.216.10 tenant_3005    ----s      900      Up           VR70c07e9d-5261-4028-a90c-36df
=============================================================================
Clients Flag: m - MPLS, o - OSPF, s - Static
NOTE: All timers in milliseconds.

The issue is that the f flag seems to be set for all destinations, even if the BFD protection is requested but not yet active, ie the other peer end has not been seen yet, This is also seen by flag "b". As we understand it, this is wrong, or? If we bring up the destinations once, then the f flag is following the BFD session status. Down => flag removed, and UP => flag added. And, if we remove iproute sharing, the f-flag remains only for the first route entry.

Max shared gateways has been configured to 32.

The issue was seen with default installed XOS 15.6.1.4, but yesterday we upgraded to latest XOS 16.1.2.14. But issue remains same.

And yes, we have been looking through this forum for similar issues without luck.

BR,
Harri
Photo of Harri Jaakkola

Harri Jaakkola

  • 100 Points 100 badge 2x thumb

Posted 3 years ago

  • 0
  • 1
Photo of Stephen Williams

Stephen Williams, Employee

  • 8,838 Points 5k badge 2x thumb
I was able to replicate the issue you have seen when the BFD sessions have never been up.  If the sessions are up and then go down it does work.


Captures from my test.

switch.114 # show bfd session 
Neighbor Interface Clients Detection Status VR
=============================================================================
1.1.1.1 routeing ----s 3000 Up VR-Default
11.11.11.2 v1 ----s 3000 Up VR-Default
22.22.22.2 v2 ----s 3000 Up VR-Default
=============================================================================

switch.115 # show iproute
Ori Destination Gateway Mtr Flags VLAN Duration
#d 1.1.1.0/24 1.1.1.2 1 U------um--f- routeing 0d:0h:49m:11s
#s 2.2.2.0/24 1.1.1.1 1 UG---Spum--f- routeing 0d:0h:37m:48s
#s 2.2.2.0/24 11.11.11.2 1 UG---Spum--f- v1 0d:0h:7m:22s
#s 2.2.2.0/24 22.22.22.2 1 UG---Spum--f- v2 0d:0h:7m:34s
#d 11.11.11.0/24 11.11.11.1 1 U------um--f- v1 0d:0h:9m:26s
#d 22.22.22.0/24 22.22.22.1 1 U------um--f- v2 0d:0h:8m:20s

* switch.116 # show bfd session
Neighbor Interface Clients Detection Status VR
=============================================================================
1.1.1.1 routeing ----s 3000 Up VR-Default
11.11.11.2 v1 ----s 3000 Up VR-Default
22.22.22.2 v2 ----s 0 Down VR-Default
=============================================================================

switch.117 # show iproute
Ori Destination Gateway Mtr Flags VLAN Duration
#d 1.1.1.0/24 1.1.1.2 1 U------um--f- routeing 0d:0h:49m:33s
#s 2.2.2.0/24 1.1.1.1 1 UG---Spum--f- routeing 0d:0h:38m:10s
#s 2.2.2.0/24 11.11.11.2 1 UG---Spum--f- v1 0d:0h:7m:44s
s 2.2.2.0/24 22.22.22.2 1 -G---Spum---- v2 0d:0h:7m:56s
#d 11.11.11.0/24 11.11.11.1 1 U------um--f- v1 0d:0h:9m:48s
#d 22.22.22.0/24 22.22.22.1 1 U------um--f- v2 0d:0h:8m:42s
(Edited)
Photo of Stephen Williams

Stephen Williams, Employee

  • 8,838 Points 5k badge 2x thumb
Harri,

Where you able to try the solution.  I want to make sure it worked for you.

Thanks,

Stephen
Photo of Harri Jaakkola

Harri Jaakkola

  • 100 Points 100 badge 2x thumb
Yes, as I also wrote initally, if we bring the forwarding destination IPs up once, in order for the BFD session to be established once, then it works. The issue is that we want the forwarding sharing to work correctly even if we don't bring them up once. Why are the destinations put in the forwarding table immediately, when BFD session is not yet up?

BR,
Harri
Photo of Stephen Williams

Stephen Williams, Employee

  • 8,838 Points 5k badge 2x thumb
I understand, the BFD feature was probably only written to remove the route when the BFD session goes from Up to Down.  You can open a case with GTAC and reference this hub post to get a bug/feature-request created for this.

Thanks for letting us know about this behavior.

Stephen
Photo of Harri Jaakkola

Harri Jaakkola

  • 100 Points 100 badge 2x thumb

OK. Thanks for recreating the problem and your ack of bug-candidate.

/Harri

Photo of Stephen Williams

Stephen Williams, Employee

  • 8,838 Points 5k badge 2x thumb
I created an article so others can follow the solution to this thread.

https://gtacknowledge.extremenetworks.com/articles/Q_A/BDF-session-is-down-but-route-is-still-in-the...
Photo of OscarK

OscarK, ESE

  • 7,702 Points 5k badge 2x thumb
The seen behavior is the designed behavior. This is confirmed by engineering.
Photo of Harri Jaakkola

Harri Jaakkola

  • 100 Points 100 badge 2x thumb

Hi Oscar,

Thanks for confirming the problem. Then we believe the design should be questioned, we don’t believe that it should work like this.

If you have requested a BFD protection of the route, then the route should be installed only if BFD is UP. And initially, until the peer have been seen, it is NOT up.

What do you think?

Best regards,
Harri