<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#ffffff" text="#000000">
    On 23.07.2011 21:54, Digimer wrote:
    <blockquote cite="mid:4E2B26E9.8010307@alteeve.com" type="cite"><br>
      Thanks for the reply Andy.
      <br>
      <br>
      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:
      <br>
        <span style="white-space: pre;">&gt; <br>
          &gt; --- an-node07.sn ping statistics --- 1 packets
          transmitted, 1<br>
          &gt; received, 0% packet loss, time 0ms rtt min/avg/max/mdev =<br>
          &gt; 0.686/0.686/0.686/0.000 ms ====<br>
          &gt; <br>
          &gt; node2: ==== [root@an-node07 ~]# ifconfig eth1 mtu 9000 <br>
          &gt; [root@an-node07 ~]# ifconfig eth1 eth1 Link
          encap:Ethernet<br>
          &gt; HWaddr 00:1B:21:72:96:F2 inet addr:192.168.2.77
          Bcast:192.168.2.255<br>
          &gt; Mask:255.255.255.0 inet6 addr:
          fe80::21b:21ff:fe72:96f2/64<br>
          &gt; Scope:Link UP BROADCAST RUNNING MULTICAST MTU:9000
          Metric:1 RX<br>
          &gt; packets:30593 errors:0 dropped:0 overruns:0 frame:0 TX
          packets:26756<br>
          &gt; errors:0 dropped:0 overruns:0 carrier:0 collisions:0
          txqueuelen:1000 <br>
          &gt; RX bytes:31161397 (29.7 MiB) TX bytes:30838239 (29.4 MiB)
          <br>
          &gt; Interrupt:17 Memory:feae0000-feb00000</span>[root@an-node07
      ~]# clear; tcpdump -i eth1 icmp
      <br>
      tcpdump: verbose output suppressed, use -v or -vv for full
      protocol decode
      <br>
      listening on eth1, link-type EN10MB (Ethernet), capture size 96
      bytes
      <br>
      15:45:10.474134 IP an-node06.sn &gt; an-node07.sn: ICMP echo
      request, id 11554, seq 1, length 8908
      <br>
      15:45:10.475236 IP an-node07.sn &gt; an-node06.sn: ICMP echo
      reply, id 11554, seq 1, length 8908
      <br>
      ====
      <br>
    </blockquote>
    <br>
    Ah. The '-Mdo' argument to ping just spares you the 'tcpdump'.<br>
    <br>
    <blockquote cite="mid:4E2B26E9.8010307@alteeve.com" type="cite">1.
<a class="moz-txt-link-freetext" href="http://www.intel.com/products/desktop/adapters/gigabit-ct/gigabit-ct-overview.htm">http://www.intel.com/products/desktop/adapters/gigabit-ct/gigabit-ct-overview.htm</a><br>
      2. <a class="moz-txt-link-freetext" href="http://dlink.ca/products/?pid=DGS-3100-24">http://dlink.ca/products/?pid=DGS-3100-24</a>
      <br>
    </blockquote>
    <br>
    Mhh, I have a peer of nodes - actually with DRBD 0.8.11, not 0.8.10
    as I thought - and Intel 82571EB NICs working rather well, but then
    these are connected back-to-back.<br>
    <br>
    We had some bad experience with a D-Link switch in the past. Don't
    remember the model, but we eventually scraped it because of the
    troubles.<br>
    <br>
    If you use pacemaker+corosync, you may want to check the "netmtu"
    setting in "corosync.conf". That should not affect DRBD though.<br>
    <br>
    Ciao<br>
    &nbsp; Andi<br>
  </body>
</html>