Ethernet Bridge development
 help / color / mirror / Atom feed
* [Bridge] Preventing packet reassembly
@ 2008-04-27 23:56 Leigh Sharpe
  2008-04-28  5:35 ` Stephen Hemminger
  0 siblings, 1 reply; 5+ messages in thread
From: Leigh Sharpe @ 2008-04-27 23:56 UTC (permalink / raw)
  To: bridge

[-- Attachment #1: Type: text/plain, Size: 2135 bytes --]

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?
 
 
 
Regards,
             Leigh
 
Leigh Sharpe
Network Systems Engineer
Pacific Wireless
Ph +61 3 9584 8966
Mob 0408 009 502
Helpdesk 1300 300 616
email lsharpe@pacificwireless.com.au
<blocked::mailto:lsharpe@pacificwireless.com.au> 
web www.pacificwireless.com.au
<blocked::http://www.pacificwireless.com.au/> 
 

[-- Attachment #2: Type: text/html, Size: 4869 bytes --]

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [Bridge] Preventing packet reassembly
  2008-04-27 23:56 [Bridge] Preventing packet reassembly Leigh Sharpe
@ 2008-04-28  5:35 ` Stephen Hemminger
  0 siblings, 0 replies; 5+ messages in thread
From: Stephen Hemminger @ 2008-04-28  5:35 UTC (permalink / raw)
  To: Leigh Sharpe; +Cc: bridge

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.

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [Bridge] Preventing packet reassembly
@ 2008-04-28  7:28 Leigh Sharpe
  2008-05-02 19:24 ` Jason Lunz
  2008-05-05 18:10 ` Patrick McHardy
  0 siblings, 2 replies; 5+ messages in thread
From: Leigh Sharpe @ 2008-04-28  7:28 UTC (permalink / raw)
  To: Stephen Hemminger; +Cc: bridge

 
> Are you using hardware that does Large Receive Offload (LRO)? Most

As far as I can tell, no. I'm using standard e1000 cards, which I
believe don't do LRO. Ethtool -S eth1 doesn't show any counters related
to LRO.

> hardware doesn't. The other possible problem would be
ebtables/iptables
> rules.  

Hmm. This may be the problem.

I have iptables rules on the management interface of the box, but not on
any of the ports which participate in bridging.
By removing iptables from my bootup, I get a properly functioning
bridge.

Why would iptables rules on one interface affect traffic bridged on
other interfaces? I'm presuming it's some kind of interaction with the
ip_conntrack module? Any way to stop it from loading?


Cheers,
Leigh.



-----Original Message-----
From: Stephen Hemminger [mailto:shemminger@vyatta.com] 
Sent: Monday, 28 April 2008 3:36 PM
To: Leigh Sharpe
Cc: bridge@lists.linux-foundation.org
Subject: Re: [Bridge] Preventing packet reassembly
>  
>  
> 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.

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [Bridge] Preventing packet reassembly
  2008-04-28  7:28 Leigh Sharpe
@ 2008-05-02 19:24 ` Jason Lunz
  2008-05-05 18:10 ` Patrick McHardy
  1 sibling, 0 replies; 5+ messages in thread
From: Jason Lunz @ 2008-05-02 19:24 UTC (permalink / raw)
  To: Leigh Sharpe; +Cc: Stephen Hemminger, bridge

In gmane.linux.network.bridge, you wrote:
> I have iptables rules on the management interface of the box, but not on
> any of the ports which participate in bridging.
> By removing iptables from my bootup, I get a properly functioning
> bridge.
>
> Why would iptables rules on one interface affect traffic bridged on
> other interfaces? I'm presuming it's some kind of interaction with the
> ip_conntrack module? Any way to stop it from loading?

You might find the iptables NOTRACK target helpful.

Jason

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [Bridge] Preventing packet reassembly
  2008-04-28  7:28 Leigh Sharpe
  2008-05-02 19:24 ` Jason Lunz
@ 2008-05-05 18:10 ` Patrick McHardy
  1 sibling, 0 replies; 5+ messages in thread
From: Patrick McHardy @ 2008-05-05 18:10 UTC (permalink / raw)
  To: Leigh Sharpe; +Cc: Stephen Hemminger, bridge

Leigh Sharpe wrote:
> I have iptables rules on the management interface of the box, but not on
> any of the ports which participate in bridging.
> By removing iptables from my bootup, I get a properly functioning
> bridge.

Connection tracking performs defragmentation for all packets,
independant of the ruleset. For briding the packets should get
re-fragmented when leaving the bridge device though.

Please try "iptables -t raw -I PREROUTING -i <br-dev> -j TRACE",

load the ipt_LOG module and post the output.


^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2008-05-05 18:10 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2008-04-27 23:56 [Bridge] Preventing packet reassembly Leigh Sharpe
2008-04-28  5:35 ` Stephen Hemminger
  -- 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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox