|
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 - lvs-users@xxxxxxxxxxxxxxxxxxxxxx
Send requests to lvs-users-request@xxxxxxxxxxxxxxxxxxxxxx
or go to http://lists.graemef.net/mailman/listinfo/lvs-users
|
