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

Distance-Vector-Routing

سلام به همه ی مهندسین گرامی. در این قسمت سعی داریم تا با هم بررسی کنیم که پروتکل های مسیریابی 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 ها، بی نهایت را یک تعداد گام مشخص اعلام کردند. به عنوان مثال اینگونه تعیین کردند که اگر تعداد گام برای یک مسیر ۱۶ گام شد، متریک آن بی نهایت است و دیگر آن مسیر در دسترس نیست. به این ترتیب با تعریف حداکثر گام برای مسیرها، مشکل loop در کل ساختار و شمارش متریک یک مسیر تا بینهایت حل شد.

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

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

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

Distance-Vector-Routing

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

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

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

    1. سلام و ممنون. خوشحالم که مطلب تونسته مفید واقع بشه. برای منبع اگر بخوام منبعی رو بگم پیشنهادم مطالعه ی کتاب Routing TCP/IP نوشته ی Jeff Doyle هست. اما این رو درنظر داشته باشید که یک کتاب هیچ وقت به تنهایی کافی نیست. شما باید به هر موضوعی که میرسید ببینید به درکی از اون نوشته رسیدید که بتونید تحلیلش کنید یا نه. شاید حتی به نظر شما یک مطلب اصلا اشتباه بیان شده باشه، پس باید برید و سرچ کنید و منابع مختلف رو پیدا کنید و بعد بر حسب اطلاعاتی که جمع کردید، برای خودتون قضیه رو تحلیل کنید. بنابراین شاید واقعا نشه یک کتاب یا حتی چند کتاب رو صرفا معرفی کرد و گفت همین ها کافی هست. مثلا در آینده اگر عمری باقی باشه و وارد مباحث اصلی یعنی بررسی خود روتینگ پروتکل ها بشیم, اونجا تنها منبع شما RFC ها خواهند بود و بعد در کنار اونها، کتاب ها و منابع دیگه. اما کتابی که معرفی کردم دید خوبی بهتون میده 🙂
      موفق باشید.

پاسخ دهید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *