From: Pablo Neira Ayuso <pablo@netfilter.org> Date: 2018-10-04 06:54:33
Hi,
The following patchset adds a new field to the tunnel metadata template
to restrict the configuration to a given tunnel driver. Currently, a
misconfiguration may result in packets going to the wrong tunnel driver.
Although we have the tunnel option flags, they are not mandatory for
some tunnel drivers, eg. vxlan, which may use it or not; and gre which
does not use them.
This patch updates tc's tunnel action and netfilter's tunnel extension
to use this new field. OVS netlink interface has been left unset, although they
could be updated to use this.
By extending the existing tc action to support the IP_TUNNEL_INFO_BRIDGE
mode, I think it should be possible to expose IP_TUNNEL_TYPE_VLAN too,
although this patchset doesn't address this scenario.
The field is initialized to zero, which maps to IP_TUNNEL_TYPE_UNSPEC to
retain the existing behaviour, so the existing flexibility is still in
place while this new feature is added.
Cc'ing people that git annotate show as dealing with these bits more
recently.
Compile tested only.
Comments welcome, thanks.
Pablo Neira Ayuso (3):
ip_tunnel: add type field to struct ip_tunnel_info
net: act_tunnel_key: support for tunnel type
netfilter: nft_tunnel: support for tunnel type
drivers/net/geneve.c | 3 ++-
drivers/net/vxlan.c | 13 +++++++------
include/net/dst_metadata.h | 1 +
include/net/ip_tunnels.h | 16 ++++++++++++++++
include/uapi/linux/netfilter/nf_tables.h | 10 ++++++++++
include/uapi/linux/tc_act/tc_tunnel_key.h | 10 ++++++++++
net/ipv4/ip_gre.c | 2 ++
net/ipv6/ip6_gre.c | 2 ++
net/netfilter/nft_tunnel.c | 9 ++++++++-
net/openvswitch/flow_netlink.c | 1 +
net/sched/act_tunnel_key.c | 9 +++++++++
11 files changed, 68 insertions(+), 8 deletions(-)
From: Pablo Neira Ayuso <pablo@netfilter.org> Date: 2018-10-04 06:54:32
This new field allows you to restrict the metadata template for a given
tunnel driver. This is convenient in scenarios that combine different
tunneling drivers, to deal with possible misconfigurations given that
the template can be interpreted by any target tunnel driver. Default
value is IP_TUNNEL_TYPE_UNSPEC, to retain the existing behaviour. This
also implicitly exposes what drivers are currently supported in the
IP_TUNNEL_INFO_TX mode.
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
---
drivers/net/geneve.c | 3 ++-
drivers/net/vxlan.c | 13 +++++++------
include/net/dst_metadata.h | 1 +
include/net/ip_tunnels.h | 16 ++++++++++++++++
net/ipv4/ip_gre.c | 2 ++
net/ipv6/ip6_gre.c | 2 ++
net/openvswitch/flow_netlink.c | 1 +
7 files changed, 31 insertions(+), 7 deletions(-)
From: Pablo Neira Ayuso <pablo@netfilter.org> Date: 2018-10-04 06:54:35
This patch allows you to set an explicit tunnel driver type in the
metadata template. In case of misconfiguration, ie. if the packets ends
up in the wrong tunnel device, the packet is dropped.
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
---
include/uapi/linux/tc_act/tc_tunnel_key.h | 10 ++++++++++
net/sched/act_tunnel_key.c | 9 +++++++++
2 files changed, 19 insertions(+)
From: Pablo Neira Ayuso <pablo@netfilter.org> Date: 2018-10-04 06:54:35
This patch allows you to set an explicit tunnel driver type in the
metadata template. In case of misconfiguration, ie. if the packets ends
up in the wrong tunnel device, the packet is dropped.
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
---
include/uapi/linux/netfilter/nf_tables.h | 10 ++++++++++
net/netfilter/nft_tunnel.c | 9 ++++++++-
2 files changed, 18 insertions(+), 1 deletion(-)
From: Daniel Borkmann <daniel@iogearbox.net> Date: 2018-10-04 16:17:59
On 10/04/2018 02:03 AM, Pablo Neira Ayuso wrote:
quoted hunk
This new field allows you to restrict the metadata template for a given
tunnel driver. This is convenient in scenarios that combine different
tunneling drivers, to deal with possible misconfigurations given that
the template can be interpreted by any target tunnel driver. Default
value is IP_TUNNEL_TYPE_UNSPEC, to retain the existing behaviour. This
also implicitly exposes what drivers are currently supported in the
IP_TUNNEL_INFO_TX mode.
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
---
drivers/net/geneve.c | 3 ++-
drivers/net/vxlan.c | 13 +++++++------
include/net/dst_metadata.h | 1 +
include/net/ip_tunnels.h | 16 ++++++++++++++++
net/ipv4/ip_gre.c | 2 ++
net/ipv6/ip6_gre.c | 2 ++
net/openvswitch/flow_netlink.c | 1 +
7 files changed, 31 insertions(+), 7 deletions(-)
@@ -2602,6 +2602,7 @@ static int validate_and_copy_set_tun(const struct nlattr *attr,ovs_tun->tun_dst=tun_dst;tun_info=&tun_dst->u.tun_info;+tun_info->type=IP_TUNNEL_TYPE_UNSPEC;tun_info->mode=IP_TUNNEL_INFO_TX;if(key.tun_proto==AF_INET6)tun_info->mode|=IP_TUNNEL_INFO_IPV6;
If so then this should also be made explicit IP_TUNNEL_TYPE_UNSPEC in BPF code
since all these tunnel types are supported there as well.
Thanks,
Daniel
From: Pablo Neira Ayuso <pablo@netfilter.org> Date: 2018-10-04 18:06:52
On Thu, Oct 04, 2018 at 11:25:33AM +0200, Daniel Borkmann wrote:
On 10/04/2018 02:03 AM, Pablo Neira Ayuso wrote:
quoted
This new field allows you to restrict the metadata template for a given
tunnel driver. This is convenient in scenarios that combine different
tunneling drivers, to deal with possible misconfigurations given that
the template can be interpreted by any target tunnel driver. Default
value is IP_TUNNEL_TYPE_UNSPEC, to retain the existing behaviour. This
also implicitly exposes what drivers are currently supported in the
IP_TUNNEL_INFO_TX mode.
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
---
drivers/net/geneve.c | 3 ++-
drivers/net/vxlan.c | 13 +++++++------
include/net/dst_metadata.h | 1 +
include/net/ip_tunnels.h | 16 ++++++++++++++++
net/ipv4/ip_gre.c | 2 ++
net/ipv6/ip6_gre.c | 2 ++
net/openvswitch/flow_netlink.c | 1 +
7 files changed, 31 insertions(+), 7 deletions(-)
@@ -2602,6 +2602,7 @@ static int validate_and_copy_set_tun(const struct nlattr *attr,ovs_tun->tun_dst=tun_dst;tun_info=&tun_dst->u.tun_info;+tun_info->type=IP_TUNNEL_TYPE_UNSPEC;tun_info->mode=IP_TUNNEL_INFO_TX;if(key.tun_proto==AF_INET6)tun_info->mode|=IP_TUNNEL_INFO_IPV6;
If so then this should also be made explicit IP_TUNNEL_TYPE_UNSPEC in BPF code
since all these tunnel types are supported there as well.
Are you refering to proper initialization? I can see a memset() there
for the ip_tunnel_info structure, which is implicitly setting
tun_info->type to zero, ie. IP_TUNNEL_TYPE_UNSPEC.
I can also make it explicit there if you prefer.
Thanks.
@@ -2602,6 +2602,7 @@ static int validate_and_copy_set_tun(const struct nlattr *attr,ovs_tun->tun_dst=tun_dst;tun_info=&tun_dst->u.tun_info;+tun_info->type=IP_TUNNEL_TYPE_UNSPEC;tun_info->mode=IP_TUNNEL_INFO_TX;if(key.tun_proto==AF_INET6)tun_info->mode|=IP_TUNNEL_INFO_IPV6;
If so then this should also be made explicit IP_TUNNEL_TYPE_UNSPEC in BPF code
since all these tunnel types are supported there as well.
Are you refering to proper initialization? I can see a memset() there
for the ip_tunnel_info structure, which is implicitly setting
tun_info->type to zero, ie. IP_TUNNEL_TYPE_UNSPEC.
I can also make it explicit there if you prefer.
Yeah that would be my preference as otherwise we might miss future changes there.
Thanks,
Daniel
From: Jakub Kicinski <hidden> Date: 2018-10-05 02:08:39
On Thu, 4 Oct 2018 02:03:42 +0200, Pablo Neira Ayuso wrote:
Hi,
The following patchset adds a new field to the tunnel metadata template
to restrict the configuration to a given tunnel driver. Currently, a
misconfiguration may result in packets going to the wrong tunnel driver.
Although we have the tunnel option flags, they are not mandatory for
some tunnel drivers, eg. vxlan, which may use it or not; and gre which
does not use them.
Option flags are necessary because interpretation of option blob is
entirely protocol-specific.
This patch updates tc's tunnel action and netfilter's tunnel extension
to use this new field. OVS netlink interface has been left unset, although they
could be updated to use this.
By extending the existing tc action to support the IP_TUNNEL_INFO_BRIDGE
mode, I think it should be possible to expose IP_TUNNEL_TYPE_VLAN too,
although this patchset doesn't address this scenario.
The field is initialized to zero, which maps to IP_TUNNEL_TYPE_UNSPEC to
retain the existing behaviour, so the existing flexibility is still in
place while this new feature is added.
Cc'ing people that git annotate show as dealing with these bits more
recently.
From: Pablo Neira Ayuso <pablo@netfilter.org> Date: 2018-10-05 04:53:33
Hi Jakub,
On Thu, Oct 04, 2018 at 12:13:57PM -0700, Jakub Kicinski wrote:
On Thu, 4 Oct 2018 02:03:42 +0200, Pablo Neira Ayuso wrote:
quoted
Hi,
The following patchset adds a new field to the tunnel metadata template
to restrict the configuration to a given tunnel driver. Currently, a
misconfiguration may result in packets going to the wrong tunnel driver.
Although we have the tunnel option flags, they are not mandatory for
some tunnel drivers, eg. vxlan, which may use it or not; and gre which
does not use them.
Option flags are necessary because interpretation of option blob is
entirely protocol-specific.
quoted
This patch updates tc's tunnel action and netfilter's tunnel extension
to use this new field. OVS netlink interface has been left unset, although they
could be updated to use this.
By extending the existing tc action to support the IP_TUNNEL_INFO_BRIDGE
mode, I think it should be possible to expose IP_TUNNEL_TYPE_VLAN too,
although this patchset doesn't address this scenario.
The field is initialized to zero, which maps to IP_TUNNEL_TYPE_UNSPEC to
retain the existing behaviour, so the existing flexibility is still in
place while this new feature is added.
Cc'ing people that git annotate show as dealing with these bits more
recently.
What practical scenario are you trying to address here?
Incorrect configuration. The tunnel template defines an ID field, this
ID means vni in vxlan, but it also means session in erspan. If a
packet that should go to vxlan tunnel device (to be encapsulated using
vni 5) ends up in a gre/erspan device, you will get an erspan packet
with session 5. With this new tunnel type field, you can restrict
the tunnel template to work _only_ for a given tunnel device driver.
Hence, if the packet ends up in the wrong tunnel device driver due to
incorrect configuration, packet gets dropped.
Hm, I remember to have seen some hw offload driver code that is making
assumptions on the destination ports to pick the tunnel protocol,
based on what the act_key_tunnel is passing.
This patchset may probably help there too since act_key_tunnel will
convey the tunnel type, given this can now be made explicit. The tc
action parsing from the driver can annotate the tunnel type that has
been set in this rule via act_tunnel_key, then validate that follow up
mirred action points to a tunnel device of the same type.
Thanks.
From: Or Gerlitz <hidden> Date: 2018-10-14 14:22:51
On Fri, Oct 5, 2018 at 12:58 AM Pablo Neira Ayuso [off-list ref] wrote:
Hi Jakub,
On Thu, Oct 04, 2018 at 12:13:57PM -0700, Jakub Kicinski wrote:
quoted
On Thu, 4 Oct 2018 02:03:42 +0200, Pablo Neira Ayuso wrote:
quoted
Hi,
The following patchset adds a new field to the tunnel metadata template
to restrict the configuration to a given tunnel driver. Currently, a
misconfiguration may result in packets going to the wrong tunnel driver.
Although we have the tunnel option flags, they are not mandatory for
some tunnel drivers, eg. vxlan, which may use it or not; and gre which
does not use them.
Option flags are necessary because interpretation of option blob is
entirely protocol-specific.
quoted
This patch updates tc's tunnel action and netfilter's tunnel extension
to use this new field. OVS netlink interface has been left unset, although they
could be updated to use this.
By extending the existing tc action to support the IP_TUNNEL_INFO_BRIDGE
mode, I think it should be possible to expose IP_TUNNEL_TYPE_VLAN too,
although this patchset doesn't address this scenario.
not following... can you elaborate further please?
quoted
quoted
The field is initialized to zero, which maps to IP_TUNNEL_TYPE_UNSPEC to
retain the existing behaviour, so the existing flexibility is still in
place while this new feature is added.
Cc'ing people that git annotate show as dealing with these bits more
recently.
What practical scenario are you trying to address here?
Incorrect configuration. The tunnel template defines an ID field, this
ID means vni in vxlan, but it also means session in erspan. If a
packet that should go to vxlan tunnel device (to be encapsulated using
vni 5) ends up in a gre/erspan device, you will get an erspan packet
with session 5. With this new tunnel type field, you can restrict
the tunnel template to work _only_ for a given tunnel device driver.
Hence, if the packet ends up in the wrong tunnel device driver due to
incorrect configuration, packet gets dropped.
Hm, I remember to have seen some hw offload driver code that is making
assumptions on the destination ports to pick the tunnel protocol,
based on what the act_key_tunnel is passing.
[..]
for udp based tunneling this is valid practice, b/c a driver can get the tunnel
type <--> udp dest port relation from the stack through the udp tunnel ndo.
HW offloading wise, I think it would be better first pursue Januk and Co
proposal which deals with the problematic part of tc/tunnels -- ingress rules
set on tunnel devices (decap rules). The RFC looks very promising and
I understand
this is going to be reposed as non-rfc early in the next cycle
From: Pablo Neira Ayuso <pablo@netfilter.org> Date: 2018-10-14 17:05:08
Hi Or,
On Sun, Oct 14, 2018 at 09:42:42AM +0300, Or Gerlitz wrote:
On Fri, Oct 5, 2018 at 12:58 AM Pablo Neira Ayuso [off-list ref] wrote:
[...]
quoted
On Thu, Oct 04, 2018 at 12:13:57PM -0700, Jakub Kicinski wrote:
quoted
On Thu, 4 Oct 2018 02:03:42 +0200, Pablo Neira Ayuso wrote:
quoted
Hi,
The following patchset adds a new field to the tunnel metadata template
to restrict the configuration to a given tunnel driver. Currently, a
misconfiguration may result in packets going to the wrong tunnel driver.
Although we have the tunnel option flags, they are not mandatory for
some tunnel drivers, eg. vxlan, which may use it or not; and gre which
does not use them.
Option flags are necessary because interpretation of option blob is
entirely protocol-specific.
quoted
This patch updates tc's tunnel action and netfilter's tunnel extension
to use this new field. OVS netlink interface has been left unset, although they
could be updated to use this.
By extending the existing tc action to support the IP_TUNNEL_INFO_BRIDGE
mode, I think it should be possible to expose IP_TUNNEL_TYPE_VLAN too,
although this patchset doesn't address this scenario.
not following... can you elaborate further please?
It should be possible to extend act_key_tunnel to support the
IP_TUNNEL_INFO_BRIDGE flag, but this is just a suggestion.
quoted
quoted
quoted
The field is initialized to zero, which maps to IP_TUNNEL_TYPE_UNSPEC to
retain the existing behaviour, so the existing flexibility is still in
place while this new feature is added.
Cc'ing people that git annotate show as dealing with these bits more
recently.
What practical scenario are you trying to address here?
Incorrect configuration. The tunnel template defines an ID field, this
ID means vni in vxlan, but it also means session in erspan. If a
packet that should go to vxlan tunnel device (to be encapsulated using
vni 5) ends up in a gre/erspan device, you will get an erspan packet
with session 5. With this new tunnel type field, you can restrict
the tunnel template to work _only_ for a given tunnel device driver.
Hence, if the packet ends up in the wrong tunnel device driver due to
incorrect configuration, packet gets dropped.
Hm, I remember to have seen some hw offload driver code that is making
assumptions on the destination ports to pick the tunnel protocol,
based on what the act_key_tunnel is passing.
[..]
for udp based tunneling this is valid practice, b/c a driver can get the tunnel
type <--> udp dest port relation from the stack through the udp tunnel ndo.
HW offloading wise, I think it would be better first pursue Januk and Co
proposal which deals with the problematic part of tc/tunnels -- ingress rules
set on tunnel devices (decap rules). The RFC looks very promising and
I understand this is going to be reposed as non-rfc early in the next cycle
Sorry, I think there's a misunderstanding here.
My patchset is of benefit for pure software/control plane approach:
This allows users to narrow down tunnel configurations, existing
approach is very flexible - probably a bit too much for people willing
to validate things are correct - since it is allowing too loose
configurations. This is leaving room to the user to make configuration
mistakes that result in bad things, such as packets being tunneled
through the wrong encapsulation type. With this patchset, packets
going to the wrong tunnel devices will be simply dropped - and we
could even do more specific validation from control plane after this.
This patchset is backward compatible, so it doesn't restrict for the
existing flexibility that users may want for this.
This patchset _never_ meant to replace Jakub's work nor any HW offload
infrastructure. After reading Jakub's email, I was just suggesting
that this may (probably) still help drivers too, since this would
provide more hints to the driver. Please, let me know if this is
causing any interference with your ongoing HW driver development in
some way, and if so, in what way.
Let me know,
Thanks.
From: Or Gerlitz <hidden> Date: 2018-10-14 19:05:37
On Sun, Oct 14, 2018 at 12:24 PM Pablo Neira Ayuso [off-list ref] wrote:
On Sun, Oct 14, 2018 at 09:42:42AM +0300, Or Gerlitz wrote:
quoted
On Fri, Oct 5, 2018 at 12:58 AM Pablo Neira Ayuso [off-list ref] wrote:
[...]
quoted
quoted
On Thu, Oct 04, 2018 at 12:13:57PM -0700, Jakub Kicinski wrote:
quoted
On Thu, 4 Oct 2018 02:03:42 +0200, Pablo Neira Ayuso wrote:
quoted
Hi,
The following patchset adds a new field to the tunnel metadata template
to restrict the configuration to a given tunnel driver. Currently, a
misconfiguration may result in packets going to the wrong tunnel driver.
Although we have the tunnel option flags, they are not mandatory for
some tunnel drivers, eg. vxlan, which may use it or not; and gre which
does not use them.
Option flags are necessary because interpretation of option blob is
entirely protocol-specific.
quoted
This patch updates tc's tunnel action and netfilter's tunnel extension
to use this new field. OVS netlink interface has been left unset, although they
could be updated to use this.
By extending the existing tc action to support the IP_TUNNEL_INFO_BRIDGE
mode, I think it should be possible to expose IP_TUNNEL_TYPE_VLAN too,
although this patchset doesn't address this scenario.
not following... can you elaborate further please?
It should be possible to extend act_key_tunnel to support the
IP_TUNNEL_INFO_BRIDGE flag, but this is just a suggestion.
quoted
quoted
quoted
quoted
The field is initialized to zero, which maps to IP_TUNNEL_TYPE_UNSPEC to
retain the existing behaviour, so the existing flexibility is still in
place while this new feature is added.
Cc'ing people that git annotate show as dealing with these bits more
recently.
What practical scenario are you trying to address here?
Incorrect configuration. The tunnel template defines an ID field, this
ID means vni in vxlan, but it also means session in erspan. If a
packet that should go to vxlan tunnel device (to be encapsulated using
vni 5) ends up in a gre/erspan device, you will get an erspan packet
with session 5. With this new tunnel type field, you can restrict
the tunnel template to work _only_ for a given tunnel device driver.
Hence, if the packet ends up in the wrong tunnel device driver due to
incorrect configuration, packet gets dropped.
Hm, I remember to have seen some hw offload driver code that is making
assumptions on the destination ports to pick the tunnel protocol,
based on what the act_key_tunnel is passing.
[..]
for udp based tunneling this is valid practice, b/c a driver can get the tunnel
type <--> udp dest port relation from the stack through the udp tunnel ndo.
HW offloading wise, I think it would be better first pursue Januk and Co
proposal which deals with the problematic part of tc/tunnels -- ingress rules
set on tunnel devices (decap rules). The RFC looks very promising and
I understand this is going to be reposed as non-rfc early in the next cycle
Sorry, I think there's a misunderstanding here.
My patchset is of benefit for pure software/control plane approach:
This allows users to narrow down tunnel configurations, existing
approach is very flexible - probably a bit too much for people willing
to validate things are correct - since it is allowing too loose
configurations. This is leaving room to the user to make configuration
mistakes that result in bad things, such as packets being tunneled
through the wrong encapsulation type.
I see your point, but I think that the fact that effectively all or most
of the IP based tunnels in the kernel conform to struct ip_tunnel_info
is a plus and not a minus.. control planes can do their mistakes if they
don't read the man, this wrong tunneling that you mentioned is not going
to live far beyond the next networking hop or even dropped earlier, within the
stack of this node.
through the wrong encapsulation type. With this patchset, packets
going to the wrong tunnel devices will be simply dropped - and we
could even do more specific validation from control plane after this.
This patchset is backward compatible, so it doesn't restrict for the
existing flexibility that users may want for this.
This patchset _never_ meant to replace Jakub's work nor any HW offload
infrastructure. After reading Jakub's email, I was just suggesting
that this may (probably) still help drivers too, since this would
provide more hints to the driver.
well, yes, more hints and sort of no (see next)
provide more hints to the driver. Please, let me know if this is
causing any interference with your ongoing HW driver development in
some way, and if so, in what way.
for example, if newer controller wants to work over older kernel that doesn't
have the new flag, they have to write code that can go both ways, this is doable
-- but do we want to do that just for the sake of reacting to user
mis-configurations?
I am open / will be happy to hear more opinions here.
Or.
From: Pablo Neira Ayuso <pablo@netfilter.org> Date: 2018-10-15 01:41:52
Hi Or,
On Sun, Oct 14, 2018 at 02:24:42PM +0300, Or Gerlitz wrote:
On Sun, Oct 14, 2018 at 12:24 PM Pablo Neira Ayuso [off-list ref] wrote:
quoted
On Sun, Oct 14, 2018 at 09:42:42AM +0300, Or Gerlitz wrote:
[...]
quoted
quoted
for udp based tunneling this is valid practice, b/c a driver can get the tunnel
type <--> udp dest port relation from the stack through the udp tunnel ndo.
HW offloading wise, I think it would be better first pursue Januk and Co
proposal which deals with the problematic part of tc/tunnels -- ingress rules
set on tunnel devices (decap rules). The RFC looks very promising and
I understand this is going to be reposed as non-rfc early in the next cycle
Sorry, I think there's a misunderstanding here.
My patchset is of benefit for pure software/control plane approach:
This allows users to narrow down tunnel configurations, existing
approach is very flexible - probably a bit too much for people willing
to validate things are correct - since it is allowing too loose
configurations. This is leaving room to the user to make configuration
mistakes that result in bad things, such as packets being tunneled
through the wrong encapsulation type.
I see your point, but I think that the fact that effectively all or most
of the IP based tunnels in the kernel conform to struct ip_tunnel_info
is a plus and not a minus.. control planes can do their mistakes if they
don't read the man, this wrong tunneling that you mentioned is not going
to live far beyond the next networking hop or even dropped earlier, within the
stack of this node.
I think it is worse that just 'please read the manpage', look:
The tunnel ID field is 64 bits, but it is trimmed down to 32 bits for
VxLAN, and then it is 8 bits in case of ERSPAN for the session field.
Semantics depend on the tunnel protocol. Depending on the tunneling
protocol, the ID have different tunnel header field length. The
control plane cannot reject a 0xff00ffff in ERSPAN because the
ip_tunnel_info structure has no tunnel type semantics. I think it
would be good if users get some sort of 'sorry, you cannot specify
tunnel ID larger that 8 bits in ERSPAN'.
Another example, you can also specify via tc/ingress a rule like:
act_tunnel_key id 50 src-addr 192.168.2.1
with no fwd/mirred action in a bridge setup. The tunnel device is part
of the bridge in this case, and the template passes the configuration
to the tunnel device that is part of the bridge. So we cannot assume
the fwd/mirred action always follow act_tunnel_key in software.
Probably in HW offload it makes sense to always follow it up with
fwd/mirred to keep things simple, but we already have scenarios in
software where this is not the case.
quoted
through the wrong encapsulation type. With this patchset, packets
going to the wrong tunnel devices will be simply dropped - and we
could even do more specific validation from control plane after this.
This patchset is backward compatible, so it doesn't restrict for the
existing flexibility that users may want for this.
This patchset _never_ meant to replace Jakub's work nor any HW offload
infrastructure. After reading Jakub's email, I was just suggesting
that this may (probably) still help drivers too, since this would
provide more hints to the driver.
well, yes, more hints and sort of no (see next)
quoted
provide more hints to the driver. Please, let me know if this is
causing any interference with your ongoing HW driver development in
some way, and if so, in what way.
for example, if newer controller wants to work over older kernel that doesn't
have the new flag, they have to write code that can go both ways
This is backward compatible, your controller can keep using the
existing approach forever.
Anyway, I think the problem you're refering about older kernel and new
controller is an interesting one but a different problem: This is an
existing limitation in netlink. Currently, there is not way to know
what the API supports other than doing probing, and probing is
something may not even help. I already proposed something to address
this problem in case you're interested [1].
, this is doable
-- but do we want to do that just for the sake of reacting to user
mis-configurations?
I am open / will be happy to hear more opinions here.
Please note that this new feature is optional, for people willing to
have an interface/control plane that can validate what they are
configuring can be good. Users tend to make mistakes, manpage is last
resort, well if control plane can help / provide hints on what is
wrong, things become easier for users.
Thanks for your feedback!
[1] https://lwn.net/Articles/746776/