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

با هم امروز به ادامه بحث می پردازیم.

Static Neighbors

بواسطه Static Neighborship ما می تونیم به صورت دستی در EIGRP همسایه تعریف کنیم. با این کار عملا ارسال Hello Packet بین روترهای همسایه قطع می شود و شاید یکی از کاربردهایش هم همین باشد که در شبکه هایی که پهنای باند پایینی دارند Overhead حاصل از ارسال و دریافت Hello Packet را از روی شبکه برداریم.

اما چگونه Static Neighborship پیاده سازی می شود؟

فرض کنید مطابق شکل بالا ما دو روتر داریم که بین آنها روتینگ پروتکل EIGRP را پیاده سازی کرده ایم . پیاده سازی Static Neighbors  خیلی ساده است. فقط  کافی است به داخل هر کدام از روتر ها برویم و دستور زیر را پیاده سازی کنیم.

Router-1(config)#router eigrp 1
Router-1(Config-router)#neighbor 10.10.10.2 serial 0/0

همانطور که در بالا می بینید من به داخل روتینگ پروتکل eigp در روتر اول رفتم و با دستور Neighbor آی پی روتر مقابل را مشخص کردم و در پایان هم گفتم که این روتر به کدام پورت سریال من وصل است.

در روتر مقابل یعنی روتر R2 نیز همین کار را می کنیم.

Router-2(config)#router eigrp 1
Router-2(Config-router)#neighbor 10.10.10.1 serial 0/0

به همین راحتی بین دو روتر همسایگی به روش استاتیک برقرار می شود.

در اینجا یک نکته هم به شما بگم. در مثال بالا به محض اینکه در روتر اول دستور Neighbor را بکار می برید و همسایه را به روش استاتیک معرفی می کنید، همسایگی Down می شود . اما اگر این کار را روتر به اطلاع شما نمی رساند یا به اصطلاح Log نمی اندازد که همسایگی Down شد. شما می توانید با استفاده از دستور زیر در محیط کانفیگ روتینگ پروتکل eigrp ، از روتر بخواهید که به هنگام تغییر در همسایگی آن را به اطلاع شما برساند.

Router-1(Config-router)#eigrp log-neighbor-changes

پارامترهایی که باعث جلوگیری از ایجاد همسایگی بین دو روتر می شوند:

در صفحه 46 از کتاب ccnp -route جدولی آورده شده که در آن پارامترهایی را که از ایجاد همسایگی جلوگیری می کنند ، در دو روتینگ پروتکل OSPF و EIGRP بررسی کرده است. من این جدول را در زیر آورده ام.

خط به خط به بررسی این جدول می پردازیم.

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

در خط دوم میگه: اینترفیس های روبروی هم روترهای همسایه حتما باید توی یک شبکه و سابنت باشند که در هر دو روتیگ پروتکل EIGRP و OSPF این قضیه صادق هست. ولی در BGP ما می توانیم بین دو شبکه مختلف تشکیل همسایگی بدهیم.

در خط سوم میگه: اینترفیس های متصل در دو روتر همسایه Passive نباید باشند. این قضیه واضح است. ما یک اینترفیس را برای چی Passive می کردیم؟ این کار را می کردیم که از ایجاد همسایگی جلوگیری کنیم. چون دیگه روی اون اینترفیس Hello packet مالتی کست نمی شد دیگه. پس مسلما اگر یک اینترفیس Passive باشد از ایجاد همسایگی جلوگیری می کند و این در هر دو روتینگ پروتکل صادق است.

در خط چهارم میگه: در EIGRP حتما باید AS Number در دو روتر همسایه یکسان باشد. یعنی اگر یک طرف میگذاریم Router EIGRP با AS Number یک در طرف دیگر هم باید Router EIGRP 1 بگذاریم و اگر غیر از این بگذاریم همسایگی تشکیل نمی شود. اما در OSPF این قضیه صادق نیست و اختلاف Process-id ها مشکلی در ایجاد همسایگی نمی کند.

در خط پنجم میگه: Hello Interval و Hold Timer در EIGRP لزومی ندارد که در هر دو روتر همسایه یکسان باشد اما در OSPF این طور نیست و باید Hello Interval و Dead Timer در هر دو سمت یکسان باشد تا همسایگی ایجاد شود وگرنه همسایگی تشکیل نمی شود.

در خط ششم میگه: اگر Authentication بین روتر های همسایه ایجاد کردی باید در هر دو سمت یکسان باشد و این واضح است.

در خط هفتم میگه: باید دو روتر همسایه در یک Area باشند که همانطور که میدونید Area بندی در EIGRP نداریم و این بحث در OSPF مطرح است. و برای تشکیل همسایگی در OSPF ، حتما دو روتر همسایه باید در یک َArea باشند. ان شاء الله در مبحث OSPF مفصل بحث می شود.

در خط هشتم میگه:در روتینگ پروتکل EIGRP مقدار MTU یا حداکثر طول پکت در دو روتر همسایه ، لزومی ندارد یکسان باشد اما در OSPF حتما باید یکسان باشد. هرچند یکسان نبودن MTU ممکن است مشکلاتی در روتینگ بوجود بیاورد اما بحث در اینجا بر سر تشکیل همسایگی است .

در خط نهم میگه: K-value ها در هر دو روتر همسایه باید یکسان باشد تا همسایگی تشکیل شود که این بحث (K-value ها) رو ما فقط در بحث متریک EIGRP داریم و متریک در OSPF بر اساس Cost هست نه K-value.

