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

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

***

Reliable Transport Protocol (RTP):

 مدیریت تحویل و دریافت پیام های EIGRP و هم چنین رعایت ترتیب در تحویل پکت ها، برعهده ی RTP است. برای تضمین این تحویل، RTP از الگوریتم اختصاصی سیسکو با نام Reliable Multicast بهره می گیرد.

تصدیق تحویل پکت ها و تضمین حفظ ترتیب آن ها در هنگام دریافت، از طریق دو Sequence Number در هدر EIGRP صورت می گیرد. یکی از این Sequence Number ها توسط روتر دریافت کننده ی پکت مقداردهی می شود و می تواند هر مقداری داشته باشد و هر زمان که روتر پکت جدیدی تولید کند، مقدار این Sequence Number یک واحد افزایش می یابد.

Sequence Number دوم در واقع Sequence Number آخرین پکتی خواهد بود که روتر دریافت کرده و باید تصدیق دریافت آن ارسال شود. این Sequence Number دوم در فیلد Acknowledgment Number در هدر EIGRP قرار می گیرد. قالب هدر EIGRP به صورت زیر می باشد:

تصویر 1   هدر پکت EIGRP

در EIGRP چندین پکت مختلف وجود دارد که بسته به نوع پکت، RTP از یکی از روش های Reliable Delivery یا Unreliable Delivery برای تحویل پکت ها استفاده می کند.

روش Reliable Delivery به این صورت است که پکتی که از این روش برای آن استفاده شده باشد حتما باید  Ack مربوط به دریافت شدن آن از طرف مقابل، دریافت گردد. در روش Unreliable Delivery نیازی به تصدیق دریافت پکت نیست.

اگر پکتی قرار نباشد به روش Reliable Delivery ارسال شود در فیلد Sequence Number آن مقدار صفر قرار می گیرد. اما EIGRP از چه پکت هایی استفاده می کند و برای هر کدام از این پکت ها از چه روشی استفاده می شود؟

به طور کلی EIGRP از پنج پکت زیر استفاده می کند که نوع پکت متناسب با مقداری که در فیلد Opcode قرار می گیرد مشخص خواهد شد:

• Hello: به منظور تشخیص همسایه ها، حفظ ارتباطات همسایگی و تشخیص از دست رفتن یک همسایه (فرآیند Neighbor Discovery/Recovery) از این پکت ها استفاده می شود. این پکت ها به صورت Multicast ارسال می شوند و از روش Unreliable Delivery برای آن ها بهره گرفته می شود. هنگامی که در فیلد Opcode مقدار 5 قرار داشته باشد، به این معناست که پکت از نوع Hello است.
• Acknowledgment (Ack): این پکت ها در واقع همان پکت های Hello هستند تنها با این تفاوت که در آن ها هیچ داده ای وجود ندارد و همیشه به صورت Unicast ارسال شده و از روش Unreliable Delivery برای آن ها استفاده می شود.
• Update: اطلاعات مسیرها از طریق این پیام منتقل می شوند. برخلاف پیام های Update در دیگر Distance Vector ها، این پکت ها فقط در صورت لزوم ارسال شده و تنها شامل اطلاعات ضروری می باشند هم چنین این پکت ها تنها برای روتری که این اطلاعات را درخواست کرده باشد، ارسال می شوند. زمانی که آپدیت ها تنها توسط یک روتر خاص تقاضا شده باشند، پیام آپدیت به صورت Unicast و فقط برای همان روتر ارسال می شود و زمانی که آپدیت ها توسط چندین روتر درخواست شده باشند، مثلا به محض تغییر متریک و یا رخ دادن تغییری در توپولوژی، پیام های آپدیت به صورت Multicast ارسال می شوند. پیام های آپدیت همیشه از روش Reliable Delivery استفاده می کنند. اگر در فیلد Opcode مقدار 1 قرار گرفته باشد، به این معنی است که پکت از نوع Update می باشد.
• Query و Reply: این پیام ها توسط DUAL finite state machine (که در قسمت بعد به سراغ این موضوع خواهیم رفت 🙂 ) برای مدیریت diffusing computation مورد استفاده قرار می گیرند. Query ها می توانند به صورت Unicast یا Multicast ارسال شوند اما Reply ها همیشه به صورت Unicast ارسال می شوند. هر دو پیام Query و Reply از حالت Reliable delivery استفاده می کنند. اگر در فیلد Opcode مقدار 3 قرار داشته باشد، پکت از نوع Query و اگر مقدار 4 قرار داشته باشد، پکت Reply می باشد.

