public inbox for pve-devel@lists.proxmox.com
 help / color / mirror / Atom feed
From: "DERUMIER, Alexandre via pve-devel" <pve-devel@lists.proxmox.com>
To: "andrew@apalrd.net" <andrew@apalrd.net>
Cc: "DERUMIER, Alexandre" <alexandre.derumier@groupe-cyllene.com>,
	"pve-devel@lists.proxmox.com" <pve-devel@lists.proxmox.com>
Subject: Re: [pve-devel] [PATCH ifupdown2 1/1] Correctly handle IPv6 addresses in vxlan
Date: Wed, 9 Oct 2024 21:05:39 +0000	[thread overview]
Message-ID: <mailman.252.1728507950.332.pve-devel@lists.proxmox.com> (raw)
In-Reply-To: <17214981-4406-4100-AFF6-9F70E12E421B@apalrd.net>

[-- Attachment #1: Type: message/rfc822, Size: 26084 bytes --]

From: "DERUMIER, Alexandre" <alexandre.derumier@groupe-cyllene.com>
To: "andrew@apalrd.net" <andrew@apalrd.net>
Cc: "pve-devel@lists.proxmox.com" <pve-devel@lists.proxmox.com>
Subject: Re: [PATCH ifupdown2 1/1] Correctly handle IPv6 addresses in vxlan
Date: Wed, 9 Oct 2024 21:05:39 +0000
Message-ID: <99349e23b9a957cdf81d5bf2fa8c6af9f6b24ad0.camel@groupe-cyllene.com>

Personnally, I'm ok with your patch

>>Ultimately I disagreed with the solution to use a separate parameter
>>for IPv6, for the following reasons:
>>- We can only have one local tunnel IP, so having two parameters
>>means we need to check if the other one has been set (since setting
>>both would be invalid)
>>- There are already other cases in ifupdown2 which do ip.version == 6
>>including common parameters like address and gateway, and most
>>parameters do take both IPv4 and IPv6 addresses (such as the remoteip
>>field in vxlan), so having one parameter for both families would be
>>consistent with other parameters in the interfaces file which take
>>both families (regardless of the kernel implementation having two
>>fields instead of one in this case)
>>- ifupdown-ng already solved this problem using a single parameter
>>instead of two, so doing something else would diverge ifupdown2 vs
>>ifupdown-ng syntax which should be the same


but we need to be able to not diverge too much from upstream,
if one day (ok that's waiting since 4 years...) an official
support is added by cumulus/nvidia.
(to be honest, the upstream is a lot less active since nvidia have buy
cumulus/mellanox)

That's mean maintain both syntax, or plan a config update,
between 2 majors pve releases. Not a big deal.


but yes, we already use "address ..." for example, for both ipv6/ipv4.
and here, as you said, we can have only ipv4 or ipv6 for local tunnel.


>>I could add additional error checking to ensure that remoteip[] and
>>localip are the same address family if you’d like. Currently that
>>results in a Netlink exception which gets passed back as an error
>>message. The kernel only allows one address family for a vxlan
>>interface.

yes, it could be great to test it.



BTW, I don't have followed the ifupdown-ng project since a long time.
(just follow the early days). Is the project really active and have
almost same features than ifupdown2 ?  (netlink support, reload support
with diff of running config,...)

-------- Message initial --------
De: Andrew <andrew@apalrd.net>
À: "DERUMIER, Alexandre" <alexandre.derumier@groupe-cyllene.com>
Cc: pve-devel@lists.proxmox.com <pve-devel@lists.proxmox.com>
Objet: Re: [PATCH ifupdown2 1/1] Correctly handle IPv6 addresses in
vxlan
Date: 09/10/2024 18:55:50

Yes, I read all of the PRs and discussion on ifupdown2 GitHub before
implementing this.

Ultimately I disagreed with the solution to use a separate parameter
for IPv6, for the following reasons:
- We can only have one local tunnel IP, so having two parameters means
we need to check if the other one has been set (since setting both
would be invalid)
- There are already other cases in ifupdown2 which do ip.version == 6
including common parameters like address and gateway, and most
parameters do take both IPv4 and IPv6 addresses (such as the remoteip
field in vxlan), so having one parameter for both families would be
consistent with other parameters in the interfaces file which take both
families (regardless of the kernel implementation having two fields
instead of one in this case)
- ifupdown-ng already solved this problem using a single parameter
instead of two, so doing something else would diverge ifupdown2 vs
ifupdown-ng syntax which should be the same

I could add additional error checking to ensure that remoteip[] and
localip are the same address family if you’d like. Currently that
results in a Netlink exception which gets passed back as an error
message. The kernel only allows one address family for a vxlan
interface.

Thanks,

Andrew

> On Oct 9, 2024, at 11:37, DERUMIER, Alexandre
> <alexandre.derumier@groupe-cyllene.com> wrote:
> 
> Try to look at ifupdown2 github, their are 2 old pull request about
> this (never merged/ never completed)
> 
> 
> 
> https://github.com/CumulusNetworks/ifupdown2/pull/172
> 
> "
> For this we would need a new attribute vxlan-local-tunnelip6, we
> don't
> want to reuse the same attribute for ipv6.
> We are using netlink to configure vxlans, so it's important to use a
> different attribute to set the proper netlink attribute (I don't want
> to have things like if IPAddress(value).version == 6:  set
> Link.IFLA_VXLAN_LOCAL
> "
> 
> https://github.com/CumulusNetworks/ifupdown2/pull/182
> 
> 
> so, at minimum, this need to use a different "vxlan-local-tunnelip6"
> attribute for ipv6
> 
> 
> -------- Message initial --------
> De: apalrd <andrew@apalrd.net>
> À: pve-devel@lists.proxmox.com
> Cc: apalrd <andrew@apalrd.net>
> Objet: [PATCH ifupdown2 1/1] Correctly handle IPv6 addresses in vxlan
> Date: 08/10/2024 06:01:09
> 
> ---
>  ifupdown2/addons/vxlan.py | 26 ++++++++++++++++----------
>  1 file changed, 16 insertions(+), 10 deletions(-)
> 
> diff --git a/ifupdown2/addons/vxlan.py b/ifupdown2/addons/vxlan.py
> index 084aec9..4aa8e50 100644
> --- a/ifupdown2/addons/vxlan.py
> +++ b/ifupdown2/addons/vxlan.py
> @@ -51,7 +51,7 @@ class vxlan(Vxlan, moduleBase):
>              },
>              "vxlan-local-tunnelip": {
>                  "help": "vxlan local tunnel ip",
> -                "validvals": ["<ipv4>"],
> +                "validvals": ["<ipv4>,<ipv6>"],
>                  "example": ["vxlan-local-tunnelip 172.16.20.103"]
>              },
>              "vxlan-svcnodeip": {
> @@ -66,7 +66,7 @@ class vxlan(Vxlan, moduleBase):
>              },
>              "vxlan-remoteip": {
>                  "help": "vxlan remote ip",
> -                "validvals": ["<ipv4>"],
> +                "validvals": ["<ipv4>,<ipv6>"],
>                  "example": ["vxlan-remoteip 172.16.22.127"],
>                  "multiline": True
>              },
> @@ -521,7 +521,7 @@ class vxlan(Vxlan, moduleBase):
>              local = self._vxlan_local_tunnelip
>  
>          if link_exists:
> -            cached_ifla_vxlan_local =
> cached_vxlan_ifla_info_data.get(Link.IFLA_VXLAN_LOCAL)
> +            cached_ifla_vxlan_local =
> cached_vxlan_ifla_info_data.get(Link.IFLA_VXLAN_LOCAL) or
> cached_vxlan_ifla_info_data.get(Link.IFLA_VXLAN_LOCAL6)
>  
>              # on ifreload do not overwrite anycast_ip to individual
> ip
>              # if clagd has modified
> @@ -547,7 +547,7 @@ class vxlan(Vxlan, moduleBase):
>  
>          if local:
>              try:
> -                local = ipnetwork.IPv4Address(local)
> +                local = ipnetwork.IPAddress(local)
>  
>                  if local.initialized_with_prefixlen:
>                      self.logger.warning("%s: vxlan-local-tunnelip
> %s:
> netmask ignored" % (ifname, local))
> @@ -559,13 +559,19 @@ class vxlan(Vxlan, moduleBase):
>          if local:
>              if local != cached_ifla_vxlan_local:
>                  self.logger.info("%s: set vxlan-local-tunnelip %s" %
> (ifname, local))
> -                user_request_vxlan_info_data[Link.IFLA_VXLAN_LOCAL]
> =
> local
> +                if local.version == 6:
> +                   
> user_request_vxlan_info_data[Link.IFLA_VXLAN_LOCAL6] = local
> +                else:
> +                   
> user_request_vxlan_info_data[Link.IFLA_VXLAN_LOCAL] = local
>  
>                  # if both local-ip and anycast-ip are identical the
> function prints a warning
>                  self.syntax_check_localip_anycastip_equal(ifname,
> local, self._clagd_vxlan_anycast_ip)
>          elif cached_ifla_vxlan_local:
>              self.logger.info("%s: removing vxlan-local-tunnelip
> (cache
> %s)" % (ifname, cached_ifla_vxlan_local))
> -            user_request_vxlan_info_data[Link.IFLA_VXLAN_LOCAL] =
> None
> +            if cached_ifla_vxlan_local.version == 6:
> +                user_request_vxlan_info_data[Link.IFLA_VXLAN_LOCAL6]
> =
> None
> +            else:
> +                user_request_vxlan_info_data[Link.IFLA_VXLAN_LOCAL]
> =
> None
>  
>          return local
>  
> @@ -1236,7 +1242,7 @@ class vxlan(Vxlan, moduleBase):
>          if remoteips:
>              try:
>                  for remoteip in remoteips:
> -                    ipnetwork.IPv4Address(remoteip)
> +                    ipnetwork.IPAddress(remoteip)
>              except Exception as e:
>                  self.log_error('%s: vxlan-remoteip: %s' %
> (ifaceobj.name, str(e)))
>  
> @@ -1244,7 +1250,7 @@ class vxlan(Vxlan, moduleBase):
>          # purge any removed remote ip
>          old_remoteips = self.get_old_remote_ips(ifaceobj.name)
>  
> -        if vxlan_purge_remotes or remoteips or (remoteips !=
> old_remoteips):
> +        if vxlan_purge_remotes or (isinstance(remoteips,list) and
> remoteips != old_remoteips):
>              # figure out the diff for remotes and do the bridge fdb
> updates
>              # only if provisioned by user and not by an vxlan
> external
>              # controller.
> @@ -1281,8 +1287,8 @@ class vxlan(Vxlan, moduleBase):
>                          "00:00:00:00:00:00",
>                          None, True, addr
>                      )
> -                except Exception:
> -                    pass
> +                except Exception as e:
> +                    self.log_error('%s: vxlan-remoteip<add>: %s' %
> (ifaceobj.name, str(e)))
>  
>          self.vxlan_remote_ip_map(ifaceobj, vxlan_mcast_grp_map)
>  
> 




[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel

      parent reply	other threads:[~2024-10-09 21:05 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20241008040109.322473-1-andrew@apalrd.net>
2024-10-08  4:01 ` apalrd via pve-devel
     [not found] ` <20241008040109.322473-2-andrew@apalrd.net>
2024-10-09 15:37   ` DERUMIER, Alexandre via pve-devel
     [not found]   ` <9045eca45de7aa50fd817fb9221cfa04c524ff19.camel@groupe-cyllene.com>
2024-10-09 16:55     ` Andrew via pve-devel
     [not found]     ` <17214981-4406-4100-AFF6-9F70E12E421B@apalrd.net>
2024-10-09 21:05       ` DERUMIER, Alexandre via pve-devel [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=mailman.252.1728507950.332.pve-devel@lists.proxmox.com \
    --to=pve-devel@lists.proxmox.com \
    --cc=alexandre.derumier@groupe-cyllene.com \
    --cc=andrew@apalrd.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Service provided by Proxmox Server Solutions GmbH | Privacy | Legal