Re: [lvs-users] Apparent MTU problem using LVS-DR and Windows 2003 RealS

To: Christopher Smith <csmith@xxxxxxxxxxxxxxxx>
Subject: Re: [lvs-users] Apparent MTU problem using LVS-DR and Windows 2003 RealServers
Cc: lvs-users@xxxxxxxxxxxxxxxxxxxxxx
From: Simon Horman <horms@xxxxxxxxxxxx>
Date: Wed, 16 Sep 2009 11:27:11 +1000
On Tue, Sep 15, 2009 at 03:19:37PM -0700, Christopher Smith wrote:
> 15:14:42.335761 arp reply is-at 00:50:56:99:66:4a
> 15:14:42.335911 IP > NBT UDP PACKET(137): 
> 15:14:42.336130 IP > NBT UDP PACKET(137): 
> 15:14:42.963860 IP > . 3285:4745(1460) 
> ack 185 win 65351
> 15:14:42.963874 IP > . 3285:4745(1460) 
> ack 185 win 65351
> 15:14:43.122349 IP > . ack 4745 win 40000
> 15:14:43.122361 IP > . 4745:7665(2920) 
> ack 185 win 65351
> 15:14:43.122373 IP > ICMP 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 (
sends two 1460+40=1500 byte packets and then decides to send a
2920+40=2960 byte packet. At that point (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: mailing list - lvs-users@xxxxxxxxxxxxxxxxxxxxxx
Send requests to lvs-users-request@xxxxxxxxxxxxxxxxxxxxxx
or go to

<Prev in Thread] Current Thread [Next in Thread>