سفر به اعماق پروتکل های مسیریابی: 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)

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

با کمی تامل این گونه به نظر می آید که بسیاری از رفتارهای Distance Vector ها در EIGRP بهینه شده و اولین موضوعی که تا اینجا شاید بتوان  به آن اشاره نمود آن باشد که با این تغییرات در ارسال آپدیت، EIGRP پهنای باند کم تری نسبت به سایر Distance Vector ها مصرف می نماید.
مساله ی دیگر در رابطه با EIGRP که آن را از Distance Vector ها کمی متمایز می کند آن است که EIGRP برای لینک های کم سرعت هم راهکار ارائه می دهد به این صورت که EIGRP برای ارسال ترافیک خود تنها از 50 درصد bandwidth لینک استفاده می کند.

نکته ی بعدی در رابطه با EIGRP و تفاوتش با سایر Distance Vector ها آن است که، سایر Distance Vector ها برای به دست آوردن فاصله تا هر مقصد فقط به تعداد گام تا آن مقصد توجه می کنند.  یعنی هر مسیری که تعداد گام کم تری تا مقصد داشته باشد، دارای اولویت بیشتری است. حال تصور کنید که برای رسیدن به مقصدی مانند A دو راه وجود داشته باشد، یک مسیر با یک گام و از طریق یک لینک سریال و  مسیر دیگر با دو گام ولی هر دو گام از طریق لینک اترنت. Distance Vector ها مسیر از سمت لینک سریال را انتخاب می کنند، چرا که تعداد گام کم تری دارد در حالی که با این تصمیم گیری، پهنای باند قربانی تعداد گام می شود! شاید مسیر از سمت لینک اترنت دو گام دورتر باشد ولی باز هم پهنای باند بهتری نسبت به مسیر یک گامی لینک سریال دارد. در چنین شرایطی سایر Distance Vector ها با استفاده از روش های دیگر کاری می کنند که برای مسیر با پهنای باند کم تر و تعداد گام کم تر، متریک بیش تری  تبلیغ شود و در نتیجه مسیر با تعداد گام بیشتر به عنوان مسیر اصلی برای ارسال ترافیک انتخاب شود.

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

این پارامترها چه هستند و از کجا می آیند؟ از نظر EIGRP در تعیین مسیر بهتر، لینک مهم ترین نقش را دارد. پس برای انتخاب مسیر بهتر به پارامترهای وابسته به لینک توجه می کند. این پارامترها عبارتند از: Bandwidth، Delay، Load و Reliability. عده ای MTU یا همان حداکثر واحد انتقال لینک را نیز به عنوان یکی از پارامترهای محاسبه متریک عنوان می کنند اما دقت داشته باشید که درست است که این پارامتر به همراه سایر پارامترهای متریک (و همین طور Hop-Count) به همسایه ها گزارش داده می شود، اما هیچ نقشی در محاسبه متریک ندارد. از آن جایی که EIGRP از ترکیبی از چند پارامتر برای محاسبه ی متریک استفاده می کند، به این متریک اصطلاحا Composite metric گفته می شود. در اصل این روش محاسبه ی متریک را، EIGRP از جد خود یعنی IGRP به ارث برده است.

EIGRP برای این که به یکسری از پارامترهای محاسبه ی متریک اولویت بیش تری نسبت به سایر موارد بدهد، از ضرایبی استفاده می کند که به آن ها K Value ها گفته می شود. از طرف دیگر برای این که متریک 24 بیتی که IGRP از آن استفاده می نموده، به یک متریک 32 بیتی مبدل شود، در فرمول، کل پارامترها در یک 256 نیز ضرب می شوند و به این ترتیب فرمول محاسبه ی Composite metric به صورت زیر در می آید:

metric = 256 * ({(K1*BW) + [(K2*BW)/(256-LOAD)] + (K3*DELAY)}*(K5/(REL+K4)))

به صورت پیش فرض EIGRP زمان محاسبه ی متریک فقط از Bandwidth و Delay استفاده می کند و برای آن که فقط این دو پارامتر در محاسبه ی متریک استفاده شوند، به ضریب K آنها مقدار یک داده و به ضرایب K سایر پارامترها مقدار 0 می دهد. منظور از Bandwidth در فرمول Composite metric، کوچکترین Bandwidth در بین Bandwidth ها در طول کل مسیر و منظور از Delay ، مجموع کل Delay های اینترفیس های خروجی در طول مسیر رسیدن به مقصد می باشد.

Bandwidth ای که در فرمول محاسبه ی متریک قرار می گیرد از تقسیم 10⁷ تقسیم بر کوچکترین Bandwidth در طول کل مسیر به دست می آید. منظور از این Bandwidth ،Bandwidth حقیقی لینک نیست بلکه Bandwidth ای است که به صورت استاتیک به اینترفیس اختصاص داده شده و قابل تغییر می باشد. نکته ی دیگر آن که  Delay ها نیز به صورت استاتیک برای اینترفیس ها تعیین می شوند و قابل تغییر می باشند. زمان قرار گرفتن Delay اختصاص پیدا کرده به یک اینترفیس در فرمول محاسبه ی متریک، مقدار Delay تقسیم بر 10 شده و به این ترتیب مجموع Delay هایی که در رابطه ی محاسبه ی متریک قرار می گیرند بر حسب tens of microsecound خواهد شد. با تمام این توضیحات، اگر مقدار ضرایب K را به صورت پیش فرض در نظر بگیریم، نهایتا فرمول محاسبه ی متریک EIGRP به صورت زیر در خواهد آمد:

 metric = 256 * { [(10^7)/ BWmin] + [sum of delays]}

