Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
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 at an-node06 ~]# ifconfig eth1 mtu 9000
[root at 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 at 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 at an-node07 ~]# ifconfig eth1 mtu 9000
[root at 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 at 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: digimer at 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?"