Sadece Cisco 4500 anahtarlarımdan birinin saatinin yanlış gittiğini şansla fark ettim: görünüşte işlevsel ntp'ye rağmen 2 dakikadan fazla geride kaldı . Kanımca, bir saniye bile ilgili sistemler için kabul edilebilir sayılmamalıdır. Ayrıca, basit bir duvar saati ile karşılaştırmasaydım, teşhisden farkı fark edemezdim.
Bazı detaylar
İşte bazı ana bilgisayarlarım (10.0.99.1, 10.0.99.2, 10.0.1.119, 10.0.99.241) için geri dönüş için kısmen referans veren ntp bilgileri, ancak esas olarak hepsi 10.0.0.1 ile senkronize ederek dışarıdan zaman. Dolayısıyla, zaman uyuşmazlığı farklı orijinal zaman kaynaklarından kaynaklanamaz. Gözlemler beni biraz paranoyak yaptı gibi, aşağıdaki araçlarında "doğru zamanı var": show clock(veya date) (ince göre benim duvar saati ve benim yerel sistem saatine uyar üretim değeriyle http://time.is ile) kesinlikle 1 saniyenin altında bir hata (yerel saatimi izlerken ENTER tuşuna basmamın doğruluğu)
10.0.1.119 (Ubuntu) zamanı doğru
$ ntpq -np
remote refid st t when poll reach delay offset jitter
==============================================================================
+10.0.99.1 10.0.0.1 3 u 855 1024 377 0.904 -2.658 0.113
*10.0.0.1 130.149.17.8 2 u 266 1024 377 0.253 0.909 0.127
10.0.99.241 (Cisco 2960) doğru zamana sahip
#sho ntp associations
address ref clock st when poll reach delay offset disp
*~10.0.99.1 10.0.0.1 3 28 64 377 1.462 85.288 19.758
+~10.0.99.2 10.0.1.119 4 29 64 377 1.297 83.515 5.369
* sys.peer, # selected, + candidate, - outlyer, x falseticker, ~ configured
10.0.99.2 (Cico 4500) doğru zamana sahip
#sho ntp associations
address ref clock st when poll reach delay offset disp
+~10.0.99.1 10.0.0.1 3 6 1024 111 1.148 -1.618 42.875
*~10.0.1.119 10.0.0.1 3 31 1024 377 0.043 1.687 1.064
* sys.peer, # selected, + candidate, - outlyer, x falseticker, ~ configured
10.0.99.1 (Cisco 4500) yaklaşık 2 dakika 6 saniye geride kalıyor
#sho ntp associations
address ref clock st when poll reach delay offset disp
*~10.0.0.1 130.149.17.8 2 274 1024 377 15.625 3.681 30.403
+~10.0.99.2 10.0.1.119 4 415 1024 376 15.625 0.855 33.276
* sys.peer, # selected, + candidate, - outlyer, x falseticker, ~ configured
#sho ntp status
Clock is synchronized, stratum 3, reference is 10.0.0.1
nominal freq is 250.0000 Hz, actual freq is 249.9988 Hz, precision is 2**6
reference time is DAD8B428.54C6BAEA (20:36:24.331 MESZ Sat May 7 2016)
clock offset is 3.6818 msec, root delay is 32.80 msec
root dispersion is 71.74 msec, peer dispersion is 30.40 msec
loopfilter state is 'CTRL' (Normal Controlled Loop), drift is 0.000004720 s/s
system poll interval is 1024, last update was 683 sec ago.
Sorular
- Nasıl şimdiye kadar 10.0.99.1 uzakta?
- 10.0.99.1 ile senkronize edilen sistemler nasıl doğrudur?
sho ntp status10.0.99.1'deki çıktıdan saatin tamamen senkronize olmadığını nasıl öğrenebilirim ( belirtilen tüm ana bilgisayarlara ve referans saatlerine kıyaslasho ntp asso)? Benim için çıktı çok ayrıntılı bir "Ben tamamen mutluyum" gibi görünüyor.
EDIT: popüler talep tarafından, çıktısho clock detail
10.0.99.1
#sho clock detail
13:06:38.605 MESZ Tue May 10 2016
Time source is NTP
Summer time starts 02:00:00 MEZ Sun Mar 27 2016
Summer time ends 03:00:00 MESZ Sun Oct 30 2016
10.0.99.2
#sho clock detail
13:10:54.083 MESZ Tue May 10 2016
Time source is NTP
Summer time starts 02:00:00 MEZ Sun Mar 27 2016
Summer time ends 03:00:00 MESZ Sun Oct 30 2016
Ntp yapılandırmanızla ilgili göze çarpan bir sorun, her ana bilgisayarın mümkün olan en kötü zaman kaynağıyla yapılandırılmış olmasıdır . "Bir saati olan bir adam saatin kaç olduğunu bilir, iki saati olan bir adam asla emin değildir ..." Başka herhangi bir sayı ikiden daha iyidir, dört muhtemelen en iyi seçimdir, eğer biri yoksa ve hala ayrılırsa bir yastık verir üç kaynak.
—
dfc
Tüm NTP yapılandırmanızın yeniden değerlendirilmesi gerekir. Tabaka seviyeleri ile çalışmanız gerekir. @Kasperd'un işaret ettiği gibi, bir döngü ile ilgili bir sorununuz olabilir. Yalnızca daha düşük katman düzeyindeki sunuculara eşitlemelisiniz ve aynı katman düzeyindeki sunucular eşleştirilebilir, ancak birbirlerini sunucu olarak kullanamazsınız. Eşlenen cihazların hala yetkili kaynaklar olarak daha düşük bir katman düzeyinde bir veya daha fazla sunucuya ihtiyacı vardır, ancak kendilerini diğer eşlerle hizalamaya çalışırlar. NTP sunucuları olarak meşgul cihazları (örn. Çekirdek anahtarlar) kullanmayın.
—
Ron Maupin
Çok tuhaf bir şeyler oluyor. Tüm ntp çıktıları normaldir ve iyi senkronizasyon gösterir. Yine de cihazdan zamanı alma emriniz bu kadar kapalı bir zaman verdi. Bu, bazı nedenlerden dolayı, kapalı olan zamana sahip cihazın sistem saatini ntp alt sisteminden ayarlamadığını gösterir.
—
David Schwartz
Gerçekten bir hata bulduğunuza benziyor ve muhtemelen ilerlemenin tek yolu yeniden başlatmak ve gider ya da Cisco ile iletişime geçmek.
—
derobert
10.0.0.1) ile senkronize olmasına izin vermek iyi bir fikir olduğuna ikna olmadım . Ama gözlemlerimin hiçbirinin mevcut probleminizin nedenini doğrudan açıklayabileceğini sanmıyorum.