ntp szerver szinkronizációs hiba

Web, mail, IRC, IM, hálózatok

Üdv!

Szeretnék egy ntp szervert felállítani, hogy a többi kliens és szerver ehhez szinkronizáljon. Mellesleg ez a gép a mysql alapú syslog-ng szerverünk is, így nagyon jó lenne ha minden gép órája pontos lenne, már csak a log miatt is.

Szóval, a hiba az, hogy nem szinkroznizál a megadott szerverekhez az én ntp szerverem: 

# ntpq -p 148.6.0.1
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*cuckoo.kfki.hu  .GPS.            1 u 1150 1024  377    5.680   -0.136   0.218
-ntp0.nl.uu.net  .GPS.            1 u  595 1024  377   67.150   11.502  14.805
+ntp1-rz.rrze.un .DCFp.           1 u 1164 1024  377   22.790   -2.791   0.061
+ntps1-1.cs.tu-b .PPS.            1 u 1170 1024  377   33.761   -2.639   0.350
-ntp2.inrim.it   .UTCI.           1 u 1118 1024  377   40.808    3.916   3.481
 NTP.MCAST.NET   0.0.0.0         16 u    -   64    0    0.000    0.000 4000.00
# ntpq -p localhost
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 ntp.t-online.hu .INIT.          16 u    - 1024    0    0.000    0.000 4000.00
 crush.brunom.ne .INIT.          16 u    - 1024    0    0.000    0.000 4000.00
 ntp.checon.net  .INIT.          16 u    - 1024    0    0.000    0.000 4000.00
*LOCAL(0)        LOCAL(0)        13 l   42   64  377    0.000    0.000   0.001

A többi gép az én szerveremhez kiválóan szinkronizál, és így minden gép órája egyformán rosszul, az ntp szerverem hw clock-ja szerint jár, ami nagyon durván pontatlan. Mi okozhatja, hogy nem tud szinkronizálni kifelé?

Ja, és nem az a hiba, hogy türelmetlen vagyok, és nem várom meg a szinkroznizációt, mert napok óta a INIT fázisban van.

Petya

  • 6028 megtekintés

( muszi v | 2007. 02. 10., szo – 12:12 )

Probald ugy, hogy csak az IPv4-et engedelyezed: 

ntpdate -4 148.6.0.1

illetve az ntp.conf-ban: 

server -4 148.6.0.1

Üdv!

Nekem most így van beállítva: 


driftfile /var/lib/ntp/ntp.drift
statsdir /var/log/ntpstats/

statistics loopstats peerstats clockstats
filegen loopstats file loopstats type day enable
filegen peerstats file peerstats type day enable
filegen clockstats file clockstats type day enable

server -4 hu.pool.ntp.org
server -4 europe.pool.ntp.org
server -4 pool.ntp.org

server -4 127.127.1.0
fudge 127.127.1.0 stratum 13

restrict default kod notrap nomodify nopeer noquery

restrict -4 127.0.0.1 nomodify

Próbálkozom így: 

server -4 hu.pool.ntp.org burst iburst
server -4 europe.pool.ntp.org burst iburst
server -4 pool.ntp.org burst iburst

Egyelőre semmi, ugyanúgy a LOCAL-hoz szinkronizál, syslog: 

2007-02-10 14:18:02	ntpd[27005]: kernel time sync enabled 0001
2007-02-10 14:16:56	ntpd[27005]: synchronized to LOCAL(0), stratum 13
2007-02-10 14:16:56	ntpd[27005]: kernel time sync disabled 0041

update: 


# tcpdump udp port 123

itt látszanak a próbálkozások kifelé, és az is, hogy a többi gép szinkronizál a szerveremhez, és az válaszol is nekik rendesen. Kintről viszont nem jön válasz..

Kifelé ilyen sorok vannak: 


14:25:24.756199 IP ntpserver.company.tld.ntp > tilia.zsx.hu.ntp: NTPv4 client, strat 0, poll 6, prec -20

Petya

Most nézem, hogy mi is történik valójában? 

# tcpdump -vv udp port 123
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
15:30:02.335415 IP (tos 0x10, ttl  64, id 0, offset 0, flags [DF], length: 76) gepneve.company.tld.ntp > 
tilia.zsx.hu.ntp: [bad udp cksum bf22!] NTPv4 client, strat 0, poll 6, prec -20 dist 0.000000, disp 0.000061, ref 
unspec)@0.000000000 orig 0.000000000 rec 0.000000000 xmt 3380106602.335364013 (2007/02/10 15:30:02)

Mi ronthatja el a checksum-ot, és miért csak kifelé? Elképelhető, hogy valamelyik router szűri meg a csomagokat? Hogyan lehetne ez letesztelni?

szerk:

Nem adom fel... 

# nmap -sU -v 212.92.16.193 -p 123

Starting nmap 3.81 ( http://www.insecure.org/nmap/ ) at 2007-02-10 19:04 CET
Initiating UDP Scan against tilia.zsx.hu (212.92.16.193) [1 port] at 19:04
The UDP Scan took 0.21s to scan 1 total ports.
Host tilia.zsx.hu (212.92.16.193) appears to be up ... good.
Interesting ports on tilia.zsx.hu (212.92.16.193):
PORT    STATE         SERVICE
123/udp open|filtered ntp

Nmap finished: 1 IP address (1 host up) scanned in 0.351 seconds
               Raw packets sent: 4 (124B) | Rcvd: 1 (46B)

Ezek szerint tudok csatlakozni az adott gép 123-as portjához. De akkor miért nem szinkronizál?

Petya

A kimenő "bad checksumos" csomag valószínűleg normális jelenség (*BSD, checksum offloading); A tcpdump még azelőtt kapja el hogy lenne a checksum helyén valami.

Legközelebb válasz előtt megnézem a post dátumát és végigolvasom a topikot. Legközelebb válasz előtt megnézem a post dátumát és végigolvasom a topikot. Legközelebb válasz előtt megnézem a post dátumát és végigolvasom a topikot. Legközelebb válasz előtt megnézem a post dátumát és végigolvasom a topikot. Legközelebb válasz előtt megnézem a post dátumát és végigolvasom a topikot. Legközelebb válasz előtt megnézem a post dátumát és végigolvasom a topikot. Legközelebb válasz előtt megnézem a post dátumát és végigolvasom a topikot. Legközelebb válasz előtt megnézem a post dátumát és végigolvasom a topikot. Legközelebb válasz előtt megnézem a post dátumát és végigolvasom a topikot. Legközelebb válasz előtt megnézem a post dátumát és végigolvasom a topikot. Legközelebb válasz előtt megnézem a post dátumát és végigolvasom a topikot. Legközelebb válasz előtt megnézem a post dátumát és végigolvasom a topikot. Legközelebb válasz előtt megnézem a post dátumát és végigolvasom a topikot. Legközelebb válasz előtt megnézem a post dátumát és végigolvasom a topikot. ...

( colos | 2007. 02. 10., szo – 12:26 )

ha a hardware orad szinkronizalas nelkul pontatlan akkor csereld ki a cmos elemet. nalunk ez rendszeresen okoz problemat. a beszerzett gepek egyik hutobordaja futi az elemet es igy tonkremegy elallitodik a datum es az ora cmos defaultra ami szetcseszi a lokalis adatbazis adatait. szerencsere ez meg gari idon belul kiderult
--
Tuddd gi: A Dörrög Zuldán, te hűjje!
(Rejtő Jenő: Az elátkozott part)

( cstamas | 2007. 02. 10., szo – 20:02 )

Ne szívasd magad. Rakj fel openntpd -t és felejtsd el a problémákat!

Üdv!

Felraktam az openntpd-t, de ez nem változtat azon, hogy még az ntpdate sem tud szinkronizálni a különben jó szerverhez. 


# ntpdate tilia.zsx.hu
11 Feb 16:50:38 ntpdate[17851]: no server suitable for synchronization found

Mellesleg ugyanez a hibaüzenet akkor is, amikor egy másik gépet próbálok a futó openntpd-hez szinkronizálni ntpdate-tel.

Közben: 


# tcpdump -vv udp port 123
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
16:50:34.893834 IP (tos 0x0, ttl  64, id 0, offset 0, flags [DF], length: 76) gepneve.company.hu.ntp >
tilia.zsx.hu.ntp: [bad udp cksum 7a33!] NTPv4 client, strat 0, poll 4, prec -6 dist 1.000000, disp 1.000000,
 ref (unspec)@0.000000000 orig 0.000000000 rec 0.000000000 xmt 3380197834.893768012 (2007/02/11 16:50:34)
16:50:35.897644 IP (tos 0x0, ttl  64, id 0, offset 0, flags [DF], length: 76) gepneve.company.hu.ntp >
tilia.zsx.hu.ntp: [bad udp cksum 32a7!] NTPv4 client, strat 0, poll 4, prec -6 dist 1.000000, disp 1.000000,
 ref (unspec)@0.000000000 orig 0.000000000 rec 0.000000000 xmt 3380197835.897590994 (2007/02/11 16:50:35)
16:50:36.901495 IP (tos 0x0, ttl  64, id 0, offset 0, flags [DF], length: 76) gepneve.company.hu.ntp >
tilia.zsx.hu.ntp: [bad udp cksum b466!] NTPv4 client, strat 0, poll 4, prec -6 dist 1.000000, disp 1.000000,
 ref (unspec)@0.000000000 orig 0.000000000 rec 0.000000000 xmt 3380197836.901440024 (2007/02/11 16:50:36)
16:50:37.905323 IP (tos 0x0, ttl  64, id 0, offset 0, flags [DF], length: 76) gepneve.company.hu.ntp >
tilia.zsx.hu.ntp: [bad udp cksum a732!] NTPv4 client, strat 0, poll 4, prec -6 dist 1.000000, disp 1.000000,
 ref (unspec)@0.000000000 orig 0.000000000 rec 0.000000000 xmt 3380197837.905273020 (2007/02/11 16:50:37)

Van ötleted?

szerk: Ja, és van az openntpd-hez olyan parancs, mint az ntpq az ntp-hez?

update: az rdate sem működik, de itt a tcpdump sem mutat semmit. Azt vettem észre, hogy a kifelé menő csomagok hibásak, a befelé jövők viszont nem. Az openntpd-t ez nem zavarja, szépen szinkronizál. Csatlakozni továbbra sem lehet hozzá.

Petya

Valószínű, hogy a hálókártyád kezeli a checksummokat (valami offload engine a neve) és a tcpdump rossz fázisban kapja el a csomagokat, ezért találja őket hibásnak. (Ez kernel verzió függő is, lehet, hogy érdemes frissíteni, de a valódi működésen nem változtat.)

Nincs az openntpd-hez ntpq, de talán felesleges is.

Ha jól értem, akkor az openntpd szinkronizál. Mi hiányzik még, mi nem megy?
Beállítottad, hogy melyik IP-n figyeljen? (listen on ...)

Az openntpd jelzi, hogy szinkronizál, azzal nincs gond. csak az a gép egyben időt is szolgáltatna más gépeknek is, és azok nem látják. Illetve azokon a gépeken ntp kliens van, lehet, hogy ez a gond, oda is openntpd kellene?

Vannak még Mikrotik eszközök is, ezekben is van valamilyen ntp kliens, azt még nem próbáltam, de jó lenne ha azok is tudnának időt szinkronizálni, mert mind erre a szerverre küdi a logot.

Nyilván valami beállítási gond lehet, itt a konfigfile: 

listen on a.szerver.ip.cime

server 0.hu.pool.ntp.org
server 1.europe.pool.ntp.org
server 2.pool.ntp.org

Köszönöm a segítséget!

szerk: Ja, és openntpd-vel látszik, hogy a szinkronizáció során a kérésre válasz is érkezik a pool szerverektől. ntp-vel csak a kimenő kérések látszottak.

Petya

( mpathy | 2007. 03. 23., p – 10:11 )

Üdv!

Van valakinek ötlete, mi okozhatja azt, hogy egy Debian alapkonfigos csomagból feltett ntp _fél_ órával előbbre állítja az órát?

Ugyanígy telepítettem egy másik gépen (azaz apt-get install npt), és ott jól működik.

--
- Hogyan lehet tanulni? - Jól kell tudni kérdezni. - Hogyan lehet jól kérdezni? - Ahhoz sokat kell tudni...

( hrgy84 | 2007. 05. 05., szo – 14:43 )

Nem akarok újtémát nyitni, a cím úgyis ugyanez lenne.

A gond a következő:

Adott egy NTP szerver (sima ntpd) ami szonkronol a ntp.ubuntulinux.org és a time.kfki.hu szerverekkel.
Meg adottak kliensek, akik ntpdate parancssal szinkronolnának a szervertől.

A gond az, hogy a kliensek folyamatosan no suitable server hibával elhalnak.

Utánaolvasva a dolognak ennek az az oka, hogy a szerverem valamiért betonstabilan 16-os stratum-ú A doksikból az is kiderül, hogy ez automatikusan határozódik meg.

Szeretném tudni, mit tehetnék annak érdekében, hogy a szerverem kimozduljon a 16-osstratum állapotából, mert így az ntpdate kliensek képtelenek szinkronolni vele, és ha nem szinkronolnak, akkor a kerberos ideges lesz.

A kliensek külső szerverrel tudnak szinkronolni, csak ezzel a szerverrel nem.

Pls help me... 


horus:/tmp # ntpq -c readlist
assID=0 status=c074 sync_alarm, sync_unspec, 7 events, event_peer/strat_chg,
version="ntpd 4.2.2p4@1.1585-o Sun Mar  4 13:21:35 UTC 2007 (1)",
processor="i686", system="Linux/2.6.18-gentoo-r7", leap=11, stratum=16,
precision=-17, rootdelay=0.000, rootdispersion=8.715, peer=0, refid=�,
reftime=00000000.00000000  Thu, Feb  7 2036  7:28:16.000, poll=6,
clock=c9e75ca7.876e0ca8  Sat, May  5 2007 21:42:31.529, state=2,
offset=0.000, frequency=51.227, jitter=428.632, noise=0.008,
stability=0.000, tai=0

Fentebb írtam.

Az egyik a time.kfki.hu (ubul.kfki.hu névvel), a másik a ntp.ubuntulinux.org (nemtom milyen névvel).

Azt én is észrevettem, hogy az ntpd nem csinál semmit. A gép virtuális, és úgy indult, hogy valami 3 nappal volt visszább az órája mint kellett volna, de az ntp szerver nem vette észre magát. Ez mitől lehet? Lehet ez a gond? Ha a host-on befejeződik a rendszerfrissítés feldobom a ntp.conf-omat.

Hiaba irtad, attol meg nem szinkronizal... Pont azert kertem az 'ntpq -c peers'-et, mert azt is jelzi a kimenetben, hogy epp szinkronizalva van-e, vagy sem. Az ntpd egy meghatarozott idoelteres folott nem muxik. Ezt felul lehet biralni (-g), valamint arra is ra lehet venni, hogy azonnal allitsa be az orat (-x). A te esetedben ntp leallit, kezzel pl. egy 'ntpd -g -x -n' kiad, ora ellenoriz, aztan ntp elindit.



horus:/tmp # ntpq -c peers
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 fiordland.ubunt 193.79.237.14    2 u    3   64  377   46.844  2195310 6519.96
 ubul.kfki.hu    148.6.0.36       2 u   63   64  377   13.919  2187456 4743.35
horus:/tmp # /etc/init.d/ntp stop
horus:/tmp # ntpd -g -x -n -q
ntpd: time set +2207.033982s
horus:/tmp # ntpq -c readlist 
assID=0 status=c011 sync_alarm, sync_unspec, 1 event, event_restart,
version="ntpd 4.2.2p4@1.1585-o Sun Mar  4 13:21:35 UTC 2007 (1)",
processor="i686", system="Linux/2.6.18-gentoo-r7", leap=11, stratum=16,
precision=-15, rootdelay=0.000, rootdispersion=0.900, peer=0,
refid=INIT, reftime=00000000.00000000  Thu, Feb  7 2036  7:28:16.000,
poll=6, clock=c9e890ba.61f98b83  Sun, May  6 2007 19:36:58.382, state=1,
offset=0.000, frequency=29.824, jitter=0.031, noise=0.031,
stability=0.000, tai=0
horus:/tmp # ntpq -c peers
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 fiordland.ubunt 193.79.237.14    2 u   10   64    3   46.868  2198893 1295.26
 ubul.kfki.hu    148.6.0.36       2 u    9   64    3   17.929  2200206 1171.74

Azaz még mindig 16-os vagyok. Segítség!

( apal v | 2011. 03. 12., szo – 12:02 )

en sem akarok most uj temat nyitni, ez kb jo lesz...:)