(در RFC 7868 گروه دیگری از پکت ها با نام پکت های Request نیز معرفی شده اند که البته این پکت ها هرگز به مرحله ی پیاده سازی نرسیدند).

EIGRP برای ارسال پکت های Multicast خود از آدرس رزرو شده ای در کلاس D یعنی 224.0.0.10 بهره می گیرد.

با توجه به آن چه تا کنون گفته شد بیایید با مثال هایی نحوه ی ارسال پکت ها به روش Reliable Delivery را بررسی کنیم. فرض کنید در ساختاری Point-to-Point که لینک ها دارای ثبات می باشند، روتر A در گام اول یک پکت Update را برای روتر B ارسال کند (در تصاویر زیر منظور از SEQ، فیلد Sequence Number و منظور از Ack فیلد Acknowledgment Number می باشد).

تصویر 2   ارسال پیام آپدیت بر روی لینک های Point-to-Point با ثبات

در تصویر بالا روتر B بعد از دریافت پیام آپدیت از جانب روتر A، تصدیق این دریافت را از طریق ارسال یک پکت Ack که در واقع پیام Hello ای خالی از داده و با Sequence Number ای با مقدار صفر و Acknowledgment Number ای برابر با مقدار فیلد SEQ پیام Update دریافت شده می باشد، انجام می دهد.

در گام بعد روتر A برای روتر B پکت Query ارسال می کند. این فرآیند در تصویر زیر مشخص گردیده است.

تصویر 3   ارسال پیام Query بر روی لینک های Point-to-Point با ثبات

روتر B بعد از دریافت پیام Query از جانب A، پیام Reply که در فیلد Ack آن مقدار فیلد SEQ پکت Query دریافت شده از جانب A قرار گرفته، برای A ارسال می کند. A نیز بعد از دریافت این reply، پکت Ack ای را با SEQ، صفر و Ack برابر با مقدار فیلد SEQ پکت Reply برای B ارسال کرده و پکت Query را از لیست پکت های در انتظار ارسال مجدد، پاک می کند.

هر دو تصویر بالا مستقیما از RFC استخراج شده اند. اگر فرآیند ارسال Query و آپدیت  را بر روترهای سیسکو مورد بررسی قرار دهید، با کپچر پکت های ارسالی با دو تفاوت نسبت به آن چه در این مثال ها نشان داده شد رو به رو خواهید شد: اول آن که پیام های آپدیت و کوئری بر روی لینک های سریال همیشه به صورت Unicast و نه Multicast ارسال می شوند (کاملا برخلاف تصاویر نشان داده شده در بالا) و دوم آن که روتر دریافت کننده ی پکت Query ابتدا یک پیام Ack و سپس پیام Reply برای ارسال کننده ی پیام Query ارسال خواهد کرد. دلیل ذکر این موضوعات به این جهت می باشد که پیاده سازی یک پروتکل بر روی دستگاه های وندورها شاید کمی متفاوت تر از آن چه در RFC بیان شده، باشد.

ارسال پیام های آپدیت و Query در محیط Multi-access ای چون یک ساختار اترنت و در حالت ثبات به شکل تصاویر زیر خواهد بود.

تصویر 4   ارسال پیام Update در محیط های Multiaccess

تصویر 5   ارسال پیام Query در محیط های Multiaccess

تمام موارد ذکر شده در بالا برای حالت هایی است که لینک ها با ثبات و پایدار باشند. اما تصور کنید که لینک Point-to-Point ای بی ثبات باشد و پیام آپدیتی که به صورت مالتی کست ارسال شده، بنا به هر دلیلی به مقصد نرسیده و Ack آن دریافت نشود. در این صورت روتر به اندازه ی مدت زمانی که از آن با نام  Retransmit Timer یاد می شود صبر کرده و سپس پکت را مجددا ارسال می کند. اما تفاوت در اینجاست که در هنگام این ارسال مجدد، پکت به جای ارسال مالتی کست، به صورت Unicast ارسال خواهد شد.

