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

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

جایگزین نمودن مسیر با کمک Feasible Successor

حال فرض کنیم مسیر به مقصدی از دست رفته است و مسیر جایگزین هم در جدول توپولوژی وجود دارد. در این صورت یکی از دو حالت زیر اتفاق می افتد:

  • بهترین مسیر جایگزین در جدول توپولوژی Feasible Successor است که در این صورت مسیر Feasible Successor جایگزین مسیر از دست رفته و یا Successor می شود و این مسیر Successor جدید ما را تشکیل می دهد. به عبارت دیگر چنانچه مسیری از دست برود و بهترین مسیر جایگزین در جدول توپولوژی Feasible Successor باشد، زمان همگرایی بسیار سریع است و به سمت صفر گرایش دارد.

یادآدوری می شود که Feasible Successor مسیری است که AD آن از FD مسیر کوچکتر باشد. قابل اثبات است که اگر مسیری شرط فوق را داشته باشد حتما از بهترین مسیر مستقل است و می تواند سریعا جایگزین مسیر اصلی شود. البته عکس این قاعده صادق نیست. به عبارت دیگر ممکن است مسیری وجود داشته باشد که از مسیر اصلی مستقل باشد و بتواند در صورت قطع شدن مسیر اصلی سریعا جایگزین شود اما قاعده و فرمول Feasible Successor بودن در آن صادق نباشد. در این صورت پروسه همگرایی از مکانیزم Query and reply استفاده می کند و مسیر جایگزین را پیدا می کند.

fes1

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

fes2

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

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

برای درک بهتر به مثال قبل که مجددا در شکل زیر آمده است و لینک بین IOU3 و IOU4 9.5 مگابیت بر ثانیه است توجه کنید که در آن روتر IOU1 دو مسیر به 192.168.1.0/24 دارد و هر دو مسیر در جدول توپولوژی هستند و مسیر بالایی شکل Successor و مسیر پایینی شکل Feasible Successor است

همگرایی EIGRP در صورت وجود Feasible Successor

همگرایی EIGRP در صورت وجود Feasible Successor

خروجی جدول توپولوژی بدون پارامتر all-links نشان می دهد که مسیر دوم Feasible Successor است. زیرا در غیر این صورت در جدول توپولوژی قرار نمی گرفت

IOU1#sh ip eigrp topology

EIGRP-IPv4 Topology Table for AS(1)/ID(10.1.3.1)

Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,

       r - reply Status, s - sia Status

P 10.1.3.0/24, 1 successors, FD is 281600

        via Connected, Ethernet0/1

P 10.1.2.0/24, 1 successors, FD is 281600

        via Connected, Ethernet0/0

P 192.168.1.0/24, 1 successors, FD is 435200

        via 10.1.2.2 (435200/409600), Ethernet0/0

        via 10.1.3.3 (448512/422912), Ethernet0/1

P 10.2.4.0/24, 1 successors, FD is 307200

        via 10.1.2.2 (307200/281600), Ethernet0/0

P 10.3.4.0/24, 1 successors, FD is 320512

        via 10.1.3.3 (320512/294912), Ethernet0/1

        via 10.1.2.2 (332800/307200), Ethernet0/0

خروجی جدول توپولژی وقتی مسیر جایگزین مطمئنا Feasible Successor است

حال خروجی دستور را debug eigrp fsm، مشاهده کنید که اگر مسیر بین IOU1 و IOU2 قطع شود، چه اتفاقی می افتد. بدیهی است از آنجایی که بهترین مسیر جایگزین Feasible Successor است بدون هیچگونه تاخیری، مسیر جایگزین، بهترین مسیری بعدی و یا Successor خواهد بود

!!! در IOU2 لینک به سمت IOU1 را قطع می کنیم

IOU2(config)#interface ethernet 0/0

IOU2(config-if)#shutdown

!!! می بینیم که در IOU1، پروتکل BFD بلافاصله قطع شدن مسیر را تشخیص می دهد و برای مقصد 192.168.1.0/24 به دنبال Feasible Successor می گردد و آن را پیدا می کند و سریعا جایگزین می نماید.

IOU1#debug eigrp fsm

EIGRP Finite State Machine debugging is on

IOU1#

*Jul 29 13:10:18.252: %DUAL-5-NBRCHANGE: EIGRP-IPv4 1: Neighbor 10.1.2.2 (Ethern                                                      et0/0) is down: BFD peer down notified

*Jul 29 13:10:18.252: IGRP2: linkdown: start - 10.1.2.2 via Ethernet0/0

*Jul 29 13:10:18.252: DUAL: Destination 10.1.3.0/24 for tid 0

*Jul 29 13:10:18.252: DUAL: Destination 10.1.2.0/24 for tid 0

*Jul 29 13:10:18.252: DUAL: Destination 192.168.1.0/24 for tid 0

*Jul 29 13:10:18.252: EIGRP-IPv4(1): Find FS for dest 192.168.1.0/24. FD is 4352                                                      00, RD is 435200 on tid 0

*Jul 29 13:10:18.252: EIGRP-IPv4(1):    10.1.2.2 metric 4294967295/4294967295

*Jul 29 13:10:18.252: EIGRP-IPv4(1):    10.1.3.3 metric 448512/422912 found Dmin                                                       is 448512

*Jul 29 13:10:18.252: DUAL: AS(1) Removing dest 192.168.1.0/24, nexthop 10.1.2.2

*Jul 29 13:10:18.252: DUAL: AS(1) RT installed 192.168.1.0/24 via 10.1.3.3

*Jul 29 13:10:18.252: DUAL: AS(1) Send update about 192.168.1.0/24.  Reason: met                                                  ric chg on tid 0

*Jul 29 13:10:18.252: DUAL: AS(1) Send update about 192.168.1.0/24.  Reason: new                                                      if on tid 0

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

  • بهترین مسیر جایگزین در جدول توپولوژی Feasible Successor نیست. در چنین شرایطی EIGRP با بکارگیری مکانیزم Query و Reply اقدام به یافتن مسیر جایگزین و همگرا شدن می کند که این پروسه هم بسیار سریع است و حتی از SPF در OSPF نیز سریعتر است اما کمی کندتر از وقتی است که بهترین مسیر جایگزین در جدول توپولوژی Feasible Successor باشد. بدیهی است که الان این سوال در ذهن شماست که مکانیزم Query and reply چگونه عمل می کند؟

نوشتن دیدگاه


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