UDLD أو Unidirectional Link Detection هو أحد البروتوكولات التى قامت سيسكو بتطويره وهو يعمل في الطبقة الثانية ووظيفته أيجاد المشاكل التى من ممكن حدوثه على الطبقة الأولى Physical Layer من خلال مراقبة عمل المنافذ وبالتحديد مراقبة حالة الأرسال والأستقبال التى تتم على المنفذ لنتكلم عن الموضوع بشكل أوضح
لنفرض أن لدينا سويتشان مرتبطان مع بعضهما البعض بأكثر من منفذ ولنفرض منفذان وطبعا في هذه الحالة سوف يعمل بروتوكول الـSTP لكي يمنع اللوب بينهم من خلال وضع أحد المنافذ في حالة Blocking والتى تتم من خلال أرسال الـ Root Bridge لي BPDU Frame إلى السويتش الآخر مخبرا أياه بوجوب وضع أحد المنافذ في حالة Blocking وحتى هذه اللحظة كل شيء واضح لكن لنفرض هذه الفرضية بأن البورت الذي تم أرسال الفريم إليه لم يستلم أي شيء والسبب هو وجود مشكلة في الكابل وتحديدا في الطرف المسؤول عن عملية الأستقبال وطبعا أول شيء سوف يخطر على بالك هو كيف يمكن حدوث هذا الشيء ؟ والجواب هو أن هذه المشاكل تحدث عادة في أسلاك الفايبر ونادرا ماتحدث للأسلاك العادية المعروفة بي الـUTP لكن محتمله والتى سوف تسبب ليLoop بسبب عدم أستلام أي BPDU من أحد المنافذ الموجودة في السويتش الثاني وسوف تدخل الشبكة في مشكلة كبيرة والسبب هو Unidirectional Link أو لينك أحادي الأتجاه يا أما يستقبل يا أما يرسل وليس الأثنان مع بعضهما البعض يعني ممكن نجد اللينك يقوم بالأرسال فقط ولايقوم باستقبال أي شيء أو نجد العكس! وطبعا الناتج كارثي نوعا ما على الشبكة بسبب حدوث مشكلة على الطبقة الأولى أثرت في عمل بروتوكول يعمل على الطبقة الثانية والجدير ذكره أنك من خلال مراقبتك لحالة المنافذ لن تجد أي شيء يدل على أي شيء لذا سوف تكون المشكلة أكبر
كيف يعمل الـ UDLD ؟
لنتفق أولا على ضرورة تفعيل البروتوكول على كلأ الطرفين وتبدأ العملية من خلال أستكشاف كل سويتش للآخر من خلال أرسال فريم خاصة بأجهزة سيسكو ممكن أن نطلق عليها Hello msg أو advertisement msg وترسل على العنوان التالي 01:00:0C:CC:CC:CC وهذا العنوان طبعا هو MAC address Multicast وتحوي هذه الفريم device ID مع port ID (يقوم البروتوكول بأبتكاره) بالأضافة إلى قيمة تحدد مدة بقاء الفريم محفوظة في السويتش الآخر نطلق عليها timeout وعندما تصل إلى الطرف الآخر تخزن في الذاكرة حتى تنتهي المدة التى أشرنا إليها وطبعا قبل أن تنتهي سوف يصل فريم جديد يحل مكان القديمة وبهذه الطريقة تبقى السويتشات في حالة مراقبة لكل البورتات المتصلة مع السويتش الآخر وإذا أحببت أن تستزيد أكثر عن الموضوع فأتجه إلى RFC5171 (ملاحظة هامة وهي أن الفريم يرسل من خلال كل المنافذ الموجودة بين السويتشان مع تغيير قيمة الـPORT-ID)
ماهي ردة فعل الـUDLD في حال حدوث مشكلة في اللينك؟
تعتمد ردة الفعل على كيفية أعدادنا للبروتوكول على السويتش وهو بشكل عام يملك وضعيتان يمكن أعدادهم
الوضعية الأولى Normal وفيها لن يقوم السويتش بأيقاف عمل البورت وسوف يستمر عمل البورت بشكل طبيعي وبدون تغيير حالة الـSTP والشيء الوحيد الذي سوف يحدث هو إضافة كلمة undetermined إلى جانب المعلومات الخاصة بالبورت وبكلام آخر عندما تقوم بعرض حالة البورتات الموجودة من خلال الأمر Show ip interface brief سوف تلاحظ وجود كلمة undetermined بجانب أسم البورت والتى سوف تلفت نظر مسؤول الشبكة حول حدوث مشكلة في اللينك
الوضعية الثانية هي Aggressive وهي تقوم مبشرة بتحويل البورت إلى errdisable أي تقوم بأيقاف البورت بشكل كامل وقبل أن يقوم بهذا العمل يقوم البروتوكول بأرسال 8 فريم كل ثانية حتى يتأكد أن البورت يواجه مشكلة فعلية وليست شيء عابر وبعدها يتم الأيقاف
طريقة الأعداد
كما أقول دائما أن طريقة الأعدا هي أسهل شيء في الموضوع وهي تتم من خلال التوجه إلى المنفذ وكتابة الأمر التالي
Switch(config-if)#udld port aggressive
إذا في حال أردنا أن يكون الوضع هو normal لانقوم بكتابة aggressive
ملاحظات هامة
يعد هذا البروتوكول كمساعد للـSTP لأنه أكثر بروتوكول يمكن أن يتأثر بهذه المشكلة هو STP
هذا البروتوكول مدعوم في سويتشات Catalyst فقط
بعض السويتشات يدعم الوضعيتان والبعض الآخر يدعم وضعية normal فقط (سياسة خبيثة من سيسكو! ) هذا رابط يوضح المودلات المدعومة UDLD Availability on Catalyst switch
يمكننا تغيير قيمة الـ Timeout في بعض المودلات من خلال الأمر udld interval 10 وهي قيمة تتراوح من 7 إلى 90 ثانية والقيمة الطبيعية هي 15
أنتهى موضوعنا اليوم ولاتنسونا من دعواتكم في الأمتحانان القادمان في هذا الأسبوع ودمتم بود