2.6.35.11 bridge drops fragmented packets

Hello,

We've got a problem with kernel 2.6.35.11 as it does not forward
fragmented packets on a bridge.
I've seen this thread
http://lkml.indiana.edu/hypermail/linux/kernel/0604.0/0201.html and I
thought to email you.

The command "echo 0 > /proc/sys/net/bridge/bridge-nf-call-iptables"
fixes the problem.

The config from the kernel is attached.
The network configuration is as follows:
cisco, interace in mode trunk with allowed vlan 1501,299 -> linux ->
cisco, interface in mode trunk with allowed vlan 1501

The MTU on cisco and on linux interfaces is set to 1500.
Packets with size 1500 and no fragments are forwarded succesfully,
packets with size 1500 and fragments are not forwaded.
On linux it's a bond comprised of eth1.1501 and eth0.1501.
root@shaper_b2b_bucuresti:~# brctl show
bridge name     bridge id               STP enabled     interfaces
br1501          8000.0015170ae7b8       no              eth0.1501
                                                        eth1.1501
I cand see the fragmented packets arriving on eth0 and eth0.1501 but I
don't see them leaving on eth1 or eth1.1501.

Andrei

Le jeudi 11 août 2011 à 15:43 +0300, Andrei Popa a écrit :
> Hello,
> 
> We've got a problem with kernel 2.6.35.11 as it does not forward
> fragmented packets on a bridge.
> I've seen this thread
> http://lkml.indiana.edu/hypermail/linux/kernel/0604.0/0201.html and I
> thought to email you.
> 
> The command "echo 0 > /proc/sys/net/bridge/bridge-nf-call-iptables"
> fixes the problem.
> 
> The config from the kernel is attached.
> The network configuration is as follows:
> cisco, interace in mode trunk with allowed vlan 1501,299 -> linux ->
> cisco, interface in mode trunk with allowed vlan 1501
> 
> The MTU on cisco and on linux interfaces is set to 1500.
> Packets with size 1500 and no fragments are forwarded succesfully,
> packets with size 1500 and fragments are not forwaded.
> On linux it's a bond comprised of eth1.1501 and eth0.1501.
> root@shaper_b2b_bucuresti:~# brctl show
> bridge name     bridge id               STP enabled     interfaces
> br1501          8000.0015170ae7b8       no              eth0.1501
>                                                         eth1.1501
> I cand see the fragmented packets arriving on eth0 and eth0.1501 but I
> don't see them leaving on eth1 or eth1.1501.
> 
> Andrei
> 

Could you give us output of 'netstat -s' to check if IP defrag drops
some packets ?



--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

On Thu, 2011-08-11 at 15:39 +0200, Eric Dumazet wrote: 
> Le jeudi 11 août 2011 à 15:43 +0300, Andrei Popa a écrit :
> > Hello,
> > 
> > We've got a problem with kernel 2.6.35.11 as it does not forward
> > fragmented packets on a bridge.
> > I've seen this thread
> > http://lkml.indiana.edu/hypermail/linux/kernel/0604.0/0201.html and I
> > thought to email you.
> > 
> > The command "echo 0 > /proc/sys/net/bridge/bridge-nf-call-iptables"
> > fixes the problem.
> > 
> > The config from the kernel is attached.
> > The network configuration is as follows:
> > cisco, interace in mode trunk with allowed vlan 1501,299 -> linux ->
> > cisco, interface in mode trunk with allowed vlan 1501
> > 
> > The MTU on cisco and on linux interfaces is set to 1500.
> > Packets with size 1500 and no fragments are forwarded succesfully,
> > packets with size 1500 and fragments are not forwaded.
> > On linux it's a bond comprised of eth1.1501 and eth0.1501.
> > root@shaper_b2b_bucuresti:~# brctl show
> > bridge name     bridge id               STP enabled     interfaces
> > br1501          8000.0015170ae7b8       no              eth0.1501
> >                                                         eth1.1501
> > I cand see the fragmented packets arriving on eth0 and eth0.1501 but I
> > don't see them leaving on eth1 or eth1.1501.
> > 
> > Andrei
> > 
> 
> Could you give us output of 'netstat -s' to check if IP defrag drops
> some packets ?
root@shaper_b2b_bucuresti:~# echo 1
> /proc/sys/net/bridge/bridge-nf-call-iptables

On a server behind the shaper:

nl2 ~ # ping -s 65000 lg.telia.net
PING juniperlg1-sn4.m-sp.skanova.net (81.228.10.74) 65000(65028) bytes
of data.
^C
--- juniperlg1-sn4.m-sp.skanova.net ping statistics ---
9 packets transmitted, 0 received, 100% packet loss, time 8021ms

nl2 ~ # 


root@shaper_b2b_bucuresti:~# netstat -s
Ip:
    12783151 total packets received
    10960 with invalid addresses
    0 forwarded
    0 incoming packets discarded
    2738144 incoming packets delivered
    2224918 requests sent out
    20 dropped because of missing route
    2380122 fragments dropped after timeout
    1502102174 reassemblies required
    662730406 packets reassembled ok
    3060985 packet reassembles failed
    5 fragments received ok
    10 fragments created
