تسعى مجموعة الوثائق لهذا المنتج جاهدة لاستخدام لغة خالية من التحيز. لأغراض مجموعة الوثائق هذه، يتم تعريف "خالية من التحيز" على أنها لغة لا تعني التمييز على أساس العمر، والإعاقة، والجنس، والهوية العرقية، والهوية الإثنية، والتوجه الجنسي، والحالة الاجتماعية والاقتصادية، والتمييز متعدد الجوانب. قد تكون الاستثناءات موجودة في الوثائق بسبب اللغة التي يتم تشفيرها بشكل ثابت في واجهات المستخدم الخاصة ببرنامج المنتج، أو اللغة المستخدمة بناءً على وثائق RFP، أو اللغة التي يستخدمها منتج الجهة الخارجية المُشار إليه. تعرّف على المزيد حول كيفية استخدام Cisco للغة الشاملة.
ترجمت Cisco هذا المستند باستخدام مجموعة من التقنيات الآلية والبشرية لتقديم محتوى دعم للمستخدمين في جميع أنحاء العالم بلغتهم الخاصة. يُرجى ملاحظة أن أفضل ترجمة آلية لن تكون دقيقة كما هو الحال مع الترجمة الاحترافية التي يقدمها مترجم محترف. تخلي Cisco Systems مسئوليتها عن دقة هذه الترجمات وتُوصي بالرجوع دائمًا إلى المستند الإنجليزي الأصلي (الرابط متوفر).
يوضح هذا المستند كيفية أستكشاف أخطاء بروتوكول وقت الشبكة (NTP) وإصلاحها باستخدامdebug
الأوامر والأمرshow ntp
.
لا توجد متطلبات خاصة لهذا المستند.
لا يقتصر هذا المستند على إصدارات برامج ومكونات مادية معينة.
تم إنشاء المعلومات الواردة في هذا المستند من الأجهزة الموجودة في بيئة معملية خاصة. بدأت جميع الأجهزة المُستخدمة في هذا المستند بتكوين ممسوح (افتراضي). إذا كانت شبكتك قيد التشغيل، فتأكد من فهمك للتأثير المحتمل لأي أمر.
قبل أن ينظر أنت في سبب مشاكل NTP، أنت ينبغي فهمت الإستعمالمن والإخراج من هذا أمر:
ملاحظة: أستخدم أداة بحث الأوامر للحصول على مزيد من المعلومات حول الأوامر المستخدمة في هذا القسم. يمكن فقط لمستخدمي Cisco المسجلين الوصول إلى الأدوات والمعلومات الداخلية.
ملاحظة: تدعم أداة مترجم الإخراج بعض أوامر show. يمكن فقط لمستخدمي Cisco المسجلين الوصول إلى الأدوات والمعلومات الداخلية.
يمكن أن يكون اقتران NTP:
هذا مثال من إنتاج من العرض ntp اقتران أمر:
CLA_PASA#sh ntp association
address ref clock st when poll reach delay offset disp
~10.127.7.1 10.127.7.1 9 50 64 377 0.0 0.00 0.0
~10.50.44.69 10.50.36.106 5 21231 1024 0 3.8 -4.26 16000.
+~10.50.44.101 10.50.38.114 5 57 64 1 3.6 -4.30 15875.
+~10.50.44.37 10.50.36.50 5 1 256 377 0.8 1.24 0.2
~10.50.44.133 10.50.38.170 5 12142 1024 0 3.2 1.24 16000.
+~10.50.44.165 10.50.38.178 5 35 256 357 2.5 -4.09 0.2
+~10.50.38.42 10.79.127.250 4 7 256 377 0.8 -0.29 0.2
*~10.50.36.42 10.79.127.250 4 188 256 377 0.7 -0.17 0.3
+~10.50.38.50 10.79.127.250 4 42 256 377 0.9 1.02 0.4
+~10.50.36.50 10.79.127.250 4 20 256 377 0.7 0.87 0.5
* primary (synced), # primary (unsynced), + selected, - candidate, ~ configured
مدة | الشرح |
---|---|
تحتوي الأحرف قبل العنوان على التعريفات التالية:
|
|
عنوان |
هذا هو عنوان IP للنظير. في المثال، يظهر الإدخال الأول 127.127.7.1. وهذا يشير إلى أن الجهاز المحلي قد قام بالمزامنة مع نفسه. وبشكل عام، تتم مزامنة أساسية لبروتوكول وقت الشبكة (NTP) مع نفسها فقط. |
ساعة المرجع |
هذا هو عنوان الساعة المرجعية للنظير. في المثال، أول ستة أنداد/خوادم لها IP خاص كساعة مرجعية، لذلك فإن أساسياتهم ربما تكون الموجهات أو المحولات أو الخوادم داخل الشبكة المحلية. بالنسبة للإدخالات الأربعة الأخيرة، فإن الساعة المرجعية هي IP عام، لذلك فإن ابتداءاتهم قد تكون مصدر وقت عام. |
سانت |
يستخدم NTP مفهوم الاستراتيجية من أجل وصف مدى بعد الجهاز (في نقلات NTP) من مصدر زمني موثوق به. على سبيل المثال، خادم وقت Stratum 1 لديه ساعة ذرية أو راديو متصلة مباشرة به. إنه يرسل وقته إلى خادم وقت Stratum 2 من خلال NTP، وهكذا حتى الطبقة 16. يختار الجهاز الذي يشغل بروتوكول وقت الشبكة (NTP) تلقائيا الجهاز الذي يحتوي على أقل رقم إستراتيجية يمكنه الاتصال به واستخدام بروتوكول وقت الشبكة (NTP) كمصدر للوقت. |
متى |
يتم الإبلاغ عن الوقت منذ آخر حزمة NTP التي تم تلقيها من نظير في ثوان. يجب أن تكون هذه القيمة أقل من الفاصل الزمني لعملية التحقق. |
إستطلاع |
يتم الإبلاغ عن الفاصل الزمني لعملية التحقق بالثواني. تبدأ الفترة الزمنية عادة بفترات استبيان لا تقل عن 64 ثانية. يحدد RFC أنه لا يلزم أكثر من معاملة NTP واحدة في الدقيقة لمزامنة جهازين. مع إستقرار بروتوكول وقت الشبكة (NTP) بين العميل والخادم، يمكن أن يزيد الفاصل الزمني للاستطلاع في خطوات صغيرة من 64 ثانية إلى 1024 ثانية، كما يستقر بشكل عام في مكان ما بين هذه الثواني. ولكن، تتغير هذه القيمة بشكل ديناميكي، استنادا إلى ظروف الشبكة بين العميل والخادم وفقد حزم NTP. إذا تعذر الوصول إلى الخادم لبعض الوقت، تتم زيادة الفاصل الزمني للاستطلاع في الخطوات إلى 1024 ثانية لتقليل مصروفات الشبكة. لا يمكن ضبط فاصل إستطلاع NTP على موجه، نظرا لأن الخوارزميات الداخلية تحدد بواسطة الخوارزميات الاستكشافية. |
وصول |
إمكانية الوصول إلى النظير هي سلسلة بت تم الإبلاغ عنها كقيمة ثمانية. يوضح هذا الحقل ما إذا كانت الحزم الثماني الأخيرة قد تم استقبالها بواسطة عملية NTP على برنامج Cisco IOS®. يجب إستلام الحزم ومعالجتها وقبولها كصحيحة بواسطة عملية NTP وليس فقط بواسطة الموجه أو المحول الذي يستقبل حزم NTP IP. يستخدم Reach الفاصل الزمني لاستطلاع الفترة الزمنية للانتهاء لتحديد ما إذا تم تلقي حزمة أم لا. الفاصل الزمني للاستطلاع هو الوقت الذي ينتظره NTP قبل أن يستنتج أن حزمة قد فقدت. يمكن أن يكون وقت الاستطلاع مختلفا للنظراء المختلفين، لذلك يقرر الوقت قبل الوصول أن الحزمة قد فقدت من الممكن أيضا أن تختلف للنظراء المختلفين. في المثال، هناك أربع قيم وصول مختلفة:
Reach عبارة عن مؤشر جيد حول ما إذا كان يتم إسقاط حزم NTP بسبب إرتباط ضعيف، ومسائل وحدة المعالجة المركزية، ومشاكل أخرى متقطعة. محول الوحدة هو محول وحدة عبر الإنترنت لهذا التحويل والعديد من التحويلات الأخرى. |
تأخير |
يتم الإبلاغ عن تأخر الذهاب والعودة إلى النظير بالمللي ثانية. لتعيين الساعة بشكل أكثر دقة، يتم أخذ هذا التأخير في الاعتبار عند تعيين وقت الساعة. |
إزاحة |
الإزاحة هي فرق وقت الساعة بين النظراء أو بين الأساسي والعميل. هذه القيمة هي التصحيح الذي يتم تطبيقه على ساعة عميل لمزامنتها. تشير القيمة الموجبة إلى أن ساعة الخادم أعلى. تشير القيمة السالبة إلى أن ساعة العميل أعلى. |
DISP |
يقصد ب Dispersion، الذي تم الإعلام عنه بالثواني، أقصى فرق وقت للساعة تم ملاحظته على الإطلاق بين الساعة المحلية وساعة الخادم. في المثال، التشتيت هو 0.3 للخادم 10.50.36.42، لذلك فإن الحد الأقصى لفارق الوقت الذي تم ملاحظته محليا بين الساعة المحلية وساعة الخادم هو 0.3 ثانية. يمكنك توقع رؤية قيمة عالية عندما تكون الساعات متزامنة في البداية. ولكن، إذا كان التشتيت مرتفعا جدا في أوقات أخرى، فإن عملية NTP على العميل لا تقبل رسائل NTP من الخادم. الحد الأقصى للتشتيت هو 16000؛ في المثال، هذا هو التشتيت للخوادم 10.50.44.69 و 10.50.44.133، لذلك لا يقبل العميل المحلي الوقت من هذه الخوادم. إذا كان الوصول صفرا والتشتيت مرتفعا جدا، فلن يقبل العميل الرسائل من ذلك الخادم على الأرجح. ارجع إلى السطر الثاني من المثال: address ref clock st when poll reach delay offset disp على الرغم من أن الإزاحة تساوي -4.26 فقط، إلا أن التشتيت يكون مرتفعا جدا (ربما بسبب حدث سابق)، ويكون الوصول صفرا، لذلك لا يقبل هذا العميل الوقت من هذا الخادم. |
هذا مثال على الإخراج من أمر تفاصيل show ntp association:
Router#sho ntp assoc detail
10.4.2.254 configured, our_primary, sane, valid, stratum 1
ref ID .GPS., time D36968AA.CC528FE7 (02:10:50.798 UTC Fri May 25 2012)
our mode client, peer mode server, our poll intvl 64, peer poll intvl 64
root delay 0.00 msec, root disp 0.44, reach 377, sync dist 207.565
delay 2.99 msec, offset 268.3044 msec, dispersion 205.54
precision 2**19, version 3
org time D36968B7.E74172BF (02:11:03.903 UTC Fri May 25 2012)
rcv time D36968B7.A2F44E2C (02:11:03.636 UTC Fri May 25 2012)
xmt time D36968B7.A21D3780 (02:11:03.633 UTC Fri May 25 2012)
filtdelay = 2.99 2.88 976.61 574.65 984.71 220.26 168.12 2.72
filtoffset = 268.30 172.15 -452.49 -253.59 -462.03 -81.98 -58.04 22.38
filterror = 0.02 0.99 1.95 1.97 2.00 2.01 2.03 2.04
10.3.2.254 configured, selected, sane, valid, stratum 1
ref ID .GPS., time D36968BB.B16C4A21 (02:11:07.693 UTC Fri May 25 2012)
our mode client, peer mode server, our poll intvl 64, peer poll intvl 64
root delay 0.00 msec, root disp 3.34, reach 377, sync dist 192.169
delay 0.84 msec, offset 280.3251 msec, dispersion 188.42
precision 2**19, version 3
org time D36968BD.E69085E4 (02:11:09.900 UTC Fri May 25 2012)
rcv time D36968BD.9EE9048B (02:11:09.620 UTC Fri May 25 2012)
xmt time D36968BD.9EA943EF (02:11:09.619 UTC Fri May 25 2012)
filtdelay = 0.84 0.75 663.68 0.67 0.72 968.05 714.07 1.14
filtoffset = 280.33 178.13 -286.52 42.88 41.41 -444.37 -320.25 35.15
filterror = 0.02 0.99 1.97 1.98 1.98 2.00 2.03 2.03
10.1.2.254 configured, insane, invalid, stratum 1
ref ID .GPS., time D3696D3D.BBB4FF24 (02:30:21.733 UTC Fri May 25 2012)
our mode client, peer mode server, our poll intvl 64, peer poll intvl 64
root delay 0.00 msec, root disp 4.15, reach 1, sync dist 15879.654
delay 0.98 msec, offset 11.9876 msec, dispersion 15875.02
precision 2**19, version 3
org time D3696D3D.E4C253FE (02:30:21.893 UTC Fri May 25 2012)
rcv time D3696D3D.E1D0C1B9 (02:30:21.882 UTC Fri May 25 2012)
xmt time D3696D3D.E18A748D (02:30:21.881 UTC Fri May 25 2012)
filtdelay = 0.98 0.00 0.00 0.00 0.00 0.00 0.00 0.00
filtoffset = 11.99 0.00 0.00 0.00 0.00 0.00 0.00 0.00
filterror = 0.02 16000.0 16000.0 16000.0 16000.0 16000.0 16000.0 16000.0
لا يتم تكرار الشروط المحددة مسبقا في قسم الاقتران show up هنا.
مدة |
الشرح | |||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
مكون |
تم تكوين مصدر ساعة NTP هذا ليكون خادما. يمكن أن تكون هذه القيمة ديناميكية أيضا، حيث تم اكتشاف النظير/الخادم بشكل ديناميكي. |
|||||||||||||||||||||||||||
الأساسي الخاص بنا |
تمت مزامنة العميل المحلي مع هذا النظير. |
|||||||||||||||||||||||||||
إنتقيوا |
يتم تحديد النظير/الخادم للمزامنة المحتملة، عند فشل_primary، أو عند فقد العميل المزامنة. |
|||||||||||||||||||||||||||
عاقل |
يتم إستخدام إختبارات السلامة لاختبار حزمة NTP التي يتم استقبالها من خادم. يتم تحديد هذه الاختبارات في RFC 1305، مواصفات بروتوكول وقت الشبكة (الإصدار 3) وتنفيذه وتحليله. الاختبارات هي:
تكون بيانات الحزمة صالحة إذا كانت الاختبارات من 1 إلى 4 pass. ثم يتم إستخدام البيانات لحساب الإزاحة والتأخير والتشتيت. رأس الحزمة صالح إذا كان الاختبار من 5 إلى 8 pass. يمكن إستخدام الحزم ذات الرأس الصالح فقط لتحديد ما إذا كان يمكن تحديد نظير للمزامنة. |
|||||||||||||||||||||||||||
مجانين |
فشلت عمليات التحقق من سلامة النظام، لذا لم يتم قبول الوقت من الخادم. الخادم غير متزامن. |
|||||||||||||||||||||||||||
صالح |
وقت النظير/الخادم صالح. يقبل العميل المحلي هذه المرة إذا أصبح هذا النظير هو الأساسي. |
|||||||||||||||||||||||||||
غير صالح |
وقت النظير/الخادم غير صالح، ولا يمكن قبول الوقت. |
|||||||||||||||||||||||||||
معرف المرجع |
تم تعيين معرف مرجع (تسمية) لكل نظير/خادم. |
|||||||||||||||||||||||||||
زمن |
الوقت هو آخر طابع وقت تم إستلامه من هذا النظير/الخادم. |
|||||||||||||||||||||||||||
الوضع/ وضع النظير |
هذه هي حالة العميل/النظير المحلي. |
|||||||||||||||||||||||||||
مركز إستطلاع الرأي/ مركز إستطلاع الأقران |
هذه هي فترة الاستقصاء من الاستقصاء إلى هذا النظير، أو من النظير إلى الجهاز المحلي. |
|||||||||||||||||||||||||||
تأخير جذري |
التأخير الجذري هو التأخير بالمللي ثانية إلى جذر إعداد NTP. تعتبر ساعات الطبقة 1 في جذر إعداد/تصميم NTP. في المثال، يمكن أن تكون جميع الخوادم الثلاثة هي الجذر لأنها موجودة في الطبقة الأولى. |
|||||||||||||||||||||||||||
تشتت جذري |
التشتيت الجذري هو أقصى فرق زمني للساعة تمت ملاحظته على الإطلاق بين الساعة المحلية والساعة الجذر. راجع شرح DISP تحت اقتران العرض للحصول على مزيد من التفاصيل. |
|||||||||||||||||||||||||||
مسؤول المزامنة. |
هذا تقدير لأقصى فرق بين الوقت في مصدر الطبقة صفر والوقت الذي يتم قياسه بواسطة العميل. وهو يتكون من مكونات لطول الرحلة، دقة النظام، وانسياب الساعة منذ آخر قراءة فعلية لمصدر الطبقة العليا. في إعداد NTP كبير (خوادم NTP في الطبقة 1 في الإنترنت، مع خوادم مصدر الوقت في طبقات مختلفة) مع خوادم/عملاء في طبقات متعددة، يجب تنظيم مخطط مزامنة NTP من أجل إنتاج أعلى دقة، ولكن يجب عدم السماح لها بتكوين حلقة مزامنة زمنية. والعامل الإضافي هو أن كل زيادة في المستوى تتضمن خادم وقت لا يمكن الاعتماد عليه، والذي يقدم أخطاء قياس إضافية. تستخدم خوارزمية التحديد المستخدمة في بروتوكول وقت الشبكة (NTP) متغير من خوارزمية التوجيه الموزعة Bellman-Ford من أجل حساب الأشجار المتفرعة ذات الوزن الأدنى المتأصلة في الخوادم الأساسية. يتكون قياس المسافة الذي تستخدمه الخوارزمية من الطبقة العليا بالإضافة إلى مسافة المزامنة، والتي تتألف بدورها من التشتيت مضافا إليه نصف التأخير المطلق. وبالتالي، فإن مسار المزامنة يأخذ دائما الحد الأدنى لعدد الخوادم إلى الجذر، ويتم حل الروابط على أساس الحد الأقصى للخطأ. |
|||||||||||||||||||||||||||
تأخير |
هذا هو تأجيل جولة إلى نظير. |
|||||||||||||||||||||||||||
دقة |
هذه هي دقة ساعة النظير بهرتز. |
|||||||||||||||||||||||||||
الإصدار |
هذا هو رقم إصدار NTP المستخدم من قبل النظير. |
|||||||||||||||||||||||||||
وقت المؤسسة |
هذا هو الطابع الزمني لمنشئ حزمة NTP؛ بمعنى آخر، هو طابع وقت النظير عند إنشاء حزمة NTP ولكن قبل أن يرسل الحزمة إلى العميل المحلي. |
|||||||||||||||||||||||||||
وقت rcv |
هذا هو الطابع الزمني الذي تلقى فيه العميل المحلي الرسالة. الفرق بين وقت المؤسسة ووقت RCV هو الإزاحة لهذا النظير. في المثال، الإصدار الأساسي 10.4.2.254 يتضمن هذه الأوقات: org time D36968B7.E74172BF (02:11:03.903 UTC Fri May 25 2012) الفرق هو الإزاحة من 268.3044 ميللي ثانية. |
|||||||||||||||||||||||||||
وقت xmt |
هذا هو طابع وقت الإرسال لحزمة NTP التي يرسلها العميل المحلي إلى هذا النظير/الخادم. |
|||||||||||||||||||||||||||
فلتاجيل |
هذا هو تأخير الذهاب بالمللي ثانية لكل عينة. العينة هي آخر حزمة NTP يتم استقبالها. في المثال، يحتوي الأساسي 10.4.2.254 على القيم التالية: filtdelay = 2.99 2.88 976.61 574.65 984.71 220.26 168.12 2.72 تتوافق هذه العينات الثمانية مع قيمة حقل الوصول، والذي يظهر ما إذا كان العميل المحلي استلم حزم NTP الثماني الأخيرة. |
هذا مثال على الإخراج من الأمر show ntp status:
USSP-B33S-SW01#sho ntp status
Clock is synchronized, stratum 2, reference is 10.4.2.254
nominal freq is 250.0000 Hz, actual freq is 250.5630 Hz, precision is 2**18
reference time is D36968F7.7E3019A9 (02:12:07.492 UTC Fri May 25 2012)
clock offset is 417.2868 msec, root delay is 2.85 msec
root dispersion is 673.42 msec, peer dispersion is 261.80 msec
ولا يتم تكرار الشروط المحددة مسبقا في قسم show ntp association detail أو قسم show ntp association detail.
مدة | الشرح |
---|---|
دقة |
ويتم تحديد الدقة تلقائيا ويتم قياسها بمقدار قوتين. في المثال، 2**18 يعني 2^(-18)، أو 3.8 ميكروثانية. قد يرجع فقد المزامنة بين أقران بروتوكول وقت الشبكة (NTP) أو بين عميل أساسي إلى مجموعة متنوعة من الأسباب. يتجنب NTP المزامنة مع جهاز يمكن أن يكون وقته مبهما بهذه الطرق:
|
وفيما يلي بعض الأسباب الأكثر شيوعا لمسائل بروتوكول الاتصال عبر الشبكة:
تتضمن أوامر تصحيح الأخطاء المهمة التي تساعد في عزل سبب هذه المشاكل:
توضح الأقسام التالية إستخدام تصحيح الأخطاء لحل هذه المشكلات الشائعة.
ملاحظة: أستخدم أداة بحث الأوامر للحصول على مزيد من المعلومات حول الأوامر المستخدمة في هذا القسم. يمكن فقط لمستخدمي Cisco المسجلين الوصول إلى الأدوات والمعلومات الداخلية.
ملاحظة: راجع المعلومات المهمة حول أوامر التصحيح قبل استخدام أوامر debug.
أستخدم الأمر debug ip packet للتحقق من تلقي حزم NTP وإرسالها. بما أن إخراج تصحيح الأخطاء يمكن أن يكون المحادثة، فيمكنك الحد من إخراج تصحيح الأخطاء باستخدام قوائم التحكم في الوصول (ACLs). يستخدم NTP منفذ بروتوكول مخطط بيانات المستخدم (UDP) 123.
access-list 101 permit udp any any eq 123عادة ما يكون لحزم NTP منفذ مصدر ووجهة بقيمة 123، لذلك فهذا يساعد:
access-list 101 permit udp any eq 123 any
permit udp any eq 123 any eq 123
debug ip packet 101
access-list 101 permit udp host 172.16.1.1 any eq 123
access-list 101 permit udp any eq 123 host 172.16.1.1
يشير إخراج المثال هذا إلى أن الحزم لا يتم إرسالها:
241925: Apr 23 2012 15:46:26.101 ETE: IP: s=10.50.38.70 (Tunnel99), d=10.50.44.101, len 76, input feature
241926: Apr 23 2012 15:46:26.101 ETE: UDP src=123, dst=123, Ingress-NetFlow(13), rtype 0, forus FALSE,
sendself FALSE, mtu 0
241927: Apr 23 2012 15:46:26.101 ETE: IP: s=10.50.38.70 (Tunnel99), d=10.50.44.101, len 76, input feature
241928: Apr 23 2012 15:46:26.101 ETE: UDP src=123, dst=123, MCI Check(55), rtype 0, forus FALSE,
sendself FALSE, mtu 0
بمجرد تأكيد عدم تلقي حزم NTP، يجب عليك:
مع تمكين كل من أوامر debug ip packet وdebug ntp packet، يمكنك رؤية الحزم التي يتم استقبالها وإرسالها، ويمكنك أن ترى أن NTP يعمل على هذه الحزم. لكل حزمة NTP يتم استقبالها (كما هو موضح بواسطة حزمة IP debug)، هناك إدخال مطابق يتم إنشاؤه بواسطة حزم NTP لتصحيح الأخطاء .
هذا هو إخراج تصحيح الأخطاء عندما تعمل عملية NTP على الحزم المستلمة:
Apr 20 00:16:34.143 UTC: IP: tableid=0, s=10.3.2.31 (local), d=10.1.2.254 (Vlan2), routed via FIB
.Apr 20 00:16:34.143 UTC: IP: s=10.3.2.31 (local), d=10.1.2.254 (Vlan2), len 76, sending
.Apr 20 00:16:34.143 UTC: IP: s=10.3.2.31 (local), d=10.1.2.254 (Vlan2), len 76, sending full packet
.Apr 20 00:16:34.143 UTC: NTP: xmit packet to 10.1.2.254:
.Apr 20 00:16:34.143 UTC: leap 3, mode 3, version 3, stratum 0, ppoll 64
.Apr 20 00:16:34.143 UTC: rtdel 0021 (0.504), rtdsp 1105E7 (17023.056), refid 0A0102FE (10.1.2.254)
.Apr 20 00:16:34.143 UTC: ref D33B2922.24FEBDC7 (00:15:30.144 UTC Fri Apr 20 2012)
.Apr 20 00:16:34.143 UTC: org 00000000.00000000 (00:00:00.000 UTC Mon Jan 1 1900)
.Apr 20 00:16:34.143 UTC: rec 00000000.00000000 (00:00:00.000 UTC Mon Jan 1 1900)
.Apr 20 00:16:34.143 UTC: xmt D33B2962.24CAFAD1 (00:16:34.143 UTC Fri Apr 20 2012)
.Apr 20 00:16:34.143 UTC: IP: s=10.1.2.254 (Vlan2), d=10.3.2.31, len 76, rcvd 2
.Apr 20 00:16:34.143 UTC: NTP: rcv packet from 10.1.2.254 to 10.3.2.31 on Vlan2:
.Apr 20 00:16:34.143 UTC: leap 0, mode 4, version 3, stratum 1, ppoll 64
.Apr 20 00:16:34.143 UTC: rtdel 0000 (0.000), rtdsp 009D (2.396), refid 47505300 (10.80.83.0)
.Apr 20 00:16:34.143 UTC: ref D33B2952.4CC11CCF (00:16:18.299 UTC Fri Apr 20 2012)
.Apr 20 00:16:34.143 UTC: org D33B2962.24CAFAD1 (00:16:34.143 UTC Fri Apr 20 2012)
.Apr 20 00:16:34.143 UTC: rec D33B2962.49D3724D (00:16:34.288 UTC Fri Apr 20 2012)
.Apr 20 00:16:34.143 UTC: xmt D33B2962.49D997D0 (00:16:34.288 UTC Fri Apr 20 2012)
.Apr 20 00:16:34.143 UTC: inp D33B2962.25010310 (00:16:34.144 UTC Fri Apr 20 2012)
.Apr 20 00:16:36.283 UTC: IP: tableid=0, s=10.3.2.31 (local), d=10.8.2.254 (Vlan2), routed via FIB
.Apr 20 00:16:36.283 UTC: IP: s=10.3.2.31 (local), d=10.8.2.254 (Vlan2), len 76, sending
.Apr 20 00:16:36.283 UTC: IP: s=10.3.2.31 (local), d=10.8.2.254 (Vlan2), len 76, sending full packet
.Apr 20 00:16:36.283 UTC: NTP: xmit packet to 10.8.2.254:
.Apr 20 00:16:36.283 UTC: leap 3, mode 3, version 3, stratum 0, ppoll 64
.Apr 20 00:16:36.283 UTC: rtdel 002F (0.717), rtdsp 11058F (17021.713), refid 0A0102FE (10.1.2.254)
.Apr 20 00:16:36.283 UTC: ref D33B2962.25010310 (00:16:34.144 UTC Fri Apr 20 2012)
.Apr 20 00:16:36.283 UTC: org 00000000.00000000 (00:00:00.000 UTC Mon Jan 1 1900)
.Apr 20 00:16:36.283 UTC: rec 00000000.00000000 (00:00:00.000 UTC Mon Jan 1 1900)
.Apr 20 00:16:36.283 UTC: xmt D33B2964.48947E87 (00:16:36.283 UTC Fri Apr 20 2012)
.Apr 20 00:16:36.283 UTC: IP: s=10.8.2.254 (Vlan2), d=10.3.2.31, len 76, rcvd 2
.Apr 20 00:16:36.283 UTC: NTP: rcv packet from 10.8.2.254 to 10.3.2.31 on Vlan2:
.Apr 20 00:16:36.283 UTC: leap 0, mode 4, version 3, stratum 1, ppoll 64
.Apr 20 00:16:36.283 UTC: rtdel 0000 (0.000), rtdsp 0017 (0.351), refid 47505300 (10.80.83.0)
.Apr 20 00:16:36.283 UTC: ref D33B295B.8AF7FE33 (00:16:27.542 UTC Fri Apr 20 2012)
.Apr 20 00:16:36.283 UTC: org D33B2964.48947E87 (00:16:36.283 UTC Fri Apr 20 2012)
.Apr 20 00:16:36.283 UTC: rec D33B2964.4A6AD269 (00:16:36.290 UTC Fri Apr 20 2012)
.Apr 20 00:16:36.283 UTC: xmt D33B2964.4A7C00D0 (00:16:36.290 UTC Fri Apr 20 2012)
.Apr 20 00:16:36.283 UTC: inp D33B2964.498A755D (00:16:36.287 UTC Fri Apr 20 2012)
هذا مثال حيث لا يعمل NTP على الحزم المستلمة. على الرغم من تلقي حزم NTP (كما هو موضح بواسطة حزم IP debug)، إلا أن عملية NTP لا تعمل عليها. بالنسبة لحزم NTP التي يتم إرسالها، يكون إخراج حزم NTP المطابقة موجودا، نظرا لأنه يجب أن تقوم عملية NTP بإنشاء الحزمة. تكون المشكلة محددة لحزم NTP المستلمة التي لم تتم معالجتها.
071564: Apr 23 2012 15:46:26.100 ETE: NTP: xmit packet to 10.50.44.101:
071565: Apr 23 2012 15:46:26.100 ETE: leap 0, mode 1, version 3, stratum 5, ppoll 1024
071566: Apr 23 2012 15:46:26.100 ETE: rtdel 07B5 (30.106), rtdsp 0855 (32.547), refid 0A32266A
(10.50.38.106)
071567: Apr 23 2012 15:46:26.100 ETE: ref D33FDB05.1A084831 (15:43:33.101 ETE Mon Apr 23 2012)
071568: Apr 23 2012 15:46:26.100 ETE: org 00000000.00000000 (01:00:00.000 HIVER Mon Jan 1 1900)
071569: Apr 23 2012 15:46:26.100 ETE: rec 00000000.00000000 (01:00:00.000 HIVER Mon Jan 1 1900)
071570: Apr 23 2012 15:46:26.100 ETE: xmt D33FDBB2.19D3457C (15:46:26.100 ETE Mon Apr 23 2012)
PCY_PAS1#
071571: Apr 23 2012 15:47:31.497 ETE: IP: s=10.50.38.78 (Tunnel99), d=10.50.44.69, len 76, input feature
071572: Apr 23 2012 15:47:31.497 ETE: UDP src=123, dst=123, Ingress-NetFlow(13), rtype 0, forus FALSE,
sendself FALSE, mtu 0
071573: Apr 23 2012 15:47:31.497 ETE: IP: s=10.50.38.78 (Tunnel99), d=10.50.44.69, len 76, input feature
071574: Apr 23 2012 15:47:31.497 ETE: UDP src=123, dst=123, MCI Check(55), rtype 0, forus FALSE,
sendself FALSE, mtu 0
071575: Apr 23 2012 15:47:31.497 ETE: FIBipv4-packet-proc: route packet from Tunnel99 src 10.50.38.78 dst
10.50.44.69
071576: Apr 23 2012 15:47:31.497 ETE: FIBfwd-proc: base:10.50.44.69/32 receive entry
PCY_PAS1#
071577: Apr 23 2012 15:47:31.497 ETE: FIBipv4-packet-proc: packet routing failed
071578: Apr 23 2012 15:47:31.497 ETE: IP: s=10.50.38.78 (Tunnel99), d=10.50.44.69, len 76, rcvd 2
071579: Apr 23 2012 15:47:31.497 ETE: UDP src=123, dst=123
071580: Apr 23 2012 15:47:31.497 ETE: IP: s=10.50.38.78 (Tunnel99), d=10.50.44.69, len 76, stop process pak
for forus packet
071581: Apr 23 2012 15:47:31.497 ETE: UDP src=123, dst=123
PCY_PAS1#
071582: Apr 23 2012 16:03:30.105 ETE: NTP: xmit packet to 10.50.44.101:
071583: Apr 23 2012 16:03:30.105 ETE: leap 0, mode 1, version 3, stratum 5, ppoll 1024
071584: Apr 23 2012 16:03:30.105 ETE: rtdel 0759 (28.702), rtdsp 087D (33.157), refid 0A32266A
(10.50.38.106)
071585: Apr 23 2012 16:03:30.105 ETE: ref D33FDF05.1B2CC3D4 (16:00:37.106 ETE Mon Apr 23 2012)
071586: Apr 23 2012 16:03:30.105 ETE: org 00000000.00000000 (01:00:00.000 HIVER Mon Jan 1 1900)
071587: Apr 23 2012 16:03:30.105 ETE: rec 00000000.00000000 (01:00:00.000 HIVER Mon Jan 1 1900)
071588: Apr 23 2012 16:03:30.105 ETE: xmt D33FDFB2.1B1D5E7E (16:03:30.105 ETE Mon Apr 23 2012)
PCY_PAS1#
071589: Apr 23 2012 16:04:35.502 ETE: IP: s=10.50.38.78 (Tunnel99), d=10.50.44.69, len 76, input feature
071590: Apr 23 2012 16:04:35.506 ETE: UDP src=123, dst=123, Ingress-NetFlow(13), rtype 0, forus FALSE,
sendself FALSE, mtu 0
071591: Apr 23 2012 16:04:35.506 ETE: IP: s=10.50.38.78 (Tunnel99), d=10.50.44.69, len 76, input feature
071592: Apr 23 2012 16:04:35.506 ETE: UDP src=123, dst=123, MCI Check(55), rtype 0, forus FALSE,
sendself FALSE, mtu 0
071593: Apr 23 2012 16:04:35.506 ETE: FIBipv4-packet-proc: route packet from Tunnel99 src 10.50.38.78 dst
10.50.44.69
071594: Apr 23 2012 16:04:35.506 ETE: FIBfwd-proc: base:10.50.44.69/32 receive entry
PCY_PAS1#
071595: Apr 23 2012 16:04:35.506 ETE: FIBipv4-packet-proc: packet routing failed
071596: Apr 23 2012 16:04:35.506 ETE: IP: s=10.50.38.78 (Tunnel99), d=10.50.44.69, len 76, rcvd 2
071597: Apr 23 2012 16:04:35.506 ETE: UDP src=123, dst=123
071598: Apr 23 2012 16:04:35.506 ETE: IP: s=10.50.38.78 (Tunnel99), d=10.50.44.69, len 76, stop process pak
for forus packet
071599: Apr 23 2012 16:04:35.506 ETE: UDP src=123, dst=123
PCY_PAS1#
يمكن أن يحدث فقد المزامنة إذا كانت قيمة التشتيت و/أو التأخير للخادم عالية جدا. تشير القيم العالية إلى أن الحزم تستغرق وقتا طويلا جدا للوصول إلى العميل من الخادم/النظير في إشارة إلى جذر الساعة. لذلك لا يمكن للجهاز المحلي الوثوق بدقة الوقت الحاضر في الحزمة، لأنه لا يعرف كم استغرق وصول الحزمة إلى هنا.
يتسم بروتوكول وقت الشبكة (NTP) بالدقة الشديدة حول الوقت ولا يمكنه المزامنة مع جهاز آخر لا يمكنه الوثوق به أو لا يمكنه ضبطه بطريقة يمكن الوثوق به.
إذا كان هناك إرتباط مشبع ويتم التخزين المؤقت على طول الطريق، يتم تأخير الحزم كلما وصلت إلى عميل NTP. لذلك، فإن الطابع الزمني الموجود في حزمة NTP التالية يمكن أن يختلف من وقت لآخر كثيرا، ولا يمكن للعميل المحلي حقا الضبط لذلك التباين.
لا يقدم NTP طريقة لإيقاف تشغيل التحقق من صحة هذه الحزم ما لم تستخدم بروتوكول وقت الشبكة البسيط (SNTP). لا يعد SNTP بديلا كثيرا لأنه غير مدعوم على نطاق واسع في البرامج.
إذا واجهت خسارة في المزامنة، فيجب عليك التحقق من الارتباطات:
مراقبة قيمة الوصول من الأمر show ntp associations detail. أعلى قيمة هي 377. إذا كانت القيمة 0 أو منخفضة، يتم تلقي حزم NTP بشكل متقطع، ويخرج العميل المحلي عن المزامنة مع الخادم.
يشير الأمر debug ntp validity إلى ما إذا كانت حزمة NTP قد فشلت في الصحة أو في التحقق من الصحة ويكشف سبب الفشل. قارن هذا الإخراج مع إختبارات السلامة المحددة في RFC1305 التي يتم إستخدامها لاختبار حزمة NTP التي يتم استقبالها من خادم. تم تحديد ثمانية إختبارات:
إختبار |
القناع |
الشرح |
---|---|---|
1 |
0x01 |
تم تلقي حزمة مكررة. |
2 |
0x02 |
تم إستلام حزمة وهمية. |
3 |
0x04 |
البروتوكول غير متزامن. |
4 |
0x08 |
فشل تدقيق الحدود بين تأخير/تشتيت النظير. |
5 |
0x10 |
فشلت مصادقة النظير. |
6 |
0x20 |
ساعة النظير غير متزامنة (شائع للخادم غير المتزامن). |
7 |
0x40 |
طبقة النظير خارج الربط. |
8 |
0x80 |
فشل تأخير/تشتيت الجذر في فحص الحدود. |
هذا نموذج إخراج من الأمر debug ntp validity:
PCY_PAS1#debug ntp validity
NTP peer validity debugging is on
009585: Mar 1 2012 09:14:32.670 HIVER: NTP: packet from 192.168.113.57 failed validity tests 52
009586: Mar 1 2012 09:14:32.670 HIVER: Authentication failed
009587: Mar 1 2012 09:14:32.670 HIVER: Peer/Server Stratum out of bound
PCY_PAS1#
009588: Mar 1 2012 09:14:38.210 HIVER: NTP: packet from 192.168.56.1 failed validity tests 14
009589: Mar 1 2012 09:14:38.210 HIVER: Authentication failed
PCY_PAS1#
009590: Mar 1 2012 09:14:43.606 HIVER: NTP: packet from 10.110.103.27 failed validity tests 14
009591: Mar 1 2012 09:14:43.606 HIVER: Authentication failed
PCY_PAS1#
009592: Mar 1 2012 09:14:48.686 HIVER: NTP: packet from 192.168.113.57failed validity tests 52
009593: Mar 1 2012 09:14:48.686 HIVER: Authentication failed
009594: Mar 1 2012 09:14:48.686 HIVER: Peer/Server Stratum out of bound
PCY_PAS1#
009596: Mar 1 2012 09:14:54.222 HIVER: NTP: packet from 10.110.103.35 failed validity tests 14
009597: Mar 1 2012 09:14:54.222 HIVER: Authentication failed
PCY_PAS1#
009598: Mar 1 2012 09:14:54.886 HIVER: NTP: synced to new peer 10.50.38.106
009599: Mar 1 2012 09:14:54.886 HIVER: NTP: 10.50.38.106 synced to new peer
PCY_PAS1#
009600: Mar 1 2012 09:14:59.606 HIVER: NTP: packet from 10.110.103.27 failed validity tests 14
009601: Mar 1 2012 09:14:59.606 HIVER: Authentication failed
PCY_PAS1#
009602: Mar 1 2012 09:15:04.622 HIVER: NTP: packet from 192.168.113.137 failed validity tests 52
009603: Mar 1 2012 09:15:04.622 HIVER: Authentication failed
009604: Mar 1 2012 09:15:04.622 HIVER: Peer/Server Stratum out of bound
PCY_PAS1#
009605: Mar 1 2012 09:15:10.238 HIVER: NTP: packet from 192.168.56.1 failed validity tests 14
009606: Mar 1 2012 09:15:10.238 HIVER: Authentication failed
PCY_PAS1#
009607: Mar 1 2012 09:15:15.338 HIVER: NTP: packet from 10.83.23.140 failed validity tests 52
009608: Mar 1 2012 09:15:15.338 HIVER: Authentication failed
009609: Mar 1 2012 09:15:15.338 HIVER: Peer/Server Stratum out of bound
PCY_PAS1#
009610: Mar 1 2012 09:15:20.402 HIVER: NTP: packet from 192.168.113.92 failed validity tests 74
009611: Mar 1 2012 09:15:20.402 HIVER: Authentication failed
009612: Mar 1 2012 09:15:20.402 HIVER: Peer/Server Clock unsynchronized
009613: Mar 1 2012 09:15:20.402 HIVER: Peer/Server Stratum out of bound
يمكنك إستخدام الأمر debug ntp packet لعرض الوقت الذي يمنحك إياه النظير/الخادم في الحزمة المستلمة. يخبر الجهاز المحلي بالوقت أيضا الوقت الذي يعرفه للنظير/الخادم في الحزمة التي تم إرسالها.
الحقل | حزمة RCV | حزمة xmit |
---|---|---|
منظمة | الطابع الزمني للمنشئ، وهو وقت الخادم. | الطابع الزمني للمنشئ (العميل) عند إرسال الحزمة. (يقوم العميل بإنشاء حزمة إلى الخادم.) |
rec | الطابع الزمني على العميل عند تلقيه الحزمة. | وقت العميل الحالي. |
في إخراج النموذج هذا، تكون الطوابع الزمنية في الحزمة المستلمة من الخادم والحزمة المرسلة إلى خادم آخر هي نفسها، وهو ما يشير إلى أن بروتوكول وقت الشبكة (NTP) الخاص بالعميل متزامن.
USSP-B33S-SW01#debug ntp packets
NTP packets debugging is on
USSP-B33S-SW01#
May 25 02:21:48.182 UTC: NTP: rcv packet from 10.1.2.254 to 10.3.2.31 on Vlan2:
May 25 02:21:48.182 UTC: leap 0, mode 4, version 3, stratum 1, ppoll 64
May 25 02:21:48.182 UTC: rtdel 0000 (0.000), rtdsp 00F2 (3.693), refid 47505300 (10.80.83.0)
May 25 02:21:48.182 UTC: ref D3696B38.B722C417 (02:21:44.715 UTC Fri May 25 2012)
May 25 02:21:48.182 UTC: org D3696B3C.2EA179BA (02:21:48.182 UTC Fri May 25 2012)
May 25 02:21:48.182 UTC: rec D3696B3D.E58DE1BE (02:21:49.896 UTC Fri May 25 2012)
May 25 02:21:48.182 UTC: xmt D3696B3D.E594E7AF (02:21:49.896 UTC Fri May 25 2012)
May 25 02:21:48.182 UTC: inp D3696B3C.2EDFC333 (02:21:48.183 UTC Fri May 25 2012)
May 25 02:22:46.051 UTC: NTP: xmit packet to 10.4.2.254:
May 25 02:22:46.051 UTC: leap 0, mode 3, version 3, stratum 2, ppoll 64
May 25 02:22:46.051 UTC: rtdel 00C0 (2.930), rtdsp 1C6FA (1777.252), refid 0A0402FE (10.4.2.254)
May 25 02:22:46.051 UTC: ref D3696B36.33D43F44 (02:21:42.202 UTC Fri May 25 2012)
May 25 02:22:46.051 UTC: org D3696B37.E72C75AE (02:21:43.903 UTC Fri May 25 2012)
May 25 02:22:46.051 UTC: rec D3696B36.33D43F44 (02:21:42.202 UTC Fri May 25 2012)
May 25 02:22:46.051 UTC: xmt D3696B76.0D43AE7D (02:22:46.051 UTC Fri May 25 2012)
هذا مثال للإخراج عندما تكون الساعات غير متزامنة. لاحظ فرق الوقت بين حزمة xmit وحزمة rcv. يمكن أن يكون التشتيت النظير في القيمة القصوى 16000، ويمكن أن يظهر المدى للنظير 0.
USSP-B33S-SW01#
.May 25 02:05:59.011 UTC: NTP: xmit packet to 10.4.2.254:
.May 25 02:05:59.011 UTC: leap 3, mode 3, version 3, stratum 0, ppoll 64
.May 25 02:05:59.011 UTC: rtdel 00A3 (2.487), rtdsp 1104D0 (17018.799), refid 0A0402FE (10.4.2.254)
.May 25 02:05:59.011 UTC: ref D3696747.03D8661A (02:04:55.015 UTC Fri May 25 2012)
.May 25 02:05:59.011 UTC: org 00000000.00000000 (00:00:00.000 UTC Mon Jan 1 1900)
.May 25 02:05:59.011 UTC: rec 00000000.00000000 (00:00:00.000 UTC Mon Jan 1 1900)
.May 25 02:05:59.011 UTC: xmt D3696787.03105783 (02:05:59.011 UTC Fri May 25 2012)
.May 25 02:05:59.011 UTC: NTP: rcv packet from 10.4.2.254 to 10.3.2.31 on Vlan2:
.May 25 02:05:59.011 UTC: leap 0, mode 4, version 3, stratum 1, ppoll 64
.May 25 02:05:59.011 UTC: rtdel 0000 (0.000), rtdsp 0014 (0.305), refid 47505300 (10.80.83.0)
.May 25 02:05:59.011 UTC: ref D3696782.C96FD778 (02:05:54.786 UTC Fri May 25 2012)
.May 25 02:05:59.011 UTC: org D3696787.03105783 (02:05:59.011 UTC Fri May 25 2012)
.May 25 02:05:59.011 UTC: rec D3696787.281A963F (02:05:59.156 UTC Fri May 25 2012)
.May 25 02:05:59.011 UTC: xmt D3696787.282832C4 (02:05:59.156 UTC Fri May 25 2012)
.May 25 02:05:59.011 UTC: inp D3696787.03C63542 (02:05:59.014 UTC Fri May 25 2012)
ينتج الأمر debug ntp sync مخرجات سطر واحد التي تظهر ما إذا كانت الساعة قد تمت مزامنتها أو أن المزامنة قد تغيرت. يتم تمكين الأمر بشكل عام مع أحداث تصحيح الأخطاء NTP.
يعرض الأمر debug ntp events أي أحداث NTP تحدث، والتي تساعدك على تحديد ما إذا كان التغيير في NTP قد أدى إلى إصدار مثل الساعات التي تخرج عن المزامنة. (بعبارة أخرى، إذا تحولت ساعاتك التي تزامنت بسعادة إلى جنون فجأة، فأنت تعلم كيف تبحث عن التغيير أو المشغل!)
هذا مثال على كل من تصحيح الأخطاء. في البداية تمت مزامنة ساعات العميل. يظهر الأمر debug ntp events أن تغيير طبقة نظير NTP قد حدث، والساعات بعد ذلك لم تعد متزامنة.
USSP-B33S-SW01#debug ntp sync
NTP clock synchronization debugging is on
USSP-B33S-SW01#
USSP-B33S-SW01#
USSP-B33S-SW01#debug ntp events
NTP events debugging is on
USSP-B33S-SW01#
USSP-B33S-SW01#
May 25 02:25:57.620 UTC: NTP: xmit packet to 10.4.2.254:
May 25 02:25:57.620 UTC: leap 0, mode 3, version 3, stratum 2, ppoll 64
May 25 02:25:57.620 UTC: rtdel 00D4 (3.235), rtdsp 26B26 (2418.549), refid 0A0402FE (10.4.2.254)
May 25 02:25:57.620 UTC: ref D3696BF5.C47EB880 (02:24:53.767 UTC Fri May 25 2012)
May 25 02:25:57.620 UTC: org D3696BF7.E5F91077 (02:24:55.898 UTC Fri May 25 2012)
May 25 02:25:57.620 UTC: rec D3696BF5.C47EB880 (02:24:53.767 UTC Fri May 25 2012)
May 25 02:25:57.620 UTC: xmt D3696C35.9ED1CE97 (02:25:57.620 UTC Fri May 25 2012)
May 25 02:25:57.620 UTC: NTP: rcv packet from 10.4.2.254 to 10.3.2.31 on Vlan2:
May 25 02:25:57.620 UTC: leap 0, mode 4, version 3, stratum 1, ppoll 64
May 25 02:25:57.620 UTC: rtdel 0000 (0.000), rtdsp 000E (0.214), refid 47505300 (10.80.83.0)
May 25 02:25:57.620 UTC: ref D3696C37.D528800E (02:25:59.832 UTC Fri May 25 2012)
May 25 02:25:57.620 UTC: org D3696C35.9ED1CE97 (02:25:57.620 UTC Fri May 25 2012)
May 25 02:25:57.620 UTC: rec D3696C37.E5C7AB3D (02:25:59.897 UTC Fri May 25 2012)
May 25 02:25:57.620 UTC: xmt D3696C37.E5D1F273 (02:25:59.897 UTC Fri May 25 2012)
May 25 02:25:57.620 UTC: inp D3696C35.9F9EA2C4 (02:25:57.623 UTC Fri May 25 2012)
May 25 02:25:59.830 UTC: NTP: peer stratum change
May 25 02:25:59.830 UTC: NTP: clock reset
May 25 02:25:59.830 UTC: NTP: sync change
May 25 02:25:59.830 UTC: NTP: peer stratum change
May 25 02:26:05.817 UTC: NTP: xmit packet to 10.1.2.254:
May 25 02:26:05.817 UTC: leap 3, mode 3, version 3, stratum 0, ppoll 64
May 25 02:26:05.817 UTC: rtdel 00C2 (2.960), rtdsp 38E9C (3557.068), refid 0A0402FE (10.4.2.254)
May 25 02:26:05.817 UTC: ref D3696C35.9F9EA2C4 (02:25:57.623 UTC Fri May 25 2012)
May 25 02:26:05.817 UTC: org 00000000.00000000 (00:00:00.000 UTC Mon Jan 1 1900)
May 25 02:26:05.817 UTC: rec 00000000.00000000 (00:00:00.000 UTC Mon Jan 1 1900)
May 25 02:26:05.817 UTC: xmt D3696C3D.D12D0565 (02:26:05.817 UTC Fri May 25 2012)
ويحذر الموقع الشبكي Cisco.com من أن:
"يتم إنشاء الأمر ntp clock-period تلقائيا ليعكس عامل التصحيح الذي يتغير بشكل مستمر عند إدخال الأمر copy running-configuration startup-configuration لحفظ التكوين على ذاكرة NVRAM. لا تحاول إستخدام الأمر ntp clock-period يدويا. تأكد من إزالة سطر الأوامر هذا عند نسخ ملفات التكوين إلى أجهزة أخرى.
تعتمد قيمة فترة الساعة على الأجهزة، لذلك فإنها تختلف لكل جهاز.
يظهر الأمر ntp clock-period تلقائيا في التكوين عند تمكين NTP. يتم إستخدام الأمر لضبط ساعة البرنامج. تعوض قيمة التسوية الفاصل الزمني ل 4 مللي ثانية، بحيث، مع التعديل الثانوي، يكون لديك ثانية واحدة في نهاية الفاصل الزمني.
إذا قام الجهاز بحساب أن ساعة النظام الخاصة به تفقد الوقت (ربما يلزم أن يكون هناك تعويض تردد من المستوى الأساسي للموجه)، فإنه يضيف هذه القيمة تلقائيا إلى ساعة النظام للحفاظ على تزامنها. يجب ألا يقوم المستخدم بتغيير هذا الأمر.
فترة ساعة NTP الافتراضية للموجه هي 17179869 ويتم إستخدامها بشكل أساسي لبدء عملية NTP.
صيغة التحويل هي 17179869 * 2^ (-32) = 0.00399999995715916156768798828125، أو حوالي 4 مللي ثانية.
على سبيل المثال، تم العثور على ساعة النظام لموجهات السلسلة 2611 من Cisco (أحد موجهات سلسلة 2600 من Cisco) غير متزامنة بشكل طفيف ويمكن إعادة تزامنها باستخدام هذا الأمر:
ntp clock-period 17208078
وهذا يساوي 17208078 * 2^ (-32) = 0.004006567876785935760498046875، أو ما يزيد قليلا على 4 مللي ثانية.
cisco يوصي أن يترك أنت المسحاج تخديد يركض لمدة أسبوع أو هكذا في شبكة عادي شرط وبعد ذلك يستعمل ال wr m أمر in order to أنقذت القيمة. هذا يعطيك رقم دقيق لإعادة التشغيل التالية ويسمح NTP بالمزامنة بسرعة أكبر.
أستخدم الأمر no ntp clock-period عند حفظ التكوين للاستخدام على جهاز آخر لأن هذا الأمر يقوم بإسقاط فترة الساعة مرة أخرى إلى الإعداد الافتراضي لذلك الجهاز المعين. يمكنك إعادة حساب القيمة الحقيقية (ولكن يمكنك تقليل دقة ساعة النظام أثناء الفترة الزمنية لإعادة الحساب).
تذكر أن هذه القيمة مرتبطة بالأجهزة، لذلك إذا قمت بنسخ تكوين ما واستخدامه على أجهزة مختلفة، فقد تتسبب في حدوث مشاكل. تخطط Cisco لاستبدال الإصدار 3 من NTP بالإصدار 4 لحل هذه المشكلة.
إذا لم تكن على علم بتلك المشاكل، يمكنك أن تقرر أن تقوم بالتلاعب يدويا بهذه القيمة. للترحيل من جهاز إلى آخر، يمكنك تحديد نسخ التكوين القديم ولصقه على الجهاز الجديد. للأسف، نظرا لظهور الأمر ntp clock-period في running-config و startup-config، يتم لصق فترة ساعة NTP على الجهاز الجديد. عندما يحدث ذلك، دائما ما يكون NTP على العميل الجديد غير متزامن مع الخادم مع قيمة تشتيت عالية للنظير.
بدلا من ذلك، قم بمسح فترة ساعة NTP باستخدام الأمر no ntp clock-period، ثم قم بحفظ التكوين. يقوم الموجه في نهاية المطاف بحساب فترة الساعة المناسبة له.
لم يعد الأمر ntp clock-period متوفرا في برنامج Cisco IOS® الإصدار 15.0 أو إصدار أحدث؛ يرفض المحلل الآن الأمر مع الخطأ:
"%NTP: This configuration command is deprecated."
غير مسموح لك بتكوين فترة الساعة يدويا، ولا يسمح بفترة الساعة في running-config. بما أن المحلل يرفض الأمر إذا كان في تكوين بدء التشغيل (في إصدارات Cisco IOS السابقة مثل 12.4)، فإن المحلل يرفض الأمر عندما ينسخ تكوين بدء التشغيل إلى running-config على التمهيد.
إن الأمر الجديد البديل هو NTP clear drift.
المراجعة | تاريخ النشر | التعليقات |
---|---|---|
4.0 |
12-Nov-2024 |
تم تحديث العنوان ومتطلبات العلامة التجارية والتنسيق. |
3.0 |
15-Aug-2024 |
إعادة الاعتماد. |
2.0 |
15-Feb-2023 |
تنسيق ومعلومات محدثة. CCW المصحح. إعادة الاعتماد. |
1.0 |
06-May-2013 |
الإصدار الأولي |