Kenapa salah satu sakelar saya mati dua menit meskipun ntp?

Saya hanya memperhatikan secara kebetulan bahwa salah satu switch Cisco 4500 saya mengalami kesalahan: lebih dari 2 menit di belakang meskipun ntp tampaknya berfungsi. Menurut pendapat saya, bahkan satu detik pun tidak dapat dianggap dapat diterima untuk sistem yang terlibat. Juga, saya tidak akan memperhatikan perbedaan dari diagnosa, jika saya tidak membandingkannya dengan jam dinding sederhana.

Beberapa detail

Inilah informasi ntp untuk beberapa host saya (10.0.99.1, 10.0.99.2, 10.0.1.119, 10.0.99.241) yang sebagian mereferensikan satu sama lain untuk fallback, tetapi sebagian besar pada akhirnya semua harus disinkronkan dengan 10.0.0.1, yang lagi-lagi menarik waktu dari luar. Jadi perbedaan waktu tidak dapat dihasilkan dari sumber waktu asli yang berbeda. Karena pengamatan membuat saya agak paranoid, "memiliki waktu yang tepat" dengan cara berikut: show clock(atau date) menghasilkan output yang cocok dengan jam dinding saya dan jam sistem lokal saya (yang baik-baik saja menurut http://time.is ) dengan kesalahan pasti di bawah 1 detik (akurasi saya mengenai ENTER saat menonton jam lokal saya)

10.0.1.119 (Ubuntu) memiliki waktu yang tepat

$ 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) memiliki waktu yang tepat

#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) memiliki waktu yang tepat

#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) tertinggal sekitar 2 menit 6 detik

#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.

Pertanyaan

Kenapa 10.0.99.1 begitu jauh?
Mengapa sistem yang disinkronkan ke 10.0.99.1 benar?
Bagaimana saya harus belajar dari output sho ntp statuspada 10.0.99.1 bahwa jam sebenarnya sama sekali tidak sinkron (dibandingkan dengan semua host dan jam referensi yang disebutkan dalam sho ntp asso)? Bagi saya hasilnya terlihat seperti "Saya sangat senang".

EDIT: Dengan permintaan populer, output darisho 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

cisco ntp time-synchronization

— Hagen von Eitzen
sumber

Saya tidak dapat menemukan sistem di mana alamat IP yang telah Anda konfigurasi sebagai server ntp yang digunakan oleh setiap perangkat. Dan saya melihat loop serta pasangan menggunakan satu sama lain sebagai server ntp. Saya percaya pada kasus-kasus itu Anda seharusnya menentukannya sebagai ntp peer daripada server. Meskipun saya harus mengakui bahwa saya tidak tahu apa bedanya sebenarnya apakah Anda menentukannya sebagai peer atau server. Juga, saya tidak yakin itu adalah ide yang baik untuk membiarkan semuanya disinkronkan melalui satu host ( 10.0.0.1). Tapi saya rasa pengamatan saya tidak bisa secara langsung menjelaskan penyebab masalah Anda saat ini.

— kasperd

Satu masalah mencolok dengan konfigurasi ntp Anda adalah bahwa setiap host dikonfigurasikan dengan jumlah sumber waktu terburuk. "Seorang pria dengan satu jam tangan tahu jam berapa sekarang, seorang pria dengan dua jam tangan tidak pernah yakin ..." Angka lain lebih baik dari dua, empat mungkin merupakan pilihan terbaik, itu memberikan bantal jika salah satu tidak tersedia dan masih pergi tiga sumber.

— dfc

Seluruh konfigurasi NTP Anda perlu dipertimbangkan kembali. Anda perlu bekerja dengan level strata. Seperti yang ditunjukkan oleh @kasperd, Anda mungkin memiliki masalah dengan loop. Anda hanya harus menyinkronkan ke server dengan level strata yang lebih rendah, dan mereka yang berada pada level strata yang sama dapat diintip, tetapi tidak saling menggunakan sebagai server. Perangkat yang diintip masih membutuhkan satu atau lebih server pada tingkat strata yang lebih rendah sebagai sumber yang berwenang, tetapi akan mencoba menyelaraskan diri dengan rekan-rekan lainnya. Jangan gunakan perangkat sibuk (mis. Sakelar inti) sebagai server NTP.

— Ron Maupin

Sesuatu yang sangat aneh sedang terjadi. Semua output ntp cukup normal dan menunjukkan sinkronisasi yang baik. Namun perintah Anda untuk mendapatkan waktu dari perangkat memberi waktu yang jauh. Itu menunjukkan bahwa karena alasan tertentu, perangkat dengan waktu tidak aktif tidak mengatur jam sistemnya dari subsistem ntp.