در محیط های Multi-access این روند کمی تفاوت دارد. اگر روتری در یک محیط مالتی کست بنا به هر دلیلی پیام Update ای را دریافت نکند و یا نتواند Ack مربوط به آن را ارسال کند و اگر روتر ارسال کننده ی پیام آپدیت قبل از ارسال این پیام به صورت Unicast، نیاز باشد تا پیام آپدیت جدیدی را به صورت مالتی کست ارسال کند، روتر دچار تاخیر، در حالی که  هنوز پیام یونیکست مربوط به آپدیت اول را دریافت نکرده، پیام مالتی کست بعدی را دریافت می کند و این امر بدین معناست که شرط حفظ ترتیب پکت ها در هنگام تحویل، رعایت نشده است. برای حل این مشکل از حالتی با نام Conditionally Receive Mode استفاده می شود.

به عنوان مثال، در تصویر 4 تصور کنید که روتر B نتواند بنا به هر دلیلی Ack مربوط به پیام آپدیت روتر A با SEQ=100 را پاسخ دهد. در چنین شرایطی روتر A متوجه می شود که در Retransmit List روتر B، هم چنان یک پیام آپدیت وجود دارد. به همین دلیل روتر A قبل از ارسال پکت آپدیت مالتی کست بعدی با SEQ=101، ابتدا یک پکت Hello که در آن از Sequence TLV استفاده شده تولید و به صورت مالتی کست ارسال میکند. در واقع روتر A در این TLV آدرس IP تمام روترهایی که در Retransmit  List آن ها پکتی وجود داشته باشد، ذکر میکند.

روترهای C و D با دریافت این پیام Hello و پردازش Sequence TLV و عدم مشاهده ی آدرس IP خود در این TLV به حالت CR-Mode یا Conditionally Receive Mode می روند. به این معنی که اگر پیامی دریافت کنند که در آن از CR-Flag استفاده شده باشد باید آن پیام را دریافت و پردازش کنند. اما روتر B از آن جایی که آدرس IP خود را در Sequence TLV پکت Hello دریافتی از جانب A مشاهده می کند، به حالت CR-Mode نرفته و در نتیجه اگر پکت آپدیت مالتی کستی از جانب A دریافت کند باید آن را discard نماید.

حال روتر A پکت آپدیتی که قرار بر ارسال آن بود، به صورت مالتی کست ارسال میکند فقط با این تفاوت که در این پیام آپدیت فیلد Flags مقدار 0x02 دارد به عبارتی اگر مقدار این فیلد 0x02 باشد یعنی از CR-Flag در این پیام استفاده شده است. روترهای C و D با مشاهده ی پکتی که در آن از CR-Flag استفاده شده، این پکت را پذیرفته و پردازش می کنند و Ack مربوط به آن را برای A ارسال می کنند. اما روتر B که به حالت Conditionally Receive نرفته و حق پردازش پکت هایی که در آن ها از CR-Flag استفاده شده باشد، ندارد، این پکت را discard کرده و هیچ Ack ای در قبال آن برای روتر A ارسال نمی کند.

به این ترتیب روتر A پیام آپدیت با SEQ=100 را مجددا به صورت Unicast برای روتر B ارسال می کند. از آن جایی که روتر B قبلا پکت آپدیت با SEQ=100 را دریافت کرده، پکت آپدیت یونیکست با SEQ=100 را discard کرده و فقط Ack آن را برای A ارسال می کند. A این پکت را از Retransmit List روتر B حذف می کند. سپس پکت آپدیت با SEQ=101 را برای روتر B به صورت یونیکست ارسال می کند. روتر B این آپدیت جدید را پذیرفته و Ack مربوط به آن را برای A ارسال می کند و به این ترتیب Retransmit List روتر B خالی می شود.

در نتیجه RTP با انجام این اعمال، تحویل پکت ها با ترتیب درست را تضمین می کند 🙂

Neighbor Discovery/Recovery:

