cancel
Showing results forĀ 
Search instead forĀ 
Did you mean:Ā 

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

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

Harri_Jaakkola
New Contributor
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
8 REPLIES 8

Harri_Jaakkola
New Contributor
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

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

StephenW
Extreme Employee
Harri,

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

Thanks,

Stephen

StephenW
Extreme Employee
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
GTM-P2G8KFN