a problema a kovetkezo": adott egy alix.6e1, teljesen jol megy minden, kiveve az oraja. az kb 1%-os hibat halmoz fel, tehat 1-2 perc alatt 1 masodperc ke'se'st produkal alapbol. ez elegge rossz. feltettem ntpd-t (deb/lenny) alatt, es nem igazan megy. a kovetkezo" a jelenseg:
- inditaskor (/etc/init.d/ntp start) jol beszinkronizal, az fasza
- utana viszont semmit nem csinal. ez kicsit bovebben:
- `minpoll 4 maxpoll 6`-ra van allitva a szerver, a /var/log/ntp/peerstats-ba szepen 16-32 masodpercenkent jonnek a jelentesek, hogy mennyi a drift. es valoban annyi, ha kezzel nezem egy masik gepen is az ido"t. tehat ilyen "a szervert nem birja elerni" problema nem all fent
- kezzel az ntpdate mukodik. cron-ba, percenkent, ha lefuttatom, akkor fasza'n 1 sec alatt lehet tartani a kesest. de ez igy persze minden csak nem elegans.
- a /var/lib/ntp/ntp.drift nem letezik. a konfigba be van irva (es a konfig az kb szoszerint ugyanaz mint feltucat masik deb/lenny ill deb/squeeze alatt) ugyan, de a file maga nem keletkezik le. pedig az rtfm alapjan e file tarolna valami "statikus driftet", amit valahogy adaptivan megtanul.

