Ethernet Bridge development
 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox