نفق RSVP-TE يعمل، لكن L3VPN الخاص بالعميل لا يملك مسارًا
النقل والخدمة قراران منفصلان. اقرأ مكدس التسميات، وافحص تحليل القفزة التالية وربط VRF كلًا على حدة، ثم اختبر تدفقًا حقيقيًا واحدًا للعميل.
يمكن أن يكون الفريقان على حق معًا عندما يبلّغ العميل بأن الـ VPN متوقفة ويبلّغ فريق النقل بأن النفق سليم. يجيب LSP المهندَس هندسيًا و MPLS L3VPN على سؤالين مختلفين: الأول ينقل الحزم الموسومة عبر النواة، والثاني يقرر إلى أي سياق توجيه تنتمي الحزمة. وعندما يُخلط بينهما، تدور المناقشة في حلقة مفرغة لأن كل طرف يقيس كائنًا مختلفًا وكلتا القياسين صحيحان.
ارتفاع النقل وانخفاض الخدمة حالة طبيعية
يمكن أن يكون الـ LSP قائمًا ويحمل الحركة ويظهر في كل نظام مراقبة، بينما تبقى خدمة العميل غير قابلة للاستخدام. لا شيء في هذا المزيج متناقض، لأن النفق لا رأي له في وجود بادئة بعيدة، ولا في قبول سياسة الاستيراد لها، ولا في تمرير دائرة الربط للإطارات.
العلامة التي تفضح الالتباس عادةً غير متناظرة: تنجح اختبارات ping من واجهة PE الحلقية بينما لا يحصل مضيف على شبكة العميل المحلية على شيء، أو العكس. دوّن العناوين التي نجحت قبل أن تكوّن نظرية. وبمجرد أن تلاحظ أنك تختبر كائنين مختلفين، تكون الخطوة التالية قراءة مكدس التسميات بدلًا من الجدال حول أي رسم بياني صحيح. عنوانان، ومالكان، وعادةً شخصان مختلفان يعتقد كل منهما أن الآخر كسر شيئًا.
اقرأ المكدس بوصفه مسؤوليتين
التسمية السفلية تنتمي إلى الخدمة والتسمية العلوية تنتمي إلى المسار. يصف RFC 4364 التسلسل بوضوح: تُفرض تسمية مسار VPN أولًا، ثم تُنفق تلك الحزمة الموسومة نحو القفزة التالية لـ BGP، وهناك يدفع نفق هندسي تسميته الخاصة إلى الأعلى.
| Object | Decision it encodes | Who owns it |
|---|---|---|
| Attachment and VRF | Which customer context receives the arriving packet | Edge configuration |
| VPN route and service label | Which remote forwarding context handles the destination | BGP VPN signalling |
| Transport LSP and tunnel label | How the core carries the packet to the BGP next hop | RSVP-TE or another tunnel mechanism |
عند الـ PE البعيد تختار تسمية الخدمة المعاملة، وقد تكون بحثًا في VRF أو قرار ربط. لا يمكن استبدال تلك التسمية بأخرى تعبر النواة فقط، والاثنتان غير قابلتين للتبادل حتى عندما تظهران في المكدس نفسه على الواجهة نفسها.
ما يثبته نجاح RSVP وما لا يثبته
ينشئ RSVP-TE مسارات LSP ذات توجيه صريح، مع حجوزات موارد أو بدونها، وهذا ضمان محدد ومفيد بشأن المسار الذي تسلكه الحزمة عبر النواة. وهو ليس تصريحًا عن مسارات العميل، واسم نفق مُعدّ ليس مسارًا على الإطلاق.
ولا يوفّر وجود RSVP وعدًا بأداء طرفي. حجز النطاق الترددي على LSP واحد لا يقول شيئًا عن دائرة الربط، ولا عن خط وصول العميل نفسه، ولا عن سلوك الاصطفاف عند الحافة البعيدة. التعامل معه كضمان ينتج إجابات واثقة عن أسئلة لم يطرحها أحد. وإذا كان المطلب حقًا التزامًا بالنطاق الترددي، فيجب تجميعه من القطع التي تفرضه فعليًا، والـ LSP ليس سوى وسط تلك السلسلة.
افحص بالترتيب ثم توقف
اعمل من النقل إلى الخارج وتوقف عند أول خطوة تفشل، لأن كل خطوة لاحقة تفترض أن الخطوات السابقة صمدت. أولًا تأكد من أن LSP قائم وأن إدخال التحويل للبادئة الخاصة بالخدمة يشير إليه فعلًا. ثم تأكد من أن مسار VPN موجود في الجدول الصحيح، وأن ربط تسميته حاضر، وأن سياسة الاستيراد قبلته. ثم تأكد من الربط: الواجهة، والتغليف، وحيث ينطبق، معرّف VLAN الذي ينتمي إلى ذلك العقد.
show mpls lsp
show mpls forwarding-table 10.60.0.0 24
show bgp vpnv4 unicast vrf CUSTOMER 10.60.0.0/24
show ip vrf detail CUSTOMERتختلف صياغة الأوامر حسب المنصة، لذا تعامل مع تلك الأسطر الأربعة كأسئلة أربعة لا كسكربت. الجزء المهم أن كلًا منها يستجوب كائنًا مختلفًا، وهذا ما يجعل الفشل يشير إلى مالك محدد.
اتبع طلبًا واحدًا مسموحًا واحفظ الأدلة الجيدة
اختم بطلب عميل حقيقي واحد، يسمح به السياسة، وبردّه. تدفق واحد يعمل من طرف إلى طرف يحسم أكثر من صفحة من قراءات العدادات، ويمارس المزيج بدلًا من كل قطعة على حدة.
عندما تفشل مرحلة لاحقة، احفظ ملاحظة LSP الناجحة بدلًا من إعادة بناء النقل. إعادة بناء نفق عامل لا يمكنها إصلاح بادئة بعيدة غائبة، أو ربط VRF خاطئ، أو قاعدة وصول للوجهة، وهي تدمر الدليل الذي أخبرك أصلًا أن النقل سليم.