مشکلی که در رابطه با فرمول محاسبه ی متریک به این شیوه وجود دارد آن است که این رابطه جوابگوی لینک هایی با ‏bandwidth‏ بالا نیست (یعنی برای یک لینک ‏‎10G:256*107/107=256‎‏ و برای یک لینک ‏‎40G‎‏ هم ‏bandwidth EIGRP‏ برابر است با 256) و از سوی دیگر حداقل ‏delay‏ قابل پیکربندی برای هر اینترفیس با هر ‏bandwidth‏ ای هم 10 میکروثانیه است (یعنی لینک های ‏سریعتر هم همان ‏delay‏ ای را دارند که لینک هایی با سرعت کم تر دارند) به همین دلیل تصمیم بر آن شد که فرمول محاسبه ی متریک عوض شود. به این ترتیب به فرمولی که در بالا ذکر گردید متریک کلاسیک و به رابطه ی جدیدی که برای محاسبه ی متریک در ‏EIGRP‏ تعریف شده، ‏Wide ‎Metric‏ گویند. با این تغییر این امکان برای ‏EIGRP‏ فراهم شد تا هم جوابگوی لینک هایی با ‏Bandwidth‏ بالا باشد و هم ‏با محاسبه ی ‏delay‏ بر حسب ‏picosecond‏ مشکل حداقل ‏delay‏ برطرف شود.

‏
پارامترهای اصلی شرکت کننده در فرمول Wide Metric عبارتند از:  minimum Throughput, latency, load, Reliability و Extended Attribute‏ ها. ‏علاوه بر این پارامترها مواردی مثل MTU و Hop-Count  نیز به همراه پارامترهای متریک به همسایه ها گزارش داده می شوند. منظور از Extended Attribute ها Jitter و Energy هستند که این پارامترها و نحوه ی محاسبه ی آنها از یک مبدا تا یک مقصد، فعلا در حال توسعه و بررسی می باشد و تنها ‏در صورتی در فرمول محاسبه ی متریک شرکت داده می شوند که روتر از این پارامترها پشتیبانی نماید.
تغییر دیگری که در فرمول ‏Wide Metric‏ ایجاد شد معرفی ضریب جدیدی به نام ‏K6‎‏ بود که در صورت پشتیبانی روتر از ‏Extended Attribute‏ ها از این ضریب برای شرکت این پارامترها در محاسبه ی متریک استفاده می شود.‏

به صورت پیش فرض ‏Wide metric‏ بر اساس حداقل ‏Throughputو مجموع ‏Latency‏ ها محاسبه می گردد. به عبارتی در ‏این فرمول جدید، ‏Bandwidth‏ به ‏Throughput و ‏Delay‏ به ‏Latency‏ تبدیل شده است. برای محاسبه ی ‏Throughput‏ از ‏رابطه ی زیر استفاده می شود:‏

Throughput = K1 * (EIGRP_BANDWIDTH * EIGRP_WIDE_SCALE) / Interface Bandwidth (kbps)

که در این رابطه:

EIGRP_BANDWIDTH= 10⁷‎
EIGRP_WIDE_SCALE= 65536‎

و برای محاسبه ی ‏Latency‏ نیز از رابطه ی زیر استفاده می شود:‏

Latency = K3 * (Delay * EIGRP_WIDE_SCAL)/(EIGRP_DELAY_PICO)

که در این رابطه:

EIGRP_WIDE_SCAL= 65536‎
EIGRP_DELAY_PICO= 10⁶

به این ترتیب با فرض این که ضرایب ‏K1‎‏ تا ‏K6‎‏ مقادیر پیش فرض را داشته باشند و فقط ضرایب ‏K1‎‏ و ‏K3‎‏ در فرمول محاسبه متریک اثرگذار باشند، فرمول محاسبه ی ‏Wide Metric‏ به صورت زیر در خواهد آمد:‏

Metric = (K1 * min(Throughput)) + (K3 * sum(Latency))

این تغییرات در متریک سبب به وجود آمدن تغییراتی در قالب پکت های EIGRP شد که در قسمت های بعد به سراغ این تغییرات نیز خواهیم رفت. تا به اینجا با EIGRP و این که چه تغییراتی برای بهینه تر شدن آن نسبت به سایر Distance Vector ها انجام شده، کمی با هم آشنا شدیم. عملکرد EIGRP کلا در چهار مولفه ی اصلی خلاصه می شود:

  o Reliable Transport Protocol
 o Neighbor Discovery/Recovery
 o Finite State Machine
 o Route Management

در قسمت بعد به سراغ این مولفه ها می رویم و خیلی ریزتر و دقیق تر به بررسی عملکرد EIGRP خواهیم پرداخت. امیدوارم مثل همیشه همراه ما در این سفر باشید 🙂