دقت کنید ما داریم بررسی می کنیم که اگر همسایگی تشکیل نشد چه عللی ممکن است وجود داشته باشد و شما می تونید این پارامترهارو بررسی کنید تا علت عدم تشکیل همسایگی رو تشخیص دهید.

و در خط دهم میگه: Router-ID در EIGRP لزومی ندارد که Unique یا منحصربه فرد باشد. اما در OSPF حتما باید منحصر به فرد باشد. راجع به این مقوله جلوتر مفصل بحث می کنیم.

در پایین جدول یک نکته ای را یادآوری کرده است که هرچند یکسان نبودن Router ID بین روتر های همسایه در EIGRP از ایجاد همسایگی جلوگیری نمی کند اما می تواند مشکلاتی در انجام عملیات Redistribution به داخل EIGRP ایجاد کند.

Metric

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

در ابتدا فرمول محاسبه EIGRP را مشاهده کنید.

در این فرمول تنها تفاوتش با IGRP همان ضرب 256 آخر فرمول است. K-value های موجود در این فرمول عبارتند از:

K1=Bandwidth
K2=Load
K3=Delay
K4=Reliability
k5=MTU

همانطور که می دانید فقط مقادیر Bandwidth و Delay هست که دراین فرمول قرار می گیرند ومحاسبه می شوند و به جای مقادیر دیگر صفر قرار می گیرد. یعنی فرمول اصلی به این صورت در می آید.

در فرمول بالا وقتی K5 برابر 0 باشد کل عبارت نادیده گرفته می شود و در فرمول تاثیر داده نمی شود.

خب . ما توسط دستور Metric weights می توانیم دو پارامتر دیگر یعنی Link Load و Link Reliability را در فرمول دخیل کنیم. اما سیسکو قویا تاکید می کند که دست به این فرمول نزنید و فقط بگذارید Delay و Bandwidth بعنوان معیار انتخاب متریک باقی بماند.

اما نحوه استفاده از دستور به چه صورت است؟

Router-1(config)#router eigrp 1
Router-1(config)#metric weights 0 1 0 1 0 0

اون صفر اول بعنوان Type of service مورد استفاده قرار می گیرد که فقط هم اجازه استفاده از صفر را به ما می دهد. و برای تغییر متریک حتما باید گذاشته شود.

از کجا بفهمیم مقادیر دستکاری شده است؟
با دستور Show IP Protocols می تونیم مقادیر متریک داده شده را مشاهده کنیم. من در تصویر زیر برای شما مشخص کرده ام.

همانطور که در جدول بالا خط نهم گفتم ، اگر از دستور Metric weights استفاده کنید، عملا همسایگی با همسایه ها قطع می شود.

اگر ضرایب را در دستور Metric weights بیشتر از 1 بدهیم، در فرمول اهمیت آن پارامتر بیشتر می شود.

با همه این تواصیف اگر قصد داشتید که بینن BW و Delay تغییری بدهید ، سیسکو ارجحیت را به دستکاری Delay می دهد.
بگذارید کمی قضیه را بازتر کنم. همانطور که می دانید به صورت پیش فرض Bandwidth اینترفیس سریال برابر 1544 و Delay آن برابر 20000 میکروثانیه هست.

حال فرض کنید که ما از Serivce Provider مون یک لینک به پهنای باند مثلا 128 گرفتیم. اینجا نیاز هست که ما داخل اینترفیس سریال برویم و پهنای باند را به 128 کیلوبیت تغییر بدهیم. چرا؟ چون پیش فرض لینک سریال ما برابر 1544 کیلوبیت هست . تغییر 1544 به 128 فقط و فقط برای درستی محاسبات هست و هیچ تاثیری در اینکه ظرفیت پهنای باند ما بالا و پایین شود ندارد.
بعبارت ساده تر دستور Bandwidth که در داخل اینترفیس سریال مورد استفاده قرار می گیرد برای این است که روتر بفهمد که پهنای باندی که شما استفاده می کنید چقدر است که اگر خواست در جاهایی مثل متریک EIGRP یا QOS مورد استفاده قرار دهد ، بتواند به درستی محاسبات را انجام دهد و بهترین مسیر را محاسبه کند.

حالا فرض کنید ما خواستیم بنا به دلایل خاصی پهنای باند 128 کیلوبیتمون به 1 مگ ارجحیت داده شود . سیسکو می گوید ، نیا در داخل اینترفیس و با دستور Bandwidth به صورت غیر واقعی پهنای باند سریال رو افزایش بده تا در فرمول ارجحیت داده شود، بلکه Delay رو تغییر بده. چرا؟ چون Bandwdth غیر از متریک EIGRP در جاهای دیگه ای مثل QOS و ... هم استفاده می شود و با این کار همه محاسبات به هم میریزد ولی Delay کمتر استفاده می شود و ارجحیت با تغییر Delay هست.

به نظر شما اگر دستور Bandwidth حد سرعت یک لینک را مشخص نمی کند پس چه دستوری است که پهنای باند یک لینک را مشخص می کند؟ بله . دستور Clockrate
البته همانطور که می دانید این دستور از سمت DCE یا سرویس پروایدر مشخص می شود و ما عملا هیچ نقشی در تعیین پهنای باند نداریم . یعنی وقتی در DCE ، کلاک ریت کانفیگ می شود عملا به DTE ، اجبار می شود که از آن پهنای باند استفاده کند.

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