From: Eelco Chaudron <echaudro@redhat.com>
To: Aaron Conole <aconole@redhat.com>
Cc: netdev@vger.kernel.org, dev@openvswitch.org,
linux-kernel@vger.kernel.org, Pravin B Shelar <pshelar@ovn.org>,
"David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
Jesse Gross <jesse@nicira.com>,
Ilya Maximets <i.maximets@ovn.org>, Simon Horman <horms@ovn.org>,
Jaime Caamano <jcaamano@redhat.com>
Subject: Re: [PATCH v2 net] openvswitch: Set the skbuff pkt_type for proper pmtud support.
Date: Tue, 21 May 2024 12:09:39 +0200 [thread overview]
Message-ID: <701FCF52-7D25-4094-9B0E-8F7AE8A68107@redhat.com> (raw)
In-Reply-To: <20240516200941.16152-1-aconole@redhat.com>
On 16 May 2024, at 22:09, Aaron Conole wrote:
> Open vSwitch is originally intended to switch at layer 2, only dealing with
> Ethernet frames. With the introduction of l3 tunnels support, it crossed
> into the realm of needing to care a bit about some routing details when
> making forwarding decisions. If an oversized packet would need to be
> fragmented during this forwarding decision, there is a chance for pmtu
> to get involved and generate a routing exception. This is gated by the
> skbuff->pkt_type field.
>
> When a flow is already loaded into the openvswitch module this field is
> set up and transitioned properly as a packet moves from one port to
> another. In the case that a packet execute is invoked after a flow is
> newly installed this field is not properly initialized. This causes the
> pmtud mechanism to omit sending the required exception messages across
> the tunnel boundary and a second attempt needs to be made to make sure
> that the routing exception is properly setup. To fix this, we set the
> outgoing packet's pkt_type to PACKET_OUTGOING, since it can only get
> to the openvswitch module via a port device or packet command.
>
> Even for bridge ports as users, the pkt_type needs to be reset when
> doing the transmit as the packet is truly outgoing and routing needs
> to get involved post packet transformations, in the case of
> VXLAN/GENEVE/udp-tunnel packets. In general, the pkt_type on output
> gets ignored, since we go straight to the driver, but in the case of
> tunnel ports they go through IP routing layer.
>
> This issue is periodically encountered in complex setups, such as large
> openshift deployments, where multiple sets of tunnel traversal occurs.
> A way to recreate this is with the ovn-heater project that can setup
> a networking environment which mimics such large deployments. We need
> larger environments for this because we need to ensure that flow
> misses occur. In these environment, without this patch, we can see:
>
> ./ovn_cluster.sh start
> podman exec ovn-chassis-1 ip r a 170.168.0.5/32 dev eth1 mtu 1200
> podman exec ovn-chassis-1 ip netns exec sw01p1 ip r flush cache
> podman exec ovn-chassis-1 ip netns exec sw01p1 \
> ping 21.0.0.3 -M do -s 1300 -c2
> PING 21.0.0.3 (21.0.0.3) 1300(1328) bytes of data.
> From 21.0.0.3 icmp_seq=2 Frag needed and DF set (mtu = 1142)
>
> --- 21.0.0.3 ping statistics ---
> ...
>
> Using tcpdump, we can also see the expected ICMP FRAG_NEEDED message is not
> sent into the server.
>
> With this patch, setting the pkt_type, we see the following:
>
> podman exec ovn-chassis-1 ip netns exec sw01p1 \
> ping 21.0.0.3 -M do -s 1300 -c2
> PING 21.0.0.3 (21.0.0.3) 1300(1328) bytes of data.
> From 21.0.0.3 icmp_seq=1 Frag needed and DF set (mtu = 1222)
> ping: local error: message too long, mtu=1222
>
> --- 21.0.0.3 ping statistics ---
> ...
>
> In this case, the first ping request receives the FRAG_NEEDED message and
> a local routing exception is created.
>
> Tested-by: Jaime Caamano <jcaamano@redhat.com>
> Reported-at: https://issues.redhat.com/browse/FDP-164
> Fixes: 58264848a5a7 ("openvswitch: Add vxlan tunneling support.")
> Signed-off-by: Aaron Conole <aconole@redhat.com>
Thanks for the additional comments and detailed commit message. The change looks good to me.
Acked-by: Eelco Chaudron <echaudro@redhat.com>
next prev parent reply other threads:[~2024-05-21 10:09 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-16 20:09 Aaron Conole
2024-05-21 10:09 ` Eelco Chaudron [this message]
2024-05-21 13:41 ` patchwork-bot+netdevbpf
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=701FCF52-7D25-4094-9B0E-8F7AE8A68107@redhat.com \
--to=echaudro@redhat.com \
--cc=aconole@redhat.com \
--cc=davem@davemloft.net \
--cc=dev@openvswitch.org \
--cc=edumazet@google.com \
--cc=horms@ovn.org \
--cc=i.maximets@ovn.org \
--cc=jcaamano@redhat.com \
--cc=jesse@nicira.com \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=pshelar@ovn.org \
/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
all inboxes | Powered by JetHome®