Icmp:
    352 ICMP messages received
    0 input ICMP message failed.
    ICMP input histogram:
        destination unreachable: 327
        echo requests: 9
        echo replies: 16
    340 ICMP messages sent
    0 ICMP messages failed
    ICMP output histogram:
        destination unreachable: 304
        echo request: 27
        echo replies: 9
IcmpMsg:
        InType0: 16
        InType3: 327
        InType8: 9
        OutType0: 9
        OutType3: 304
        OutType8: 27
Tcp:
    193 active connections openings
    14926 passive connection openings
    8 failed connection attempts
    17 connection resets received
    2 connections established
    1603905 segments received
    1248972 segments send out
    1140 segments retransmited
    0 bad segments received.
    19 resets sent
Udp:
    991041 packets received
    2 packets to unknown port received.
    0 packet receive errors
    991110 packets sent
UdpLite:
TcpExt:
    8 resets received for embryonic SYN_RECV sockets
    16113 delayed acks sent
    1 delayed acks further delayed because of locked socket
    Quick ack mode was activated 46 times
    27639 packets directly queued to recvmsg prequeue.
    1894178 bytes directly in process context from backlog
    18824 bytes directly received in process context from prequeue
    380110 packet headers predicted
    1356 packets header predicted and directly queued to user
    160586 acknowledgments not containing data payload received
    730360 predicted acknowledgments
    10 times recovered from packet loss by selective acknowledgements
    Detected reordering 7 times using time stamp
    4 congestion windows fully recovered without slow start
    9 congestion windows partially recovered using Hoe heuristic
    4 congestion windows recovered without slow start by DSACK
    16 fast retransmits
    7 forward retransmits
    21 retransmits in slow start
    229 other TCP timeouts
    46 DSACKs sent for old packets
    24 DSACKs received
    13 connections reset due to early user close
    4 connections aborted due to timeout
    TCPDSACKIgnoredOld: 12
    TCPDSACKIgnoredNoUndo: 3
    TCPSackMerged: 2
    TCPSackShiftFallback: 30
IpExt:
    InMcastPkts: 12981
    InBcastPkts: 129863
    InOctets: 1509979125
    OutOctets: 551230551
    InMcastOctets: 363468
    InBcastOctets: 8832164




--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Le jeudi 11 août 2011 à 16:44 +0300, Andrei Popa a écrit :
> On Thu, 2011-08-11 at 15:39 +0200, Eric Dumazet wrote: 
> > Le jeudi 11 août 2011 à 15:43 +0300, Andrei Popa a écrit :
> > > Hello,
> > > 
> > > We've got a problem with kernel 2.6.35.11 as it does not forward
> > > fragmented packets on a bridge.
> > > I've seen this thread
> > > http://lkml.indiana.edu/hypermail/linux/kernel/0604.0/0201.html and I
> > > thought to email you.
> > > 
> > > The command "echo 0 > /proc/sys/net/bridge/bridge-nf-call-iptables"
> > > fixes the problem.
> > > 
> > > The config from the kernel is attached.
> > > The network configuration is as follows:
> > > cisco, interace in mode trunk with allowed vlan 1501,299 -> linux ->
> > > cisco, interface in mode trunk with allowed vlan 1501
> > > 
> > > The MTU on cisco and on linux interfaces is set to 1500.
> > > Packets with size 1500 and no fragments are forwarded succesfully,
> > > packets with size 1500 and fragments are not forwaded.
> > > On linux it's a bond comprised of eth1.1501 and eth0.1501.
> > > root@shaper_b2b_bucuresti:~# brctl show
> > > bridge name     bridge id               STP enabled     interfaces
> > > br1501          8000.0015170ae7b8       no              eth0.1501
> > >                                                         eth1.1501
> > > I cand see the fragmented packets arriving on eth0 and eth0.1501 but I
> > > don't see them leaving on eth1 or eth1.1501.
> > > 
> > > Andrei
> > > 
> > 
> > Could you give us output of 'netstat -s' to check if IP defrag drops
> > some packets ?
> root@shaper_b2b_bucuresti:~# echo 1
> > /proc/sys/net/bridge/bridge-nf-call-iptables
> 
> On a server behind the shaper:
> 
> nl2 ~ # ping -s 65000 lg.telia.net
> PING juniperlg1-sn4.m-sp.skanova.net (81.228.10.74) 65000(65028) bytes
> of data.
> ^C
> --- 

65000 bytes means 43 frames, and your network seems a bit busy.

If _one_ frame is lost (becasue of shaping for example), IP
fragmentation in bridge will fail -> all frames are discarded.

Could you try with "-s 2000" ?

I could not reproduce your problem on my dev machine (admitidly using a
more recent kernel)




--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html