[ntp:questions] Question on "calldelay"
uwe_klein_habertwedt at t-online.de
Fri May 4 22:01:39 UTC 2007
thanks for your reply,
Harlan Stenn wrote:
>>>>In article <cv6rg4-68s.ln1 at klein-habertwedt.de>, Uwe Klein <uwe_klein_habertwedt at t-online.de> writes:
> Uwe> Hi, I have tried using calldelay 15 server $myserver burst prefer
> Uwe> .........
> I gotta wonder if 'burst' is really needed.
my previous and ailing setup was without calldelay
and "burst" was assumed to kick open the door.
this got me delays of between 400 and 4000ms
even no reach on occasion in the statistics.
currently the local ntpd is switching between
the remote upstream server and the local clock.
The think that irks me is ntpd at version 4.0.??
had been running in a previous and similar setup
for a couple of years without any hitch.
The thing that makes this difficult is the pair
of cisco boxen _and_ my linux instrumentation box
have changend in the same interval .
first the local cisco interface died unexpectedly
in august 06 ( and was replaced in february 07,
in the meantime i had rigged a connection from
the linux box via ISDN raw IP to my home network.
christmas eve 06 the linux instrumentation box
died of smashed platters and was replaced with
a brand new box ( AM2-86_64 SuSE 10.2 ntpd 4.2.2p4-6 )
due to some errors in the cisco setup the ISDN line
was up continuously masking the errors that emerge now.
The cisco boxes are managed not by me but
by the sysadmin of my customer.
> I was initially wondering if $myserver was an IP or a name, but...
> Uwe> to (pre)start up my notorious ISDN dialup connection. i have problems
> Uwe> with that.
> Uwe> in my (tcpdump) logs i can see
> Uwe> the initial ntpv4 client packet
> this implies you are able to turn the situation into an IP.
the host name has been resolved into an IP , the
system and ntpd have been running for some time
the host for 78 days currently ntpd for ~18hours.
during daylight hours there is regular traffic
and the ISDN connection has a good chance of being up
on any exchange with the upstream server.
> Uwe> the syslog info from the ciscobox
> Uwe> that indicates the dialup being connected and then nothing. the
> Uwe> initial packet seems to be dropped ( bahh, world loss )
> Uwe> dialup is taken down after timeout ( ~75 seconds )
> Uwe> if the connection is already up the initial ntpv4 client packet answer
> Uwe> from server delay 15 seconds 3 pairs of query answer packets.
> Uwe> My question: is the current poll aborted when the first packet is not
> Uwe> answered?
> I don't *believe* so...
> I do wonder about the "interface state change" and if something might be
> going on there.
There is no interface state change on the box running ntpd.
default route is the cisco box and it dials when it gets
packets dumped at its doormat.
my current guess is that
A: the ciscobox drops the ringing up paket
B: ntpd aborts on no reply of the initial packet
sent for the calldelay feature
> Perhaps Frank or Danny might have more to say.
OK, lets see.
More information about the questions