الوحدة 05: المقاييس الموسعة والتلاقي فائق السرعة و M-ISIS
الهدف الهندسي للوحدة
دراسة التحول الحتمي من المقاييس الضيقة القديمة (Narrow Metrics) إلى المقاييس الموسعة (Wide Metrics RFC 5305) اللازمة لهندسة المرور الحديثة والـ Segment Routing؛ فهم مخاطر الهجرة بين الأنماط؛ استيعاب عزل طوبولوجيا IPv4 عن IPv6 عبر M-ISIS (RFC 5120) لمنع الثقوب الصامتة؛ وضبط محرك التلاقي لأقل من ثانية عبر مؤقتات IETF SPF وخوارزمية iSPF وتفضيل المسارات الحرجة (PRF).
1. المقاييس الضيقة مقابل المقاييس الموسعة (Narrow vs Wide Metrics)
في معيار ISO 10589 الأصلي، خُصص لحقل التكلفة (Metric) لكل رابط في حزم TLV 2 القديمة 6 بتات فقط، مما جعل أقصى تكلفة يمكن وضعها على أي رابط هي 63 فقط! بينما بلغ الحد الأقصى للمسار الكامل عبر الشبكة 1023 (10 بتات).
لماذا تمثل المقاييس الضيقة كارثة في شبكات مزودي الخدمة الحديثة؟
- فقدان الدقة الهندسية: لا يمكن التمييز في التكلفة بين رابط 10Gbps ورابط 100Gbps ورابط 400Gbps؛ فجميعها ينتهي بها الأمر بتكلفة متقاربة (مثل 10 و 20) لأن السقف 63 ضيق للغاية.
- تشبع مقياس المسار (Metric Saturation): في شبكة إقليمية عابرة للقارات، يتجاوز مجموع الروابط بسهولة سقف 1023، فتتساوى المسارات البعيدة كلياً وتفشل خوارزمية ديكسترا في المفاضلة.
- العجز عن حمل سمات هندسة المرور: لا تتسع الحقول القديمة لأي تفاصيل إضافية عن السعات المحجوزة أو الألوان أو وسوم التوجيه.
الحل المعياري (RFC 5305 Wide Metrics):
- توسيع مقياس الرابط إلى 24 بت (قيم تصل إلى 16,777,215) عبر TLV 22 (Extended IS Reachability).
- توسيع مقياس المسار الكامل إلى 32 بت (قيم تصل إلى أكثر من 4 مليارات) عبر TLV 135 (Extended IP Reachability).
- دعم الحقول الفرعية (Sub-TLVs) لنقل سمات Segment Routing وهندسة المرور.
2. مخاطر الانتقال (Migration Hazards) ونمط Transition
إذا كان لديك شبكة قائمة تعمل بالمقاييس الضيقة (Narrow)، وقمت بتغيير أحد موجهات النواة مباشرة إلى metric-style wide، يحدث انفصال كارثي للشبكة:
- الموجهات القديمة لا تفهم TLV 22 و TLV 135 وتتجاهلها تماماً، فتفقد رؤية الموجه المحدث ومساراته.
- الحل الإلزامي على Cisco IOS XR هو الانتقال عبر خطوتين:
- تفعيل metric-style transition (يرسل ويستقبل النمطين معاً لضمان التوافق المؤقت).
- بعد ترقية كافة موجهات الشبكة، يتم التثبيت النهائي على metric-style wide.
3. تعدد الطوبولوجيا (Multi-Topology IS-IS RFC 5120)
في بيئات Dual-Stack التي تشغل كلاً من IPv4 و IPv6، يعتمد IS-IS التقليدي على شجرة طوبولوجيا وحيدة مشتركة (Single-Topology).
الثقب الأسود لـ IPv6 في البيئة المشتركة:
إذا سقط منفذ IPv6 على أحد الروابط (أو نسي المهندس تهيئته)، بينما ظل IPv4 يعمل بنجاح، فإن خوارزمية SPF تعتبر الرابط متاحاً لكلا البروتوكولين! يقوم الموجه بإرسال حزم IPv6 إلى ذلك الرابط لتسقط فوراً في اللاشيء!
الحل عبر M-ISIS (RFC 5120):
يقوم IS-IS بحساب شجرتي SPF مستقلتين تماماً في الذاكرة:
- MT ID 0: شجرة التوجيه الخاصة بـ IPv4 Unicast حصراً.
- MT ID 2: شجرة التوجيه الخاصة بـ IPv6 Unicast حصراً، ويتم الإعلان عنها عبر TLV 229 و TLV 237.
4. التلاقي فائق السرعة ومؤقتات IETF SPF Exponential Backoff
عند حدوث عطل في الرابط، يحتاج الموجه لإعادة تشغيل خوارزمية ديكسترا (SPF Calculation). ولكن لو بدأ الرابط بالتذبذب السريع (Flapping عدة مرات في الثانية)، فإن تشغيل SPF المتواصل يستهلك 100% من قدرة المعالج ويشل حركة الموجه.
لحماية المعالج مع الحفاظ على التلاقي الفوري في الحالات الطبيعية، تم تصميم خوارزمية IETF SPF Exponential Backoff باستخدام ثلاثة مؤقتات:
| المؤقت | القيمة الموصى بها في SP | الوظيفة الهندسية |
|---|---|---|
| Initial Wait (init-delay) | 50 ms | زمن الانتظار بعد أول حدث عطل؛ يضمن تلاقياً شبه فوري لأول حادثة انقطاع. |
| Secondary Wait (short-delay) | 100 ms | زمن الانتظار في حال تكرار الحدث سريعاً؛ يتضاعف تصاعدياً (Exponential). |
| Maximum Wait (long-delay) | 2000 ms | السقف الأقصى لتأخير الـ SPF أثناء العواصف التذبذبية لحماية المعالج. |
5. خوارزمية iSPF وأولوية البادئات (Prefix Prioritization - PRF)
الـ SPF التدريجي: Incremental SPF (iSPF)
إذا أُضيفت شبكة طرفية (Leaf IP Prefix) أو تغيرت تكلفتها دون أي تغيير في الروابط بين الموجهات، لا يقوم iSPF بإعادة بناء الشجرة الهيكلية كاملة (O(V log V))، بل يكتفي بتحديث العقدة الطرفية مباشرة في زمن ثابت O(1) يقاس بالميكروثانية!
أولوية البادئات: Prefix Prioritization (PRF)
في شبكات النواة التي تضم 50,000 بادئة، يقوم محرك Cisco IOS XR ببرمجة عناوين Loopback0 (/32) الخاصة بنقاط قفزات BGP (Next-Hops) في شرائح الـ FIB العتادية أولاً، قبل الشروع في برمجة آلاف المسارات العادية، مما يعيد خدمات BGP والـ VPN للعمل في أجزاء من الثانية!