Short version: Since 3.4.92, when forwarding, GRO aggregated packets are no longer forwarded because kernel believes segments exceed path mtu. This is because kernels pre 3.11 lack commit 21d1196a35f5686c4323e42a62fdb4b23b0ab4a3 Author: Eric Dumazet <edumazet@xxxxxxxxxx> ipv4: set transport header earlier [ this commit was already picked up by 3.10.y tree ] The backport of 895162b1101b3ea5db08ca6822ae9672717efec0 exposed this problem. Original report quoted below. ----- Forwarded message from Florian Westphal <fw@xxxxxxxxx> ----- Date: Fri, 27 Jun 2014 11:05:25 +0200 From: Florian Westphal <fw@xxxxxxxxx> To: jungwon park <jwpark2@xxxxxxxxxxxxxxx> Cc: netdev@xxxxxxxxxxxxxxx Subject: Re: GRO issue with kernel 3.4.94 (icmp fragmentation needed) jungwon park <jwpark2@xxxxxxxxxxxxxxx> wrote: > When using the linux router is turned on GRO, router send the 'fragmentation > needed' packets to the sender. Indeed 8-( > When I turned off GRO, the router operate normally, and there is no problem. > and with 3.4.91 kernel, the router has no problem. > > I doubt 'ipv4: ip_forward: fix inverted local_df test' patch. > (http://patchwork.ozlabs.org/patch/345509/) > When I revert this patch, the router has no problem. Can you please cherry-pick following patch on top of vanilla 3.4.92? https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=21d1196a35f5686c4323e42a62fdb4b23b0ab4a3 commit 21d1196a35f5686c4323e42a62fdb4b23b0ab4a3 Author: Eric Dumazet <edumazet@xxxxxxxxxx> ipv4: set transport header earlier I think that should fix this bug, it should apply cleanly on top of 3.4.y tree. [ patch is in 3.11, also backported to 3.10.y tree ] The problem is that, when dealing with GRO packets, we try to determine the size of the individual packets. To do this, we rely on the transport header. Unfortunately the transport header is not set for the forward path in 3.4, so we look at the network header instead. ----- End forwarded message ----- -- To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html