From mboxrd@z Thu Jan 1 00:00:00 1970 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8A8C2.5BAA3D60" Date: Mon, 28 Apr 2008 09:56:49 +1000 Message-ID: <96CF49BD8B56384395D698BA99007FA32FA1E7@exchange.pacwire.local> From: "Leigh Sharpe" Subject: [Bridge] Preventing packet reassembly List-Id: Linux Ethernet Bridging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: bridge@lists.linux-foundation.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C8A8C2.5BAA3D60 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All,=20 I'm having some issues with my bridge reassembling fragmented packets, with disastrous results. I have a simple bridge set up: =20 brctl addbr br0 brctl addif br0 eth0=20 brctl addif br0 eth1 =20 Simple enough. The MTU on each interface is 1500, and so is the MTU on the bridge itself.=20 I have the bridge connected something like this: =20 PC A----Switch A---eth0 (bridge) eth1---Switch B---PC B. =20 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. =20 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. =20 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. =20 The question is, then: How do I stop the bridge from reassembling fragmented packets? =20 =20 =20 Regards, Leigh =20 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 =20 web www.pacificwireless.com.au =20 =20 ------_=_NextPart_001_01C8A8C2.5BAA3D60 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi = All,=20

I'm = having some=20 issues with my bridge reassembling fragmented packets, with disastrous=20 results.

I have = a simple=20 bridge set up:

brctl = addbr=20 br0

brctl = addif br0 eth0=20

brctl = addif br0=20 eth1

Simple = enough. The=20 MTU on each interface is 1500, and so is the MTU on the bridge itself.=20

I have = the bridge=20 connected something like this:

PC = A----Switch=20 A---eth0 (bridge) eth1---Switch B---PC B.

The = Switches are=20 adding VLAN headers and the like, but this seems to be irrelevant to the = problem.

If i = ping from PC A=20 to PC B, all is OK. But, when I ping using a 1500-byte payload (or = larger), the=20 ping doesn't get through. Removing the linux bridge and just going = switch-switch=20 works OK.

Watching the=20 ethernet ports on the bridge indicate that the ping is entering the = bridge on=20 eth0, but not coming out of eth1. A packet sniffer shows that the ping = is being=20 fragmented by PC A, and two packets enter eth0. I then increased the MTU = on=20 eth0, eth1 and br0 to 1600, to see if this was an MTU issue. I then see = packets=20 coming out of eth1, but my switch is dropping them, because they are=20 oversized.

Connecting eth1=20 straight to a packet sniffer shows that when two packets enter eth0, the = bridge=20 is reassembling them into a single, larger packet, which it then either = drops=20 because it is larget than the MTU of eth1, or it passes a large packet = (in this=20 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=20 packet.

I am = seeing this=20 behaviour with any IP packets, not just ICMP. The result is that = anything which=20 has a large-ish payload is being dropped after it leaves the=20 bridge.

The = question is,=20 then: How do I stop the bridge from reassembling fragmented=20 packets?

Regards,
&nbs= p; =20 Leigh

Leigh Sharpe
Network Systems = Engineer
Pacific=20 Wireless
Ph +61 3 9584 8966
Mob 0408 009 502

Helpdesk 1300 300 616
email lsharpe@pacificwi= reless.com.au
web=20 www.pacificwireless.= com.au

------_=_NextPart_001_01C8A8C2.5BAA3D60-- From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Sun, 27 Apr 2008 22:35:37 -0700 From: Stephen Hemminger Message-ID: <20080427223537.74cd0f7f@extreme> In-Reply-To: <96CF49BD8B56384395D698BA99007FA32FA1E7@exchange.pacwire.local> References: <96CF49BD8B56384395D698BA99007FA32FA1E7@exchange.pacwire.local> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [Bridge] Preventing packet reassembly List-Id: Linux Ethernet Bridging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Leigh Sharpe Cc: bridge@lists.linux-foundation.org On Mon, 28 Apr 2008 09:56:49 +1000 "Leigh Sharpe" 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. From mboxrd@z Thu Jan 1 00:00:00 1970 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 28 Apr 2008 17:28:16 +1000 Message-ID: <96CF49BD8B56384395D698BA99007FA32FA1E8@exchange.pacwire.local> From: "Leigh Sharpe" Subject: Re: [Bridge] Preventing packet reassembly List-Id: Linux Ethernet Bridging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stephen Hemminger Cc: bridge@lists.linux-foundation.org =20 > 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. =20 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]=20 Sent: Monday, 28 April 2008 3:36 PM To: Leigh Sharpe Cc: bridge@lists.linux-foundation.org Subject: Re: [Bridge] Preventing packet reassembly > =20 > =20 > 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. From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Fri, 2 May 2008 12:24:27 -0700 From: Jason Lunz Message-ID: <20080502192425.GA32302@falooley.org> References: <96CF49BD8B56384395D698BA99007FA32FA1E8@exchange.pacwire.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <96CF49BD8B56384395D698BA99007FA32FA1E8@exchange.pacwire.local> Subject: Re: [Bridge] Preventing packet reassembly List-Id: Linux Ethernet Bridging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Leigh Sharpe Cc: Stephen Hemminger , bridge@lists.linux-foundation.org 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 From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <481F4D82.3000804@trash.net> Date: Mon, 05 May 2008 20:10:10 +0200 From: Patrick McHardy MIME-Version: 1.0 References: <96CF49BD8B56384395D698BA99007FA32FA1E8@exchange.pacwire.local> In-Reply-To: <96CF49BD8B56384395D698BA99007FA32FA1E8@exchange.pacwire.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Bridge] Preventing packet reassembly List-Id: Linux Ethernet Bridging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Leigh Sharpe Cc: Stephen Hemminger , bridge@lists.linux-foundation.org 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 -j TRACE", load the ipt_LOG module and post the output.