ilyesmi esetben mi lehet a gond? latszik, hogy a szerverekkel minden oke, jogosultsag gond sincs (kulonben se az `ntpdate` se az `ntp` indulaskor nem birna szinkronizalni), attettem minden file-t es programot root juzer ala' (a gep maga elegge belso halon van, az ntpd igy root alatt fut); de a szinkronizacio elmarad. otlet, estleg? vagy legyek turelmes es hatha pa'r ora alatt megtanul mindent es akkor jol beall a szinkron?

log: lasd feljebb.

ntpq -p most ezt mondja: 


pschtcm:~# ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*xxx.yyy.hu      .PPS.            1 u    7   64  377    2.339  844.442 514.895
 localhost.local .STEP.          16 l    - 1024    0    0.000    0.000   0.000

a drift most kb. 6-7 perc lenne _de_ folyamatosan fut az ntpdate (percenkent, cron-bol) mert most epp hasznalatba van a gep es szuksegunk van a pontos idore. holnap napkozben leallitom az ntpdate futkosasat, es akkoris bemasolok vmit.

Nem mondanam kevesnek ekkora offset-et es jittert, de meg mindig 1 sec alatt lenne ezzel, honnan veszed h 6-7 perc lenne a drift?
Nem ugy nez ki mint amit most inditottal el, ntpdate-ed megis lefut? Ilyenkor elvileg nyavajognia kellene h ntp socketet mar hasznalja.

--
Don't Panic if you see me laughing,
that's not a bug, just a feature.