در این حالت روتری مسیر مقصدی را از دست داده است و مسیر جایگزین هم در جدول توپولوژی وجود دارد اما فرمول Feasible Successor در مورد بهترین مسیر جایگزین صادق نیست. در چنین شرایطی روتر از مکانیزم Query and Reply بهره می برد. در این مکانیزم روتر از همه همسایه هایش سوال می کند که آیا  برای این مقصد مسیری دارید؟

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

  • روتری که از آن سوال شده است آیا برای مقصد X مسیری داری، اصلا مقصدی به نام X در جدول مسیریابی اش ندارد که در این صورت بلافاصله پاسخ می دهد مسیری ندارم. این حالت معمولا وقتی اتفاق می افتد که روتر همسایه، مسیر خلاصه شده ای از چند مقصد که مقصد X نیز در دل آن است را دارد اما دقیقا برای مقصد X مسیری در جدول مسیریابی ندارد.
  • روتری که از آن سوال شده است آیا برای مقصد X مسیری داری، مسیر دارد. در این صورت به ما اعلام می کند که برای مقصد X مسیر را می داند و بنابراین این همسایه یکی از انتخابهای ما برای مسیر رسیدن به مقصد X خواهد بود.
  • در حالت سوم، همسایه ای که از آن سوال شده است آیا برای مقصد X مسیری دارد، مسیر دارد. اما مسیر روتر به مقصد همان روتری است که از او سوال پرسیده است که در این صورت مسیر روتر همسایه نیز به مقصد X، Down می شود. در چنین شرایطی همسایه نیز پروسه Query and Reply را دنبال می کند و از همه همسایه هایش سوال می کند که آیا مسیری برای مقصد X دارند. اینکه، روتری که از او سوال پرسیدیم، خود از همه همسایه هایش سوال کند، ممکن است باعث طولانی شدن و حتی گاهی بی نهایت شدن زمان پروسه Query and Reply شود که راه حل آن Active Timer است و کمی جلوتر در مورد آن صحبت خواهیم نمود

برای درک بهتر این موضوع مجددا به مثال قبل توجه کنید اما این بار لینک بین IOU3 و IOU4، 9 مگابیت بر ثانیه است. دیدیم که در چنین شرایطی مسیر دوم که بهترین و تنها مسیر جایگزین به مقصد 192.168.1.0/24 است، Feasible Successor نیست. بدیهی است که اگر مسیر اصلی IOU1 به مقصد قطع شود، روتر بدلیل آنکه بهترین مسیر جایگزین Feasible Successor نیست از مکانیزم Query and Reply برای یافتن مسیر جدید بهره می برد.

Query1

مکانیزم Query and Reply وقتی Feasible Successor نداشته باشیم

خروجی جداول show ip eigrp topology و show ip eigrp topology all-links نشان می دهد که روتر به مقصد 192.168.1.0/24 دو مسیر دارد اما مسیر دوم که بهترین مسیر جایگزین است، Feasible Successor نیست هر دو مسیر در خروجی دستور show ip eigrp topology all-links ظاهر می شوند اما در خروجی دستور show ip eigrp topology فقط یک مسیر ظاهر می شود

IOU1#sh ip eigrp topology all-links

P 192.168.1.0/24, 1 successors, FD is 435200, serno 17

        via 10.1.2.2 (435200/409600), Ethernet0/0

        via 10.1.3.3 (463616/438016), Ethernet0/1

IOU1#sh ip eigrp topology

P 192.168.1.0/24, 1 successors, FD is 435200

        via 10.1.2.2 (435200/409600), Ethernet0/0

        via 10.1.2.2 (332800/307200), Ethernet0/0

نمایش جزئیات پروسه همگرایی وقتی مسیر جایگزین مطمئنا Feasible Successor است

در زیر مشاهده می کنیم وقتی که مسیر بالایی را قطع می کنیم و بعد از آنکه IOU1 با کمک BFD متوجه قطعی مسیر بالایی می شود، روتر مسیر به مقصد 192.168.1.0/24 را از حالت Passive به Active تغییر می دهد. به صورت پیش فرض در جدول توپولوژی کنار هر مسیر حرف P به معنی Passive قرار می گیرد. زمانی که روتر برای جایگزین کردن مسیر، با مکانیزم Feasible Successor به نتیجه نرسد، وارد پروسه Query and Reply می شود که در این حالت مسیر را از Passive به Active تغییر می دهد. البته بدلیل سرعت بالای همگرایی معمولا نمی توان در خروجی دستور Show این تغییر را مشاهده نمود اما در این مثال با کمک دستور debug مشاهده می کنیم که روتر مسیر را به حالت Active می برد. همچنین نشان می دهد که روتر Reply Count را به 1 تغییر می دهد بدین معنی که یک Query ارسال نموده و منتظر یک Reply است. در ادامه نیز مشاهده می کنید که با دریافت Reply و یافتن مسیر، آن را جایگزین می نماید.