— David Schwartz

Ini benar-benar terdengar seperti Anda telah menemukan bug, dan mungkin satu-satunya cara ke depan adalah mem-boot ulang dan berharap itu hilang atau untuk menghubungi Cisco.

— derobert

Jawaban:

Saya agak enggan untuk memposting ini sebagai jawaban karena penyebab aslinya masih belum jelas. Namun demikian, masalahnya tampaknya diselesaikan - setidaknya untuk saat ini.

Mengikuti komentar yang dibuat oleh htm11h , saya memutuskan untuk memperbarui firmware. Dan memang, sekarang saya menjalankan dengan firmware yang lebih baru, jam sepertinya cocok dengan waktu yang tepat.

Tetapi apakah itu berarti firmware baru adalah solusinya? Sayangnya tidak ada. Dalam upaya pertama saya untuk memuat firmware baru, saya lupa mengubah register konfigurasi, yang masih pada pengaturan standar pabrik. Oleh karena itu, reboot pertama saya berakhir dengan image ROM asli yang sama dengan yang telah dijalankan router selama hampir empat tahun (yaitu sejak power-on awal). Namun, ini sudah cukup bagi jam untuk melakukan satu penyesuaian besar dan kemudian tetap sinkron. Ini menunjukkan bahwa hanya reboot mungkin membantu - sementara. Pada gilirannya, ini berarti bahwa waktu yang sekarang benar ditunjukkan dengan firmware yang lebih baru mungkin masih melayang jauh dari waktu ntp selama bertahun-tahun yang akan datang. Ini akan memakan waktu beberapa hari sampai saya dapat dengan aman mengetahui apakah jamnya hilang sekitar 5 detik per hari ...

Untuk saat ini, kasing ditutup.

— Hagen von Eitzen
sumber

Saya telah melakukan sedikit pekerjaan dengan proyek NTP Pool sejak pertengahan 90-an dan menjalankan beberapa server NTP Stratum-1 GPS Synced di sini. Seperti yang telah dinyatakan orang lain, Anda membutuhkan lebih dari 2 server untuk mendapatkan waktu. Saya biasanya menggunakan 4 di sini untuk alasan yang dinyatakan oleh Ron Maupin di atas. Juga seperti yang tercantum, Anda perlu melihat loop dan menetapkan hal sebagai server vs rekan.

Penyimpangan waktu dapat disebabkan oleh bug yang dikenal di iOS yang diperbaiki dalam pembaruan iOS ini yang berhubungan dengan ntp.drift tidak dihapus atau diperbarui dengan benar dan dengan demikian masalah penyimpangan. Juga 4 TAHUN tanpa reboot atau pembaruan harus meninggalkan Anda di tempat yang sangat buruk keamanan bijaksana karena pembaruan Keamanan IOS keluar cukup sering.

Berikut adalah pos yang sangat baik tentang pengaturan NTP di Cisco IOS http://packetlife.net/blog/2011/mar/28/cisco-ios-clocks-and-ntp/

Semoga ini bermanfaat. Silakan tanyakan jika Anda memiliki lebih banyak pertanyaan atau masalah.

— George Kasica
sumber

Pengungkapan penuh: Saya hanya sesekali mengotak-atik konfigurasi switch sama sekali, dan saya sama sekali tidak ahli NTP.

Yang mengatakan, saya dulu melihat daemon NTP pada sistem RHEL 5.x (ya, saya akan kembali, tetapi Anda memang mengatakan switch Anda memiliki gambar ~ ~ 4 tahun tua ...) terjebak dalam keadaan "bahagia" , di mana tampaknya berpikir itu disinkronkan dengan sempurna tetapi jelas tidak. Kami akan menggunakan sesi ClusterSSH untuk menjalankan "tanggal" pada semua sistem secara bersamaan, dan itu kadang-kadang akan menunjukkan 5 menit pergeseran antar sistem. Jika saya ingat dengan benar, kami hanya bisa memperbaiki masalah dengan me-restart daemon, dan akhirnya hanya membuat cron me-restart layanan setiap malam ...

Bukan dengan cara apa pun solusi yang ideal, tetapi Anda mungkin dapat mengadopsi pendekatan yang sama dengan pekerjaan cron untuk terhubung ke sakelar dan memulai reboot, atau entah bagaimana "menendang" NTP daemon pada sakelar?

Semoga ini membantu!

— Dan
sumber