أستكشاف أخطاء NTP وإصلاحها في بنية قائمة التحكم في الوصول (ACI) من Cisco

المقدمة

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

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

تم إستخراج المواد من هذا المستند من فصل إدارة قائمة التحكم في الوصول (ACI) وإصلاحها والخدمات الأساسية — دليل سياسات PoD ودليل التكوين الأساسي لواجهة برمجة التطبيقات (APIC) من Cisco، الإصدار 6.1(x) — تزويد خدمات بنية قائمة التحكم في الوصول (ACI) الأساسية، ودليل تصميم قائمة التحكم في الوصول (ACI) من Cisco.

نظرة عامة

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

نموذج سياسة NTP في ACI

تتم إدارة NTP في واجهة برمجة التطبيقات من خلال سلسلة تتألف من أربعة كائنات سياسة:

1. نهج التاريخ والوقت (datetimePol) — يحدد تكوين NTP بما في ذلك الحالة الإدارية وحالة المصادقة وحالة الخادم والوضع الرئيسي. موجود تحت البنية > سياسات البنية > السياسات > Pod > التاريخ والوقت.
2. موفر NTP (datetimeNtpProv) — يحدد إدخالات خادم NTP الفردية (الموفرون) ضمن نهج التاريخ والوقت، بما في ذلك IP/FQDN الخاص بالخادم وتحديد EPG للإدارة (خارج النطاق الترددي أو داخل النطاق الترددي) والعلم المفضل وفترات الانتظار.
3. مجموعة سياسات POD (FabricPodPGrp) — تشير إلى سياسة التاريخ والوقت مع السياسات الأخرى على مستوى POD (BGP RR، SNMP، وما إلى ذلك). موجود تحت البنية > سياسات البنية > PODS > مجموعات السياسات.
4. ملف تعريف Pod (FabricPodP) — يربط مجموعة نهج Pod بمحدد Pod. موجود تحت البنية > سياسات البنية > PODS > ملفات التخصيص.

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

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

• يجب إكمال اكتشاف البنية.
• يجب تعيين عناوين إدارة العقدة (OOB أو داخل النطاق) إلى جميع APICs والمحولات ضمن مستأجر الإدارة.
• ل خارج النطاق NTP، يجب أن يسمح EPG إدارة OOB بمنفذ UDP 123.
• بالنسبة ل NTP داخل النطاق، يجب تكوين مجموعة إدارة EPG داخل النطاق مع العقود المناسبة وإمكانية الوصول إلى خادم NTP. لا يمكن الوصول إلى عناوين IP داخل النطاق من خارج البنية بدون نهج إضافي.

مصادقة NTP

تدعم قائمة التحكم في الوصول (ACI) ثلاثة أنظمة مصادقة NTP: MD5 و SHA-1 و AES128-CMAC. تم إدخال AES128-CMAC في APIC الإصدار 6.1(1) وهو النظام الموصى به، حيث يعتبر MD5 ضعيفا وغير آمن. عند تمكين وضع FIPS، يتم دعم AES128-CMAC و SHA-1 فقط.

وظائف خادم NTP

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

ملاحظة: يجب ألا تتزامن محولات البنية مع محولات أخرى من نفس البنية. يجب أن تتزامن محولات البنية دائما مع خوادم NTP الخارجية.

التحقق من التكوين

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

الخطوة 1: التحقق من عناوين إدارة العقد

انتقل إلى المستأجرين > الإدارة > عناوين إدارة العقد (للتعيين الثابت) أو حزم إدارة العقد (لمجموعات الاتصال).

تأكد من أن كل عقدة APIC والمحول تحتوي على عنوان IP للإدارة تم تعيينه. يتعذر على العقد التي لا تحتوي على عناوين إدارة الاتصال بخادم NTP.

بدلا من ذلك، استفسر عن واجهة برمجة التطبيقات (API):

apic1# moquery -c mgmtRsOoBStNode

الخطوة 2: التحقق من أن نهج التاريخ والوقت به موفر NTP

انتقل إلى البنية > سياسات البنية > السياسات > Pod > التاريخ والوقت > [سياستك].

تأكد من تكوين موفر NTP (خادم) واحد على الأقل. في حالة وجود موفرين متعددين، ضع علامة على موفر واحد على الأقل على أنه مفضل.

تحقق من موفر NTP عبر واجهة برمجة التطبيقات (API):

apic1# moquery -c datetimeNtpProv
# datetimeNtpProv
dn           : uni/fabric/time-NTP-Policy/ntpprov-10.1.1.100
name         : 10.1.1.100
preferred    : yes                   <--- at least one should be "yes"
epgDn        : uni/tn-mgmt/mgmtp-default/oob-default   <--- management EPG
minPoll      : 4
maxPoll      : 6
keyId        : 0

أخطاء تكوين شائعة

• لا يوجد موفر NTP مكون — نهج الوقت والتاريخ موجود ولكن به صفر من الموفرين. سيتم تطبيق النهج ولكن لن يكون للعقد خادم NTP لمزامنته.
• تحديد إدارة غير صحيحة — يشير مزود NTP إلى EPG خارج النطاق ولكن خادم NTP يمكن الوصول إليه فقط عبر النطاق داخل النطاق (أو العكس). تحقق من الإدارة التي توفر EPG إمكانية الوصول إلى خادم NTP.
• FQDN و IP من نفس الخادم الذي تمت إضافته كموفرين منفصلين — يؤدي هذا إلى إنشاء خطأ IP مكرر. حذف الإدخال المكرر.
• الموفر المستند إلى FQDN بدون نهج DNS — في حالة إستخدام اسم المضيف لمزود NTP، تأكد من تكوين سياسة خدمة DNS وتطبيق تسمية DNS المناسبة على VRF الخاص بالإدارة.

الخطوة 3: التحقق من أن مجموعة نهج POD تشير إلى نهج التاريخ والوقت

انتقل إلى البنية > سياسات البنية > PODS > مجموعات السياسات > [مجموعة نهج POD الخاصة بك].

تأكيد مرجع حقل نهج وقت التاريخ لنهج الوقت والتاريخ الصحيح.

apic1# moquery -c fabricPodPGrp -f 'fabricPodPGrp.name=="default"'

ابحث عن سمة datetimePolName أو علاقة fabricRsTimePol المقترنة.

أخطاء تكوين شائعة

• تشير "مجموعة نهج POD" إلى نهج التاريخ والوقت غير الصحيح — إذا كانت هناك سياسات تاريخ ووقت متعددة (مثل "افتراضي" ونهج مخصص)، فتحقق من أن "مجموعة نهج Pod" تشير إلى السياسة المقصودة.
• لم يتم إنشاء مجموعة نهج POD على الإطلاق — قد لا يكون لدى مجموعة نهج POD الافتراضية نهج التاريخ والوقت المقترن. التحقق دائما.

الخطوة 4: تحقق من مرجع ملف تعريف POD لمجموعة نهج POD

انتقل إلى البنية > سياسات البنية > PODS > ملفات التخصيص > [ملف تخصيص POD الخاص بك].

تأكيد مرجع حقل مجموعة نهج البنية لمجموعة نهج POD الصحيحة.

أخطاء تكوين شائعة

• يشير ملف تعريف POD إلى مجموعة نهج Pod الخاطئة — خاصة في البيئات متعددة pod، يجب أن يشير كل ملف تعريف POD إلى مجموعة نهج POD الصحيحة.

الخطوة 5: التحقق من تنسيق التاريخ والوقت

انتقل إلى النظام > إعدادات النظام > التاريخ والوقت.

تأكد من تعيين تنسيق العرض (محلي أو UTC) والمنطقة الزمنية كما هو متوقع. هذا الإعداد هو نهج افتراضي لتنسيق وقت التاريخ لا يمكن حذفه أو تكراره.

التحقق العملي

بعد التأكد من صحة سلسلة التكوين، أستخدم الأوامر التالية للتحقق من عمل NTP في وقت التشغيل.

التحقق من APIC

show ntpq

يعرض هذا الأمر حالة مزامنة NTP عبر جميع APICs. يشير الرمز * إلى أن الخادم محدد للمزامنة.

apic1# show ntpq
 nodeid     remote                          refid                           st        t   when      poll      reach     auth  delay     offset    jitter
 ------  -  ------------------------------  ------------------------------  --------  --  --------  --------  --------  ----  --------  --------  --------
 1       *  ntp.example.com                 .GPS.                           1         u   20        64        377       none  0.213     +0.102    0.005
 2       *  ntp.example.com                 .GPS.                           1         u   6         64        377       none  0.196     +0.007    0.004
 3       *  ntp.example.com                 .GPS.                           1         u   27        64        377       none  0.216     -0.008    0.006

كيف يبدو هذا جيدا:

• تظهر جميع APICs * (المحددة للمزامنة) بجوار الخادم البعيد.
• وتصل إلى 377 (ثماني)، مما يشير إلى أن آخر 8 انتخابات كانت ناجحة.
• st (stratum) بين 1 و 15. Stratum 16 تعني أن الخادم غير متزامن.
• الإزاحة منخفضة (عادة أقل من 100 مللي ثانية للبيئة الصحية).

ما الذي يبدو سيئا:

• لا * بجوار أي خادم — لم يتم تحديد خادم للمزامنة.
• الوصول هو 0 — لم يتم تلقي استجابات NTP.
• st هو 16 — لا يتم مزامنة خادم NTP مع مصدر وقت البث الخاص به.
• الإزاحة كبيرة جدا (بآلاف المللي ثانية) - الساعة تنجرف بشكل ملحوظ.

ساعة العرض

apic1# show clock
Time : 11:24:18.391 UTC-04:00 Tue Apr 07 2026

تأكد من دقة الوقت. قارن مع الوقت المتوقع لاكتشاف انحراف الساعة.

APIC BASH (بديل)

apic1# bash
admin@apic1:~> date
Tue Apr 7 11:24:45 EDT 2026

التحقق من المحول (ورقة/عمود فقري)

إظهار نظراء NTP

تحقق من دفع موفر NTP إلى المحول.

leaf1# show ntp peers
-----------------------------------------------------------------------------
  Peer IP Address                         Serv/Peer Prefer KeyId   Vrf
-----------------------------------------------------------------------------
  10.1.1.100                              Server    yes    None    management

كيف يبدو هذا جيدا: يظهر ال NTP نادل ip أو hostname مع serv/نظير = نادل وال VRF صحيح (عادة إدارة ل OOB).

ما الذي يبدو سيئا: لا يوجد نظراء مسرودين، أو أن IP لخادم NTP لا يطابق الموفر الذي تم تكوينه. يشير ذلك عادة إلى عدم تطبيق نهج التاريخ والوقت من خلال سلسلة ملف تعريف Pod Policy Group / Pod.

show ntp peer-status

تحقق من تحديد خادم NTP للمزامنة.

leaf1# show ntp peer-status
Total peers : 1
* - selected for sync, + - peer mode(active),
- - peer mode(passive), = - polled in client mode
    remote                               local           st poll reach delay vrf
--------------------------------------------------------------------------------
*10.1.1.100                              0.0.0.0         1  64   377   0.000  management

الحرف * أساسي — إنه يؤكد إستخدام خادم NTP للمزامنة.

ما الذي يبدو سيئا:

• لا * بجوار الخادم — المحول لا تتم مزامنته إلى الخادم.
• الوصول هو 0 — لم يتم تلقي استجابات NTP. يشير ذلك إلى وجود مشكلة في إمكانية الوصول.
• st هو 16 — خادم NTP غير متزامن ولا يمكنه توفير وقت صالح.

show ntp statistics peer ipaddr

تحقق من تبادل حزم NTP لتأكيد إمكانية الوصول. استبدلت العنوان مع ال NTP مزود عنوان للمفتاح يتأثر.

leaf1# show ntp statistics peer ipaddr 10.1.1.100
...
packets sent:     9256
packets received:   9256
...

كيف يبدو هذا جيدا: تكون الحزم المرسلة والحزم المستلمة متساوية تقريبا ومتزايدة.

ما الذي يبدو سيئا: تزداد الحزم المرسلة ولكن الحزم المستلمة هي 0 أو تزيد بالكاد — لا تصل استجابات NTP إلى المحول.

ساعة العرض

leaf1# show clock
11:24:24.121066 EDT Tue Apr 07 2026

التحقق من واجهة المستخدم الرسومية (GUI)

انتقل إلى البنية > سياسات البنية > السياسات > Pod > التاريخ والوقت > [سياستك] > [مزود NTP].

يجب أن يظهر عمود حالة المزامنة مزامنته إلى خادم NTP البعيد لجميع العقد. قد يستغرق الأمر عدة دقائق حتى تتلاقى حالة المزامنة بعد النشر الأولي.

التحقق من واجهة برمجة التطبيقات

الاستعلام عن فئة datetimeNtpq للتحقق من مزامنة NTP عبر جميع APICs:

apic1# moquery -c datetimeNtpq
# datetimeNtpq
dn        : topology/pod-1/node-1/sys/ntpq-ntp.example.com
remote    : ntp.example.com
tally     : *                            <--- selected for sync
stratum   : 1
reach     : 377                          <--- all recent polls successful
offset    : +0.102
delay     : 0.213
jitter    : 0.005
refid     : .GPS.

أستكشاف أخطاء سير العمل وإصلاحها

أستخدم شجرة القرارات هذه عند الإبلاغ عن إصدار NTP على أي عقدة من عقد قائمة التحكم في الوصول (ACI).

الخطوة 1: هل تم تكوين نظراء NTP على المحول؟

سجل مقياس سرعة داخل ال يتأثر مفتاح وشغل:

leaf1# show ntp peers

• لم يتم تطبيق نهج → التاريخ والوقت على هذه العقدة من النظراء. انتقل إلى السيناريو 1: لم يتم دفع موفر NTP إلى المحول.
• → الأقران المدرجين يواصلون الخطوة 2.

الخطوة 2: هل تم تحديد خادم NTP للمزامنة؟

leaf1# show ntp peer-status

• * تتم مزامنة NTP الحالية →. إذا كان الوقت لا يزال يبدو خاطئا، انتقل إلى السيناريو 5: إزاحة كبيرة / انزحال الساعة.
• لا * حالي → تابع الخطوة 3.

الخطوة 3: هل قيمة الوصول صفر؟

تحقق من عمود الوصول في show ntp peer-status.

• المدى = 0 → بدون استجابات من خادم NTP. انتقل إلى السيناريو 2: يتعذر الوصول إلى خادم NTP.
• الوصول > 0 ولكن لا * →توجد استجابات قيد الوصول ولكن لم يتم إنشاء المزامنة. فحص الطبقة — انتقل إلى الخطوة 4.

الخطوة 4: هل قيمة الطبقة العليا 16؟

• Stratum = 16 → لا يتم مزامنة خادم NTP مع مصدر الخادم الخاص به. انتقل إلى السيناريو 3: خادم NTP غير متزامن (Stratum 16).
• Stratum 1-15 ولكن لا → مزامنة انتقل إلى السيناريو 4: عدم تطابق مصادقة NTP.

سيناريوهات أستكشاف الأخطاء وإصلاحها الشائعة

