NTP بـ MD5 authentication وaccess-group، وPTP (IEEE 1588) واختيار الـ grandmaster
R2 مش بيتزامن، وR1 بيدّي الوقت لأي حد على الإنترنت، وswitch خاطف دور الـ grandmaster في شبكة الـ PTP. هتصلّح NTP authentication (key وtrusted-key)، وتقفل الـ NTP بـ access-group من غير ما تقطع التزامن، وتفهم الـ BMCA وإزاي الـ boundary clocks بتوزّع الوقت من ساعة GPS.
مدة التجربة 35 دقيقة · 3 مهام
الأجهزة في بداية التجربة
- NTP — سيرفر
- R1 — راوتر
- R2 — راوتر
- R4 — راوتر
- GPS — سيرفر
- DSW1 — سويتش L3
- DSW2 — سويتش L3
- ASW — سويتش
التوصيلات
- NTP eth0 ↔ R1 Gi0/0/0
- R1 Gi0/0/1 ↔ R2 Gi0/0/0
- R1 Gi0/0/2 ↔ R4 Gi0/0/0
- GPS eth0 ↔ DSW1 Gi1/0/1
- DSW1 Gi1/0/2 ↔ DSW2 Gi1/0/2
- DSW2 Gi1/0/3 ↔ ASW Gi0/1
- DSW1 Gi1/0/3 ↔ ASW Gi0/2
العناوين المضبوطة مسبقًا
- R1 g0/0/0: 10.9.9.1/24
- R1 g0/0/1: 10.0.12.1/24
- R1 g0/0/2: 203.0.113.1/24
- R2 g0/0/0: 10.0.12.2/24
- R4 g0/0/0: 203.0.113.4/24
- 01R2 مش بيتزامن مع R1 رغم إن الـ NTP authentication متفعّل على الاتنين — لاقي السبب وصلّحه
يتحقق المعمل من R2 متزامن مع NTP، على R2: الأمر show ntp associations detail يظهر فيه «»، على R2: الأمر show ntp status يظهر فيه «»
تلميح / الحل المقترح
show ntp associations على R2 ← reach 0 و.INIT.، وshow ntp associations detail ← authentication failed: MAC mismatch. الـ client بيبعت الطلب ومعاه key ID والـ MD5 digest، والـ server بيرد بالـ digest بتاع نفس الـ key ID عنده — لو الـ keys مختلفة الـ MAC مش هيطابق فالـ client بيرمي الرد. show running-config | include ntp ← الـ key على R2 مكتوب بـ type 7 فقارنه بـ R1. الحل على R2: ntp authentication-key 1 md5 Basma-NTP (الـ keys case-sensitive). الثلاثي المطلوب على الـ client: ntp authenticate + ntp authentication-key + ntp trusted-key + ntp server … key N. الـ server محتاج الـ authentication-key بس
- 02R1 بيدّي الوقت لأي حد على الإنترنت (R4 متزامن معاه) — خلّيه يخدم 10.0.0.0/8 بس، ومن غير ما يفقد التزامن مع سيرفر NTP
يتحقق المعمل من R1 متزامن مع NTP، على R4: الأمر show ntp status يظهر فيه «»، على R1: الأمر show running-config يظهر فيه «»، R2 متزامن مع NTP
تلميح / الحل المقترح
access-list 10 permit 10.0.0.0 0.255.255.255 ← ntp access-group serve-only 10. دلوقتي R1 نفسه هيفقد التزامن! أول ما أي ntp access-group يتعمل، أي NTP packet مش متطابق مع ACL بيترفض — وserve-only/serve بيسمحوا بالطلبات بس، مش إن R1 يتزامن مع حد. لازم: access-list 11 permit host 10.9.9.10 ← ntp access-group peer 11. اتأكد: show ntp associations على R1 فيه *~10.9.9.10، وعلى R4: show ntp status ← unsynchronized (ممكن ياخد كذا poll لحد ما R4 يفقد التزامن)
- 03PTP: ساعة الـ GPS (GPS، class 6) لازم تكون الـ grandmaster للشبكة كلها — بس فيه switch خاطفها
يتحقق المعمل من على ASW: الأمر show ptp parent يظهر فيه «»، على DSW1: الأمر show ptp port يظهر فيه «»، على ASW: الأمر show ptp port يظهر فيه «»، على DSW2: الأمر show ptp clock يظهر فيه «»
تلميح / الحل المقترح
show ptp parent على DSW1 ← Grandmaster Clock Identity مش بتاع GPS والـ Priority1: 0. الـ BMCA (Best Master Clock Algorithm) بيقارن بالترتيب: priority1 ← clock class (GPS = 6، الـ switch = 248) ← accuracy ← variance ← priority2 ← clock identity، والأقل يكسب. priority1 0 على ASW بيخليه يكسب قبل ما الـ class تتقارن أصلًا. على ASW: no ptp priority1 (يرجع 128). بعدها: show ptp parent على ASW ← Class: 6، وshow ptp port على DSW1 ← Gi1/0/1 SLAVE (ناحية الـ GPS) وباقي البورتات MASTER، وعلى ASW بورت SLAVE وواحد PASSIVE (عشان مفيش loop في التوقيت). الـ boundary clock بيتزامن على بورت واحد ويبقى master على الباقي، عكس الـ transparent clock اللي بيعدّل الـ correction field بس

