المحتويات

المقدمة

المتطلبات الأساسية

المتطلبات

المكونات المستخدمة

أوامر عرض NTP

show ntp association

عرض تفاصيل اقتران NTP

عرض حالة ntp

أستكشاف أخطاء NTP وإصلاحها باستخدام تصحيح الأخطاء

حزم NTP غير مستلمة

حزم NTP التي لم تتم معالجتها

فقدان المزامنة

صحة debug ntp

حزم debug ntp

debug ntp sync و debug ntp events

تعيين فترة ساعة NTP يدويا

معلومات ذات صلة

المقدمة

يوضح هذا المستند كيفية أستكشاف أخطاء بروتوكول وقت الشبكة (NTP) وإصلاحها  debug  الأوامر و  show ntp  erasecat4000_flash:.

المتطلبات الأساسية

المتطلبات

لا توجد متطلبات خاصة لهذا المستند.

المكونات المستخدمة

لا يقتصر هذا المستند على إصدارات برامج ومكونات مادية معينة.

تم إنشاء المعلومات الواردة في هذا المستند من الأجهزة الموجودة في بيئة معملية خاصة. بدأت جميع الأجهزة المُستخدمة في هذا المستند بتكوين ممسوح (افتراضي). إذا كانت شبكتك قيد التشغيل، فتأكد من فهمك للتأثير المحتمل لأي أمر.

أوامر عرض NTP

قبل أن ينظر أنت في سبب مشاكل NTP، أنت ينبغي فهمت الإستعمالمن والإخراج من هذا أمر:

- show ntp association

- عرض تفاصيل اقتران NTP

- عرض حالة ntp

ملاحظة: أستخدم أداة بحث الأوامر للحصول على مزيد من المعلومات حول الأوامر المستخدمة في هذا القسم. يمكن فقط لمستخدمي Cisco المسجلين الوصول إلى الأدوات والمعلومات الداخلية.

ملاحظة: تدعم أداة مترجم الإخراج بعض أوامر show. استخدم "أداة مترجم الإخراج" لعرض تحليل لمُخرَج الأمر show. يمكن فقط لمستخدمي Cisco المسجلين الوصول إلى الأدوات والمعلومات الداخلية.

show ntp association

يمكن أن يكون اقتران 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 قبل أن يستنتج أن حزمة قد فقدت. يمكن أن يكون وقت الاستطلاع مختلفا للنظراء المختلفين، لذلك يقرر الوقت قبل الوصول أن الحزمة قد فقدت من الممكن أيضا أن تختلف للنظراء المختلفين.

في المثال، هناك أربع قيم وصول مختلفة:

- 377 octal = 1111111 ثنائي، والذي يشير إلى أن عملية NTP تلقت الحزم الثماني الأخيرة.

- 0 octal = 000000، والذي يشير إلى أن عملية NTP لم تستلم أي حزمة.

- 1 octal = 0000001، والذي يشير إلى أن عملية NTP تلقت أحدث حزمة فقط.

- 357 octal = 1110111، والذي يشير إلى الحزمة قبل فقد الحزم الأربع الأخيرة.

يعد Reach مؤشرا جيدا على ما إذا كان يتم إسقاط حزم NTP بسبب إرتباط ضعيف أو مشاكل وحدة المعالجة المركزية (CPU) أو مشاكل أخرى متقطعة.

محول الوحدة هو محول وحدة عبر الإنترنت لهذا التحويل والعديد من التحويلات الأخرى.

تأخير

يتم الإبلاغ عن تأخر الذهاب والعودة إلى النظير بالمللي ثانية. لتعيين الساعة بشكل أكثر دقة، يتم أخذ هذا التأخير في الاعتبار عند تعيين وقت الساعة.

إزاحة

الإزاحة هي فرق وقت الساعة بين النظراء أو بين الأساسي والعميل. هذه القيمة هي التصحيح الذي يتم تطبيقه على ساعة عميل لمزامنتها. تشير القيمة الموجبة إلى أن ساعة الخادم أعلى. تشير القيمة السالبة إلى أن ساعة العميل أعلى.

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

~10.50.44.69  10.50.36.106   5  21231  1024     0    3.8   -4.26  16000.

على الرغم من أن الإزاحة تساوي -4.26 فقط، إلا أن التشتيت يكون مرتفعا جدا (ربما بسبب حدث سابق)، ويكون الوصول صفرا، لذلك لا يقبل هذا العميل الوقت من هذا الخادم.

عرض تفاصيل اقتران NTP

هذا مثال على الإخراج من الأمر show ntp association detail:

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 هذا ليكون خادما. يمكن أن تكون هذه القيمة ديناميكية أيضا، حيث تم اكتشاف النظير/الخادم بشكل ديناميكي.

الأساسي الخاص بنا

تمت مزامنة العميل المحلي مع هذا النظير.

إنتقيوا

يتم تحديد النظير/الخادم للمزامنة المحتملة عند فشل 'our_primary' أو عند فقدان العميل للمزامنة.

عاقل

يتم إستخدام إختبارات السلامة لاختبار حزمة NTP التي يتم استقبالها من خادم. يتم تحديد هذه الاختبارات في RFC 1305، مواصفات بروتوكول وقت الشبكة (الإصدار 3) وتنفيذه وتحليله. الاختبارات هي:

إختبار

القناع

الشرح

1

0x01

تم تلقي الحزمة المكررة

2

0x02

تم إستلام حزمة وهمية

3

0x04

البروتوكول غير متزامن

4

0x08

التحقق من الحدود فشل تأخير/تشتيت النظير

5

0x10

فشلت مصادقة النظير

6

0x20

ساعة النظير غير متزامنة (شائع للخادم غير المتزامن)

7

0x40

إستراتيجية النظير خارج المجموعة

8

0x80

فحص الحدود فشل تأخير/تشتيت الجذر

بيانات الحزمة صالحة إذا تم تمرير الاختبارات من 1 إلى 4. ثم يتم إستخدام البيانات لحساب الإزاحة والتأخير والتشتيت.

رأس الحزمة صالح إذا تم تمرير الاختبارات 5 إلى 8. يمكن إستخدام الحزم ذات الرأس الصالح فقط لتحديد ما إذا كان يمكن تحديد نظير للمزامنة.

مجانين

فشلت عمليات التحقق من سلامة النظام، لذا لم يتم قبول الوقت من الخادم. الخادم غير متزامن.

صالح

وقت النظير/الخادم صالح. يقبل العميل المحلي هذه المرة إذا أصبح هذا النظير هو الأساسي.

غير صالح

وقت النظير/الخادم غير صالح، ولا يمكن قبول الوقت.

معرف المرجع

تم تعيين معرف مرجع (تسمية) لكل نظير/خادم.

زمن

الوقت هو آخر طابع وقت تم إستلامه من هذا النظير/الخادم.

الوضع/ وضع النظير

هذه هي حالة العميل/النظير المحلي.

مركز إستطلاع الرأي/ مركز إستطلاع الأقران

هذه هي فترة الاستقصاء من الاستقصاء إلى هذا النظير أو من النظير إلى الجهاز المحلي.

تأخير جذري

التأخير الجذري هو التأخير بالمللي ثانية إلى جذر إعداد NTP. تعتبر ساعات الطبقة 1 في جذر إعداد/تصميم NTP. في المثال، يمكن أن تكون جميع الخوادم الثلاثة هي الجذر لأنها موجودة في الطبقة الأولى.

تشتت جذري

التشتيت الجذري هو أقصى فرق زمني للساعة تمت ملاحظته على الإطلاق بين الساعة المحلية والساعة الجذر. ارجع إلى شرح "disp" تحت اقتران العرض للحصول على مزيد من التفاصيل.

مسؤول المزامنة.

هذا تقدير لأقصى فرق بين الوقت في مصدر الطبقة العليا 0 والوقت الذي يقيسه العميل، ويتألف من مكونات لوقت الذهاب والعودة، ودقة النظام، وانجراف الساعة منذ آخر قراءة فعلية لمصدر الطبقة العليا.

في إعداد 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)

rcv time D36968B7.A2F44E2C (02:11:03.636 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

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

تتوافق هذه العينات الثمانية مع قيمة حقل الوصول، والذي يظهر ما إذا كان العميل المحلي استلم حزم NTP الثماني الأخيرة.

عرض حالة 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 أو قسم تفاصيل اقتران show ntp.

مدة

الشرح

دقة

ويتم تحديد الدقة تلقائيا ويتم قياسها بمقدار قوتين. في المثال، 2**18 يعني 2^(-18)، أو 3.8 ميكروثانية.

قد يرجع فقد المزامنة بين أقران بروتوكول وقت الشبكة (NTP) أو بين عميل أساسي إلى مجموعة متنوعة من الأسباب. يتجنب NTP المزامنة مع جهاز يمكن أن يكون وقته مبهما بهذه الطرق:

1. لا يقوم NTP بالمزامنة أبدا مع جهاز لم تتم مزامنته بنفسه.

1. تقوم NTP بمقارنة الوقت الذي يتم الإبلاغ عنه بواسطة العديد من الأجهزة ولا يتم مزامنته مع الجهاز الذي يختلف وقته بشكل ملحوظ عن الأجهزة الأخرى، حتى إذا كانت درجته أقل.

أستكشاف أخطاء NTP وإصلاحها باستخدام تصحيح الأخطاء

وفيما يلي بعض الأسباب الأكثر شيوعا لمسائل بروتوكول الاتصال عبر الشبكة:

- لم يتم إستلام حزم NTP.

- يتم إستلام حزم NTP، ولكن لا تتم معالجتها بواسطة عملية NTP على Cisco IOS.

- تتم معالجة حزم NTP، ولكن تتسبب العوامل الخاطئة أو بيانات الحزم في فقدان المزامنة.

- تم تعيين فترة ساعة NTP يدويا.

تتضمن أوامر تصحيح الأخطاء المهمة التي تساعد في عزل سبب هذه المشاكل:

- debug ip packet <acl>

- حزم debug ntp

- صحة debug ntp

- debug ntp sync

- أحداث debug ntp

توضح الأقسام التالية إستخدام تصحيح الأخطاء لحل هذه المشكلات الشائعة.

ملاحظة: أستخدم أداة بحث الأوامر للحصول على مزيد من المعلومات حول الأوامر المستخدمة في هذا القسم. يمكن فقط لمستخدمي Cisco المسجلين الوصول إلى الأدوات والمعلومات الداخلية.

ملاحظة: ارجع إلى معلومات مهمة عن أوامر تصحيح الأخطاء قبل أن تستخدم أوامر debug.

حزم NTP غير مستلمة

أستخدم الأمر debug ip packet للتحقق من تلقي حزم NTP وإرسالها. بما أن إخراج تصحيح الأخطاء يمكن أن يكون المحادثة، فيمكنك الحد من إخراج تصحيح الأخطاء باستخدام قوائم التحكم في الوصول (ACLs). يستخدم NTP منفذ بروتوكول مخطط بيانات المستخدم (UDP) 123.

1. إنشاء قائمة التحكم في الوصول (ACL) 101:

access-list 101 permit udp any any eq 123

access-list 101 permit udp any eq 123 any
عادة ما يكون لحزم NTP منفذ مصدر ووجهة بقيمة 123، لذلك فهذا يساعد:

permit udp any eq 123 any eq 123

2. أستخدم قائمة التحكم في الوصول (ACL) هذه للحد من الإخراج من الأمر debug ip packet:

debug ip packet 101

3. إذا كانت المشكلة مع أقران معينين، فقم بتقليل قائمة التحكم في الوصول (ACL) رقم 101 إلى هؤلاء الأقران. إذا كان النظير هو 172.16.1.1، فقم بتغيير قائمة التحكم في الوصول (ACL) رقم 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، يجب عليك:

- تحقق من تكوين NTP بشكل صحيح.

- التحقق من حظر قائمة التحكم في الوصول لحزم NTP.

- تحقق من مشاكل التوجيه إلى IP المصدر أو الوجهة.

حزم NTP التي لم تتم معالجتها

مع تمكين كل من أوامر debug ip packet و debug ntp، يمكنك رؤية الحزم التي يتم استقبالها وإرسالها، ويمكنك أن ترى أن 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 المطابقة ل debug 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 بديلا كثيرا لأنه غير مدعوم على نطاق واسع في البرامج.

إذا واجهت خسارة في المزامنة، فيجب عليك التحقق من الارتباطات:

- هل هي مشبعة؟

- هل هناك أي نوع من حالات السقوط في إرتباطات الشبكة واسعة النطاق (WAN) لديك

- هل يحدث التشفير؟

مراقبة قيمة الوصول من الأمر show ntp associations detail. أعلى قيمة هي 377. إذا كانت القيمة 0 أو منخفضة، يتم تلقي حزم NTP بشكل متقطع، ويخرج العميل المحلي عن المزامنة مع الخادم.

صحة debug 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

يمكنك إستخدام الأمر 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 و debug ntp events

ينتج الأمر 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)

تعيين فترة ساعة NTP يدويا

ويحذر الموقع الشبكي 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 mem لحفظ القيمة. هذا يعطيك رقم دقيق لإعادة التشغيل التالية ويسمح 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 متوفرا في الإصدار 15.0 من برنامج Cisco IOS Software أو إصدار أحدث؛ يرفض المحلل الآن الأمر مع الخطأ:

"%NTP: This configuration command is deprecated."

غير مسموح لك بتكوين فترة الساعة يدويا، ولا يسمح بفترة الساعة في running-config. بما أن المحلل يرفض الأمر إذا كان في تكوين بدء التشغيل (في إصدارات Cisco IOS السابقة مثل 12.4)، فإن المحلل يرفض الأمر عندما ينسخ تكوين بدء التشغيل إلى running-config على التمهيد.

الأمر الجديد البديل هو NTP clear drift.

معلومات ذات صلة

- مؤشر ترابط منتدى الدعم: لم يتم تكوين فترة ساعة NTP

- بروتوكول وقت الشبكة: تقرير رسمي عن أفضل الممارسات

- استكشاف أخطاء بروتوكول وقت الشبكة (NTP) وإصلاحها

- الدعم التقني والتنزيلات من Cisco