IOU1#debug eigrp fsm

*Jul 30 10:51:48.302: %DUAL-5-NBRCHANGE: EIGRP-IPv4 1: Neighbor 10.1.2.2 (Ethernet0/0) is down: BFD peer down notified

*Jul 30 10:51:48.302: IGRP2: linkdown: start - 10.1.2.2 via Ethernet0/0

*Jul 30 10:51:48.302: DUAL: Destination 10.1.3.0/24 for tid 0

*Jul 30 10:51:48.302: DUAL: AS(1) Removing dest 10.1.3.0/24, nexthop 10.1.2.2

*Jul 30 10:51:48.302: DUAL: Destination 10.1.2.0/24 for tid 0

*Jul 30 10:51:48.302: DUAL: Destination 192.168.1.0/24 for tid 0

!!! بخشی از خروجی حذف شده است

!!! مسیر به مقصد 192.168.1.0/24 به حالت Active می رود

*Jul 30 10:51:48.302: DUAL: AS(1) Dest 192.168.1.0/24 entering active state for tid 0.

*Jul 30 10:51:48.302: EIGRP-IPv4(1): Set reply-status table. Count is 1.

!!! بخشی از خروجی حذف شده است

*Jul 30 10:51:48.370: EIGRP-IPv4(1): rcvreply: 192.168.1.0/24 via 10.1.3.3 metric 463616/438016 for tid 0

*Jul 30 10:51:48.370: EIGRP-IPv4(1): reply count is 1

!!! بخشی از خروجی حذف شده است

جزئیات مکانیزم Query and Reply

محدود کردن دامنه Query and Reply:

بدلایل مختلف ممکن است در شبکه با پروتکل EIGRP، مکانیزم Query and Reply در یک پروسه طولانی و یا حتی بی نهایت قرار بگیرد. وقتی شبکه دارای مسیرهای افزونه و پیچیده باشد مانند توپولوژی Dual Hub and Spoke و یا وقتی که لینک های غیر مطمئنی در شبکه وجود داشته باشد که بسته Query و یا Reply در آن گم میشود، ممکن است با چنین شرایطی مواجه شویم. برای ممانعت از چنین شرایطی دو راه حل وجود دارد که در اینجا صرفا به عناوین آنها اشاره می کنیم اما هر دو راه حل از مباحث این فصل بوده و مفصلا در مورد آنها صحبت خواهد شد.

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

Active Timer:

همانطور که قبلا نیز گفته شد، پروسه Query and Reply وقتی پایان می یابد که اولین روتری که Query ارسال نموده است، پاسخ همه Query ها را دریافت کند. با توجه به بحث پاراگراف های قبلی، گاهی این اتفاق نمی افتد و روتر فقط به این دلیل که پاسخ فقط یکی از روترها را دریافت نکرده است، نمی تواند پروسه همگرایی خود را به پایان برساند و باید تا ابد منتظر بماند. برای رفع این مشکل در EIGRP مکانیزمی به نام Active Timer پیش بینی شده است. منظور از Active Timer حداکثر زمانی است که روتر برای یک مقصد در حالت Active  می ماند. این زمان به صورت پیش فرض 3 دقیقه است و با دستور زیر قابل تغییر است. همانطور که می دانید حالت Active حالتی است که روتر با مکانیزم Feasible Successor مسیر جایگزین را پیدا نمی کند و سراغ پروسه Query and Reply می رود. زمانی که روتر این پروسه را اجرا می کند، مقصد مورد نظر در جدول توپولوژی در حالت Active قرار دارد.

IOU1(config-router)#timers active-time ?

  <1-65535>  active state time limit in minutes

  disabled   disable time limit for active state

تغییر زمان Active Timer

وقتی روتر به زمان Active Timer می رسد و همچنان از یکی یا چند تا از همسایه ها پیغام Reply را دریافت نکرده باشد، همسایگی با آن همسایه ها را ریست می کند و تمام مسیرها از ابتدا با آن همسایه ها جابجا می گردد و بدین ترتیب پروسه همگرایی خاتمه می باید.

از IOS نسخه 12.1(5) به بعد پروسه Active تغییراتی در آن ایجاد شد که باعث بهبود این پروسه و رفع بعضی مشکلات گردیده است. نه به این مشکلات و نه بهبود آن در این کتاب اشاره نمی شود

نوشتن دیدگاه


تصویر امنیتی
تصویر امنیتی جدید