سفر به اعماق پروتکل های مسیریابی: Distance Vector ها (۲)

سلام به همه ی مهندسين گرامی. در اين قسمت سعی داريم تا با هم بررسی کنيم که پروتکل های مسیریابی Distance Vector  برای حل مشکلاتی که در پايان قسمت قبل مطرح کرديم، چه راهکارهايی رو به کار می برند.

***

• اگر از قسمت قبل به یاد داشته باشید، بیان شد که Distance Vector ها بر طبق قانون خود بايد کل Routing Table را بعد از گذشت يک بازه ی زمانی مشخص ارسال می کردند. اما تصور کنيد روتر X همسايه ای با نام Y دارد و از آن مسيرها به مقاصد A و B را فرا گرفته و در Routing Table خود ثبت نموده است. بازه ی زمانی مشخص مي گذرد و X بايد تمام مسيرهای موجود در Routing Table خود را با يک پيام آپديت برای همسايه ی خود یعنی Y ارسال نماید، در اين صورت روتر X بايد مسيرها به مقاصد A و B اي را که از Y فرا گرفته، دوباره به آن تبليغ کند.

اينجا دو مساله مطرح مي شود: اول اين که روتر X با اين کار بيهوده به نوعی سبب هدر رفت منابع می شود (پهنای باند براي ارسال جداول روتی با حجم بالا که اکثر مسيرها از طريق همان همسايه فراگرفته شده باشد)

دوم اين که فرض کنيد مقصد A، از دسترس خارج شود. روتر Y از اين موضوع باخبر می شود و قصد دارد تا با يک پيام آپديت اين موضوع رو به همسايه اش اطلاع دهد، اما قبل از اين که بتواند اين کار را انجام دهد ناگهان آپديتی از روتر X دريافت مي کند مبنی بر اين که روتر X به مقصد A که يک گام با آن فاصله دارد، دسترسی دارد. اگر به خاطر داشته باشید بیان شد که Distance Vector ها حکم تابلویی سر دو راهي را دارند که فقط فاصله و جهت تا یک مقصد را اطلاع می دهند، اما اين که آيا اين اطلاعات واقعا درست است يا نه، هيچ تضمينی نيست. بنابراين روتر Y، حرف X را قبول کرده و دوباره مسير به مقصد A را با افزايش يک گام به hop-count آن، به جدول روت خود اضافه می کند. به اين ترتيب اگر پکتی به مقصد A به دست X برسد، آن را برای Y ارسال می کند و Y دوباره آن را برای X ارسال می کند و این عمل همينطور ادامه پيدا کرده و  Loop در مسیریابی رخ ميدهد.

در اینجا قانونی مطرح می شود که : اگر آپديتی از طريق يک اينترفيس ارسال شود، نبايد شامل مسيرهايی باشد که از طريق دريافت پيام آپديتی از روي همان اينترفيس، فرا گرفته شده باشند. به این قانون يک خطی Simple Split Horizon گفته می شود. پس Simple Split Horizon با سرکوب مسيرها از بروز loop جلوگيری ميکند.

اما هميشه قانونی هست که می گوید: “خبر بد دادن بهتر از هيچ خبری ندادن است!“ اين سياستی است که قانون Split Horizon with Poisoned Reverse Route از آن تبعيت مي کند. این امر به این معنی است که روتر به جای سرکوب و عدم ارسال تمام مسيرهايی که از همسایه ی خود فرا گرفته، آن مسيرها را با متريک بی نهايت (يا Unreachable) برای آن همسایه، ارسال می کند. به این کار اصطلاحا “سمی کردن مسیر” گفته می شود.

قانون دوم Split Horizon از قانون اول قوی تر است، چرا که هميشه با اصطلاحا “سمی کردن مسيرها“، از بروز خطا در مسيريابی جلوگيري می کند. اما عيبی که نسبت به قانون اول دارد آن است که مشکل مصرف منابع هم چنان سرجای خود باقی است و افزايش سايز پکت ها ممکن است باعث افزايش ازدحام شود.

• اما تا اينجا متوجه شدیم که Split Horizon از رخ دادن loop بين دو روتر جلوگيری می کند، اما مشکل ديگری که وجود داشت اين بود که این قانون مانع از بروز loop در کل ساختار نمی شود.

فرض کنيد مسير رسيدن به يک مقصد fail شود و در طول ارسال آپديت از طريق روتری که به اين مسير متصل است، براي اطلاع اين fail شدن به همسايه هایش، روتر ديگری که چند گام دورتر قرار دارد آپديتي مبنی بر اين که به آن مقصد دسترسی دارد، ارسال کند در نتيجه روترها این پیام او را پذیرفته و دوباره آن مسير را با افزايش يک گام به hop-count آن، به Routing Table های خود اضافه کنند. به این ترتیب مسير به مقصدی که اصلا وجود ندارد، مدام بين روترها دست به دست شده و متريکش تا بی نهايت اضافه می شود!

براي حل اين مشکل Distance Vector ها، بی نهايت را يک تعداد گام مشخص اعلام کردند. به عنوان مثال اینگونه تعیین کردند که اگر تعداد گام برای يک مسير 16 گام شد، متريک آن بی نهايت است و دیگر آن مسیر در دسترس نيست. به این ترتیب با تعريف حداکثر گام برای مسيرها، مشکل loop در کل ساختار و شمارش متريک يک مسير تا بينهايت حل شد.

• اما مشکل بعدی اين بود که اگر روتر رسيدن به يک مقصد fail مي شد، روترها چگونه تشخیص می دادند که آن مقاصد ديگر در دسترس نيستند؟ آنها بدون اطلاع، پکت ها را به مقصدي ارسال ميکردند که وجود خارجي نداشت و اين باعث ايجاد black hole در ساختار مي شد! Distance Vector ها برای حل اين مشکل تايمری برای منقضی کردن مسيرها تعريف نمودند. يعنی اینگونه بیان کردند که اگر مثلا n پيام آپديت (مثلا 3 پيام آپديت) دريافت شد ولی در اين پيام ها خبری از مسير مورد نظر نبود، به آن مسير مارک Unreachable ميزدند. منطقی است که وقتی روتری fail شود، آپدیتی هم ارسال نمی کند در نتیجه مسیرهایی هم که از طریق آن در دسترس بوده اند، چون توسط هیچ پیام آپدیتی برای سایر روترها تبلیغ نمی شوند، تایم آنها منقضی شده و در Routing Table سایر روترها، مارک Unreachable خواهند خورد.

• اما روترها چطور تغييرات توپولوژي را به همسايه های خود اطلاع می دهند؟ آیا بايد صبر کنند تا تايم نرمال ارسال آپديت فرا رسد و بعد اين اطلاع رساني را انجام دهند؟ در این صورت زمان همگرايي مجدد به شدت افزايش پيدا می کند. پس براي حل اين مشکل از مفهومي استفاده شد به اسم Triggered Update که اینگونه بیان می کند که هر زمان تغييري در ساختار رخ دهد، بدون منتظر ماندن براي تايم ارسال آپديت به صورت نرمال، روتر باید بلافاصله پيام آپديتي حاوي تغييرات رخ داده، ارسال کند. اين روش هم مشکل شمارش تا بي نهايت را به نوعي کاهش ميدهد، هم زمان همگرايي مجدد و هم اين که اگر اين پيام آپديت به گونه ای تعریف گردد که تنها حاوي تغييرات باشد، در کاهش زمان پردازش و پهناي باند در کل ساختار موثر است. اما کمکي به حل مشکل خطا در مسيريابي نمي کند، چرا که ممکن است بعد از دريافت Triggered Update، روتر يک آپديت نرمال را از روتري که هنوز همگرا نشده دريافت کند.

• و اما مشکل آخري که Distance Vector ها بايد براي حل آن نیز به دنبال چاره اي مي بودند، ارسال Broadcast پيام هاي آپديت به صورت همزمان در يک ساختار Broadcast بود که باعث بروز Collision مي شد. براي حل اين مشکل هم دو پيشنهاد مطرح شد: يکي اين که تايم ارسال آپديت روي هر روتر، مستقل از فرآيند مسيريابي تعريف شود، که در اين صورت اگر قطعي برق در ساختار رخ مي داد و روترها همه به صورت همزمان راه اندازي مجدد مي شدند، دوباره همه در يک وضعيت يکسان قرار ميگرفتند و باز هم مشکل حل نمی گردید. روش دوم استفاده از يک مقدار تصادفي براي اضافه کردن يا کم کردن از تايم نرمال ارسال آپديت بود که به اين مقدار تصادفي timing jitter گفته مي شد.

به اين ترتيب Distance Vector ها توانستن بر مشکلات خود غلبه کنند 🙂

اما هنوز هم یک چیز در رابطه با آنها غير قابل تغيير بود:

آنها فقط مسير تبليغ مي کردند و هيچ اطلاعي از کل ساختار در اختيار قرار نمي دادند.

همين امر باعث می شود که پروتکل هاي هوشمندي خطاب نشوند! در ادامه ي اين سفر همراه ما باشيد چون قصد داريم به سمت دسته اي برویم که برخلاف Distance Vector ها، از هوشمندي زيادي برخوردارند و شايد تنها نسل از IGP ها در آينده، پروتکل هاي مسیریابی اين دسته باشند 😉