Page MenuHomeVyOS Platform

VRF IPv6 static routes subnet deletion
Closed, WontfixPublicBUG

Description

Hi,

a minor thing I've also found in the vrf static route code for ipv6, related to how ip6 addresses shortening works...

When I add a route with
set protocols vrf ivrf static route6 fe::0/64 next-hop fe:fe::1 interface eth0

it gets added into frr as:

vrf ivrf
 ipv6 route fe::/64 fe:fe::1 eth0
 exit-vrf

but when trying to delete the route with:
delete protocols vrf ivrf static route6 fe::0/64

it errors:

 delete protocols vrf ivrf static route6 fe::0/64
[edit]
vyos@vyos# commit
[ protocols vrf ivrf static route6 fe::0/64 next-hop fe:fe::1 ]
% Command incomplete: no

delete [ protocols vrf ivrf static route6 fe::0/64 ] failed
Commit failed
[edit]

most probably due to the way the deletion code works - looks very similar to https://phabricator.vyos.net/T2338, where issue was capital letters in the ipv6 address.

Worth noting is something that may be useful during developing a fix is that for the vyos cli fe:b::0/64 and fe:b::/64 are different routes, so potentially the logic should be in the subnet format validation, not in this node?

set protocols vrf ivrf static route6 fe:b::0/64  next-hop fe:fe::1 interface eth0
set protocols vrf ivrf static route6 fe:b::/64  next-hop fe:fe::1 interface eth0

gives the below output:

vyos@vyos# compare
[edit protocols vrf ivrf static]
+route6 fe:b::0/64 {
+    next-hop fe:fe::1 {
+        interface eth0
+    }
+}
+route6 fe:b::/64 {
+    next-hop fe:fe::1 {
+        interface eth0
+    }
+}

Details

Difficulty level
Unknown (require assessment)
Version
1.3-rolling-202005072035
Why the issue appeared?
Will be filled on close
Is it a breaking change?
Unspecified (possibly destroys the router)
Issue type
Bug (incorrect behavior)

Event Timeline

Okay the problem here is that FRR stores the network as fe::/64 and not as fe::0/64 which was specified on the VyOS commandline. Thus the grep command used when deleting the route does not find the proper FRR entry and gives that error.

A workaround would be to use set protocols vrf ivrf static route6 fe::/64 next-hop fe:fe::1 interface eth0 instead. This can and will be fixed when the CLI is migrated to the new XML python based approach. Maybe this will come rather sooner then later for VRFs.

I'm closing this as "wontfix" as it wil be resolved entirely by the rewrite. But will aattach it to the VRF CLI XML rewrite.

Thank you for the good explanation in the issue!

erkin set Issue type to Bug (incorrect behavior).Aug 30 2021, 6:15 AM
erkin removed a subscriber: Active contributors.