public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Ido Schimmel <idosch@idosch.org>
To: Jakub Kicinski <kuba@kernel.org>
Cc: Thomas Lamprecht <t.lamprecht@proxmox.com>,
	"David S. Miller" <davem@davemloft.net>,
	Eric Dumazet <edumazet@google.com>,
	Paolo Abeni <pabeni@redhat.com>,
	netdev@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: vxlan: how to expose opt-in RFC conformity with unprocessed header flags
Date: Mon, 22 Jan 2024 11:39:16 +0200	[thread overview]
Message-ID: <Za43xKoWDtL6MxCn@shredder> (raw)
In-Reply-To: <20240116082357.22daf549@kernel.org>

On Tue, Jan 16, 2024 at 08:23:57AM -0800, Jakub Kicinski wrote:
> On Fri, 12 Jan 2024 16:13:22 +0100 Thomas Lamprecht wrote:
> > What would be the accepted way to add a switch of making this RFC conform in
> > an opt-in way? A module parameter? A sysfs entry? Through netlink?
> 
> Thru netlink. 

+1 

> My intuition would be to try to add a "ignore bits" mask, rather than
> "RFC compliance knob" because RFCs may have shorter lifespan than
> kernel's uAPI guarantees..

Newer Spectrum chips have a 64 bit mask that covers the entire VXLAN
header. If a bit is set in the mask and the corresponding bit in the
VXLAN header is not zero, the packet is dropped / trapped.

Another option, assuming the interface that receives the encapsulated
packets is known, is to clear the reserved bits in the VXLAN header
using pedit. This seems to work:

tc -n ns2 qdisc add dev veth1 clsact
tc -n ns2 filter add dev veth1 ingress pref 1 proto ip flower ip_proto udp \
        dst_port 4789 \
        action pedit munge offset 28 u8 set 0x08

Tested by setting the reserved bits on the other side and making sure
ping works:

tc -n ns1 qdisc add dev veth0 clsact
tc -n ns1 filter add dev veth0 egress pref 1 proto ip flower ip_proto udp \
        dst_port 4789 \
        action pedit munge offset 28 u8 set 0xff

The advantage is that no kernel changes are required whereas the netlink
solution will have to be maintained forever, even after the other side
is fixed.

      reply	other threads:[~2024-01-22  9:39 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-01-12 15:13 vxlan: how to expose opt-in RFC conformity with unprocessed header flags Thomas Lamprecht
2024-01-16 16:23 ` Jakub Kicinski
2024-01-22  9:39   ` Ido Schimmel [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=Za43xKoWDtL6MxCn@shredder \
    --to=idosch@idosch.org \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=t.lamprecht@proxmox.com \
    /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