Refactor initial tunnel implementation#3576
Conversation
* Move utils/tunnel.py to extra/tunnel/__init__.py * Return interface list from 'select source interface' function, making if useful in environments with additional requirements * Make tunnel.af check optional to support dual-stack-capable tunnels * Move most of GRE processing to _p2p.py utility function, assuming it can be used (or adapted) to other tunnel implementations. Also: * Move all link-related utility functions to augment/links and move them to the top of that module
|
@jbemmel -- Looking at your wireguard code, there was a lot of duplication with the GRE code, so I refactored the whole thing and created a bunch of (hopefully useful) _p2p functions. Also, the "select source interface" now returns a list of viable interfaces (and ignores AF if it's not set) which you can then use to do smarter interface selection. |
| if 'name' in intf and '->' in intf.name and 'GRE' not in intf.name: | ||
| intf.name += ' [GRE tunnel]' | ||
| node_iflist = _p2p.feature_check(topology,t_mode='gre',t_desc='GRE tunnels') | ||
| _p2p.tunnel_source(topology,node_iflist,default_af='ipv4',t_name='GRE') |
There was a problem hiding this comment.
The current code requires the user to explicitly specify tunnel.af: ipv6 in an IPv6-only setup. I would suggest we infer tunnel.af from the available address families on the selected interface, preferring ipv4 if both are available. This behavior should be consistent across tunnel plugins
There was a problem hiding this comment.
You know that uneasy feeling I had when looking at #3541?
I get a similar feeling considering auto-AF for GRE tunnels. I can't tell you what could break, but I'll stay with the current "ipv4 is the default" behavior.
There was a problem hiding this comment.
I get a similar feeling considering auto-AF for GRE tunnels. I can't tell you what could break, but I'll stay with the current "ipv4 is the default" behavior.
I have no problem with that, just thinking that we might want to do that like this?
attributes:
link:
tunnel:
af: # Transport address family
{ type: str, valid_values: [ ipv4, ipv6 ], _default: ipv4 }
rather than bury it inside Python logic?
There was a problem hiding this comment.
And what would happen when someone uses tunnel.gre and tunnel.wireguard in the same topology?
There was a problem hiding this comment.
Nothing, this section would be under GRE not affecting Wireguard
There was a problem hiding this comment.
Are you absolutely sure about that? Want to try it out first?
* Move utils/tunnel.py to extra/tunnel/__init__.py * Return interface list from 'select source interface' function, making if useful in environments with additional requirements * Make tunnel.af check optional to support dual-stack-capable tunnels * Move most of GRE processing to _p2p.py utility function, assuming it can be used (or adapted) to other tunnel implementations. Also: * Move all link-related utility functions to augment/links and move them to the top of that module
Also: