On Tue, Sep 15, 2009 at 03:19:37PM -0700, Christopher Smith wrote: > 15:14:42.335761 arp reply 10.183.3.113 is-at 00:50:56:99:66:4a > 15:14:42.335911 IP 10.183.3.10.137 > 10.183.3.113.137: NBT UDP PACKET(137): > QUERY; POSITIVE; RESPONSE; UNICAST > 15:14:42.336130 IP 10.183.3.10.137 > 10.183.3.113.137: NBT UDP PACKET(137): > QUERY; POSITIVE; RESPONSE; UNICAST > 15:14:42.963860 IP 10.183.3.241.1122 > 10.183.3.112.104: . 3285:4745(1460) > ack 185 win 65351 > 15:14:42.963874 IP 10.183.3.241.1122 > 10.183.3.112.104: . 3285:4745(1460) > ack 185 win 65351 > 15:14:43.122349 IP 10.183.3.112.104 > 10.183.3.241.1122: . ack 4745 win 40000 > 15:14:43.122361 IP 10.183.3.241.1122 > 10.183.3.112.104: . 4745:7665(2920) > ack 185 win 65351 > 15:14:43.122373 IP 10.183.3.112 > 10.183.3.241: ICMP 10.183.3.112 unreachable > - need to frag (mtu 1500), length 556 > > > > Then it just continues with the 'need to frag' messages indefinitely. > > > I had a bit of a look around on Google and the list archives, but all the > postings I could find were referring to using LVS-TUN, not LVS-DR. > > Has anyone seen this problem before ? I'm assuming it has something to > do with the larger data transfers of the DICOM association needing > packets to fragment, but the smaller HTTP requests do not, but surely > that shouldn't be a problem with all hosts on the same vlan ?
Hi Christopher, that is somewhat odd. Just to confirm that we are reading the dump the same way, What seems to be happening is that the client (10.183.3.241) sends two 1460+40=1500 byte packets and then decides to send a 2920+40=2960 byte packet. At that point 10.183.3.112 (which could be the linux-director or the real-server, it isn't clear because the mac address isn't shown in the dump) sends an ICMP message that the client either doesn't see or ignores. >From that reading I tend to think that the best place to investigate things at this stage would be on the client. * Does it see the ICMP message? * What is its MTU? It would also be interesting to know if it is the linux-director or the real-server that is sending the ICMP, I assume the former. It should be easy enough to tell by running tcpdump with the -e flag to include the MAC address in the log of each packet. As for why HTTP works. I think your analysis is correct. Its quite likely that the client never sends large amounts of data using HTTP. All such packets in your dump appear to be 0+40=40 bytes long. Though weather large data would be correctly segmented or fragmented, or not is another question. _______________________________________________ Please read the documentation before posting - it's available at: http://www.linuxvirtualserver.org/ LinuxVirtualServer.org mailing list - [email protected] Send requests to [email protected] or go to http://lists.graemef.net/mailman/listinfo/lvs-users
