7

Due to this problem, I'm going to sniff some packets on the MySQL server backend to see what happens:

# tcpdump -vv -s0 -c 100 -i bond0 tcp port 3306 and host 192.168.3.87 -w /home/quanta/3.87_aborted.pcap

As you can see, I set snaplen to 0, but still get the message "Packet size limited during capture":

MySQL Protocol
    Packet Length: 579
    Packet Number: 96
    text: 336
    text: 1004352
    text: 147619
    text: 336
[Packet size limited during capture: MySQL truncated]

The offload settings on my interface:

# ethtool -k bond0
Offload parameters for bond0:
Cannot get device rx csum settings: Operation not supported
rx-checksumming: off
tx-checksumming: on
scatter-gather: on
tcp segmentation offload: on
udp fragmentation offload: off
generic segmentation offload: off
generic-receive-offload: off

/proc/net/bonding/bond0:

Ethernet Channel Bonding Driver: v3.4.0-1 (October 7, 2008)

Bonding Mode: adaptive load balancing
Primary Slave: None
Currently Active Slave: eth1
MII Status: up
MII Polling Interval (ms): 100
Up Delay (ms): 0
Down Delay (ms): 0

Slave Interface: eth1
MII Status: up
Speed: 1000 Mbps
Duplex: full
Link Failure Count: 0
Permanent HW addr: 00:30:48:c3:20:be

Reply to @HeatfanJohn:

# ethtool -k eth1
Offload parameters for eth1:
Cannot get device udp large send offload settings: Operation not supported
rx-checksumming: on
tx-checksumming: on
scatter-gather: on
tcp segmentation offload: on
udp fragmentation offload: off
generic segmentation offload: off
generic-receive-offload: on

Reply to @Doon:

bond0     UP BROADCAST RUNNING MASTER MULTICAST  MTU:1500  Metric:1

Sniffing with -s 1500 also shows:

 41  11.371783  192.168.6.7 -> 192.168.3.87 MySQL Response OK
 42  11.371974 192.168.3.87 -> 192.168.6.7  MySQL Request Ping
 43  11.371996  192.168.6.7 -> 192.168.3.87 MySQL Response OK
 44  11.378562 192.168.3.87 -> 192.168.6.7  MySQL Request Query
 45  11.379604  192.168.6.7 -> 192.168.3.87 MySQL Response
 46  11.402431 192.168.3.87 -> 192.168.6.7  MySQL Request Query
 47  11.402992  192.168.6.7 -> 192.168.3.87 MySQL Response[Packet size limited during capture]
Community
  • 1
quanta
  • 50,327
  • 19
  • 152
  • 213
  • What bond mode are you using? – Mike Pennington Aug 02 '12 at 07:05
  • adaptive load balancing. updated my question. – quanta Aug 02 '12 at 07:13
  • 1
    Do you have TCP offload enabled? I have seen very large TCP packets returned to WinPCAP when TCP offload is enabled. – HeatfanJohn Aug 06 '12 at 01:41
  • Yes, TCP offload was enabled on `eth1` slave (I think by default). – quanta Aug 06 '12 at 03:25
  • What is MTU? Have you tried doing a snaplen of MTU size? -s0 normally set it back to default length – Doon Aug 06 '12 at 03:56
  • MTU=1500. I've tried to set snaplen to MTU size but still get that message. – quanta Aug 10 '12 at 03:47
  • 3
    I would try this with segmentation offload disabled. With it enabled, it's very possible that tcpdump able to get what it is expecting. – mcauth Aug 11 '12 at 12:25
  • I'm very unfamilar with bonding, but from what I can read I suspect that both of your issues might be due to jumbo frames. I think you can disable them by forcing the MTU to 1500 (http://pthree.org/2012/02/26/setup-network-interfaces-in-debian/). – Tyler Szabo Aug 12 '12 at 14:18

2 Answers2

1

Something about TCP offloading I fully comply with: http://www.linuxfoundation.org/collaborate/workgroups/networking/toe

Michuelnik
  • 3,260
  • 3
  • 18
  • 24
1

Here it is in answer form, with correct wording :) I would try this with segmentation offload disabled. With it enabled, it's very possible that tcpdump isn't able to get what it is expecting.

--Matt

mcauth
  • 420
  • 2
  • 5