EIGRP باید قادر باشد تا از طریق روشی همسایه های خود را کشف کرده و از سوی دیگر از دست رفتن یک همسایه را تشخیص دهد. برای انجام این اعمال EIGRP از پکت های Hello استفاده می کند. به این صورت که به محض فعال شدن EIGRP بر روی یک لینک، پکت های Hello بر روی آن اینترفیس ارسال می شوند. در اکثر ساختارهای شبکه، پیام های Hello هر 5 ثانیه یکبار (منهای یک مقدار تصادفی برای جلوگیری از همزمانی) به صورت multicast ارسال می شوند.

پیام Hello ای که از جانب همسایه ای دریافت می شود شامل یک hold time است که این hold time در واقع برای روتر دریافت کننده ی پیام Hello، حداکثر تایم انتظار برای دریافت پکت Hello بعدی را مشخص می کند. اگر قبل از دریافت پکت Hello، تایمر hold time منقضی شود، همسایه Unreachable در نظر گرفته شده و DUAL این همسایگی را از دست رفته اعلام می کند. به صورت پیش فرض مقدار hold time، سه برابر hello-interval می باشد.

در پکت Hello مقدار Sequence Number همیشه صفر بوده و علاوه بر hold-time، شامل ضرایب شرکت کننده در معادله ی محاسبه ی متریک یعنی K-Value ها نیز می باشد.

هنگامی که قرار است برای اولین بار بین دو روتر ارتباط همسایگی برقرار شود، بعد از دریافت پکت Hello از جانب همسایه و چک یکسان بودن پارامترهای همسایگی، به منظور اطمینان از تحویل پکت های Unicast و Multicast، روتر یک پیام آپدیت خالی (بدون هیچ اطلاعات مسیری) برای همسایه ی تازه کشف شده ی خود ارسال می کند. به این پکت آپدیت اولیه اصطلاحا Null Update گویند که در آن فیلد Flags مقدار 0x01 داشته و این مقدار به معنی استفاده از INIT-Flag (Initial-Flag) می باشد. INIT-Flag به این معنی است که روتر دریافت کننده ی چنین پکتی باید تمام مسیرهای خود را تبلیغ کند. 

یک کاربرد دیگر برای INIT-Flag غیر از تشکیل ارتباط اولیه بین دو همسایه، برای زمانی است که روتری در حین کار ریستارت شود ولی قبل از آن که همسایه اش از این down شدن چند لحظه ای آن باخبر شود، مجددا up گردد. در چنین شرایطی اگر تغییری رخ داده باشد باید روتر ریستارت شده نیز از این تغییرات آگاه شود. در نتیجه با ارسال یک پیام آپدیت که در آن از INIT-Flag استفاده شده، از همسایه ی خود تقاضا میکند که آپدیتی شامل تمام مسیرهایی که شناسایی نموده، برایش ارسال کند.

فرض کنید بین روترهای A و B قرار است برای نخستین بار ارتباط همسایگی تشکیل شود. روتر A بعد از دریافت پکت Hello از جانب روتر B، یک پکت Null Update به صورت Unicast برای B ارسال کرده و وضعیت همسایگی روتر B را حالت pending (یا انتظار) تعیین میکند. روتر B با دریافت این Null Update بلافاصله یک پکت Null Update به صورت Unicast برای A ارسال می کند. روتر A با دریافت پکت Null Update از جانب روتر B، وضعیت آن را از pending به up تغییر داده و پیام آپدیتی حاوی کل اطلاعات توپولوژی که تاکنون شناسایی کرده، برای روتر B به صورت Unicast ارسال می کند. روتر B با دریافت این پیام آپدیت، ابتدا Ack آن را برای A ارسال کرده و سپس پیام آپدیتی حاوی کل اطلاعات موجود در Route Table خود به صورت Unicast برای روتر A ارسال می کند.

نکته ی حائز اهمیت در اینجا آن است که تا زمانی که پکت های Null Update از جانب هر دو همسایه ارسال و دریافت نگردند (یعنی همسایه در وضعیت pending باشد) هیچ پکت آپدیت (حاوی اطلاعات توپولوژی) یا Query اجازه ی ارسال نخواهند داشت.

***

امیدوارم خستتون نکرده باشم.در قسمت بعد به سراغ Diffusing Update Algorithm یا همون DUAL خواهیم رفت و بیشتر با این الگوریتم آشنا میشیم. همراه ما در این سفر باشید 🙂