شبكة واحدة، إفصاح مختلف: ما الذي أضافته وسوم MPLS إلى خطأ ICMP؟

الخلاصة

• يصف امتداد MPLS داخل ICMP مكدس الوسوم عند وصول الحزمة إلى الموجّه الذي يبلّغ عن الخطأ، مع الإبقاء على اقتباس بيانات IP.
• إمكان إرفاق الدليل لا يعني وجوب كشفه لكل جهة؛ فقد تختلف الإضافة بحسب عنوان المستلم أو الإعداد العام أو عمق المكدس.
• لا تكفي سلامة التنسيق لإثبات هوية المبلّغ، ولا يكفي غياب سطر الوسوم لإثبات غياب MPLS عن المسار.

من يتلقى التقرير يغيّر ما يظهر فيه

تضع RFC 4950، المنشورة في أغسطس 2007، احتمالًا تشغيليًا واضحًا: قد يرغب مشغّل الشبكة في إظهار معلومات MPLS بصورة انتقائية. من الأمثلة أن تُرفق التفاصيل برسائل ICMP المتجهة إلى كتل عناوين الإدارة، لا بكل رسالة تخرج من الموجّه.

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

هذه نقطة مهمة عند النظر إلى شاشة traceroute. السطر الذي يعرض وسمًا ليس مجرد نافذة محايدة فُتحت على البنية الداخلية. قبل أن يصل إلى الشاشة، يجب أن توجد رسالة مناسبة، وأن يُضاف إليها الامتداد، وأن تصل، وأن يفهمها البرنامج.

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

ما الذي لم تكن رسالة IP تحتفظ به؟

قبل مناقشة الإفصاح، كانت هناك مشكلة أبسط: لم يكن التقرير يحمل بعض المعلومات أصلًا.

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

لكن المكدس الذي وصل مع الرزمة لم يعد في هذا الاقتباس. وهذه ليست تفاصيل هامشية؛ فهو السياق الذي كان الموجّه سيعتمد عليه في اختيار التمرير.

قد تكون الرسالة دقيقة فيما اقتبسته، مع أنها لا تحتفظ بما يكفي لشرح القرار. لذلك عرّفت RFC 4950 كائن امتداد ينقل مكدس الوسوم كما وصل إلى الجهاز الذي يولّد الخطأ. وأوصت بإرفاقه بالأخطاء المختارة، مع إلزام الرسالة بالاحتفاظ بترويسة IP وبداية الحمولة الأصلية أيضًا.

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

لماذا لا تكفي زيادة طول الاقتباس؟

في سبتمبر 1981، عرّفت RFC 792 رسالة Time Exceeded بحيث تتضمن ترويسة الإنترنت وأول 64 بت من بيانات الرزمة الأصلية. تساعد هذه الأوكتتات الثمانية المضيف على ربط الخطأ بالعملية المناسبة، ومنها الاستفادة من أرقام المنافذ إذا كان البروتوكول الأعلى يستخدمها في البداية.

كان ذلك حلًا لمسألة الارتباط: أي اتصال تخصه هذه الرسالة؟ ولم يكن وعدًا بتسجيل كل حالة استخدمها كل جهاز في الطريق. كما لا يصح جعل هذا الوصف التاريخي دليلًا على أن جميع صيغ ICMP اللاحقة اقتبست دائمًا ثمانية أوكتتات فقط.

في MPLS تقع البيانات المفقودة قبل ترويسة IP، لا بعد نهاية الجزء المقتبس منها. توضح RFC 3032، الصادرة في يناير 2001، أن مكدس الوسوم يأتي بعد ترويسات طبقة الوصلة وقبل ترويسة طبقة الشبكة.

يشغل كل عنصر أربعة أوكتتات. يظهر عنصر القمة أولًا، ويشير البت S إلى العنصر الأخير. ومن البحث عن الوسم العلوي يتحدد، ضمن أمور أخرى، القفز التالي والعملية على المكدس: استبدال عنصر، أو نزعه، أو إضافة عناصر.

لذلك لا تستعيد زيادة الاقتباس داخل رزمة IP تلقائيًا الطبقة التي أزيلت قبلها. كان لا بد من حفظها بوصفها معلومة منفصلة ذات اسم وحدود.

لحظة الوصول ليست حالة الخروج

يصف كائن RFC 4950 المكدس الوارد كاملًا بترتيبه وصيغته عند وصوله إلى الموجّه المبلّغ. ويمكن إضافته إلى Time Exceeded وDestination Unreachable في كل من ICMPv4 وICMPv6. لا تمتد هذه القاعدة تلقائيًا إلى كل أنواع ICMP.

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

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

في كل عنصر عشرون بتًا لقيمة الوسم، وثلاثة بتات كان اسمها EXP، وبت S واحد، وثمانية بتات لـTTL. غيّرت RFC 5462، في فبراير 2009، اسم EXP إلى Traffic Class أو TC لتوضيح الاستخدام. لم يغيّر ذلك حجم العنصر.

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

رقم مشترك للتنسيق، لا هوية مشتركة لكل وسم

تعرّف RFC 3031 وسم MPLS بأنه معرّف ذو دلالة محلية لفئة تكافؤ في التمرير. وهو ليس ترميزًا لعنوان IP المقصود.

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

أما تسجيل فئة كائن ICMP ونوعه الفرعي فينظم كيفية قراءة التقرير. يعرف البرنامج أن البنية التالية مكدس وارد، بدل أن يخمّن معناها. لا يوزع هذا التسجيل قيم الوسوم التي تختارها أو تربطها الأنظمة المحلية.

هذا فصل بين تنسيق المعرفة وبين إدارة الشبكة. قد تحتاج الأنظمة المستقلة إلى قاموس مشترك كي تفهم دليلًا متبادلًا، من دون أن تنقل قرارات التمرير إلى الجهة التي تسجل مفردات ذلك القاموس.

لا بد من معرفة أين ينتهي الأصل

يعتمد الكائن على RFC 4884، المنشورة في أبريل 2007. فهي تتيح لبعض رسائل ICMP بنية متعددة الأجزاء: منطقة تقتبس الرزمة الأصلية، ثم ترويسة امتداد واحدة، ثم كائن واحد أو أكثر.

أضافت الوثيقة سمة طول من ثمانية بتات في حيز كان محجوزًا. تقاس منطقة الاقتباس بكلمات من 32 بتًا في ICMPv4، وبكلمات من 64 بتًا في ICMPv6. وعند إرفاق امتداد، يجب أن تحتوي المنطقة 128 أوكتتًا على الأقل؛ فإذا كان الأصل أقصر، يُستكمل بأصفار مع مراعاة المحاذاة اللازمة.

هذا العدد حد أدنى في التنسيق، لكنه كان موضعًا ثابتًا لدى بعض البرامج القديمة. تسجل RFC 4884 وجود تطبيقات بين 1999 وتاريخ نشرها كانت تضيف الامتدادات بعد 128 أوكتتًا بالضبط، من دون التصريح بالطول الجديد.

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

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

وضع التوافق اختيار معلن

تفرض القراءة المطابقة للوثيقة أن تعني سمة الطول الصفرية عدم وجود امتدادات. غير أن هذا التفسير يفوّت امتدادات بعض الرسائل القديمة التي لم تملأ السمة.

لهذا طلبت RFC 4884 من تطبيقات traceroute المطابقة توفير وضع غير افتراضي لقراءة تلك الاستجابات. إذا كانت الرسالة طويلة بما يكفي، يمكن لهذا الوضع البحث عن ترويسة صحيحة في الموضع القديم، مع التحقق من الإصدار والمجموع الاختباري.

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

وقد تتعامل التطبيقات التقليدية التي لا تعرف الامتدادات مع الأوكتتات الجديدة على أنها استمرار للاقتباس الأصلي. تناقش الوثيقة آثار ذلك، ولا تضمن أن كل تطبيق قديم سيبقى بلا أثر.

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

المكدس داخل التقرير غير الغلاف الذي يحمله

تصف RFC 3032 مشكلة أخرى: قد لا يعرف موجّه داخل نطاق MPLS طريقًا مباشرًا إلى مصدر IP الأصلي. وفي بعض الحالات يمكن نقل رسالة ICMP المنشأة أولًا باتجاه وجهة الحزمة الأصلية، حتى تصل إلى موجّه يعرف كيف يعيدها إلى المصدر.

تُنسخ قيم الوسوم لهذا النقل، لكن قيم TTL تضبط لتناسب رحلة الرسالة الجديدة. هذه الوسوم الخارجية تعمل فعليًا في حمل الخطأ. أما كائن RFC 4950 الموجود داخل الخطأ فيسجل حالة وصول الحزمة التي فشلت.

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

قد يحمل التقرير وصفًا دقيقًا لحالة واردة، بينما يقطع هو نفسه رحلة مختلفة حتى يصل إلى المراقب.

تفاصيل أكثر لا تعني قفزات أكثر ظهورًا

لا تعيد RFC 4950 تعريف العلاقة العامة كلها بين MPLS وICMP، ولا إجراءات TTL الخاصة بكل تغليف. وتقول صراحة إن المعالجة التي تعطل آلية traceroute الأساسية تحد أيضًا من النسخة الموسعة.

تشرح RFC 3443، من يناير 2003، نماذج ذات صلة. يزامن نموذج Uniform قيمتي TTL الداخلية والخارجية عند مدخل النفق ومخرجه. أما نماذج Pipe فيمكن أن تبدأ قيمة TTL الخارجية بقيمة مستقلة عن الداخلية.

لذلك قد لا يؤدي تغيير TTL داخل رزمة IP إلى إنتاج خطأ في كل قفزة داخل المسار الموسوم كما يتوقع صاحب الاختبار. لا يعني ذلك أن TTL الخارجي بلا حد، أو أن كل رسالة ICMP ممنوعة. بل إن شروط نشوء الرد لا تتغير لمجرد أن صيغة الرد أصبحت أغنى.

ثم تأتي سياسة الإفصاح مرة أخرى. يمكن أن يوجد رد صالح من دون أن يرفق المكدس لهذا المستلم. ويمكن أن توجد بايتات صحيحة لا يعرضها القارئ. من المسافة بين هذه الحالات تتكون حدود الرؤية.

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

إضافة المكدس أنقذت سياقًا كان يضيع عند الانتقال إلى معالجة IP. ولم تُلغ الحاجة إلى سؤال أبسط قبل كل استنتاج: ما الذي أتيح لهذا المراقب أن يراه، وفي أي ظروف؟