السيناريو 1: لم يتم دفع موفر NTP إلى التبديل

العرض: لا يرجع عرض نظراء NTP على المحول أي إدخالات.

فحص التكوين:

1. تحقق من أن نهج "التاريخ والوقت" به موفر NTP واحد على الأقل تم تكوينه.
2. تحقق من أن "مجموعة نهج POD" تشير إلى نهج الوقت والتاريخ الصحيح.
3. تحقق من أن مرجع POD يشير إلى مجموعة نهج POD الصحيحة.
4. تحقق من أن العقدة لها عنوان IP للإدارة تم تعيينه تحت مستأجر الإدارة.

السبب الجذري: تم قطع أحد الارتباطات الأربعة في سلسلة السياسات (Date and Time Policy → NTP Provider → Pod Policy Group → Pod Profile). السبب الأكثر شيوعا هو عدم اقتران مجموعة نهج Pod بملف تعريف Pod، أو عدم تحديد نهج التاريخ والوقت في مجموعة نهج Pod.

الحل: أكمل الارتباط المفقود في سلسلة النهج. تأكد من أن ملف تعريف Pod الخاص ب POD المتأثر يشير إلى مجموعة نهج Pod تحتوي على نهج التاريخ والوقت الصحيح. وبمجرد تطبيقها، سيتم دفع تكوين موفر NTP إلى المحولات في غضون دقائق قليلة.

السيناريو الثاني: يتعذر الوصول إلى خادم NTP

العرض: يعرض عرض حالة نظير NTP الوصول = 0. يعرضعرضبيانات نظير إحصائيات NTP الحزم المستلمة = 0.

فحص التكوين: تحقق من اقتران موفر NTP ب EPG الإدارة الصحيحة (OOB أو داخل النطاق). إذا كنت تستخدم خارج النطاق (OOB)، فتحقق من أن عقود خارج النطاق (OOB) تسمح بمنفذ UDP 123.

فحص عملياتي:

1. يؤز ال NTP نادل من ال يتأثر مفتاح يستعمل الإدارة VRF:

   leaf1# ping 10.1.1.100 vrf management
   

2. قم بتشغيل tcpdump على المحول للتحقق مما إذا كانت حزم NTP في طريقها إلى الخروج والوصول:

   leaf1# tcpdump -n -i eth0 dst port 123
   tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
   listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
   16:49:01.431624 IP 10.1.20.23.123 > 10.1.1.100.123: NTPv4, Client, length 48
   16:49:01.440303 IP 10.1.1.100.123 > 10.1.20.23.123: NTPv4, Server, length 48
   

السبب الجذري: بشكل نموذجي أحد الأمور التالية:

• لا يحتوي المحول على عنوان IP للإدارة تم تعيينه.
• البوابة الافتراضية للإدارة VRF مفقودة أو غير صحيحة.
• يمنع جدار حماية منفذ UDP 123 بين المحول وخادم NTP.
• لا يسمح عقد OOB بمنفذ UDP 123.
• يشير موفر NTP إلى EPG الإدارة الخاطئة (على سبيل المثال، OOB محدد ولكن فقط داخل النطاق له إمكانية الوصول).

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

السيناريو 3: خادم NTP غير متزامن (Stratum 16)

العرض: show ntp peer-status show stratum (st) = 16. لن تتم مزامنة المحول مع خادم Stratum 16.

فحص عملياتي: قم بتسجيل الدخول إلى خادم NTP أو الاستعلام عنه من مضيف خارجي للتحقق من مزامنته إلى مصدر وقت البث الخاص به.

السبب الجذري: لقد فقد خادم NTP نفسه المزامنة مع الساعة المرجعية للتحميل الخاصة به. يقوم الخادم المزود بالمحول Stratum 16 بالإعلان عن عدم توفر مصدر وقت يمكن الاعتماد عليه.

الحل: قم بإصلاح خادم NTP. هذا خارج بنية قائمة التحكم في الوصول (ACI) — تحقق من تكوين خادم NTP ومصدر وقت التشغيل الخاص به. إذا تعذر إصلاح خادم NTP فورا، فقم بتكوين موفر NTP بديل في نهج التاريخ والوقت.

السيناريو 4: عدم تطابق مصادقة NTP

العرض: عرض حالة نظير NTP يعرض الوصول > 0 والطبقة العليا صالحة، ولكن لا * يعرض. يستجيب خادم NTP ولكن المحول لا يقبل الاستجابة.

فحص التكوين:

1. تحقق ما إذا كان خادم NTP يتطلب المصادقة أم لا.
2. إذا كانت المصادقة مطلوبة، فتحقق من أن نهج التاريخ والوقت به حالة المصادقة معينة على تمكين.
3. تحقق من مطابقة معرف مفتاح المصادقة وقيمة المفتاح والخوارزمية (MD5 أو SHA-1 أو AES128-CMAC) بين بنية واجهة التحكم في الوصول (ACI) وخادم NTP.
4. تحقق من وضع علامة موثوق بها في جدول مفاتيح مصادقة عميل NTP.

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

الحل: قم بمحاذاة تكوين المصادقة. تأكد من تكوين معرف المفتاح نفسه وقيمة المفتاح والخوارزمية على كل من واجهة التحكم في الوصول (ACI) وخادم NTP. يوصى باستخدام AES128-CMAC للإصدار 6.1(1) من APIC والإصدارات الأحدث.

ملاحظة: عند تمكين وضع FIPS، يتم دعم أنظمة المصادقة AES128-CMAC و SHA-1 فقط. لن يعمل MD5 في وضع FIPS.

السيناريو 5: إزاحة كبيرة / انزحال الساعة

العرض: يبدو أن المحول تمت مزامنته (* حالي، الوصول = 377)، لكن قيمة الإزاحة في show ntp peer-status أو show ntpq كبيرة جدا (مئات أو آلاف المللي ثانية)، أو أن الساعة خاطئة بشكل واضح.

فحص عملياتي:

apic1# show ntpq

تحقق من عمود الإزاحة. الإزاحة السليمة تكون عادة أقل من 100 مللي ثانية.

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

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

السيناريو 6: أخطاء APIC في وضع الاستعداد مع NTP داخل النطاق

العرض: يتم إنشاء أخطاء على APIC إستعداد متعلق ب NTP أو نهج المراقبة عند تكوين NTP للإدارة داخل النطاق.

السبب الجذري: عند تطبيق سياسة NTP للإدارة داخل النطاق، تتطلب أيضا واجهة برمجة التطبيقات (APIC) الاحتياطية تكوين داخل النطاق. فبدونها تثار الاخطاء.

الحل: قم بتكوين الإدارة داخل النطاق ل APIC للاستعداد أيضا. وهذا يصفي العيوب.

السيناريو 7: خطأ IP مكرر

العرض: يتم رفع خطأ IP مكرر بعد إضافة موفري NTP.

السبب الجذري: تمت إضافة FQDN كموفر NTP، ثم تمت إضافة عنوان IP الذي تم تحليله الخاص ب FQDN كموفر NTP ثان. يكتشف ACI التكرار.

الحل: احذف أحدث موفر مكرر تمت إضافته (إدخال عنوان IP إذا تمت إضافة FQDN أولا، أو العكس). أستخدم إدخالا واحدا فقط لكل خادم NTP — إما FQDN أو عنوان IP، وليس كلاهما.

السيناريو 8: فشل تحليل DNS لموفر NTP المستند إلى FQDN

العرض: لم يتم حل موفر NTP الذي تم تكوينه باسم المضيف. لا يعرض عرض نظائر NTP عنوان IP المتوقع، أو لا تتم مزامنة NTP.

فحص التكوين:

