NTP клиента с домейн имена

[trapatoni]

Ползвам отдавна NTP пакета, заради наличието на NTP server за локалната мрежа. Също отдавна ползвам и scheduled скрипт, който всеки ден резолва два сървъра от пуул на ntp.org и ъпдейтва ИП-тата в NTP client областта, защото могат само IP адреси да се вкарат там, което в началото се оказа проблем, защото спираха да работят някои сървъри и се наложи с домейни.

Гледам и cloudflare имат нтп сървър, и се чудех микротик ще оправят ли някога тази недомислица и да може да се зададе домейн, на който по човешкия начин да се респектва TTL и както си му е редът?
Как решавате този проблем, само със скрипт ли?

[madmanz]

Аз използвам:

/system ntp client
set enabled=yes server-dns-names=0.bg.pool.ntp.org,1.bg.pool.ntp.org,2.bg.pool.ntp.org

Струва ми се, че работи:

 

system ntp client print 
             enabled: yes
         primary-ntp: 0.0.0.0
       secondary-ntp: 0.0.0.0
    server-dns-names: 0.bg.pool.ntp.org,1.bg.pool.ntp.org,2.bg.pool.ntp.org
                mode: unicast
       poll-interval: 32s
       active-server: 185.117.82.66
    last-update-from: 185.117.82.66
  last-update-before: 9s710ms
     last-adjustment: 17ms356us

Поздрави!

[trapatoni]

Да, но явно не си инсталирал отделния ntp пакет . Той освен че се инсталира основно заради NTP Server-a, замества и НТП клиента в ROS с по-скопен такъв, за съжаление. Което последното ми е непонятно защо е направено така.

[madmanz]

Досега не го бях използвал. Сега го прегледах, наистина е спартански. Може би бай-добрия вариант е един скрипт, който през 10 минути да сетва два сървъра на произволен принцип от pool.ntp.org и DHCP лийзове на 10 минути също. По принцип ми се струва, че дори и да е по-голям период-а обикновено на компютрите не им бяга толкова бързо часа. Дори и час да е би трябвало да е ок. Друга опция се замислих вдигаш един виртуален CHR и на него му настройваш SNTP клиент, а другия раздава адреса на виртуалния рутер като NTP сървър. Потнциално, ако има налична инфраструктура, може и нормален NTP сървър да вдигнеш в мрежата.

[trapatoni]

Да, то не е особен проблем, аз съм настроил scheduled скрипт веднъж дневно да резолва едни и същи два адреса от бг.пуул..-а, които май всеки ден резолват към различни ИП адреси, и това е достатъчно, от което следва че не е нужно да се ползват произволни сървъри/домейни от ntp.org, което би усложнило скрипта. Да, за 1 ден не се разминават часовниците толкова дори да се загуби един ден от неработещи сървъри. Една от машините ако се остави 3-4 дни и значително й напредва часовника (примерно 5-6 сек), затова гледам повече от 2 дни да не остава без сверка.
Иначе самия скрипт в рутера на какъв период ще рънва има отношение само до сверяването на часовника на самия рутер, а той е относително точен и не бяга много с дните, за разлика от компютрите, някои от които започват да бягат с доста секунди за 3-4 дни.
Но вече над година ли колко стана, схемата работи, просто се чудех кога ще оправят това недоразумение.

Между другото стигнах до това да ползвам NTP сървър, защото в Windows така и не оправиха сверяването да работи надеждно. Минеше се не мине някакво време и по друг повод виждам, че часовника в някои Windows-и/машини изостанал или напреднал с няколко минути, 10-15 за няколко месеца! А уж всичко е настроено и е работело. Затова и ползвам на всички Виндовси програмчето NetTime, което работи идеално откакто го ползвам вместо НТП клиента на Вин-овете.

Мен тоя сетъп ме удовлетворява, за едно NTP server да вдигам виртуалки или специални неща... така от самия рутер е Ок, въпреки малкото неудобство със скопения нтп клиент. Но е силно учудващо след като вече имат SNTP-то в самия ROS защо скопяват и клиента при слагането на допълнителния пакет, защото е удобно в рутера да върви и нтп сървър за всичко в мрежата.

Редактирано 1 Октомври, 2019 от trapatoni

[kokaracha]

Няма нужда да се вдига нещо,всяко удтроисъво или всяка ОС си има нтп клиент.

В нашия пул ктм  момента има 45 активни  нтп стратум 2 съсрвъра и 2 активни публични стратум 1.

