برچسب: Distance Vector

سفر به اعماق پروتکل های مسیریابی: EIGRP بخش اول

سلام به همراهان عزیز. بعد از شناختی که از سرزمین های هدفمون به دست آواردیم قصد داریم سفرمون رو شروع کنیم و پا به این سرزمین ها بذاریم. همونطور که در آخر قسمت قبل هم بیان کردم میخوایم به سراغ عضوی از سرزمین Distance Vector بریم که در حقیقت عضو این سرزمین بوده و هست ولی خیلیا اون رو دو رگه خطاب می کنن. شاید حدس زده باشید، بله منظورم پروتکل Cisco EIGRP هست 🙂 اما قبل از این که به سراغ این پروتکل بریم باید این رو عنوان کنم که از اینجا به بعد منبع ما برای بررسی پروتکل ها RFC هست. نه با زبان سخت و ثقیل RFC ها بلکه با زبان خودمون. اون چه که از این بعد قراره با هم بررسی کنیم پروتکلی که روی دستگاه یک وندور پیاده سازی شده نیست، بلکه هدف ما بررسی ذات حقیقی پروتکل های مسیریابی و آشنایی با نحوه ی عملکرد اصلی اون هاست. شاید خیلیا این کار و بیهوده و فقط مفید برای توسعه دهندگان پروتکل ها خطاب کنن اما خیلی وقتا مشکلات در پیاده سازی یک پروتکل مسیریابی از عدم درک درست عملکرد اون پروتکل نشات میگیره. بنابراین باز هم این رو تکرار میکنم که همیشه مشکلات سخت و پیچیده از جایی نشات می گیرن که ما ساده ترین مفاهیم رو فراموش کردیم 🙂 اما بیان بالاخره دل و به دریا بزنیم و وارد سرزمین Distance Vector بشیم.

معرفی پروتکل EIGRP:
ممکنه از خودتون بپرسید که چرا من شایسته ترین عضو سرزمین Distance Vector یعنی RIP رو برای شروع سفرم انتخاب نکردم. در جوابش باید بگم که هدفم بیشتر بررسی پروتکل هایی هست که در آینده ی نه چندان دور شاید تنها پروتکل های مسیریابی از نسلی باشن که من و شما می شناسیم (حتی ممکنه در آینده همین EIGRP هم دیگه جوابگو نباشه) اما اگر دوست داشتید که راجع به RIP هم صحبت کنیم و اون رو هم بیشتر بشناسیم خوشحال میشم حتما نظرتون رو در قسمت نظرات عنوان کنید 🙂

اما شاید باز از خودتون بپرسید که در اول این متن من بیان کردم که هدف ما بررسی پروتکل هایی فارغ از وندور هست ولی EIGRP که یک پروتکل برای شرکت سیسکو محسوب میشه و بنابراین نباید اینجا مطرح بشه. افرادی که کمی پیگیر جریان پروتکل ها هستن خوب می دونن که نهایتا در ماه مه سال 2016، RFC 7868 تحت عنوان ” Cisco’s Enhanced Interior Gateway Routing Protocol (EIGRP)” منتشر شد. به عقیده ی خیلیا این RFC معرفی کننده ی EIGRP اصیلی که روی دستگاه های شرکت سیسکو پیاده سازی شده نیست. اما قصد ما اینه که با رفتار این پروتکل متناسب با RFC آشنا بشیم اما اون بخشی از عملکرد این پروتکل که در RFC لحاظ نشده هم سعی می کنیم نهایتا با هم بررسی کنیم.

***

برای معرفی EIGRP باید به زمانی برگشت که توسعه دهندگان پروتکل IGRP که یک پروتکل اختصاصی شرکت سیسکو بود تصمیم بر توسعه ی این پروتکل گرفته و در صدد تبدیل آن به یک پروتکل Classless برآمدند. اما همزمان با تلاش برای بهبود قابلیت های عملکردی پروتکل IGRP، بر آن شدند تا از الگوریتم های آکادمیکی که در رابطه با بهبود زمان همگرایی بودند نیز در راستای این توسعه کمک گیرند. در نتیجه آن ها نه تنها به هدف خود یعنی ارتقای IGRP دست پیدا کردند بلکه سبب ایجاد پروتکل مسیریابی جدیدی شدند که با وجود برخی شباهت ها در رفتار به IGRP، یک پروتکل کاملا مجزا محسوب می شود.

اگر از قسمت اول این سری به خاطر داشته باشید، بیان شد که Distance Vector ها از الگوریتم مشهور Bellman-Ford برای پیدا کردن کوتاهترین مسیر استفاده می کنند، اما برخلاف آنها، EIGRP از یک سیستم محاسباتی جدید با نام Defusing Computation بهره می گیرد.
از سوی دیگر همانطور که در قسمت اول هم بیان گردید Distance Vector ها آپدیت های خود را به صورت دوره ای بعد از گذشت یک مدت زمان مشخص ارسال می کنند و نوع گزارش مسیرها نیز به صورت برداری از direction/distance می باشد. EIGRP هم از فرمول Direction/Distance برای گزارش مسیرها استفاده میکند اما آپدیت هایش دیگر به صورت دوره ای نیست بلکه دارای سه ویژگی است:

1- غیر دوره ای (یا همان non-periodic)
2- جزیی ( یا همان Partial)
3- محدود (یا همان Bounded)

ادامه خواندن “سفر به اعماق پروتکل های مسیریابی: EIGRP بخش اول”

همخوان کنید

سفر به اعماق پروتکل های مسیریابی: 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 جلوگيری ميکند.

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

همخوان کنید

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

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

تقريبا کل ديروز و داشتم در رابطه با اين فکر مي کردم که نقطه ی شروع مباحثم چی می تونه باشه، نهايتا ياد چند ماه پيش افتادم که تصميم گرفتم پروتکل های مسيريابی رو خيلي جزيی بررسی کنم. تو شروع اين راه فهميدم اگر ميخوام رفتار يک پروتکل مسيريابی رو خوب درک کنم بايد هرچی که تا اون لحظه ياد گرفتم رو بذارم کنار و دوباره شروع کنم به يادگيری. من باید تمام پیش فرض ها رو فراموش میکردم و از صفر شروع میکردم. فهميدم تو اين راه مدام ذهنم بايد بپرسه چرا؟ چطور؟ و اين که پشت هر مساله ی سختي يک مفهوم خيلی ساده بوده که فراموش شده، پس بايد از اول با همون مفاهيم ساده که خيلی بهشون اهميت نمی دادم کارم رو شروع کنم.

تصميم بر اين هست که اون چه دارم تو اين مسير از اول فرا ميگيرم با شما به اشتراک بذارم. اما قبل از رفتن سراغ يک پروتکل مسيريابی مشخص و بررسی نحوه ی عملکرد حقيقی يک پروتکل، شروع داستان سفرم رو قصد دارم با همون مفاهيم ساده ولی خيلی مهم که به فراموشی سپرده ميشن شروع کنم يعنی: بررسی عملکرد دو دسته ی کلی Distance Vector ها و Link State ها! هميشه داشتن اطلاعات در رابطه با منشا يک موضوع، ديد بازتری به آدم در تحليل اون موضوع خواهد داد (البته به نظر من 🙂 )
برای همين قسمت اول “سفر به اعماق پروتکل های مسيريابی” رو به بررسی رفتار کلی Distance Vector ها اختصاص دادم.

ادامه خواندن “سفر به اعماق پروتکل های مسیریابی: Distance Vector ها (۱)”

همخوان کنید