1. تحقق من تكوين سياسة خدمة DNS ضمن البنية > سياسات البنية > السياسات > العمومية > ملفات تعريف DNS.
2. تحقق من إمكانية الوصول إلى موفر DNS (خادم DNS) من VRF الخاص بالإدارة.
3. تحقق من تكوين تسمية DNS المناسبة لمثيل VRF داخل النطاق الترددي أو خارج النطاق من EPG الخاص بالإدارة.

السبب الجذري: يتعذر الوصول إلى خادم DNS أو لم يتم تكوينه، مما يتسبب في فشل تحليل اسم المضيف لموفر NTP.

الحل: قم بتكوين نهج خدمة DNS، وضمان إمكانية الوصول إلى DNS، وتطبيق تسمية DNS الصحيحة. وبدلا من ذلك، أستخدم عنوان IP لخادم NTP بدلا من اسم المضيف.

الأخطاء والأحداث ذات الصلة

فيما يلي الشروط المتعلقة ب NTP التي قد تتسبب في حدوث أخطاء في واجهة التحكم في الوصول (ACI):

• خطأ IP مكرر — يظهر عندما تتم إضافة FQDN وعنوان IP لنفس خادم NTP كموفرين. الدقة: قم بإزالة الإدخال المكرر.
• أخطاء NTP داخل النطاق لواجهة برمجة التطبيقات الاحتياطية — يتم إصلاحها عند تطبيق سياسة مراقبة أو NTP على النطاق داخل النطاق ولكن واجهة برمجة التطبيقات (APIC) الاحتياطية تفتقر إلى التكوين داخل النطاق.
• حالة المزامنة غير متقاربة — تظهر واجهة المستخدم الرسومية "غير متزامنة" أو حالة أخرى غير "تمت المزامنة إلى خادم NTP البعيد" لعقد واحدة أو أكثر. هذا ليس رمز خطأ ولكنه مؤشر حالة تشغيل. اتبع سير عمل أستكشاف الأخطاء وإصلاحها أعلاه للتشخيص.

معايير التصعيد

تذكر التصعيد إلى Cisco TAC إذا:

• تم التحقق من صحة سلسلة التكوين ومن إمكانية الوصول إلى خادم NTP (يعمل ping، و tcpdump يعرض استجابات NTP)، ولكن لا يزال المحول غير متزامن.
• يتم فقد مزامنة NTP بشكل متكرر بدون تغييرات التكوين أو مشاكل خادم NTP.
• يعرض إخراج show ntp status النظير سلوك غير متوقع مثل الطبقة المستمرة 16 على خادم تم تأكيده بمزامنته خارجيا.
• تنحرف الساعة بشكل كبير بين عمليات إعادة التشغيل، مما قد يشير إلى وجود مشكلة في ساعة الأجهزة (RTC).

عند مشاركة TAC، قم بتوفير البيانات التالية:

• إخراج show ntpq من جميع APICs.
• خرج من عرض أقران ntp، وعرض حالة نظير ntp، وعرض ملف تعريف نظير إحصائيات ntp <ip>، وعرض الساعة من جميع المحولات المتأثرة.
• إخراج moquery -c datetimePol، moquery -c datetimeNtpProv، وmoquery -c datetimeNtpq من APIC.
• دعم فني من العقدة (العقد) المتأثرة.

المراجع

• دليل التكوين الأساسي ل Cisco APIC، الإصدار 6.1(x) — إمداد خدمات بنية واجهة التحكم في الوصول (ACI) الأساسية
• أستكشاف أخطاء إدارة قائمة التحكم في الوصول (ACI) والخدمات الأساسية وإصلاحها — سياسات POD
• دليل تصميم البنية الأساسية المرتكزة على التطبيقات (ACI) من Cisco

محفوظات المراجعة

المراجعة	تاريخ النشر	التعليقات
1.0	07-Apr-2026	الإصدار الأولي