قل «شغّل شبكة IPv6 L3VPN عبر IPv6 BGP» في مراجعة تصميم، وستجد ثلاث قرارات منفصلة مخبأة داخل تلك الجملة الواحدة. أي البادئات تنتمي إلى VPN الخاصة بالعميل، وأي العناوين تحمل جلسة التوجيه بين حواف المزوّد، وأي شبكة أساسية تنقل الحزمة الموسومة، كلها خيارات مستقلة. يمكن أن تكون كلها IPv6، ويمكن أن تكون مختلطة، والخلط مسموح به عن قصد. وفصل هذه الثلاثة هو ما يحوّل متطلبًا غامضًا إلى شيء يمكن اختبار المنصة عليه.

افصل المهام الثلاث

المهمة الأولى هي مسار العميل: بادئات IPv6 التي تنتمي إلى سياق توجيه واحد للـ VPN ويجب أن تبقى خارج كل سياق آخر. والثانية هي اتصال التوجيه بين موجهات حافة المزوّد التي تتبادل تلك البادئات. والثالثة هي النقل الذي يحمل حزمة العميل الموسومة عبر الشبكة الأساسية إلى الحافة البعيدة. وتسمية واحدة منها فقط ليست تصميمًا بعد.

JobThe question it answersWhat confusion looks like
Customer VPN routesWhich IPv6 prefixes belong to each VPN context, and how are they kept apart?Prefixes leak into the global table and between customers
PE-to-PE BGP sessionWhich addresses carry the routing connection between the two edges?A session-family mismatch gets chased as a core transport fault
Transport to the remote PEHow does the chosen core move the labelled packet to the far edge?A route is present and unforwardable in the same moment

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

عائلة المسار هي VPN-IPv6، لا IPv6 unicast

RFC 4659 يحدد عائلة BGP/MPLS IPv6 VPN، والعضوية فيها أدق مما توحي به كلمة IPv6. والمسار هناك مميّز مسار مرتبط ببادئة IPv6، مشفّر ضمن AFI 2 وSAFI 128. والـ IPv6 unicast العادي عائلة مختلفة، لذا قد لا يكون الإعلان الذي يبدو كبادئة في looking glass هو الشيء نفسه على الإطلاق. وقراءة العائلة بشكل خاطئ هي أول طريق يفسد فيه هذا التصميم.

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

قد تعمل الجلسة بعائلة مختلفة عن الـ VPN

لا شيء يفرض على اتصال BGP بين حافتين أن يستخدم عائلة الـ VPN نفسها. فالمواصفة تسمح بجلسة IPv4 أو IPv6، ونقل IPv6 VPN نفسه معرّف فوق نوعي الشبكة الأساسية. لذا فجلسة IPv6 لا تقول شيئًا عن عائلة ما تحمله، ولا تختار مستوى البيانات أيضًا. ثلاث بتات مستقلة، وعلى التصميم أن يحملها ثلاثتها منفصلة.

هذا محرّر وسهل القراءة الخاطئة في آن واحد. فيمكن لمسارات العميل IPv6 أن تسير على جلسة معنونة بـ IPv4، ويمكن لمسارات IPv4 أن تسير على جلسة IPv6، بشرط أن تدعم المنصة هذا المزيج وأن تُحلّ القفزة التالية. وما يجب ألا يحدث هو أن تُترك الجلسة لتدل على الحمولة، في وثيقة التصميم أو في المراقبة التي تثبت الخدمة لاحقًا.

القفزة التالية على شبكة أساسية IPv4 لها ترميزها الخاص

عندما تكون الشبكة الأساسية تحت الـ VPN من نوع IPv4، لا يظهر المسار بقفزة تالية يمكن لحافة الدخول استخدامها مباشرة. بل يصل بصيغة IPv6 مغلّفة بعنوان IPv4، وهكذا تعبّر المواصفة عن حافة الخروج عندما يكون النقل تحتها IPv4. ثم على الموجه الداخلي أن يحوّل ذلك العنوان المغلّف إلى شيء يستطيع الوصول إليه فعليًا عبر الشبكة الأساسية، والحل هو الخطوة التي تفشل بهدوء.

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

اكتب المتطلب في أربعة أسطر

المتطلب الذي يستحق الاختبار يسمّي أربعة أشياء: عائلة الـ VPN، ونقل الجلسة، وترميز القفزة التالية، وترتيب الشبكة الأساسية. ثم يسمّي بادئة عميل واحدة تُتابع من طرف إلى طرف، عبر التبادل والتثبيت وحل التسمية ومسار العودة. و«يدعم IPv6 BGP» لا يغطي أيًا من الأربعة ويخفي أين يكمن عدم التوافق فعلًا.

الجلسة السليمة بدون تبادل VPN-IPv6 ناقصة، والمسار VPN المستلم بدون تمرير عامل ناقص بالقدر نفسه. وإبقاء هذه كسطور قبول منفصلة يجعل محادثة استكشاف الأخطاء التالية قصيرة، لأن السطر الفاشل مكتوب مسبقًا.

مقالات ذات صلة