← Back to team overview

netplan-developers team mailing list archive

  1. netplan-developers team
  2. Mailing list archive
  3. Message #00105

Re: gretap support for Open vSwitch

  Thread Previous • Date Previous • • Thread Next 
Hi Brian!

Yes, I saw that. Thank you very much!
I was busy testing and deploying the netplan 0.104 release (amongst other stuff).
Actually, I like keeping the discussion on Github, close to the suggested changes/PR, so everybody else can jump in and we keep it as a future reference.
I've addressed all of your questions at https://github.com/canonical/netplan/pull/261 

Cheers,
  Lukas

Am 17.02.22 um 13:24 schrieb Brian Turek:

Hi Lukas,

I submitted a WIP PR a few days ago
(https://github.com/canonical/netplan/pull/261) that has working
GRETAP support for OVS. I'm not quite sure the best communication
medium so I'll copy my questions included in the PR below:

- OVS calls GRE tunnels between two bridges just gre tunnels. However,
in the semantics of netplan, it is actually a gretap tunnel (i.e. it's
putting layer 2 packets through a GRE tunnel). I went with calling
these gretap/ip6gretap tunnels as I feel it's technically correct but
I also think this is going to cause confusion. Thoughts?
- For all tunnel types, the local_ip is a required YAML key but it's
really optional for most tunnels. Is it OK to remove the required
check on it? I'm happy to tweak the affected tests.
- I opted for OVS-flavored bridges to make any attached
gretap/ip6gretap tunnels inherit being OVS controlled. I don't have a
firm understanding on the order in which interfaces are parsed so am
unsure if this method works every time or is dependent on interface
order.
   - This raises a secondary question about OVS bonds: if a bond
detects one of its members being OVS, it then switches its back-end to
OVS. However, I didn't see any code to make a bridge containing a now
OVS bond to then become OVS.

- Brian

On Wed, Feb 9, 2022 at 10:54 AM Lukas Märdian
<lukas.maerdian@xxxxxxxxxxxxx> wrote:


Hey Brian!

Am 09.02.22 um 13:22 schrieb Brian Turek:

I'm leaning towards just using the interfaces stanza after spending a
bit more time looking at the code. I initially made the incorrect
assumption based off the VLAN definition that ports needed to know
their parent bridge. However, it looks like OVS bonds handle the
bridge<->port mapping without explicitly knowing their parent bridge
and OVS bonds also already have the logic to error out if a bridge
doesn't claim them as a member. I think I can use bonds as a good
reference.


Sure, that's certainly a viable option. Using existing schema
definitions is always a nice way to handle new features, we just need to
make sure to update the documentation/reference (netplan.md) to describe
the new cases.


In terms of schema change, I believe the only things that would need
to change is allowing for tunnels (some tunnels?) to have a
openvswitch key and, if they are OVS-flavored, to make "local" (the
local tunnel IP) not required. I have never specified local_ip while
making a OVS GRE tunnel so it might even have to be explicitly absent.


It shouldn't be a problem to extend the existing "openvswitch": {...}
stanza to tunnels. To check for the tunnel type and local IP conditions
you can make use of the validation.c module.


This one will take me a bit as my C is rusty. Do you prefer WIP PRs or
just a PR once it's viable?


Cool, I'm looking forward to your PR! We usually submit "Draft" PRs on
Github as soon as we have something presentable, then once it's done
switch it over to the "Ready for review" state. In the meantime, feel
free to ping people on this mailing list or on IRC in #netplan on
libera.chat.

Cheers,
    Lukas

Attachment: OpenPGP_signature
Description: OpenPGP digital signature

References

  Thread Previous • Date Previous • • Thread Next