* [pve-devel] [PATCH ifupdown2 1/1] Correctly handle IPv6 addresses in vxlan
[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>
1 sibling, 0 replies; 6+ messages in thread
From: apalrd via pve-devel @ 2024-10-08 4:01 UTC (permalink / raw)
To: pve-devel; +Cc: apalrd
[-- Attachment #1: Type: message/rfc822, Size: 7238 bytes --]
From: apalrd <andrew@apalrd.net>
To: pve-devel@lists.proxmox.com
Cc: apalrd <andrew@apalrd.net>
Subject: [PATCH ifupdown2 1/1] Correctly handle IPv6 addresses in vxlan
Date: Tue, 8 Oct 2024 00:01:09 -0400
Message-ID: <20241008040109.322473-2-andrew@apalrd.net>
---
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)
--
2.39.5
[-- 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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [pve-devel] [PATCH ifupdown2 1/1] Correctly handle IPv6 addresses in vxlan
[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>
1 sibling, 0 replies; 6+ messages in thread
From: DERUMIER, Alexandre via pve-devel @ 2024-10-09 15:37 UTC (permalink / raw)
To: andrew; +Cc: DERUMIER, Alexandre, pve-devel
[-- Attachment #1: Type: message/rfc822, Size: 19952 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 15:37:55 +0000
Message-ID: <9045eca45de7aa50fd817fb9221cfa04c524ff19.camel@groupe-cyllene.com>
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [pve-devel] [PATCH ifupdown2 1/1] Correctly handle IPv6 addresses in vxlan
[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>
1 sibling, 0 replies; 6+ messages in thread
From: Andrew via pve-devel @ 2024-10-09 16:55 UTC (permalink / raw)
To: DERUMIER, Alexandre; +Cc: Andrew, pve-devel
[-- Attachment #1: Type: message/rfc822, Size: 11178 bytes --]
From: Andrew <andrew@apalrd.net>
To: "DERUMIER, Alexandre" <alexandre.derumier@groupe-cyllene.com>
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, 09 Oct 2024 16:55:50 +0000
Message-ID: <17214981-4406-4100-AFF6-9F70E12E421B@apalrd.net>
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [pve-devel] [PATCH ifupdown2 1/1] Correctly handle IPv6 addresses in vxlan
[not found] ` <17214981-4406-4100-AFF6-9F70E12E421B@apalrd.net>
@ 2024-10-09 21:05 ` DERUMIER, Alexandre via pve-devel
[not found] ` <99349e23b9a957cdf81d5bf2fa8c6af9f6b24ad0.camel@groupe-cyllene.com>
1 sibling, 0 replies; 6+ messages in thread
From: DERUMIER, Alexandre via pve-devel @ 2024-10-09 21:05 UTC (permalink / raw)
To: andrew; +Cc: DERUMIER, Alexandre, pve-devel
[-- 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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [pve-devel] [PATCH ifupdown2 1/1] Correctly handle IPv6 addresses in vxlan
[not found] ` <99349e23b9a957cdf81d5bf2fa8c6af9f6b24ad0.camel@groupe-cyllene.com>
@ 2024-11-25 10:25 ` Stefan Hanreich
2024-11-25 15:09 ` Andrew via pve-devel
0 siblings, 1 reply; 6+ messages in thread
From: Stefan Hanreich @ 2024-11-25 10:25 UTC (permalink / raw)
To: DERUMIER, Alexandre, andrew; +Cc: pve-devel
On 10/9/24 23:05, DERUMIER, Alexandre wrote:
> 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.
yes, it seems a bit tricky, since we'd have to predict what ifupdown2 is
doing - but with the current speed of ifupdown2 development, I'm not
sure if VXLAN IPv6 support will land anytime soon. There's a similar PR
open though in the ifupdown2 github [1].
Since there is currently discussion about moving away from ifupdown2 on
debian-devel [2] [3] and the point of contention is not really about IF
they will be moving away from ifupdown2 but rather WHAT the replacement
will be, we could support our implementation (with possible
compatibility patches) while we move to a new network stack.
> 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,...)
Judging from the current discussion on debian-devel, ifupdown-ng doesn't
seem to be a candidate for the Debian network stack moving forward.
There's some heated discussion between netplan and systemd-networkd,
with some (from my perception) preference for systemd-networkd so we'll
be monitoring that closely for our trixie release.
I'll test this series a bit this week and report back. Would you be
interested in sending a v2 afterwards? (particularly wrt to the perl
style issues). Otherwise I can also take this patch series over. in any
case, have you signed a CLA with us already? Otherwise we cannot include
your patches in our repositories.
[1] https://github.com/CumulusNetworks/ifupdown2/pull/315
[2] https://lists.debian.org/debian-devel/2024/07/msg00098.html
[3] https://lists.debian.org/debian-devel/2024/09/msg00240.html
_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [pve-devel] [PATCH ifupdown2 1/1] Correctly handle IPv6 addresses in vxlan
2024-11-25 10:25 ` Stefan Hanreich
@ 2024-11-25 15:09 ` Andrew via pve-devel
0 siblings, 0 replies; 6+ messages in thread
From: Andrew via pve-devel @ 2024-11-25 15:09 UTC (permalink / raw)
To: Stefan Hanreich; +Cc: Andrew, pve-devel
[-- Attachment #1: Type: message/rfc822, Size: 6089 bytes --]
From: Andrew <andrew@apalrd.net>
To: Stefan Hanreich <s.hanreich@proxmox.com>
Cc: "DERUMIER, Alexandre" <alexandre.derumier@groupe-cyllene.com>, "pve-devel@lists.proxmox.com" <pve-devel@lists.proxmox.com>
Subject: Re: [PATCH ifupdown2 1/1] Correctly handle IPv6 addresses in vxlan
Date: Mon, 25 Nov 2024 15:09:48 +0000
Message-ID: <2DB93EBD-8A9D-4CB9-8992-9A9C85742505@apalrd.net>
Hello,
Yes, I’ve signed the CLA.
You’re welcome to take it over to fix the style issues.
At least for Trixie it seems like PVE staying on ifupdown2 would make sense, given how tightly integrated it’s syntax is with SDN.
Andrew
> On Nov 25, 2024, at 05:25, Stefan Hanreich <s.hanreich@proxmox.com> wrote:
>
>
> On 10/9/24 23:05, DERUMIER, Alexandre wrote:
>> 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.
>
> yes, it seems a bit tricky, since we'd have to predict what ifupdown2 is
> doing - but with the current speed of ifupdown2 development, I'm not
> sure if VXLAN IPv6 support will land anytime soon. There's a similar PR
> open though in the ifupdown2 github [1].
>
> Since there is currently discussion about moving away from ifupdown2 on
> debian-devel [2] [3] and the point of contention is not really about IF
> they will be moving away from ifupdown2 but rather WHAT the replacement
> will be, we could support our implementation (with possible
> compatibility patches) while we move to a new network stack.
>
>> 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,...)
>
> Judging from the current discussion on debian-devel, ifupdown-ng doesn't
> seem to be a candidate for the Debian network stack moving forward.
> There's some heated discussion between netplan and systemd-networkd,
> with some (from my perception) preference for systemd-networkd so we'll
> be monitoring that closely for our trixie release.
>
>
> I'll test this series a bit this week and report back. Would you be
> interested in sending a v2 afterwards? (particularly wrt to the perl
> style issues). Otherwise I can also take this patch series over. in any
> case, have you signed a CLA with us already? Otherwise we cannot include
> your patches in our repositories.
>
> [1] https://github.com/CumulusNetworks/ifupdown2/pull/315
> [2] https://lists.debian.org/debian-devel/2024/07/msg00098.html
> [3] https://lists.debian.org/debian-devel/2024/09/msg00240.html
>
[-- 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
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2024-11-26 10:36 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <20241008040109.322473-1-andrew@apalrd.net>
2024-10-08 4:01 ` [pve-devel] [PATCH ifupdown2 1/1] Correctly handle IPv6 addresses in vxlan 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
[not found] ` <99349e23b9a957cdf81d5bf2fa8c6af9f6b24ad0.camel@groupe-cyllene.com>
2024-11-25 10:25 ` Stefan Hanreich
2024-11-25 15:09 ` Andrew via pve-devel
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox