Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1562907 > unrolled thread

Inconsistency in packet drop due to MTU (eth vs veth)

Started byFredrik Markstrom <fredrik.markstrom@gmail.com>
First post2017-01-19 17:50 +0100
Last post2017-01-19 20:10 +0100
Articles 2 — 2 participants

Back to article view | Back to linux.kernel


Contents

  Inconsistency in packet drop due to MTU (eth vs veth) Fredrik Markstrom <fredrik.markstrom@gmail.com> - 2017-01-19 17:50 +0100
    Re: Inconsistency in packet drop due to MTU (eth vs veth) Eric Dumazet <eric.dumazet@gmail.com> - 2017-01-19 20:10 +0100

#1562907 — Inconsistency in packet drop due to MTU (eth vs veth)

FromFredrik Markstrom <fredrik.markstrom@gmail.com>
Date2017-01-19 17:50 +0100
SubjectInconsistency in packet drop due to MTU (eth vs veth)
Message-ID<t1o4q-3Xc-47@gated-at.bofh.it>
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

[toc] | [next] | [standalone]


#1563015

FromEric Dumazet <eric.dumazet@gmail.com>
Date2017-01-19 20:10 +0100
Message-ID<t1qfU-5uo-5@gated-at.bofh.it>
In reply to#1562907
On Thu, 2017-01-19 at 17:41 +0100, Fredrik Markstrom wrote:
> 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() ?

It looks this was added in commit
38d408152a86598a50680a82fe3353b506630409
("veth: Allow setting the L3 MTU")

But what was really needed here was a way to change MRU :(

[toc] | [prev] | [standalone]


Back to top | Article view | linux.kernel


csiph-web