On 07/23/2011 03:30 PM, Andreas Hofmeister wrote:
On 23.07.2011 06:30, Digimer wrote:
Any way to debug this? If it looks like a DRBD bug,
I don't think so. I have DRBD running with jumbo frames on several
machines and it just work (albeit with 0.8.10).
Check you networking.
Try "ping -c1 -Mdo -s 8192 <other node>", that should tell you if you
get jumbo frames to the other side or if there is a problem on the IP
layer.
If you get something like "From <other node> icmp_seq=1 Frag needed and
DF set (mtu = <actual MTU>)", check your devices MTU and check your
routing as it is actually possible to define a MTU per route.
If you just get no answer or the response is too short, check the specs
of your network hardware. The supported size for jumbo frames varies
widely, not just between vendors but also between NIC chips from the
same vendor. In some cases, even different chips support by the same
driver differ in the maximum frame size.
Ciao
Andi
Thanks for the reply Andy.
The hardware (Intel Pro1000/CT NICs[1] and a D-Link DGS-3100-24[2]) both
support 9kb+ frames (and JFs are enabled in the switch). With the MTU on
either node's DRBD interface (eth1) set to 9000, I confirmed that JFs
worked using a method very similar to what you suggested:
node1:
====
[root@an-node06 ~]# ifconfig eth1 mtu 9000
[root@an-node06 ~]# ifconfig eth1
eth1 Link encap:Ethernet HWaddr 00:1B:21:72:9B:59
inet addr:192.168.2.76 Bcast:192.168.2.255 Mask:255.255.255.0
inet6 addr: fe80::21b:21ff:fe72:9b59/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:9000 Metric:1
RX packets:12614 errors:0 dropped:0 overruns:0 frame:0
TX packets:14197 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:15357943 (14.6 MiB) TX bytes:15483995 (14.7 MiB)
Interrupt:17 Memory:feae0000-feb00000
[root@an-node06 ~]# ping -s 8900 -c 1 an-node07.sn
PING an-node07.sn (192.168.2.77) 8900(8928) bytes of data.
8908 bytes from an-node07.sn (192.168.2.77): icmp_seq=1 ttl=64 time=0.686 ms
--- an-node07.sn ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.686/0.686/0.686/0.000 ms
====
node2:
====
[root@an-node07 ~]# ifconfig eth1 mtu 9000
[root@an-node07 ~]# ifconfig eth1
eth1 Link encap:Ethernet HWaddr 00:1B:21:72:96:F2
inet addr:192.168.2.77 Bcast:192.168.2.255 Mask:255.255.255.0
inet6 addr: fe80::21b:21ff:fe72:96f2/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:9000 Metric:1
RX packets:30593 errors:0 dropped:0 overruns:0 frame:0
TX packets:26756 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:31161397 (29.7 MiB) TX bytes:30838239 (29.4 MiB)
Interrupt:17 Memory:feae0000-feb00000
[root@an-node07 ~]# clear; tcpdump -i eth1 icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), capture size 96 bytes
15:45:10.474134 IP an-node06.sn > an-node07.sn: ICMP echo request, id
11554, seq 1, length 8908
15:45:10.475236 IP an-node07.sn > an-node06.sn: ICMP echo reply, id
11554, seq 1, length 8908
====
Just one packet used. So I know that the interfaces are properly
using 9000 byte frames. This is why I thought the problem was within
DRBD itself.
1.
http://www.intel.com/products/desktop/adapters/gigabit-ct/gigabit-ct-overview.htm
2. http://dlink.ca/products/?pid=DGS-3100-24
--
Digimer
E-Mail: digi...@alteeve.com
Freenode handle: digimer
Papers and Projects: http://alteeve.com
Node Assassin: http://nodeassassin.org
"At what point did we forget that the Space Shuttle was, essentially,
a program that strapped human beings to an explosion and tried to stab
through the sky with fire and math?"
_______________________________________________
drbd-user mailing list
drbd-user@lists.linbit.com
http://lists.linbit.com/mailman/listinfo/drbd-user
