تسمية لكل VRF أم لكل بادئة؟ فاتورة السعة الحقيقية

يعلن تصميمان البادئة نفسها للعميل عبر النواة نفسها لمزوّد الخدمة. يخصّص أحدهما تسمية لكل بادئة، ويخصّص الآخر تسمية واحدة لكل الـVRF، ويبدو الثاني أرخص على كل شريحة عرض. عدد التسميات حقيقي، لكنه ليس الميزانية التي تنفد عادةً أولًا. والاختيار بين التصميمين يعني عدّ أربعة موارد لا مورد واحد، والتسميات هي أصغرها.

ويعتمد الاختيار أيضًا على ما يجب أن يفعله موجّه الخروج بالحزمة بعد إزالة التسمية. هذا الفرق الوظيفي، لا حساب التسميات، هو ما ينبغي أن يقود القرار.

ما يوفّره كل تخصيص فعليًا

يحمل التخصيص لكل بادئة معلومات التمرير في التسمية. يستطيع موجّه الخروج إرسال الحزمة مباشرةً إلى التجاور الصحيح دون البحث عن الوجهة، ولهذا يتوسّع جيدًا مع مجموعات مسارات VRF الكبيرة، ولهذا يستهلك تسمية واحدة لكل بادئة معلنة في كل VRF. أما التخصيص لكل VRF، مثل Junos vrf-table-label، فيعلن تسمية واحدة لكل نسخة توجيه ويستخدم تلك التسمية لاختيار جدول VRF؛ ثم يجري الموجّه بحثًا عن عنوان IP داخل الجدول.

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

سجل التسميات هو الأصغر

تسميات MPLS محدودة، لكن فضاء التسميات كبير بما يكفي بحيث لا يستنفده مزوّدو الخدمة العاديون ببضعة آلاف من البادئات. إن ما يساعد التوسيم لكل VRF حقًا هو المنصات ذات جداول التسميات الصغيرة في العتاد، أو التصاميم التي يحمل فيها VRF واحد تغذية إنترنت كاملة فتضاعف تسميات كل بادئة الطلب بمقدار عدد المسارات. هذه قيود حقيقية، وهي سبب وجود الميزة. ولا شيء منها يتعلق بعدد البادئات في الجدول.

عُدّ التسميات للخدمة والنقل قبل أن تختار. لا يزال تصميم لكل VRF يحتاج تسميات نقل لواجهات loopback ولكل قفزة على المسار، ولا يزال يحتاج حالة تجاور. وإذا كانت مواصفات التصميم تعدّ تسميات الخدمة فقط، فالتوفير يُقاس على السجل الخطأ.

تغذيات المسارات تكلّف ذاكرة قبل التسميات

كل مسار مستلم يستهلك ذاكرة مستوى التحكم ومعالجة التحديثات ووقت التقارب، سواء استخدم الـVRF تسمية واحدة أو عشرة آلاف. التغذية الكاملة للإنترنت داخل VRF مكلفة بسبب مسارات BGP وجدول RIB ومدخلات FIB والتقلبات خلفها، لا بسبب التسمية التي تتصدر الجدول. والتغذية نفسها ترفع أيضًا نطاق تأثير تسريب مسار أو خطأ سياسة داخل ذلك المستأجر.

لذا اسأل عمّا يحتاجه العميل فعلًا. إذا كان العقد مواقع خاصة مع مخرج افتراضي، فإن جدولًا كاملًا يضيف كلفة دون أن يضيف متطلبًا. هذا سؤال تجاري، ويستحق إجابة مكتوبة بدلًا من افتراض موروث من التصميم السابق. وإذا كانت الخدمة تحتاج التغذية فعلًا للسياسة أو لاختيار الخروج المحلي، فاجعل ذلك بندًا صريحًا بحجز سعة خاص به وسلوك فشل خاص به.

متى يكون التوسيم لكل VRF هو الافتراضي الصحيح

إنه افتراضي جيد عندما توثّقه المنصة كمدعوم، وعندما يكون عدد مسارات VRF كبيرًا، وعندما تكون كلفة البحث عند الخروج مقبولة لملف حركة المرور. وهو أيضًا الخيار الطبيعي عندما تكون البساطة التشغيلية أهم من انتزاع آخر ميكروثانية من التمرير، لأن تسمية واحدة لكل مستأجر أسهل في الشرح والتدقيق من تسمية لكل بادئة.

إنه الافتراضي الخاطئ عندما تربط وثائق المنصة الميزة بقيود عتاد أو إصدار محددة، أو عندما يعتمد التصميم على قرارات تمرير لكل بادئة عند الخروج. اقرأ مرجع المنصة الخاص بالبيان قبل افتراض السلوك؛ فأمر Junos موثّق، لكن حدود العتاد والإصدار المحيطة به هي ما يحدد النشر فعليًا.

ميزانية يمكنك الدفاع عنها

ابنِ حالة السعة كخمسة أرقام منفصلة: المسارات المستلمة، والمسارات المختارة، ومدخلات التمرير المثبّتة، وتسميات الخدمة، وتسميات النقل. أضف حالة القفزة التالية والتجاور، وعدد المستأجرين، ونموذج التكرار. لقطة المسار السعيد لـVRF واحد ليست رقم قياس، وحجم فضاء تسميات اسمي ليس جدول عتاد متاحًا.

ثم اتفق على نمط الفشل وكذلك الحالة المستقرة. ماذا يحدث عندما تنمو التغذية بالنصف، أو عندما يضيف مستأجر VRF ثانيًا، أو عندما تحتاج المنصة إعادة تشغيل لتغيير حجم جدول؟ الميزانية التي تصمد أمام هذه الأسئلة أغلى من عدد تسميات يعمل على الورق فقط.

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