From: Fredrik Markstrom <fredrik.markstrom@gmail.com>
To: "netdev" <netdev@vger.kernel.org>
Cc: "Evan Jones" <ej@evanjones.ca>,
"David S. Miller" <davem@davemloft.net>,
"Cong Wang" <cwang@twopensource.com>,
"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
"Vijay Pandurangan" <vijayp@vijayp.ca>,
"linux-kernel" <linux-kernel@vger.kernel.org>
Subject: Inconsistency in packet drop due to MTU (eth vs veth)
Date: Thu, 19 Jan 2017 17:41:23 +0100 [thread overview]
Message-ID: <159b79aa979.e23be6a5186096.2767722456700391441@gmail.com> (raw)
In-Reply-To:
Hello,
I've noticed an inconsistency between how physical ethernet and veth handles mtu.
If I setup two physical interfaces (directly connected) with different mtu:s, only the size of the outgoing packets are limited by the mtu. But with veth a packet is dropped if the mtu of the receiving interface is smaller then the packet size.
This seems inconsistent to me, but maybe there is a reason for it ?
Can someone confirm if it's a deliberate inconsistency or just a side effect of using dev_forward_skb() ?
Example:
Using physical interfaces
=================
client> ip link set dev eth0 mtu 500
server> ip link set dev eth2 mtu 1500
server> ping -qc 2 -s 600 client
PING 135.15.35.74 (135.15.35.74) 1100(1128) bytes of data.
--- 135.15.35.74 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 999ms
rtt min/avg/max/mdev = 0.818/0.864/0.910/0.046 ms
Using veth
=============
server> ip netns add clientns
server> ip link add name serverif type veth peer name clientif
server> ip addr add 10.0.0.1/24 dev serverif
server> ip link set serverif mtu 1500 up
server> ip link set clientif up netns clientns
server> ip netns exec clientns ip link set clientif mtu 500
server> ip netns exec clientns ip addr add 10.0.0.74/24 dev clientif
server> ping -qc 2 -s 600 10.0.0.74
PING 10.0.0.74 (10.0.0.74) 600(628) bytes of data.
--- 10.0.0.74 ping statistics ---
2 packets transmitted, 0 received, 100% packet loss, time 1008ms
/F
next reply other threads:[~2017-01-19 16:42 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-01-19 16:41 Fredrik Markstrom [this message]
2017-01-19 18:53 ` Eric Dumazet
2017-01-31 13:32 ` Fredrik Markstrom
2017-01-31 16:27 ` Eric Dumazet
2017-02-03 8:07 ` Fredrik Markstrom
2017-02-03 14:42 ` Toshiaki Makita
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=159b79aa979.e23be6a5186096.2767722456700391441@gmail.com \
--to=fredrik.markstrom@gmail.com \
--cc=cwang@twopensource.com \
--cc=davem@davemloft.net \
--cc=ej@evanjones.ca \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=vijayp@vijayp.ca \
/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®