topic RE: Iproute sharing enabled, static routes with BFD is in FIB even if BFD peer is not yet seen in ExtremeSwitching (EXOS/Switch Engine)

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

Harri_Jaakkola — Wed, 11 Nov 2015 20:45:00 GMT

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

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

StephenW — Wed, 11 Nov 2015 21:31:00 GMT

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

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

StephenW — Thu, 12 Nov 2015 03:53:00 GMT

Harri,

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

Thanks,

Stephen

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

Harri_Jaakkola — Thu, 12 Nov 2015 14:35:00 GMT

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

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

StephenW — Thu, 12 Nov 2015 14:35:00 GMT

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

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

Harri_Jaakkola — Thu, 12 Nov 2015 21:42:00 GMT

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

/Harri

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

StephenW — Thu, 12 Nov 2015 22:22:00 GMT

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...

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

OscarK — Mon, 16 Nov 2015 15:45:00 GMT

The seen behavior is the designed behavior. This is confirmed by engineering.

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

Harri_Jaakkola — Mon, 16 Nov 2015 16:21:00 GMT

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