النطاق /24 نفسه لعميلين؟ VPNv4 يحتاج إلى RD ووسم
يستطيع مستأجران الإعلان عن النطاق /24 نفسه فقط لأن RD يمنح كل مسار هويته الخاصة. أما الوسم فيجيب عن سؤال مختلف: كيف تُمرَّر الحزم.
يستخدم مستأجران النطاق 10.50.0.0/24 لفرعهما، وبعد تغيير يختفي مسار أحد المستأجرين من حافة المزوّد بينما يظل الآخر يعمل. التبسيط الذي يقف وراء تلك التذكرة هو عادةً إسقاط مميّز المسار (RD) بحجة أن «الوسم يعرّف العميل بالفعل». وهو لا يفعل ذلك. إن RD والوسم يجيبان عن سؤالين مختلفين، ولا تصبح الفجوة مرئية إلا عندما تفرضها العناوين المتداخلة.
مسار واحد حيث يجب أن يكون هناك مساران
يقارن الإرسال الأحادي IPv4 العادي مسارين إلى البادئة نفسها ويثبّت الأفضل. إن المسار 10.50.0.0/24 من المستأجر A والمسار 10.50.0.0/24 من المستأجر B مفتاح واحد، لذا يفوز أحدهما ولا يبقى الآخر إلا كمسار احتياطي. لقد فعل البروتوكول ما طُلب منه؛ إذ طُلب من مستوى التحكم تخزين مسارين مختلفين تحت معرّف واحد.
تبدو النتيجة وكأن مسارًا مفقودًا لا خطأً: فالـ PE الذي خسر المنافسة لا يزال يمرّر مستأجره محليًا، لذا ينجح اختبار بينغ داخل الموقع ويفشل اختبار ما بين المواقع. عُدّ الإدخالات الخاصة بتلك البادئة في جدول VPNv4 قبل أن تمسّ أي سياسة.
RD يحوّل مفتاحًا واحدًا إلى مفتاحين
يُضاف مميّز مسار من ثمانية بايتات إلى بادئة IPv4، فيصبح الكائن الذي يحمله BGP عنوان VPN-IPv4 بدلًا من بادئة IPv4. يستطيع مستأجران الاحتفاظ بالـ 32 بت نفسها لأن الـ 64 بت الأمامية تختلف. توجد أنواع تنسيق لـ RD قائم على AS ولآخر قائم على عنوان، والاختيار يعود إلى PE المنشئ. يكون RD القائم على AS شائعًا عندما تتشارك أجهزة PE في AS واحد، والقائم على العنوان عندما لا تتشارك.
لا تقرأ RD كوسم عضوية. تحكم أوسمة المسار الاستيراد والتصدير، وهي تقرر أي أجهزة VRF يجوز لها تثبيت المسار؛ أما RD فيضمن فقط أن يكون للمسار هوية خاصة به. من الممارسات الشائعة منح كل VRF وسماً خاصًا به من نوع RD، لأن ذلك يُبقي هذا التعيين مقروءًا عند تصفح جدول التوجيه.
الوسم تعليمات تمرير محلية
يحمل كل إعلان أيضًا وسم MPLS، ومعناه محصور في الموجّه الذي خصّصه. وقد يمنح PE آخر الرقم نفسه لوجهة غير ذات صلة. ولهذا تحديدًا لا يمكن أن يقوم الوسم مقام هوية العميل: فالرقم صحيح فقط إلى جانب القفزة التالية وحالة التمرير التي ثبّتته.
تتفاوت حبيبية التخصيص بحسب التنفيذ والتصميم: بعض المنصات تخصّص وسمًا واحدًا لكل VRF، وأخرى لكل بادئة، وقد يحدد الوسم إجراء تمرير لا عميلًا. لا يُعدّ وسمان مختلفان يصلان إلى الوجهة نفسها تناقضًا، ولا يُعدّ الرقم نفسه لوسم واحد عند جهازي PE تناقضًا كذلك.
| Field | Where it lives | Scope | If you remove it |
|---|---|---|---|
| RD | VPNv4 NLRI | Per advertised route | Overlapping prefixes collide |
| Route target | Extended community | Import and export policy | Route lands in the wrong VRF |
| Label | Labeled NLRI and forwarding state | Per allocating router | No instruction for the data plane |
| Next hop | Path attribute | Per path | The label cannot be resolved |
لماذا لا يحل أحدهما محل الآخر
قراءة إعلان تعني النظر إلى أربعة أمور معًا: البادئة المؤهلة بـ RD، وأوسمة المسار، والقفزة التالية، والوسم. أما قراءة حزمة مستخدم فتعني النظر إلى المكدّس الذي ثُبّت من تلك المعلومات. التصميم السليم يُظهر تطابق الجانبين، والتصميم المعطّل يكون فيه عادةً جانب صحيح وجانب قديم. هذه المقارنة تفصل مشكلة الهوية عن مشكلة التمرير.
التباين الأنيق بين مستوى التحكم ومستوى البيانات أداة تعليمية، لا وصفًا للترميز. RFC 8277 يضع الوسم داخل الـ NLRI الموسوم، فيحمل الإعلان نفسه الارتباط؛ واستخدامه للتمرير خطوة لاحقة ومنفصلة.
عندما يختفي مسار مستأجر، تحقّق بهذا الترتيب: إدخالان في VPNv4 يخصّان البادئة، ووسم المسار الصحيح على كل منهما، وقفزة تالية قابلة للحل، ووسم يملك PE المستقبِل حالة له. أما إصلاح الهوية بقيمة تمرير، أو العكس، فسوف ينجح في فحص ويفشل في التالي.