X
تبلیغات
آموزش تخصصی شبکه (2)

آموزش تخصصی شبکه (2)

هر آنچه در کلاس CCNP - route مطرح می شود.

جلسه ششم

با هم ادامه مباحث EIGRP را پی می گیریم.

Router-ID

بحث Router-ID در EIGRP فقط در زمانی مهم است که بخواهیم روت های خارجی را از طریق Redistribution به داخل EIGRP وارد کنیم و عملا EIGRP در کارهایی که انجام می دهد از روتر ID استفاده نمی کند.

این بحث مفصل در روتینگ پروتکل OSPF به زودی بحث می شود.

Router-ID  یک ساختار 32 بیتی مثل IP Address دارد اما IP Address نیست.

هر روتر در ابتدای شروع پروسه EIGRP اقدام به تعیین Router-ID بر طبق سه گام زیر خواهد کرد:

گام اول: ابتدا می آید نگاه می کند که دستور Router-ID به صورت مستقیم استفاده شده است یا خیر؟ اگر استفاده شده است که همان را به عنوان Router-ID دستگاه لحاظ می کند اگر خیر به گام بعدی می رود.

اما چگونه در EIGRP ، روتر ID به دستگاه اختصاص دهیم؟

در داخل روتینگ پروتکل EIGRP از دستور زیر استفاده می کنیم:

Router-1(config)#router eigrp 1
Router-1(config-router)#
eigrp router-id 1.1.1.1

همانطور که می بینید من به صورت دستی روتر ID ی 1.1.1.1 را به روتر شماره یک اختصاص دادم.

گام دوم: اگر روتر ID روی دستگاه تنظیم نشده باشد ،بزرگترین آدرس IP اینترفیس Loopback را بعنوان Router-ID در نظر میگیرد. حتی اگر یک اینترفیس Loopback بر روی سیستم تعریف شده باشد ، آی پی همان را بعنوان Router-ID در نظر می گیرد.چون IP Address مثل Router-ID ساختار 32 بیتی دارد ، از هر دو میتواند به جای هم استفاده کند.

گام سوم: اگر هیچ اینترفیس Loopback هم بر روی سیستم وجود نداشته باشد. بزرگترین آدرس IP مربوط به اینترفیس های فعال (UP & UP) را بعنوان Router-ID در نظر می گیرد.

 

WAN Neighbor ship

یک بحث مهم دیگه ای که اینجا مطرح میشه همسایگی روتر های ما در بستر WAN هست. همانطور که می دونید روتر های ما ، فقط تو آزمایشگاه و LAB هست که به صورت مستقیم به هم وصل میشوند و در دنیای واقعی ما لینک از Service Provider میگیرم و هر روتر ممکن است در یک منطقه جغرافیایی باشه و در اصل روتینگ های ما بر روی WAN صورت می گیره.


ما در بستر
WAN، سرویس های مختلفی داریم. مثل Frame Relay، MPLS VPN، Metro ethernet . به مرور به تفصیل این سرویس ها رو با هم بررسی می کنیم و هرجا لازم باشد به توضیح اونها می پردازم.

سرویسی به نام Metro ethernet و Frame Relay در ایران پیاده سازی نمیشود و ایران از همان ابتدا مستقیم به سراغ MPLS VPN یا MultiProtocol Label Switching Virtual Private Network رفت.

 

در بستر WAN مخابرات ایران دو سرویس می فروشد

:  MPLS VPN .1

2. اینترانت

سرویس MPLS یک سرویس WAN هست که قابلیت های خوبی مثل Traffic Engineering و VPN و MPLS-QOS و .. کلا قابلیت هایی می دهد که ما در بستر IP نداریم.

اما سرویس اینترانت ، اصلا سرویس WAN نیست و یک نوع سرویس روتینگ لایه سه معمولی محسوب میشود.

ببینید وقتی ما می گوییم WAN، یعنی بسته های ما در لایه دوم یعنی Data Link باید روش فریم بسته شود و در شبکه فرستاده شود، اما بسته ما در شبکه اینترانت عملا وارد لایه 2 نمی شود و در مخابرات روت میشود. پس عملا سرویس اینترانت مخابرات بعنوان سرویس WAN به درد نمی خورد.

 

خب حالا فرض کنید ما در بستر MPLS بین روترهامون در شهرهای مختلف ،  EIGRP ران کرده ایم. حالا میخواهیم روترهامون با هم همسایگی تشکیل بدهند. اما نمی دهند؟ چرا؟ یادتونه شرایط همسایگی رو گفتیم؟ گفتیم که همسایه ها باید توی یک شبکه باشند؟ در MPLS ، روتر ها عملا با خود مخابرات همسایگی تشکیل می دهند. برای حل این مشکل باید  Tunneling راه اندازی کنیم، یعنی همسایگی تو بستر همان تونل انجام شود. بحث تونلینگ همان مقوله VPN هست.

ان شاء الله در آینده نزدیک این مباحث با وسعت بیشتری مطرح می شود، فعلا به عنوان تیتر داشته باشید.


Topology Database Exchange

فکر می کنم راجع به این قضیه در خلال صحبت هایم بارها و بارها صحبت شد ، اما یکبار دیگر به صورت خلاصه تر در اینجا مطرح می کنم. قصد همسایگی بین روترهایی که روتینگ پروتکل EIGRP رو ران کردند این بود که درنهایت Topology Database Exchange رو انجام بدهند. به هرحال هر کدام از روتر ها اول Neighbor Discovery می کنند و بعد Full Routing Update می فرستند  که به صورت Reliable هست و نیازمند تصدیق از روتر مقابل و سپس Hello Packet ها ادامه پیدا می کند و در نهایت با تغییرات جزیی که اتفاق می افتد Partial Update می فرستند. به صورت کلی بسته هایی که EIGRP از آن استفاده می کند به قرار زیر است:

انواع پیام ها در EIGRP

1.Hello  : این پیام که معرف حضورتون هست. روترهای EIGRP برای شناسایی همسایگان خود و برای اطمینان از سالم بودن لینک ارتباطی به صورت مرتب از این پیام استفاده می کنند. که به صورت Reliable نیست. یعنی نیاز به تصدیق یا Acknowledgement ندارد. این پیام به صورت Multicast به آدرس 224.0.0.10 برای همه روترهای همسایه ارسال می شود.


 Update .2: این پیام هم معرف حضورتون هست. هر روتر کل جدول مسیریابی اش را یکبار به صورت Reliable و نیازمند تصدیق به  روترهای همسایه ارسال می کند.

در حالت کلی محتویات پیغام های Update عبارتند از:

الف - Prefix
ب - Prefix Length
ج – Metric
د – MTU, Hop Count

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

 4. Reply: این پیغام بعد از اینکه پیغام Query به دست روتر رسید به سمت روتر ارسال کننده Query به صورت Unicast ارسال می شود.

5. ACK: که برگرفته از عبارت Acknowledgement هست در پاسخ به پیام های Update  و Query  و Reply که به صورت Reliable هستند و نیازمند دریافت تصدیق می باشند فرستاده می شود.

اما یک نکته در اینجا وجود دارد که نیازمند دقت شماست.

گفتیم که در محتویات آپدیتی که روترها به سمت یکدیگر ارسال می کنند Metric هم هست . و همینطور که می دونید در متریک فقط دو مقدار Bandwidth و Delay مورد محاسبه قرار می گیرند. حالا وقتی روتر پکت آپدیت رو به سمت روتر همسایه می فرستد در آن می گوید که مثلا Delay من 10 هست و Bandwidth من 2000 هست . روتر بغلی وقتی بسته آپدیت را می گیرد به BW و Delay نگاه می کند، همینطور به لینک خودش هم نگاه می کند. وقتی می خواهد خودش بسته Full Update به روترهای همسایه اش بفرستد، Delay روتر بغلی را با Delay خودش جمع می کند و می فرستد (مثلا اگر Delay خودش 2000 باشد ، عدد 2010  را در بسته آپدیتش می فرستد)

اما در مورد Bandwidth قضیه فرق می کند.بعنوان مثال اگر Bandwidth خودش 1544  باشد. و Bandwidth روتر بغلی 2000 در بسته Full Updateش عدد 1544 را لحاظ میکند.

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

نکته دیگری که لازم هست دقت کنید: اگر یک Neighbor به صورت کامل Down بشه و دوباره UP بشه و یا یک همسایه جدید در شبکه اضافه بشود، دباره Full Update به همسایه هایش می فرستد.

خب مباحث خیلی تئوری شدند ، این جلسه رو هم داشته باشید ، ان شاء الله از جلسه بعد به صورت عملی تر این مباحث رو دنبال می کنیم.

فعلا. موفق باشید.

پایان جلسه ششم

+ نوشته شده در  چهارشنبه هجدهم مرداد 1391ساعت 18:43  توسط علیرضا مهجور  |