* [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