просто трябва да се едитне или добави :

   server 0.bg.pool.ntp.org
   server 1.bg.pool.ntp.org
   server 2.bg.pool.ntp.org
   server 3.bg.pool.ntp.org

https://www.ntppool.org/zone/bg

 

 

 

[trapatoni]

Еми аз това писах, че в повечето (всички?) Windows-и, които имам и съм имал, все са имали проблеми с вградените си (S)NTP клиенти. Но то не това е въпроса, защото поне по Windows-ите ползвам само външната NetTime програмка и откакто я ползвам, съм забравил за проблеми с времето.

Но иначе предпочитам просто от самия рутер да си се сверяват всички централизирано. Всъщност може да се помисли за предимства и недостатъци и на двата метода..
Ако нямаше предимства, нямаше да съществува ntp пакет за ROS.

[kokaracha]

Уиндоусите си сверяват времето коректно,няма проблеми в това нито е нужна външна програма.Просто в полето със избор на времеви сърър трябва да се добави ред/лист със хостнеима на бг пула.

Вдигането на НТП като услуга се обезмисля при положение че нямаш собствен източник на време,а иможе и да е опасно .Често нтп трафика се ползва за флуд.

[trapatoni]

Моя експириънс с безброй Windows-и през годините сочи друго, иначе нямаше да ползвам външната програма. Вероятно се дължи на рестриктивните политики, файруоли и т.н., но е факт, че за някакво време понякога функцията работи, и по някое време просто спира, това при различни конфигурации, рутери и т.н. през годините. Задавал съм най-различни съвръри, като реши да спре, просто спира за седмици и месеци докато усетя случайно.

За флуд от нтп трафик имаш предвид сигурно в LAN-a. То ако се види, че има такъв, ще се вземат мерки, но при една ЛАН, която е под мой контрол всички устройства, такова нещо не съм виждал, пък и той флууда ще е причинен от нещо като вирус, и този флуд сигурно би бил най-малкия проблем - вероятно той би излязал и навън ако са зададени външни сървъри. Само размишлявам.

[kokaracha]

Ами ти всъщност  сам си си отговорил,защо не работи синхронизирането на времето.Просто трябва да е указан бг пула в менюто  и да е разрешен трафика през упорт 123 удп както на уина така и на рутера на мрежата в която е уина.

По подразбиране доколкото знам уиндоус има 2 нтп сървъра в менюто си, time.windows.com / time.nist.gov  който са в Америка и често маршрута до тях е лимитиран във връзка със флуд.

 

 

[trapatoni]

Е.... .

Писах, че понякога работи, особено за някакво време след като сменя сървър/задам нов. Естествено, че удппорт 123 е отворен за навсякъде, нали иначе изобщо никога нямаше да работи. Указвал съм през годините всякакви от пулове на ntp.org и т.н. След дълги години с такива мизерни проблеми, преди 2-3г. някъде ми писна жестоко и откакто съм с NetTime навсякъде, и за миг не е имало проблем никъде.

[111111]

time.google.com
и тез ли спират?

[kokaracha]

преди 16 минути, 111111 написа:

time.google.com
и тез ли спират?

Николй нищо не спира. Просто при флуд режат порта/лимитират му трафика някъде по  трасето.

[trapatoni]

Това означава ли, че при доста машини в LAN-a (то повече са виртуалните), които по принцип всяка си се опитва да се синхронизира с външен сървър, може да се стигне до такъв резултат с рязане поради вид флудене? Ако да, значи това е един фактор в подкрепа на централизирано сверяване с рутера на всички от ЛАН-а.

[kokaracha]

Не,не означава.

Централизираното сверяване се налага и е ползва в затворени мрежи.

 

[trapatoni]

Тогава какво имаше предвид точно с по-предния си пост за рязането някъде по пътя, че нещо не разбрах. Или поне аз разбрах поста по начин, че ако от една сорс мрежа/IP/доставчик/друго подобно, пристигат голямо количество заявки за "сверяване", може да се резне по пътя, и  че това може да е причина за наблюдавания от мен феномен, че чат пат работеха зададените от мен сървъри, но по някое време просто ги сварвам, че са спрели да се синхронизират от седмици и месеци, без никаква видима причина. Поне контекстът на коментара на 111111 и твоя отговор беше в тази насока.
time.google.com надали съм пробвал, но същите, които работят без проблеми вече години, преди правеха проблеми при вградения синхронизатор в Windows (там всички правеха проблеми, не е било в тях проблема просто).