All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stephen Hemminger <shemminger@vyatta.com>
To: Leigh Sharpe <lsharpe@pacificwireless.com.au>
Cc: bridge@lists.linux-foundation.org
Subject: Re: [Bridge] Preventing packet reassembly
Date: Sun, 27 Apr 2008 22:35:37 -0700	[thread overview]
Message-ID: <20080427223537.74cd0f7f@extreme> (raw)
In-Reply-To: <96CF49BD8B56384395D698BA99007FA32FA1E7@exchange.pacwire.local>

On Mon, 28 Apr 2008 09:56:49 +1000
"Leigh Sharpe" <lsharpe@pacificwireless.com.au> wrote:

> Hi All, 
> I'm having some issues with my bridge reassembling fragmented packets,
> with disastrous results.
> I have a simple bridge set up:
>  
> brctl addbr br0
> brctl addif br0 eth0 
> brctl addif br0 eth1
>  
> Simple enough. The MTU on each interface is 1500, and so is the MTU on
> the bridge itself. 
> I have the bridge connected something like this:
>  
> PC A----Switch A---eth0 (bridge) eth1---Switch B---PC B.
>  
> The Switches are adding VLAN headers and the like, but this seems to be
> irrelevant to the problem.
> If i ping from PC A to PC B, all is OK. But, when I ping using a
> 1500-byte payload (or larger), the ping doesn't get through. Removing
> the linux bridge and just going switch-switch works OK.
>  
> Watching the ethernet ports on the bridge indicate that the ping is
> entering the bridge on eth0, but not coming out of eth1. A packet
> sniffer shows that the ping is being fragmented by PC A, and two packets
> enter eth0. I then increased the MTU on eth0, eth1 and br0 to 1600, to
> see if this was an MTU issue. I then see packets coming out of eth1, but
> my switch is dropping them, because they are oversized.
> Connecting eth1 straight to a packet sniffer shows that when two packets
> enter eth0, the bridge is reassembling them into a single, larger
> packet, which it then either drops because it is larget than the MTU of
> eth1, or it passes a large packet (in this case, 1560 bytes or so).
> Obviously, this packet is then dropped by other equipment in the
> network, because it is too large for a proper ethernet packet.
>  
> I am seeing this behaviour with any IP packets, not just ICMP. The
> result is that anything which has a large-ish payload is being dropped
> after it leaves the bridge.
>  
> The question is, then: How do I stop the bridge from reassembling
> fragmented packets?
>  
>  

Are you using hardware that does Large Receive Offload (LRO)? Most
hardware doesn't. The other possible problem would be ebtables/iptables
rules.  The bridge itself doesn't reassemble packets, but firewall
rules might.

  reply	other threads:[~2008-04-28  5:35 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-04-27 23:56 [Bridge] Preventing packet reassembly Leigh Sharpe
2008-04-28  5:35 ` Stephen Hemminger [this message]
  -- strict thread matches above, loose matches on Subject: below --
2008-04-28  7:28 Leigh Sharpe
2008-05-02 19:24 ` Jason Lunz
2008-05-05 18:10 ` Patrick McHardy

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=20080427223537.74cd0f7f@extreme \
    --to=shemminger@vyatta.com \
    --cc=bridge@lists.linux-foundation.org \
    --cc=lsharpe@pacificwireless.com.au \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.