Amanda-Users

Re: planner timeouts

2005-09-08 05:26:36
Subject: Re: planner timeouts
From: Paul Bijnens <paul.bijnens AT xplanation DOT com>
To: Charles Sprickman <spork AT bway DOT net>
Date: Thu, 08 Sep 2005 11:09:58 +0200
Charles Sprickman wrote:
On Tue, 6 Sep 2005, Paul Bijnens wrote:

http://bway.net/~spork/amanda-tcpdump.txt

You'll note that the "frags" thing is still set, but if you compare what the server sent to what the client received, it is identical.


I believe you have a UDP fragementation network problem somewhere
inbetween the two hosts, or maybe the devel2 host itself.

Compare these two lines (first: view on devel2, second: view on h13):

00:07:40.444231 devel2.945 > h13.amanda: udp 1465 (ttl 64, id 45642, len 1493) 00:07:40.484232 devel2.945 > h13.amanda: udp 1465 (frag 45642:1472@0+) (ttl 51, len 1492)

The host devel2, sends a packet, claiming length 1493 bytes.
(1465 real payload + 28 bytes UDP packet header = 1493 bytes).
It also seems to be split over many UDP packets, but the following
packet is never seen in the trace. THe packet that is shown is only 1486 bytes long. There should be a second packet with the rest
of 7 bytes, but that is missing from the trace.
From the content of the first packet, that second packet should
contain "index"+newline, indeed 7 bytes.

The host h13, is apparently 13 hops away from the client (ttl 64-51).
That's pretty strange, when you say they are connected to the same
switch.  Even more strange is that the reply packets travel 15 hops
(ttl 64-49).  But I'm not the specialist here.

The server packet however now says the total length is 1492, but the
payload length is still 1465.  Strange because the 28 byte UDP header
seems be shortened by 1 byte? That could be when the UDP checksum, which
is optional, is removed from the header.  Some device inbetween removed
the checksum byte.  Must be a real firewall or layer 3 switch, changing
packets it transmits.

Anyway, the trailing 7 byte packet never got sent.

I would take a look at the UDP configuration of that client, that seems
to have trouble with splitting large UDP datagrams.

Some OS-es need some twiggling with parameters to tune this.

As workaround, you could try to reduce the UDP packet by e.g.
leaving out some DLE's or omitting "compress-fast" from the options, or
anything that shortens the string and makes the complete datagram fit
in one packet.


I'm totally stumped here. We had another server just start doing the same thing the other day. They are all on the same subnet/lan/switch, two don't work, the remaining 10 or so do.

Verify if it is indeed the size of the UDP packet sent.
You mean the two that don't work are on the same subnet/lan/switch.
Or are all the server and client on the same subnet/lan/switch?

At least the devel2 machine is not sending the continuation packet,
and the subnet/switch/lan seems to be "strange" too.


--
Paul Bijnens, Xplanation                            Tel  +32 16 397.511
Technologielaan 21 bus 2, B-3001 Leuven, BELGIUM    Fax  +32 16 397.512
http://www.xplanation.com/          email:  Paul.Bijnens AT xplanation DOT com
***********************************************************************
* I think I've got the hang of it now:  exit, ^D, ^C, ^\, ^Z, ^Q, ^^, *
* F6, quit, ZZ, :q, :q!, M-Z, ^X^C, logoff, logout, close, bye, /bye, *
* stop, end, F3, ~., ^]c, +++ ATH, disconnect, halt,  abort,  hangup, *
* PF4, F20, ^X^X, :D::D, KJOB, F14-f-e, F8-e,  kill -1 $$,  shutdown, *
* init 0, kill -9 1, Alt-F4, Ctrl-Alt-Del, AltGr-NumLock, Stop-A, ... *
* ...  "Are you sure?"  ...   YES   ...   Phew ...   I'm out          *
***********************************************************************



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