NDB lost sync in apply() trying to set GRE tunnel configs #878
Comments
|
Got it, thanks! Fixing |
|
The root cause has been found. Preparing the fix. |
svinota
added a commit
that referenced
this issue
Feb 15, 2022
|
The issue is fixed. For NDB it's as simple as ndb
.interfaces["testtun"]
.set("gre_local", "10.10.10.3")
.commit()For IPRoute it's a bit more complicated. The GRE tunnels while setting an endpoint require both endpoints to be specified as well as some other GRE attributes. Thus if you want only to change ip.link('set',
index=31,
kind='gre', # important! required to properly populate IFLA_LINKINFO
gre_local='10.10.10.3', # setup the new local ip
gre_remote='10.10.100.3', # the remote ip must be specified as well
gre_ttl=254) # preserve TTL |
|
I commented a suggestion on your fix! I don't really know the full architecture of pyroute2 so I could be wrong but by looking at your commit I could infer that other tunnels kinds might need the same fix. Give it a look and let me know! |
|
Yep, still testing other tunnel types. |
svinota
added a commit
that referenced
this issue
Feb 15, 2022
tunnels * gre (test) * gretap * ip6gre * ip6gretap * ip6tnl * sit (test) * ipip (test) Bug-Url: #878
|
Added some more supported types. |
svinota
added a commit
that referenced
this issue
Feb 15, 2022
|
Seems like the problem is still not fixed on 0.6.6 Creating a GRE tunnel as before i get this tunnel. I tried to modify it using NDB by doing: Which didn't fail(progress!), however the tunnel value was not updated. As seen bellow. And No exception thrown but the values are not updated. Thanks for the support and let me know if you need any additional info. |
|
Yeah, it's another issue. The down tunnels don't send updates, I ignore that in the code — but forgot to force attributes reading. The interface attributes are changed in the system, but it's NDB that doesn't get updated. Will be fixed within an hour. |
svinota
added a commit
that referenced
this issue
Feb 16, 2022
Issue: down tunnels don't broadcast updates. Previous solution: flush the `changed` set and ignore missing updates. Solution: force interface reading after `set` call. Bug-Url: #878
|
Done. |
|
Awesome thank you! I assume this is not going to make it to version 0.6.6 so I will download the source and try to test again tomorrow. |
|
I tested from source (version '0.6.6.post8'). Editing GRE tunnel configurations seems to be working now! Thank you. |
|
Thanks for the feedback! I'm closing the ticket, but don't hesitate to report any further issues. |
|
If possible, could do a 0.6.7 release including this fix? It will make my life so much easier. |
|
Yep, why not if it helps. |
|
Preparing 0.6.7 to be tagged tonight. |
|
@carloslockward , during tests I've found a critical issue: #883 Tagging 0.6.7 as promised, but 0.6.8 fixing the issue is on the way and will be available this week. |
|
@svinota I've been testing 0.6.7 more thoroughly now and if found an issue when updating gre keys specifically. The incorrect gre flags message repeats multiple times and then the command hangs for about 8 seconds and then ends up in a lost sync in apply. Should I open another issue to track this or should we reopen this one? |
|
I reopened the issue. Thanks for keeping an eye on that! |
|
@carloslockward may I ask you what kind of architecture do you use? Or at least is it BE or LE? |
|
I'm running on arm64(aarch64). Its Little Endian. |
|
@carloslockward if it is possible, could you please run the same on |
|
I was able to narrow it down to "gre_iflags" and "gre_oflags". I originally tried to set the both to 32 and that caused the issue. If I delete and recreate the tunnel and try to change the gre keys it works no problem, but as soon as you set the gre flags to 32 the issue arises. After a bit of reading issue #531 I realize that this is probably not a valid flag. But i am still unclear what the valid flags actually are(0x2000 for keyed gre?). If possible could you give a list of the valid flags? Logs are pretty long so brace yourself. No sensitive info here. Now if you would try to run |
|
related code: // include/uapi/linux/if_tunnel.h
#define TUNNEL_CSUM __cpu_to_be16(0x01)
#define TUNNEL_ROUTING __cpu_to_be16(0x02)
#define TUNNEL_KEY __cpu_to_be16(0x04)
#define TUNNEL_SEQ __cpu_to_be16(0x08)
#define TUNNEL_STRICT __cpu_to_be16(0x10)
#define TUNNEL_REC __cpu_to_be16(0x20)
#define TUNNEL_VERSION __cpu_to_be16(0x40)
#define TUNNEL_NO_KEY __cpu_to_be16(0x80)
#define TUNNEL_DONT_FRAGMENT __cpu_to_be16(0x0100)
#define TUNNEL_OAM __cpu_to_be16(0x0200)
#define TUNNEL_CRIT_OPT __cpu_to_be16(0x0400)
#define TUNNEL_GENEVE_OPT __cpu_to_be16(0x0800)
#define TUNNEL_VXLAN_OPT __cpu_to_be16(0x1000)
#define TUNNEL_NOCACHE __cpu_to_be16(0x2000)
#define TUNNEL_ERSPAN_OPT __cpu_to_be16(0x4000)
#define TUNNEL_GTP_OPT __cpu_to_be16(0x8000)// include/net/gre.h
static inline __be16 gre_tnl_flags_to_gre_flags(__be16 tflags)
{
__be16 flags = 0;
if (tflags & TUNNEL_CSUM)
flags |= GRE_CSUM;
if (tflags & TUNNEL_ROUTING)
flags |= GRE_ROUTING;
if (tflags & TUNNEL_KEY)
flags |= GRE_KEY;
if (tflags & TUNNEL_SEQ)
flags |= GRE_SEQ;
if (tflags & TUNNEL_STRICT)
flags |= GRE_STRICT;
if (tflags & TUNNEL_REC)
flags |= GRE_REC;
if (tflags & TUNNEL_VERSION)
flags |= GRE_VERSION;
return flags;
}Probably we need some key validator, but not sure yet. Moving the ticket to the backlog for the time being. |
|
Thanks! |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I found this issue while trying to change the configuration of an existing GRE(or any other kind) tunnel using pyroute2 version
0.6.5Exception
Steps to reproduce
ip.link("add", ifname="testtun", kind="gre", gre_local="10.10.10.2", gre_remote="10.10.100.3", gre_ttl=254)ndb.interfaces["testtun"].set("gre_local", "10.10.10.3").commit()Notes
I also tried to change the tunnel using these commands but they didn't work(didn't throw an exception but value was not changed):
ip.link("update", index=31, IFLA_GRE_LOCAL="10.10.10.3")ip.link("set", index=31, IFLA_GRE_LOCAL="10.10.10.3")The text was updated successfully, but these errors were encountered: