المحتويات

المقدمة

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

المتطلبات

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

معلومات أساسية

آلية اقتراع NTP في منتجات UC

تحديد إصدار NTP المستخدم

تشخيص المشاكل المتعلقة ب NTP في CUCM

القضايا الشائعة المعروفة مع اقتران NTP حول CUCM

المقدمة

يصف هذا المستند كيفية أستكشاف أخطاء بروتوكول وقت الشبكة (NTP) وإصلاحها في منتجات الاتصالات الموحدة (UC) من Cisco.

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

المتطلبات

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

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

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

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

معلومات أساسية

يتطلب Cisco Unified Communications Manager (CUCM) تكوين بروتوكول وقت الشبكة (NTP) لضمان:

- تتم مزامنة الوقت على عقد CUCM.

- الوقت صحيح قبل أي تغيير تكوين حساس للوقت مثل إعادة إنشاء الشهادة.

- تتم مزامنة النسخ المتماثل لقاعدة البيانات على كافة العقد في نظام المجموعة.

آلية اقتراع NTP في منتجات UC

يستخدم CUCM مراقبة NTP لإبقاء الوقت متزامنا مع خادم NTP. تقوم "مراقبة NTP" بشكل دوري باستطلاع خادم (خوادم) NTP الخارجية وتقوم بإعادة تشغيل NTP إذا تم تعويض الوقت بأكثر من ثلاث ثوان.

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

تستطلع هيئة مراقبة إن تي بي NTP NTP مرة في الدقيقة على برنامج VMware ومرة كل 30 دقيقة على الأجهزة المادية. تكون فترة التحقق أقصر بالنسبة لبرنامج VMware لأن الساعة في الأجهزة الافتراضية (VMs) أقل إستقرارا مقارنة بالأجهزة الفعلية، كما أن ميزات VMware مثل ترحيل وحدات التخزين VMotion تؤثر سلبا على الوقت.

يجب تكوين العقدة الأساسية التي تعمل على VMware دائما من أجل المزامنة مع خوادم NTP الخارجية التي يتم تشغيلها على جهاز (أجهزة) فعلي للتعويض عن الدرجة الأعلى من الوقت المنقضي أو التأخير في جهاز (أجهزة) VM. يتم دائما تكوين العقد الثانوية تلقائيا للإشارة إلى خادم NTP للعقدة الأساسية لضمان إغلاق جميع العقد داخل نظام المجموعة في الوقت المناسب.

تتابع "مراقبة NTP" معدل إعادة تشغيل البرنامج الخفي ل NTP لإجراء عمليات تصحيح إجمالي الوقت بسبب عمليات ترحيل VMare VMare وترحيل وحدات التخزين. إذا تجاوز هذا المعدل 10 عمليات إعادة تشغيل في الساعة، تؤجل مراقبة NTP عمليات إعادة تشغيل أخرى حتى ينخفض المعدل المطلوب لعمليات إعادة التشغيل إلى أقل من 10 في الساعة. لا يمكن أن يتجاوز المعدل الإجمالي لعمليات ترحيل وحدات التخزين والترحيل VMs 10 في الساعة، نظرا لأن هذا المعدل يعد زائدا عن الحد.

بسبب تنفيذ مراقبة NTP هذا، لا تتبع الفاصل الزمني للاستطلاع، والذي يظهر في حالة NTP الخاصة بالمستخدم. كشفت عملية التقاط sniffer 8 استبيان NTP (عينة) كل 60 ثانية. ويرجع ذلك في المقام الأول إلى أن تنفيذ بروتوكول وقت الشبكة (NTP) يستخدم مراقبة بروتوكول وقت الشبكة (NTP)، وكيفية إجراء إستطلاعات لخادم بروتوكول وقت الشبكة (NTP) في تنفيذ الاتصالات الموحدة.

تحديد إصدار NTP المستخدم

ملاحظة: تم تكوين CUCM Publisher باستخدام خادم NTP خارجي، كما تتم مزامنة المشترك إلى نظام المجموعة مع Publisher.

ملاحظة: يتطلب الإصدار 9.x من CUCM والإصدارات الأحدث تكوين خادم NTPv4 كخادم NTP المفضل.

قم بتشغيل التقاط sniffer لتحديد إصدار NTP المستخدم من قبل خادم NTP الذي تم تكوينه:

admin:utils network capture port 123

Executing command with options:

size=128         count=1000             interface=eth0

src=dest=                  port=123

ip=

16:03:03.689725 IP cucmlab.cisco.local.34063 > linux.local.ntp: NTPv4,Client, length 48

16:03:03.690174 IP linux.local.ntp > cucmlab.cisco.local.34063: NTPv3,Server, length 48

يرسل CUCM حزمة NTPv4 واستجابة، تتلقى حزمة NTPv3. على الرغم من أن NTPv4 متوافق مع الإصدارات السابقة من NTPv3، إلا أن تنفيذ CUCM لبروتوكول وقت الشبكة (NTP) يختلف، مما ينتج عنه بروتوكول وقت الشبكة (NTP) غير المتزامنة:

admin:utils ntp status

ntpd (pid 22458) is running...

remote      refid     st t when poll reach   delay   offset jitter

=================================================================

172.28.5.9   .INIT.     2 u   45   64 377   0.374 492.965 18.189

unsynchronised

time server re-starting

polling server every 64 s

in order to صححت الإصدار، cisco يوصي أنت يستعمل baser linux خارجي ntp نادل أو cisco ios ® أو cisco ios ® XE NTP نادل ويضمن أن NTPv4 شكلت.

فيما يلي وصف لمصطلحات NTP في إخراج حالة NTP:

- يشير عمود إعادة التدفق إلى مصدر وقت البعيد. LOCAL(0) هي ساعة الأجهزة المحلية. .INIT. يعني أن التهيئة لم تنجح بعد.

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

- يشير العمود T إلى نوع الخادم (l: محلي؛ u: unicast؛ m: multicast، أو b: broadcast).

- يشير عمود "متى" إلى عدد الثواني التي تم الاستعلام عنها عن جهاز التحكم عن بعد.

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

- يشير عمود الوصول إلى إتجاه إختبارات إمكانية الوصول في ثماني، حيث تمثل كل رقم، عند تحويله إلى ثنائي، ما إذا كان إستقصاء معين ناجحا (ثنائي 1) أو غير ناجح (ثنائي 0). على سبيل المثال ، 1 يعنى انه تم إجراء إستطلاع واحد فقط حتى الان ، وقد كان ناجحا. 3 (= ثنائي 11) يعني أن آخر عمليتي اقتراع كانتا ناجحتين. 7 (= ثنائي 111) يعني أن آخر ثلاث انتخابات كانت ناجحة. 17 ( = الرقم الثنائي 1 111) يعني أن آخر أربع انتخابات كانت ناجحة. 15 (= ثنائي 1 101) يعني أن آخر عمليتي اقتراع كانتا ناجحتين. وقبل ذلك لم ينجح الاقتراع، وكان الاقتراع قبل ذلك ناجحا.

- أعمدة التأخير والإزاحة والتشوه هي تأخير الذهاب والإياب والتشتيت والتشوه بالمللي ثانية.

تشخيص المشاكل المتعلقة ب NTP في CUCM

أكمل هذه الخطوات لتشخيص المشاكل المتعلقة ب NTP:

1. تأكد من إمكانية اتصال CUCM بخادم NTP على المنفذ 123.

2. الحصول على إخراج حالة NTP بالكامل.

- يمكن أن يكون مستوى الاستراسم أقل من 4 على الناشر للحصول على الأداء الأمثل.

- إذا تم تكوين خوادم NTP متعددة، فتأكد من إمكانية الوصول إلى خادم واحد على الأقل؛ يمكنك رؤية رمز (*) مقابل خادم NTP المستخدم كمرجع بواسطة CUCM.

3. راجع تنبيه syslog واتخذ الإجراء وفقا لذلك. الأسباب المحتملة لتنبيهات syslog هي:

- خادم NTP الخارجي غير قابل للوصول.

- طبقة NTP أعلى من الحد المقبول.

- تم إيقاف الناشر، لذلك لم تتم مزامنة NTP الخاص بالمشترك.

- إذا تم عرض تنبيهات NTPDATE -q ذات صلة، فمن الممكن أن يكون لديك الإصدار 4.2.6+ من NTP مع تمكين ميزة "قبلة الموت" (KoD). (حسب التصميم، يكون الحد الأدنى للفاصل الزمني بين حزم الاندفاع وحزم البدء التلقائي المرسلة من قبل أي عميل إثنين، ولا ينتهك هذا القيد. يمكن إسقاط الحزم المرسلة من قبل عمليات تنفيذ أخرى تخالف هذا القيد وإرجاع حزمة KoD إذا تم تمكينها). يوصى بتعطيل هذه الميزة عند إستخدام هذا الإصدار كخادم NTP لمنتج الاتصالات الموحدة.

4. أستخدم وحدة التشخيص هذه للتحقق من تكوين خادم NTP.

- تشخيص الوحدة النمطية NTP_REACHABILITY

- تشخيص الوحدة النمطية NTP_CLOCK_DRIFT

- وحدة تشخيص uTILS ntp_stratum

5. أدخل إعادة تشغيل NTP في كل مرة لإعادة تشغيل عميل/خادم NTP. هذا الأمر مفيد عندما يحتاج تصحيح الوقت الإجمالي إلى أن يحدث فورا أو عندما تكون الخوادم الخارجية لا تزال قابلة للوصول والتشغيل، ولكن تفشل المزامنة. أستخدم الأمر utils ntp status لتحديد حالة التشغيل لخوادم NTP الخارجية.

القضايا الشائعة المعروفة مع اقتران NTP حول CUCM

معرف تصحيح الأخطاء من Cisco CSCue18813: معلمة تكوين NTP maxDist التي يتم التحكم فيها عبر CLI

القرار: يمكن رفع حالة مركز المساعدة التقنية ل Cisco من أجل إضافة المعلمة tos maxdist يدويا في ملف ntp.conf.

معرف تصحيح الأخطاء من Cisco CSCuq70611: لا يتم التحقق من صحة إختبار إستراتيجية NTP بشكل صحيح مع خادم NTP واحد

الإصدار الثابت: 10.5(2.1000.005)

معرف تصحيح الأخطاء من Cisco CSCui85967: فشل ترقية قفزة CUCM من 6.1.5 إلى 9.1.2 بسبب فقدان مرجع NTP

الحل: تم تحديث وثائق ترقية الانتقال السريع وتم إدراج تكوين NTP على أنه موجود في مهمة ما قبل الترقية.

معرف تصحيح الأخطاء من Cisco CSCtw46611: يفشل مزامنة NTP بسبب وضع علامة غير صحيحة لنظام الملفات على capture.txt

الإصدار الثابت: 8.6(2.24900.017)

معرف تصحيح الأخطاء من Cisco CSCur94973: إصدار مزامنة الوقت بين VMHost ومثيل VM أثناء الترحيل من M1

الدقة: تعطيل مزامنة NTP الخاصة ب VM مع مضيف ESXi باستخدام هذا الحل البديل . البديل البديل هو تكوين خادم ESXi وناشر CUCM للإشارة إلى خادم NTP نفسه.