تتبع المسار في شبكة MPLS
المحتويات
المقدمة
يصف هذا المستند سلوك traceroute لبروتوكول رسائل التحكم في الإنترنت (ICMP) في شبكة تحويل التسمية متعدد البروتوكولات (MPLS) ومقارنة سريعة مع تتبع LSP.
معلومات أساسية
في بيئة IP، من المتوقع أن تقوم أي عقدة عند إستلام حزمة وإذا انتهت مدة البقاء (TTL) بإنشاء رسالة خطأ ICMP "TTL Exceeded" (النوع=11، الرمز=0) وإرسالها إلى عنوان مصدر الحزمة. يتم الاستفادة من هذا المفهوم لتتبع مسار IP من المصدر إلى الوجهة عن طريق إرسال حزمة UDP مع TTL بشكل تسلسلي بدءا من 1. ويمكن ملاحظة أن المتطلبات الأساسية للغاية لهذه الوظيفة هي:
- يمكن الوصول إلى عنوان المصدر للحزمة من عقد النقل
- لا تتم تصفية ICMP على طول المسار
في بيئة MPLS، قد لا يكون لموفر النقل LSR إمكانية الوصول دائما إلى عنوان المصدر ويحتاج إلى بعض التحسين لمعالجة ICMP في مجال MPLS.
ICMP Traceroute في شبكة MPLS
يتبع السلوك الافتراضي لأي LSR على إستلام حزمة مع TTL=1 على التسمية العليا سلوك IP التقليدي لإسقاط الحزمة وتشغيل رسالة خطأ ICMP. من أجل توجيه رسالة ICMP إلى المصدر، سيقوم LSR بتنفيذ ما يلي:
- تخزين مكدس التسمية مؤقتا من الحزمة الواردة (الحزمة المستلمة مع TTL=1)
- قم بإنشاء رسالة خطأ ICMP ذات المصدر كعنوان ووجهة الخاصين بها كعنوان مصدر من الحزمة المستلمة.
- قم بإلحاق جميع التسميات من أسفل مكدس التسميات (الذي تم تخزينه مؤقتا في الخطوة 1) مع TTL=255 باستثناء العنوان الأعلى.
- احصل على التسمية العليا من مكدس التسمية المخزن مؤقتا وقم بإجراء بحث LFIB محلي للحصول على التسمية المراد إستبدالها والنقلة التالية المقترنة.
- قم بإلحاق التسمية الجديدة بأعلى المكدس باستخدام TTL=255 ثم قم بالإرسال عبر.
باستخدام هذا النهج، تنتقل رسائل خطأ ICMP من ترحيل lsr إلى مخرج LER ثم تعود إلى مدخل LER إلى المصدر الفعلي.
تم تشغيل تتبع ICMP من PE إلى PE البعيد
وفيما يلي مثال بسيط يوضح السلوك عند تشغيل تتبع ICMP من PE إلى PE البعيد داخل مجال MPLS نفسه:
في هذا المخطط، عندما يتم تشغيل ICMP traceroute من R2 إلى 10.1.4.4، يتم إرسال الحزمة الأولى مع TTL رقم 1. سيقوم R3 عند إستلام الحزمة بخفض مدة البقاء (TTL) إلى 0 وتشغيل آلية إنشاء ICMP.
سيقوم R3 بتخزين مكدس التسميات مؤقتا وإنشاء رسالة خطأ ICMP وتضمين مكدس التسميات الواردة من المخزن المؤقت في حمولة ICMP. هو يقوم أيضا بتعميم رأس IP مع عنوان المصدر من الواجهة الواردة للحزمة المسماة، عنوان الوجهة كمصدر للحزمة المسماة. تم تعيين TTL على 255. وهو الآن يدفع مكدس التسميات من المخزن المؤقت ويستشير جدول LFIB لإجراء إعادة التوجيه على التسمية العليا. في هذا المخطط، مكدس التسميات المستلمة هو 17. عند إجراء بحث في جدول LFIB، يتم تبديل التسمية 17 بالتسمية 16 ويتم إعادة توجيهها نحو Nexthop R6. وسيقوم R6 بدوره بإرجاع التسمية العليا وإعادة توجيهه إلى R4 الذي سيقوم بإعادة توجيه الحزمة مرة أخرى نحو R2.
وكما يمكن ملاحظته في إخراج traceroute على R2، سيتم إدراج التسمية الواردة بواسطة كل خطوة على المسار.
تشغيل تتبع ICMP من CE إلى CE البعيد
وفيما يلي مثال بسيط يوضح السلوك عند تشغيل تتبع ICMP من CE إلى CE البعيد عبر مجال MPLS:
في هذا المخطط، عندما يتم تشغيل ICMP traceroute من R1 (CE) إلى 192.168.5.5 (CE البعيد)، يتم إرسال الحزمة الأولى مع TTL من 1. هذه حزمة IP عادية وبالتالي فإن R2 يتبع السلوك التقليدي لإنشاء ICMP وإرسال مباشرة إلى R1. ستنتهي صلاحية الحزمة الثانية التي يتم إرسالها باستخدام TTL=2 في R3.
سيقوم R3 بتخزين مكدس التسميات مؤقتا وإنشاء رسالة خطأ ICMP وتضمين مكدس التسميات الواردة من المخزن المؤقت في حمولة ICMP. هو يقوم أيضا بتعميم رأس IP مع عنوان المصدر من الواجهة الواردة للحزمة المسماة، عنوان الوجهة كمصدر للحزمة المسماة. تم تعيين TTL على 255. وهو الآن يدفع مكدس التسميات من المخزن المؤقت ويستشير جدول LFIB لإجراء إعادة التوجيه على التسمية العليا. في المخطط أعلاه، مكدس التسميات المستلمة هو {17، 18}. عند إجراء بحث في جدول LFIB للتسمية العليا، سيتم تبديل 17 بالتسمية 16 وسيتم إعادة توجيهه نحو Nexthop R6. سيقوم R6 بدوره بإخراج التسمية العليا وإعادة توجيهه إلى R4. سيستخدم R4 ملصق VRF لتعريف VRF وإعادة توجيه الحزمة مرة أخرى إلى R1.
كما يمكن ملاحظته في إخراج traceroute على R1، يتم سرد مكدس التسمية الوارد بواسطة كل خطوة على المسار.
MPLS LSP Traceroute في شبكة MPLS
على عكس traceroute المستندة إلى بروتوكول ICMP، يستخدم LSP traceroute الأجهزة المحددة في RFC4379. وهو يستخدم تضمين IP/UDP مع عنوان الوجهة للطلب الذي تم تعيينه على عنوان الاسترجاع (نطاق 127.0.0.0/8). من المتوقع تشغيل إختبار اتصال LSP ضمن مجال MPLS نفسه وبالتالي سيتم إرسال الرد مباشرة إلى البادئ.
عندما يتم تشغيل LSP traceroute ("traceroute mpls ipV4 <fec>") من أي LSR، سيتم تضمين التفاصيل المتعلقة بالتحقق من صحة FEC في TLV على أنها "مكدس FEC الهدف" في طلب صدى MPLS. سيتم إرسال هذه الرسالة مع TTL على مكدس التسمية بشكل تسلسلي بدءا من 1. سيعالج أي LSR عابر عند إستلام الحزمة وإذا انتهت صلاحية TTL حزمة IP، بما أن عنوان الوجهة هو عنوان إسترجاع. وسيتم ربطه بوحدة المعالجة المركزية لمعالجة MPLS OAM.
سيقوم المستجيب بشكل إختياري بإجراء التحقق من صحة FEC من خلال إحضار التسمية (التسمية) من مكدس التسمية لطلب صدى MPLS الذي تم إستقباله وتفاصيل FEC من TLV الخاص بمكدس FEC الهدف للتحقق من صحة الشيء نفسه مقابل معلومات مستوى التحكم المحلي. في حالة التتبع، سيقوم "المستجيب" بتضمين معلومات تدفق البيانات مثل التسمية الصادرة وعنوان المجاور لتدفق البيانات وما إلى ذلك في TLV كتعيين تدفق البيانات (DSMAP) TLV. (سيتم إهمال DSMAP بواسطة DDMAP لأنه أكثر مرونة من DSMAP).
تم تشغيل تتبع LSP من PE إلى PE البعيد
في هذا المخطط، يتم تشغيل تتبع LSP من R2 للتحقق من صحة LSP للبادئة 10.1.4.4/32. سيتم تعيين مدة البقاء (TTL) على التسمية من 1. عند تلقيه، سيتم تطبيق R3 على وحدة المعالجة المركزية (CPU) لمعالجة OAM.
سيقوم R3 بالرد على R2 باستخدام الرد على صدى MPLS مع DSMAP TLV الذي يحمل التسمية الصادرة 16 ومعلومات إضافية مثل تفاصيل الجوار لتدفق البيانات. وعلى عكس رسائل ICMP، سيتم إعادة توجيه "الرد على صدى MPLS" مباشرة من المستجيب R3 إلى البادئ R2.
وكما يمكن ملاحظته في إخراج LSP traceroute على R2، سيتم سرد مكدس التسمية الصادرة بواسطة كل خطوة على المسار. يختلف هذا عن traceroute المستندة إلى ICMP حيث تكون التسمية المدرجة في الإخراج مكدس تسميات وارد.
تم تشغيل تتبع LSP من CE إلى CE البعيد
وهذا قابل للتطبيق في CSC مثل السيناريوهات حيث يتم تمكين MPLS بين PE-CE. هناك تحديان في تنفيذ تتبع LSP من CE إلى CE البعيد عبر مجال MPLS الخاص بالناقل كما هو موضح أدناه:
- سيتم إرسال "رد صدى LSP" مباشرة إلى البادئ. يجب أن يكون المستجيب قادرا على الوصول إلى البادئ. في المخطط أعلاه، قد لا يكون ل R3 إمكانية الوصول إلى R1 كما هو في VRF.
- بالنسبة لكل تسمية في مكدس تسميات، يجب أن تكون هناك تفاصيل FEC ذات صلة مضمنة في مكدس FEC الهدف للتحقق من الصحة. قيمة FEC المضمنة بواسطة البادئ ستكون 1 بينما سيقوم PE بدفع تسميتين. في المخطط أعلاه، يرسل R1 طلب "صدى MPLS" باستخدام FEC={192.168.5.5/32} وتضمين التسمية 28 في المكدس. بما أن ملصق تبديل R2 28 مع {17، 27}، فإن R3 سيتلقى الطلب مع ملصقتين في المكدس بينما يقوم FEC واحد في TLV بالخلط بين التحقق من صحة FEC.
يحدد RFC6424 مفهوم "FEC Stack change TLV" لمعالجة المشكلة 2. سيتم تضمين TLV هذا في الرد مع FEC ذي الصلة ك PUSH/POP الذي يمكن تضمينه بواسطة البادئ في طلب ECHO اللاحق.
يحدد draft-ietf-mpls-lsp-ping-relay-reply مفهوم حمل مكدس عناوين عقدة ترحيل الإرسال في TLV الذي يمكن إستخدامه من قبل المستجيب لترحيل الاستجابة على الرغم من أنها لا تحتوي على إمكانية الوصول إلى البادئ.
لا يتم حاليا دعم هاتين المسألتين في Cisco IOS®، لذلك سيقوم تتبع LSP من CE إلى CE البعيد بإدراج PE و CE البعيد فقط. وهذا مشمول لمجرد الاكتمال.
التعليقات