Kétségbeejtően sokat foglalkozom Linuxszal mostanában, szerencsére itt is utolér néha egy-egy érdekesebb hálózati feladat. Nemrég például arra kellett választ adnom, hogy mekkora differenciával jár tetszőleges két Linux szerver órája egymáshoz képest egy adott LAN egy adott subnetjében. Természetesen van kiépített belső NTP infrastruktúra, szóval akár csípőből megválaszolható egy ilyen kérdés azzal, hogy általában LAN esetén egy-két ms körül lehet ez az érték, annál nem valószínű, hogy több lenne az eltérés bármelyik két hoszt között, ha jól működik az NTP. Ez persze egyrészt nem pontos válasz, másrészt ha nem elég meggyőző az ember, és nincs ott a prompt válasz előkészítve, amikor mondjuk egy konferenciahívás alatt felmerül a kérdés, könnyen olyan helyzetben találhatja magát, hogy már meg is kapta az egészet feladatként.
Ebben az esetben a fókusz tehát nem azon volt, hogy mennyire pontosak az órák vmilyen abszolútnak tekinthető stratum 1-es forráshoz képest, hanem hogy az adott subnet linuxos szerverein egymáshoz képest mennyire megbízhatók a logokban és adatbázisokban található timestampek, amely feladat első lépése annak a kiderítése, hogy mennyire pontosak a rendszerórák egymáshoz képest. Az NTP implementációval érkező diagnosztikai eszközök, pl. az ntpq ezeket az adatokat csak NTP szerver - NTP kliens viszonylatban tudja megmondani, nekünk általánosabb megoldásra volt szükségünk.
Egy rövid kis megbeszélés után arra jutottunk az egyik kollégával, hogy a legegyszerűbb talán az lenne, ha valamilyen multicast programmal szórnánk az aktuális timestampet valamelyik hostról (a timestamp lenne a tartalma a multicast a UDP csomagoknak), a többi szerveren meg sniffelnénk a hálózati forgalmat ngreppel, a multicast csomagok beérkezésének timestampjét pedig a csomagban lévő timestamppel összehasonlítanánk. Utána már csak a szerepeket kell forgatni a hostok közt, ha egy teljes mátrixot szeretnénk feltölteni az eredményekkel. Persze az eredmények nem lesznek teljesen pontosak, hiszen nem az órák közti differenciát fogják mutatni, benne lesz a timestamp feldolgozási ideje, UDP + IP + Ethernet csomagolása, az Ethernet késleltetése, stb. de azért adhat egy jó közelítést az órák pontosságáról. Ha például azt találjuk majd, hogy átlagosan +10 ms körüli az eltérés az átküldött timestamp és annak sniffelési ideje között, akkor az nem lesz túl rózsás eredmény, míg mondjuk ha csak 1 ms az átlagos eltérés az imént felsorolt feldolgozási idők hozzáadódása ellenére is, akkor nyugodtan hátradőlhetünk, minden rendben (üzleti oldalról az 1 ms-os pontosság az elvárás). El is kezdtem ilyesmire alkalmas programokat keresgélni, aztán persze addig faragtam a paramétereken, míg kiderült, hogy semmilyen extra programra nincs szükség, az egész tesztet meg lehet oldani az alap Ubuntu telepítéssel érkező programokkal.
A teszthez használt "szerver", ami az aktuális időbélyeget kiteszi hálózatra, nem kell hogy bonyolultabb legyen, mint egy date és netcat parancs, multicastra sincs szükség, hiszen subneten belül ugyanúgy megteszi a broadcast is:
date +%Y/%m/%d\ %k\:%M\:%S.%N | nc -b -u 192.168.0.255 6666
A parancs az ngrep kimenetének megfelelően formázott timestamp stringet fog elküldeni a megadott broadcast cím megadott portjára. Ubuntu 10.04-ben ez működik is, a 12.04-esben viszont lecserélték a netcat csomagot az OpenBSD netcatjére, ami sajnos nem tud broadcastolni, így Precise alatt a "netcat-traditional" csomagot is telepítenünk kell. A "kliens" oldal, ami a subnet összes gépén akár párhuzamosan is futhat, az ngrep megfelelően paraméterezve:
root@betazed:~# ngrep -q -t -d eth0 port 6666
interface: eth0 (192.168.0.0/255.255.255.0)
filter: (ip or ip6) and ( port 6666 )
U 2012/12/27 23:17:54.698920 192.168.0.4:60071 -> 192.168.0.255:6666
2012/12/27 23:17:54.698705783.
U 2012/12/27 23:18:09.858924 192.168.0.4:36778 -> 192.168.0.255:6666
2012/12/27 23:18:09.858708142.
U 2012/12/27 23:18:13.428859 192.168.0.4:38310 -> 192.168.0.255:6666
2012/12/27 23:18:13.428650913.
Az adatok értelmezésére érdemes némi időt fordítani, az ngrep timestamp mikroszekundumban értendő, a közvetlenül alatta lévő sor pedig az UDP payload, ahol a date parancs által a másik hoszton előállított timestamp szerepel nanoszekundumos pontossággal. Itt például látszik, hogy az időbélyeg teljes feldolgozása, hálózaton átküldése és kliens oldali feldolgozása átlagban 213 mikroszekundum volt három különböző "szerver" futtatás alkalmával. Pontosan ugyanezek a a "szerver" lefutások természetesen más eredményt adnak egy másik hosztról nézve:
root@trill:~# ngrep -q -t -d eth0 port 6666
interface: eth0 (192.168.0.0/255.255.255.0)
filter: (ip or ip6) and ( port 6666 )
U 2012/12/27 23:17:54.699099 192.168.0.4:60071 -> 192.168.0.255:6666
2012/12/27 23:17:54.698705783.
U 2012/12/27 23:18:09.859099 192.168.0.4:36778 -> 192.168.0.255:6666
2012/12/27 23:18:09.858708142.
U 2012/12/27 23:18:13.429031 192.168.0.4:38310 -> 192.168.0.255:6666
2012/12/27 23:18:13.428650913.
Itt 388 mikroszekundum az átlagos eltérés a "szerver" által küldött időpont és az UDP szegmens "kliensre" beérkezésének időpontja között. Megint más lesz az eredmény egy harmadik "kliensről" vizsgálódva, ami sok tényezőtől függhet, például attól is, hogy hány switchen keresztül vezet az UDP broadcast útja, hiszen minden egyes switch hozzáadja a maga késleltetését. Rosszul járó órára akkor gyanakodhatunk, ha valamelyik hostról a küldött
és fogadott adatok eredményei szignifikánsan eltérnek a többieken
mértektől. A konklúzió nálunk az volt, hogy az órák egymáshoz képest meglepően pontosan járnak abban a subnetben, ahol a vizsgálatot végeztem, és a Wikipédián említett 1ms-os LAN-on elérhető NTP pontosságot messze túlteljesítjük.
