netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Vlad Yasevich <vyasevich@gmail.com>
To: Valdis.Kletnieks@vt.edu, David Newall <davidn@davidnewall.com>
Cc: Stephen Hemminger <stephen@networkplumber.org>,
	Netdev <netdev@vger.kernel.org>,
	bridge@lists.linux-foundation.org,
	Florian Westphal <fw@strlen.de>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: Revert 462fb2af9788a82a534f8184abfde31574e1cfa0 (bridge : Sanitize skb before it enters the IP stack)
Date: Tue, 20 May 2014 12:05:51 -0400	[thread overview]
Message-ID: <537B7D5F.2080802@gmail.com> (raw)
In-Reply-To: <14456.1400561749@turing-police.cc.vt.edu>

On 05/20/2014 12:55 AM, Valdis.Kletnieks@vt.edu wrote:
> On Mon, 19 May 2014 23:49:22 +0930, David Newall said:
> 
>> How does a packet get fragmented in this case?  Does it only happen when
>> bridging to a device with smaller MTU?  That scenario sounds quite
>> un-bridge-like.  It also sounds like something that can be handled by
>> real routing.
> 
> Which doesn't change the fact that you *will* get clowns who take a box that
> has a 10G card on a jumbogram-enabled subnet that's running with an MTU of
> 9000, and a 1G at MTU 1500 on the other, and try to bridge rather than route.
> (Did you know that you can actually mount an NFS filesystem across that? And
> that ls and cat and friends will work *just fine*? Until you hit a file that's
> more than 1.5 in size, that is. And when you do a traceroute to the wedged
> client, it tells you it's on the 10G network, so you have no idea why you're
> seeing an MTU issue.  Don't ask how I know this - let's just say that
> supporting HPC users is never boring. :)
> 
> So yes, we *do* need to do something sensible there - either frag the packet
> on the way out, or something.  It *would* be nice if we could drop the
> packet and send an ICMP Frag Needed back - except it's unclear what IP
> you use as the source address for the ICMP....
> 

If there is no netfilter, then the bridge will just drop the packet
(see br_dev_queue_push_xmit).  It should probably also do that with
netfilter.

On the question of ICMP, I've also debated about sending ICMP Frag
Needed, but that's really beyond the scope of the bridge device.

Recording a stat might be sufficient to help troubleshoot these types
of issues.

-vlad

  reply	other threads:[~2014-05-20 16:05 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-05-11 14:41 Bad checksum on bridge with IP options David Newall
2014-05-11 19:42 ` Lukas Tribus
2014-05-12  8:14   ` David Newall
2014-05-12 10:15     ` Lukas Tribus
2014-05-12 10:25       ` David Newall
2014-05-12 10:31         ` Lukas Tribus
2014-05-12 10:48           ` David Newall
2014-05-12 13:23 ` David Newall
2014-05-12 13:51   ` Florian Westphal
2014-05-12 14:19     ` David Newall
2014-05-12 18:54   ` Lukas Tribus
2014-05-12 23:46     ` David Newall
2014-05-14 13:08       ` David Newall
2014-05-16 14:33         ` Revert 462fb2af9788a82a534f8184abfde31574e1cfa0 (bridge : Sanitize skb before it enters the IP stack) David Newall
2014-05-16 15:19           ` Eric Dumazet
2014-05-16 15:23             ` David Newall
2014-05-16 15:24             ` David Newall
2014-05-19 12:58           ` David Newall
2014-05-19 14:01             ` Florian Westphal
2014-05-19 14:19               ` David Newall
2014-05-19 17:09                 ` Florian Westphal
2014-05-19 20:49                   ` Bart De Schuymer
2014-05-21  7:49                     ` David Newall
2014-05-21 18:51                       ` Bart De Schuymer
2014-05-21 20:18                         ` David Miller
2014-05-22 18:57                           ` Bart De Schuymer
2014-05-24 18:00                             ` David Miller
2014-05-24  5:56                           ` David Newall
2014-05-24 17:43                             ` David Miller
2014-05-25  2:32                               ` David Newall
2014-05-25  3:02                                 ` David Miller
2014-05-25  6:37                                   ` David Newall
2014-05-27  8:55                                 ` David Laight
2014-05-29 22:34                                 ` David Miller
2014-05-30  9:17                                   ` David Newall
2014-05-31  0:46                                     ` David Miller
2014-05-31  6:13                                       ` David Newall
2014-05-31  6:37                                         ` David Miller
2014-05-22  3:50                         ` David Newall
2014-05-22 18:57                           ` Bart De Schuymer
2014-05-20  3:57                   ` David Newall
2014-05-20  4:55                 ` Valdis.Kletnieks
2014-05-20 16:05                   ` Vlad Yasevich [this message]
2014-05-21  8:10                   ` David Newall
2014-05-21 20:14                     ` David Miller
2014-05-22 20:06           ` Bandan Das

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=537B7D5F.2080802@gmail.com \
    --to=vyasevich@gmail.com \
    --cc=Valdis.Kletnieks@vt.edu \
    --cc=bridge@lists.linux-foundation.org \
    --cc=davidn@davidnewall.com \
    --cc=fw@strlen.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=stephen@networkplumber.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;
as well as URLs for NNTP newsgroup(s).