ฉันเพิ่งสังเกตเห็นโดยบังเอิญว่าสวิตช์ Cisco 4500 ตัวใดตัวหนึ่งของฉันมีนาฬิกาทำงานผิดปกติ: มันใช้เวลานานกว่า 2 นาทีแม้จะมีฟังก์ชั่น ntp ในความคิดของฉันแม้แต่วินาทีเดียวก็ไม่ควรได้รับการยอมรับสำหรับระบบที่เกี่ยวข้อง นอกจากนี้ฉันจะไม่ได้สังเกตเห็นความแตกต่างจากการวินิจฉัยหากฉันไม่ได้เปรียบเทียบกับนาฬิกาแขวนเรียบง่าย
รายละเอียดบางอย่าง
นี่คือข้อมูล ntp สำหรับโฮสต์บางคนของฉัน (10.0.99.1, 10.0.99.2, 10.0.1.119, 10.0.99.241) ที่อ้างถึงอีกส่วนหนึ่งสำหรับการย้อนกลับ แต่ในท้ายที่สุดแล้วทั้งหมดควรซิงค์กับ 10.0.0.1 ซึ่งดึงข้อมูลอีกครั้ง เวลาจากภายนอก ดังนั้นความคลาดเคลื่อนเวลาไม่สามารถเกิดขึ้นจากแหล่งเวลาดั้งเดิมที่แตกต่างกัน เมื่อการสังเกตทำให้ฉันหวาดระแวง "มีเวลาที่ถูกต้อง" ในวิธีการดังต่อไปนี้: show clock(หรือdate) สร้างเอาต์พุตที่ตรงกับนาฬิกาแขวนของฉันและนาฬิการะบบในท้องถิ่นของฉัน (ซึ่งใช้ได้ตามhttp://time.is ) ด้วย ข้อผิดพลาดอย่างแน่นอนต่ำกว่า 1 วินาที (ความแม่นยำของฉันกดปุ่ม ENTER ในขณะที่ดูนาฬิกาท้องถิ่นของฉัน)
10.0.1.119 (Ubuntu) มีเวลาที่ถูกต้อง
$ 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) มีเวลาที่ถูกต้อง
#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) มีเวลาที่ถูกต้อง
#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) ล่าช้าประมาณ 2 นาที 6 วินาที
#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.
คำถาม
- 10.0.99.1 เป็นยังไงบ้าง
- ระบบที่ซิงค์กับ 10.0.99.1 มาถูกต้องอย่างไร
- ฉันควรจะเรียนรู้จากการส่งออกของ
sho ntp statusบน 10.0.99.1 ว่านาฬิกาที่เป็นจริงทั้งหมดออกจากซิงค์ (เมื่อเทียบกับทุกโฮสต์และนาฬิกาอ้างอิงที่กล่าวถึงในsho ntp asso)? สำหรับฉันผลลัพธ์ที่ออกมาดูเหมือนว่า "ฉันมีความสุขมาก"
แก้ไข:ตามความต้องการที่เป็นที่นิยม, ผลลัพธ์ของ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
10.0.0.1) แต่ฉันไม่คิดว่าการสังเกตใด ๆ ของฉันสามารถอธิบายสาเหตุของปัญหาปัจจุบันของคุณได้โดยตรง