رایکا امپرا

تاکنون مشاهده نمودیم که OSPF در شبکه های broadcast مانند Ethernet و شبکه های point-to-Point عملکرد متفاوتی دارد. تشکیل همسایگی و علی الخصوص انتقال اطلاعات در این دو نوع شبکه متفاوت است. انتقال اطلاعات بین دو روتر در شبکه Point-to-Point به صورت کامل انجام می گیرد

اما در شبکه های broadcast انتقال اطلاعات فقط با DR صورت می پذیرد و همسایگی نیز فقط با روتر DR و BDR به حالت FULL می رسد و حالت همسایگی بین دیگر روترهای شبکه broadcast که DROTHER نامیده می شوند، در حالت 2WAY باقی می ماند.

حال می خواهیم یاد بگیریم که در OSPF، انواع شبکه ها به همین دو نوع ختم نمی شوند. البته این موضوع فقط در روترهای سیسکو صدق می کند. در روترهای با پروتکل OSPF استاندارد صرفا همین دو نوع شبکه وجود دارد اما در روترهای سیسکو علاوه بر این دو نوع شبکه، سه نوع دیگر با نام های non-broadcast، point-to-multipoint و point-to-multipoint nonbroadcast نیز وجود دارند.

حتما این سوال در ذهن شماست که دلیل تنوع انواع شبکه ها در چیست؟ پاسخ این سوال را با نگاهی به همان دو نوع اول شبکه در می یابیم. چرا از عملکرد مشابه point-to-point در شبکه های broadcast استفاده نشد؟ به عبارت دیگر اگر n روتر در شبکه Ethernet قرار دارند، دو به دو با هم تشکیل همسایگی دهند و بین هر دو نیز جداگانه انتقال اطلاعات انجام گیرد. بدیهی است که اگر بخواهیم به شیوه point-to-point در شبکه Ethernet رفتار کنیم، لازم است تا n*(n-1)/2 پروسه انتقال اطلاعات در این نوع شبکه داشته باشیم که در صورت زیاد بودن تعداد روترهای شبکه، این حجم انتقال اطلاعات مقیاس پذیر نخواهد بود. بنابراین با انتخاب DR و BDR تعداد پروسه انتقال اطلاعات را به نسبت قابل توجهی کاهش می دهیم. نتیجه می گیریم که با داشتن شبکه از نوع broadcast در کنار point-to-point به کارایی بهتر OSPF کمک می کنیم.

حال شبکه های دیگری غیر از Ethernet و point-to-point مانند frame-relay نیز وجود دارند که نه عملکرد به شیوه point-to-point و نه به شیوه broadcast، هیچکدام نمی تواند بهترین کارایی را به ما بدهد. به عنوان مثال تصور کنید در شبکه ای از نوع frame-relay نوع ارتباطات به صورت partial-mesh است بدین معنی که روترهای شعب مختلف یک سازمان در بستر این شبکه بر حسب نیاز به هم متصل هستند که نوع اتصال آنها نه Full-Mesh و نه Hub-and-Spoke است بلکه به مرور زمان و بر حسب نیاز ارتباطات بین هر دو نقطه ایجاد گردیده است. 

توپولوژی Partial Mesh در Frame-Relay

در شکل بالا، ارتباطات نشان داده شده بین روترها لینکهای فیزیکی نیستند. از نظر فیزیکی همه روترهای فوق به شبکه Frame-Relay متصل هستند و ارتباطات منطقی و یا Virtual Circuit ایجاد شده بین روترها در این شکل نشان داده شده است.

در مثال هایی همچون توپولوژی فوق، پروسه OSPF نه به شیوه point-to-point و نه broadcast هیچکدام نمی تواند کارایی مناسبی ایجاد نماید. در روش point-to-point حجم انتقال اطلاعات بالاست و در روش broadcast نیز لزوما نمی توانید دو روتری را پیدا کنید که با همه روترها در ارتباط باشند که بتوانند نقش DR و BDR را داشته باشند. در شکل فوق فقط یک روتر است که با همه روترها در ارتباط است و بنابراین می تواند DR باشد اما روتر دومی که نقش پشتیبان DR را داشته باشد، وجود ندارد. چنین روتری باید با همه دیگر روترهای شبکه ارتباط VC داشته باشد.

اگر در نظر داشته باشد در سناریوی فوق و روی روترهای با پروتکل استاندارد OSPF، این پروتکل را فعال نمایید، تنها گزینه شیوه point-to-point است که البته کارا نیست. در صورت استفاده از روترهای سیسکو در سناریوی فوق، امکان پیاده سازی OSPF به انواع دیگر روش ها نیز امکان پذیر است که قصد داریم به خصوصیات آن در ادامه بپردازیم.

حتما تاکنون توجیه شده اید که چرا سیسکو انواع دیگر شبکه ها غیر از broadcast و point-to-point را در OSPF اضافه نموده است. حال می خواهیم به تفصیل در مورد تفاوت بین انواع شبکه در OSPF بپردازیم. برای بررسی انواع شبکه ها در OSPF ابتدا معیارهایی را برای مقایسه مورد توجه قرار می دهیم و مقایسه صرفا بر اساس این معیارها خواهد بود. سپس از دید طراحی و کاربرد هر یک از انواع شبکه ها و چگونگی استفاده از آنها در OSPF، به موضوع نگاه خواهیم کرد.

معیارهای مقایسه انواع شبکه ها در چهار پارامتر اصلی خلاصه می شود. اول آنکه آیا همسایگی به صورت اتوماتیک تشکیل می شود و یا باید هر همسایه را به صورت دستی تعریف کنیم؟ دومین معیار در مقایسه انواع شبکه های OSPF، ضرورت و یا عدم ضرورت ایجاد روترهای DR و BDR است. در بعضی از انواع شبکه های مانند broadcast انتقال اطلاعات فقط از طریق روترهای DR و BDR انجام می شود در حالی که در شبکه point-to-point انتقال اطلاعات مستقیما بین هر دو روتر انجام می شود. زمان ارسال و دریافت بسته hello و یا به عبارت دیگر زمان hello time و dead time سومین معیار مقایسه انواع شبکه ها در OSPF  است و نهایتا اینکه آیا در انواع شبکه فقط دو روتر می توانند تشکیل همسایگی دهند و یا آنکه امکان وجود بیش از دو روتر در آن شبکه وجود دارد؟

جدول زیر انواع شبکه ها را با این چهار معیار مقایسه می کند.

آیا امکان بیش از دو روتر در یک شبکه وجود دارد؟	آیا همسایگی باید به صورت دستی انجام شود؟	زمان Hello Time و Dead Time	آیا از DR/BDR استفاده می کند؟	نوع شبکه
خیر	خیر	10/40 ثانیه	خیر	Point-to-Point
بله	خیر	10/40 ثانیه	بله	Broadcast
بله	بله	30/120 ثانیه	بله	Non-Broadcast
بله	خیر	30/120 ثانیه	خیر	Point-to-Multipoint
بله	بله	30/120 ثانیه	خیر	Point-to-Multipoint Non-Broadcast

انواع شبکه در OSPF

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

• زمان hello time و dead time در شبکه های point-to-point و broadcast که شبکه های اصلی OSPF محسوب می شوند، 10 ثانیه و 40 ثانیه است. در بقیه موارد این زمان ها به ترتیب 40 ثانیه و 120 ثانیه هستند.
• در همه انواع شبکه ها غیر از point-to-point امکان تشکیل همسایگی بین بیش از دو روتر وجود دارد.
• هر نوع شبکه ای که کلمه non-broadcast در آن وجود داشته باشد، باید در آن همسایگی به صورت دستی تعریف شود در غیر این صورت همسایگی به صورت اتوماتیک ایجاد می شود.
• فقط در شبکه های broadcast و non-broadcast انتخاب DR و BDR ضروری است. در بقیه انواع شبکه ها انتقال اطلاعات مستقیما بین روترها انجام می شود.
• نکته پایانی که به این جدول مربوط نمی شود اینکه در اینترفیس های point-to-point نوع شبکه OSPF، به صورت پیش فرض Point-to-Point است. در اینترفیس های Ethernet نوع شبکه به صورت پیش فرض Broadcast است و در اینترفیس های Multipoint در Frame-Relay شبکه پیش فرض OSPF، Non-Broadcast است.

حال این سوال پیش می آید که بهتر است از کدام یک از انواع شبکه ها در OSPF استفاده شود؟ این سوال را اگر برای محیط های واقعی می خواهید، پاسخ صریح و شفاف است. در اینترفیس های Point-to-Point نوع شبکه را Point-to-Point در نظر بگیرید که پیش فرض نیز همین است. در اینترفیس های Ethernet نیز نوع شبکه را Broadcast در نظر بگیرید که پیش فرض نیز همین است. در اینترفیس های frame-Relay نیز اگر نوع اینترفیس مجازی Point-to-Point باشد، نوع شبکه را Point-to-Point و در غیر این صورت اگر نوع اینترفیس مجازی Multipoint باشد، نوع شبکه را ترجیحا Broadcast در نظر بگیرید و  اگر ممکن نیست نوع شبکه را Point-to-Multipoint انتخاب می کنیم. در اینترفیس مجازی Multipoint اگر حداقل دو روتر وجود نداشته باشد که با همه دیگر روتر ها ارتباط VC داشته باشد، آنگاه بهتر است Broadcast را انتخاب نکنیم و گزینه Point-to-Multipoint را جایگزین نماییم. فقط زمانی که از ارتباطات مطمئن نیستند (پهنای باند ارتباطی خیلی پایین است و قطعی نیز در ارتباطات بالاست)، از روش های Non-Broadcast استفاده کنید که در آن همسایگی به صورت دستی تعریف می شود. در این شرایط گزینه non-broadcast را جایگزین broadcast و گزینه point-to-multipoint non-broadcast را جایگزین point-to-multipoint نمایید.

اولویت سوم نوع شبکه در OSPF	اولویت دوم نوع شبکه در OSPF	اولویت اول نوع شبکه در OSPF	نوع اینترفیس
-	-	Point-to-Point	Point-to-Point
-	-	Broadcast	Broadcast
-	-	Point-to-Point	Non-Broadcast
Non-Broadcast/Point-to-Multipoint non-broadcast	Point-to-Multipoint	Broadcast	Point-to-Multipoint

چگونگی انتخاب نوع شبکه در OSPF

اگر این سوال که کدام نوع شبکه را در چه اینترفیسی می توان استفاده نمود را برای درک بهتر عملکرد OSPF می پرسید، باید به نکات زیادی نوجه کنید و نیازمند تجربه است اما مطمئنا نکات زیر به شما کمک می کند:

• 1- در انتخاب نوع شبکه در نظر داشته باشید که باید زمان hello time و dead time بین دو روتر همسایه یکسان باشد. البته در صورت یکسان نبودن این دو پارامتر می توانید به صورت دستی آنها را به مقادیر یکسان تغییر دهید.
• 2- در انتخاب نوع شبکه در نظر داشته باشید که روتر یا روترهای همسایه از این جهت که نیاز به انتخاب DR/BDR دارند و یا خیر با هم یکسان باشند.

بعد از پرداختن به مفاهیم انواع شبکه در OSPF حال نوبت آن رسیده است تا با نگاهی به یک مثال جزئیات آن را بهتر درک نماییم. مثالی که برای این موضوع درس در نظر گرفته است، به عمد مثالی با بهم ریختگی و پیچیدگی های غیر نرمال است تا بتوانیم جنبه های مختلف پیاده سازی OSPF را روی این توپولوژی تست و درک نماییم.

مشخصاتی که در توپولوژی این درس در نظر گرفته شده است، شامل موارد ذیل می باشد:

•  همانطور که مشاهده می کنید، چهار روتر در توپولوژی در نظر گرفته شده است. روترهای R1 تا R3 در شبکه ای با آدرس 168.1.0/24 و روترهای R1 و R4 نیز در شبکه دیگری با آدرس 10.1.1.0/30 قرار گرفته اند. برای پیاده سازی چنین توپولوژی روی روتر R1 دو اینترفیس مجازی یکی از نوع multipoint که آدرس شبکه آن بین روترهای R1، R2 و R3 مشترک است و دیگری از نوع point-to-point که آدرس آن بین روترهای R1 و R4 یکسان است، در نظر گرفته شده است،
•  اگر دقت کنید علی رغم اینکه روترهای R1، R2 و R3 در یک شبکه هستند اما بین دو روتر R2 و R3 هیچ ارتباط مجازی یا VC در نظر گرفته نشده است. فقط ما بین R1 و R2 و همچنین R1 و R3 ارتباط VC ایجاد شده است. همانطور که گفته شده است این ناهمگونی بین آدرس دهی لایه 3 و ارتباط لایه 2 به عمد ایجاد گردیده است.
•  برای ایجاد ارتباط بین روترهای R1، R2 و R3 روی دو روتر R1 و R2 اینترفیس مجازی multipoint ایجاد شده است اما در روتر R3 روی خود اینترفیس فیزیکی پیکربندی های مورد نیاز انجام شده است.
•  همانطور که در توپولوژی نشان داده شده است، یک ارتباط مجازی لایه 2 ای و از نوع point-to-point نیز ما بین دو روتر R1 و R4 پیش بینی شده است. اما نکته قابل توجه این است که پیاده سازی آن روی روتر R1 روی اینترفیس مجازی point-to-point صورت گرفته است اما در روتر R4 روی خود اینترفیس فیزیکی پیکربندی مورد نیاز صورت گرفته است. این ناهمگونی نیز به عمد ایجاد گردیده است.

توپولوژی نمونه برای پیاده سازی انواع شبکه در OSPF

قرار است روی این توپولوژی چه کاری انجام دهیم؟ پاسخ بدیهی است. قرار است روی این توپولوژی OSPF پیاده سازی کنیم. همین؟! البته نه به همین سادگی. می خواهیم بین دو روتر R1 و R4 پروتکل OSPF را از نوع point-to-point پیاده سازی کنیم و بین روترهای R1، R2 و R3 یکبار نوع شبکه را non-broadcast و یکبار هم point-to-multipoint در نظر بگیریم و تفاوت های بین آنها را بررسی کنیم.

قبل از پیاده سازی OSPF ابتدا ارتباطات frame-relay را به شیوه ای که تشریح شد، پیاده سازی می کنیم که در ذیل جزئیات آن را مشاهده می کنید. با توجه به توضیحات داده شده نوع پیکربندی انجام شده در OSPF کاملا قابل درک است.

!!! روی روتر R1 دو اینترفیس مجازی یکی از نوع multipoint برای ارتباط با R2 و R3 و دیگری نیز از نوع point-to-point برای ارتباط با R4 پیاده سازی شده است. !!! R1 interface Serial1/0  no shutdown  encapsulation frame-relay ! ! interface Serial1/0.1 multipoint  ip address 192.168.1.1 255.255.255.0  frame-relay map ip 192.168.1.3 103 broadcast  frame-relay map ip 192.168.1.2 102 broadcast ! interface Serial1/0.2 point-to-point  ip address 10.1.1.1 255.255.255.252  frame-relay interface-dlci 104 ! !!! روی روتر R2 یک اینترفیس مجازی از نوع multipoint برای ارتباط با روتر R1 در نظر گرفته شده است !!! R2 interface Serial1/0  no shutdown  encapsulation frame-relay ! ! interface Serial1/0.1 multipoint  ip address 192.168.1.2 255.255.255.0  frame-relay map ip 192.168.1.1 201 broadcast ! !!! روی اینترفیس فیزیکی روتر R3 یک ارتباط مجازی با روتر R1 ایجاد شده است. پیاده سازی ارتباط مجازی روی اینترفیس فیزیکی انجام شده است. !!! R3 interface Serial1/0  no shutdown  ip address 192.168.1.3 255.255.255.0  encapsulation frame-relay  frame-relay map ip 192.168.1.1 301 broadcast ! !!! علی رغم ماهیت ارتباط روتر R4 که point-to-point است، ارتباط ایجاد شده روی اینترفیس فیزیکی پیاده سازی شده است. !!! R4 interface Serial1/0  no shutdown  ip address 10.1.1.2 255.255.255.252  encapsulation frame-relay  frame-relay map ip 10.1.1.1 401 broadcast

تنظیمات اولیه توپولوژی Frame-Relay برای تست انواع شبکه در OSPF

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

!!! R1, R2, R3 and R4 !!!  X is router number ! router ospf 1  router-id X.X.X.X  network 0.0.0.0 255.255.255.255 area 0 ! !!! خروجی جدول همسایگی روتر R1 نشان می دهد که این روتر با هیچ یک از دیگر روترها تشکیل همسایگی نداده است. !!! R1 R1#sh ip ospf neighbor   !

پیاده سازی اولیه OSPF در FrameRelay بدون رعایت هر گونه ملاحضه خاص

همانطور که در خروجی جدول همسایگی روتر R1 که در بالا نشان داده شده است، مشاهده می کنید این روتر با هیچ یک از دیگر روترهای همسایه، تشکیل همسایگی نداده است. این بدان دلیل است که به صورت پیش فرض، نوع شبکه OSPF در اینترفیس های multipoint در frame-relay، non-broadcast است و همانطور که قبلا گفته شده در شبکه های non-broadcast همسایگی حتما باید به صورت دستی تعریف شود. توجه کنید که نوع شبکه به صورت پیش فرض در اینترفیس های point-to-point در frame-relay، point-to-point است. خروجی ذیل تایید کننده شبکه پیش فرض OSPF در اینترفیس های frame-relay است.

!!! R1 R1#sh ip ospf interface serial 1/0.1 Serial1/0.1 is up, line protocol is up   Internet Address 192.168.1.1/24, Area 0   Process ID 1, Router ID 1.1.1.1, Network Type NON_BROADCAST, Cost: 64 ! !!! بخشی از خروجی حذف شده است ! R1#sh ip ospf interface serial 1/0.2 Serial1/0.2 is up, line protocol is up   Internet Address 10.1.1.1/30, Area 0   Process ID 1, Router ID 1.1.1.1, Network Type POINT_TO_POINT, Cost: 64 !!! بخشی از خروجی حذف شده است

مد پیش فرض OSPF در اینترفیس های FrameRelay

بدون آنکه هیچ تغییری در نوع شبکه OSPF در این توپولوژی ایجاد کنیم، همسایگی را به صورت دستی تعریف می کنیم تا خروجی را مورد بررسی قرار دهیم.

در تعریف همسایگی به صورت دستی این نکته را مد نظر داشته باشید که به ازاء هر VC کافی است فقط در یک طرف، همسایگی را به صورت دستی تعریف نمایید. به عنوان مثال در VC ما بین دو روتر R1 و R2 صرفا روی روتر R1 همسایگی را به صورت دستی تعریف می کنیم و روی روتر R2، روتر R1 را به عنوان همسایه معرفی نمی کنیم. در VC ما بین دو روتر R1 و R3 نیز روی روتر R1 همسایگی را تعریف می کنیم. در ارتباط ما بین R1 و R4 نوع شبکه در طرف R1، point-to-point است و در این نوع شبکه، همسایگی اتوماتیک تشکیل می شود اما از آنجایی که در روتر R4 نوع اینترفیس multipoint و نوع شبکه نیز non-broadcast است، همسایگی روی روتر R4 باید به صورت دستی تعریف گردد. با توجه به نکات گفته شده پیکربندی زیر را روی روترها انجام می دهیم.

!!! R1 R1(config)#router ospf 1 R1(config-router)#neighbor 192.168.1.2 priority 0 R1(config-router)#neighbor 192.168.1.3 ! R1(config-router)#do sh runn | section router ospf router ospf 1  router-id 1.1.1.1  log-adjacency-changes  network 0.0.0.0 255.255.255.255 area 0  neighbor 192.168.1.3  neighbor 192.168.1.2 ! !!! R4 R4(config)#router ospf 1 R4(config-router)#neighbor 10.1.1.1 ! R1#show ip ospf neighbor Neighbor ID     Pri   State           Dead Time   Address         Interface 2.2.2.2           1   FULL/DROTHER    00:01:51    192.168.1.2     Serial1/0.1 3.3.3.3           1   FULL/DR                00:01:47    192.168.1.3     Serial1/0.1

تعریف دستی همسایگی در OSPF در اینترفیس های non-broadcast

همسایگی را به صورت دستی رو روترهای R1 و R4 مطابق با آنچه گفته شد، انجام دادیم اما دو مشکل مشاهده می کنیم. مشکل اول اینکه همسایگی با روتر R4 ایجاد نشده است. مشکل دوم اینکه از دید روتر R1، روتر R3، DR و خودش BDR است و از آنجایی که روتر R3 با دیگر روتر های شبکه VC ندارد لذا مطمئنا دیتابیس روتر ها به صورت ناقص ایجاد خواهد شد و جالب تر اینکه از دید روتر R2، خودش DR و روتر R1، BDR است. خروجی ذیل بیانگر این مطالب است.

!!! R1 R1#show ip ospf neighbor Neighbor ID     Pri   State           Dead Time   Address         Interface 2.2.2.2           1   FULL/DROTHER    00:01:51    192.168.1.2     Serial1/0.1 3.3.3.3           1   FULL/DR         00:01:47    192.168.1.3     Serial1/0.1 ! !!! R2 R2#sh ip ospf neighbor Neighbor ID     Pri   State           Dead Time   Address         Interface 1.1.1.1           1   FULL/BDR        00:01:31    192.168.1.1     Serial1/0.1

مشکلات ناشی از یکسان نبودن hello time و dead time و همچنین انتخاب نادرست DR و BDR در شبکه FrameRelay

اول بیاییم ببینیم چرا بین دو روتر R1 و روتر R4 همسایگی ایجاد نشده است. این بدان دلیل است که یکسان بودن hello time و dead time در ایجاد همسایگی ضروری است اما مقدار پیش فرض hello time و hold time در اینترفیس های point-to-point با اینترفیس های non-broadcast متفاوت است. در روتر R1 به سمت روتر R4 که نوع اینترفیس point-to-point است مقدار پیش فرض hello time و dead time، 10 ثانیه و 40 است اما در روتر R4 که نوع اینترفیس non-broadcast است، مقادیر پیش فرض hello time و dead time به ترتیب 40 ثانیه و 120 ثانیه هستند.
در ذیل نشان داده شده است که با تغییر hello time و dead time روی روتر R4، همسایگی روتر R1 با روتر R4 ایجاد شده است. اما نکته قابل توجه این که از دید روتر R4 همسایه R1 در حالت FULL/BDR است. به عبارت دیگر روتر R1 خودش را به عنوان DR و روتر R1 را به عنوان BDR انتخاب نموده است اما از دید روتر R1 نوع شبکه point-to-point است و اصلا نیاز به انتخاب DR و BDR ندارد و لذا حالت همسایگی را FULL/- نشان داده است. بنابراین بهتر است به جای تغییر hello time و dead time روی روتر R4 نوع اینترفیس را از nonbroadcast به point-to-point تغییر دهیم که در این صورت هم زمانهای hello time و dead time یکی خواهد شد و هم نگاه دو روتر همسایه به شبکه متفاوت نخواهد بود.

!!! R4 interface Serial1/0  ip ospf hello-interval 10  ip ospf dead-interval 40 ! !!! R1 R1#sh ip ospf neighbor Neighbor ID     Pri   State           Dead Time   Address         Interface 4.4.4.4           0   FULL/  -        00:00:22    10.1.1.2        Serial1/0.2 2.2.2.2           1   FULL/DROTHER    00:01:47    192.168.1.2     Serial1/0.1 3.3.3.3           1   FULL/DR         00:01:53    192.168.1.3     Serial1/0.1 ! !!! R4 R4#sh ip ospf neighbor Neighbor ID     Pri   State           Dead Time   Address         Interface 1.1.1.1           1   FULL/BDR        00:00:44    10.1.1.1        Serial1/0

تنظیم دستی hello time و dead time در OSPF

بنابراین در ذیل نوع اینترفیس را در روتر R4 از non-broadcast به point-to-point تغییر می دهیم و نتیجه تشکیل همسایگی و حالت همسایگی را مجددا مرور می کنیم.

!!! R4 ! R4(config)#interface serial 1/0 R4(config-if)#ip ospf network point-to-point ! R4#sh ip ospf neighbor Neighbor ID     Pri   State           Dead Time   Address         Interface 1.1.1.1           0   FULL/  -        00:00:36    10.1.1.1        Serial1/0 ! ! !!! R1 R1#sh ip ospf neighbor Neighbor ID     Pri   State           Dead Time   Address         Interface 4.4.4.4           0   FULL/  -        00:00:39    10.1.1.2        Serial1/0.2 2.2.2.2           1   FULL/DROTHER    00:01:31    192.168.1.2     Serial1/0.1 3.3.3.3           1   FULL/DR         00:01:34    192.168.1.3     Serial1/0.1

تغییر نوع اینترفیس در OSPF

یکی از مشکلات که تشکیل همسایگی بین دو روتر R1 و R4 بوده است را برطرف نمودیم اما همچنان مشکل دیگر باقی است. اینکه از دید روتر R1، روتر R3، DR و خودش BDR است اما از دید روتر R2، خودش DR و روتر R1، BDR است.

اولا بدیهی است که در شبکه frame-relay روتری باید DR و BDR شود که با همه دیگر روترها ارتباط مجازی و یا VC داشته باشد. در توپولوژی ما این فقط روتر R1 است که هم با روتر R2 و هم با روتر R3 ارتباط VC دارد بنابراین فقط این روتر می تواند نقش DR را داشته باشد. ضمنا روتر دومی که با همه دیگر روترها VC داشته باشد، وجود ندارد لذا باید مراقب باشیم تا روتری نقش BDR را به خود نگیرد. در این توپولوژی با قرار دادن نوع اینترفیس در حالت nonbroadcast فقط روتر DR خواهیم داشت و باید مراقب باشیم روتر BDR نداشته باشیم. چگونه مطمئن شویم که دو روتر R2 و R3 نقش DR و BDR را به خود نمی گیرند. اگر بخاطر داشته باشید برای اینکه روتری هیچگاه DR و یا BDR نشود کافی است priority آن را به صفر تغییر دهیم.

اگر به خاطر داشته باشد مقدار priority پیش فرض اینترفیس های broadcast و non-broadcast، که نیازمند انتخاب DR و BDR است، 1 است اما در بقیه اتواع اینترفیس ها مقدار priority به صورت پیش فرض صفر است. نگاهی به خروجی های قبل گویای این مطلب است که در روترهای R1، R2 و R3 مقدار پیش فرض priority عدد 1 است اما این مقدار در ارتباط بین R1 و R4 صفر است.

چگونه مقدار priority را تغییر دهیم تا مطمئن شویم که روتر R2 و روتر R3 هیچگاه DR و یا BDR نمی شوند. به دو شیوه می توان مقدار priority را تغییر داد

1- در دستور neighbor می تواند priority آن neighbor را تعریف نمایید. اگر جلوی دستور neighbor مقدار priority آن neighbor را تنظیم نکنید، به صورت پیش فرض نیز صفر در نظر گرفته می شود. به خروجی ذیل که از پیکربندی های قبلی برداشت شده است، مجددا نگاهی بیندازید. در ایجاد همسایگی روتر R2 مقدار priority صفر داده شده است اما در ایجاد همسایگی روتر R3 هیچ صحبتی از priority نشده است اما وقتی خروجی show runn را نگاه می کنید، مشاهده می کنید که جلوی هیچکدام از دستورات neighbor، پارامتر priority وجود ندارد. بنابراین می توان نتیجه گرفت که با دستور neighbor می توانید مقدار priority را تعیین نمایید اما در صورت عدم تعیین، مقدار آن صفر در نظر گرفته می شود. یک سوال اساسی باقی می ماند. به توضیحات پیش رو دقت کنید تا متوجه آن شوید.

!!! R1 R1(config)#router ospf 1 R1(config-router)#neighbor 192.168.1.2 priority 0 R1(config-router)#neighbor 192.168.1.3 ! R1(config-router)#do sh runn | section router ospf router ospf 1  router-id 1.1.1.1  log-adjacency-changes  network 0.0.0.0 255.255.255.255 area 0  neighbor 192.168.1.3  neighbor 192.168.1.2

روش اول در تغییر Priority بعضی اینترفیس ها در OSPF که اولویت پایین تری دارد

2- چرا علی رغم اینکه مقدار priority همسایه ها یعنی دو روتر R2 و R3 صفر در نظر گرفته شده است، این روترها همچنان تمایل به DR و یا BDR شدن از خود نشان می دهند؟ برای یافتن پاسخ پیشنهاد می کنم به روش دوم تعیین priority دقت کنید که اولویت آن از روش قبل بیشتر است. روش دوم تنظیم priority روی اینترفیس خود روتر است که به صورت پیش فرض مقدار آن 1 است. از آنجایی که این روش نسبت به روش قبل اولویت بالاتری دارد، لذا در مثال قبل از دید روتر R1 مقدار priority روتر R2 و R3، 1 در نظر گرفته شده است. در ذیل نشان داده شده است که در صورت تغییر مقدار priority روی اینترفیس روتر R2 به عدد 10، روتر R1 نیز مقدار priority این همسایه را 10 در نظر می گیرد علی رغم اینکه روی روتر R1 مقدار priority روتر R2، صفر تنظیم شده است.

!!! R1 R1#sh ip ospf neighbor 2.2.2.2  Neighbor 2.2.2.2, interface address 192.168.1.2     In the area 0 via interface Serial1/0.1     Neighbor priority is 1 (configured 0), State is FULL, 7 state changes !!! بخشی از خروجی حذف شده است ! !!! R2 R2(config)#interface serial 1/0.1 R2(config-subif)#ip ospf priority 10 ! !!! R1 R1#sh ip ospf neighbor 2.2.2.2  Neighbor 2.2.2.2, interface address 192.168.1.2     In the area 0 via interface Serial1/0.1     Neighbor priority is 10 (configured 0), State is FULL, 20 state changes

روش اصلی تغییر Priority اینترفیس ها در OSPF

حال برای رفع مشکل دوم این توپولوژی، اینکه مطمئن شویم هیچگاه روترهای R2 و R3، نقش DR و یا BDR به خود نمی گیرند، باید روی خود روترهای R2 و R3 نیز مقدار priority را به صفر تغییر دهیم. در ذیل با این تغییر نشان داده شده است که از دید هر سه روتر R1، R2 و R3، روتر R1 روتر DR و روترهای R2 و R3 روترهای DROTHER هستند.

!!! R2 R2(config)#interface serial 1/0.1 R2(config-subif)#ip ospf priority 0 ! !!! R3 R3(config)#interface serial 1/0 R3(config-if)#ip ospf priority 0 ! !!! R1 R1#sh ip ospf neighbor Neighbor ID     Pri   State           Dead Time   Address         Interface 4.4.4.4           0   FULL/  -        00:00:32    10.1.1.2        Serial1/0.2 2.2.2.2           0   FULL/DROTHER    00:01:57    192.168.1.2     Serial1/0.1 3.3.3.3           0   FULL/DROTHER    00:01:57    192.168.1.3     Serial1/0.1 ! !!! R2 R2#sh ip ospf neighbor Neighbor ID     Pri   State           Dead Time   Address         Interface 1.1.1.1           1   FULL/DR         00:01:01    192.168.1.1     Serial1/0.1 ! !!! R3 R3#sh ip ospf neighbor Neighbor ID     Pri   State           Dead Time   Address         Interface 1.1.1.1           1   FULL/DR         00:00:38    192.168.1.1     Serial1/0

چگونگی تغییر Priority برای اطمینان از انتخاب صحیح DR و BDR در OSPF

پس تا الان همه مشکلات همسایگی را بین این چهار روتر برطرف نمودیم و در قالب آن نکات زیر را یاد گرفتیم:

• در تشکیل همسایگی OSPF روی اینترفیس های multipoint در frame-relay، نوع شبکه به پیش فرض non-broadcast است. در اینترفیس های non-broadcast لازم است تا همسایگی به صورت دستی تعریف گردد. در هر VC کافی است تا فقط در یک طرف، همسایگی به صورت دستی تعریف شود.
• چنانچه در اینترفیس های frame-relay از مد broadcast و یا non-broadcast استفاده می کنید که نیاز به تشکیل DR و BDR دارد، مراقب باشید حتما روتری DR و یا BDR شود که با همه دیگر روترهای آن اینترفیس، ارتباط VC داشته باشد. برای اصمینان از DR و BDR نشدن روترها، مقدار priority را روی اینترفیس آن روترها به صفر تغییر دهید.
• در تشکیل همسایگی لازم است تا مقدار hello time و hold time یکسان باشد. چنانچه نوع شبکه OSPF بین دو روتر همسایه یکسان نیست، از یکسان بودن مقدار hello time و dead time اطمینان حاصل کنید. در صورت یکسان نبودن مقادیر آنها را به صورت دستی تغییر دهید.
• در تشکیل همسایگی لزومی ندارد نوع شبکه OSPF بین روترهای همسایه یکسان باشد. به عنوان مثال اگر نوع اینترفیس دو روتر همسایه یکی point-to-point و یکی point-to-multipoint باشد، در ایجاد همسایگی و عملکرد OSPF مشکلی ایجاد نمی گردد. با این وجود دقت کنید که نوع شبکه در روترهای همسایه، از این جهت که آیا نیاز به انتخاب DR است و یا خیر، یکسان باشند. به عنوان مثال هیچگاه نوع شبکه در دو روتر همسایه را یکی non-broadcast و دیگری point-to-multipoint انتخاب نکنید. در این مثال مقدار hello time و dead time دو روتر همسایه یکسان است اما بدلیل تفاوت عملکرد در نحوه انتقال اطلاعات دیتابیس، مسیریابی با مشکل مواجه خواهد شد.

غیر از موارد فوق نکته قابل تامل و بسیار مهم دیگری نیز در این سناریو، که در آن نوع شبکه بین روترهای R1، R2 و R3 را non-broadcast انتخاب نمودیم، وجود دارد. همانطور که می دانید در دو نوع شبکه broadcast و non-broadcast، همه روترهای شبکه اطلاعات خود را صرفا از طریق روتر DR به دیگر روترهای آن شبکه منتقل می کنند. روتر DR صرفا جابجا کننده اطلاعات است و فیلد next-hop را تغییر نمی دهد. به عنوان مثال در توپولوژی مورد بحث ما که در آن روتر R1 روتر DR است و روترهای R2 و R3 از طریق روتر R1 اطلاعات را بین هم جابجا می کنند، از دید روتر R2، دسترسی به شبکه های متصل به R3 از طریق DR نیست بلکه دسترسی به صورت مستقیم و از طریق روتر R3 صورت می گیرد و بالعکس روتر R3 برای دسترسی به شبکه های متصل به روتر R2 نیز مستقیم ترافیک را به روتر R2 ارسال می کند.

این موضوع در شبکه های frame-relay می تواند گهگاه باعث بروز مشکلاتی گردد. برای درک این موضوع به مثال قبل توجه کنید که در آن روتر R1، DR است و روترهای R2 و R3 اطلاعات خود را از طریق R1 بین هم جابجا می کنند. از دید روتر R2 برای دسترسی به شبکه 172.16.3.0/24 باید ترافیک را مستقیما به روتر با آدرس 192.168.1.3 تحویل دهد که روتر R3 است و بالعکس روتر R3 نیز برای ارسال ترافیک به 172.16.2.0/24، ترافیک را مستقیما به روتر R2 یعنی 192.168.1.2 تحویل می دهد. از طرفی ارسال مستقیم ترافیک بین دو روتر R2 و R3 امکان پذیر نیست زیرا بین این دو روتر هیچ VC ای وجود ندارد. خروجی جدول مسیریابی دو روتر R2 و R3 و همچنین خروجی دستور ping بیانگر این مشکل است که در ذیل نشان داده شده است.

!!! R1 R1#sh ip ospf neighbor 2.2.2.2  Neighbor 2.2.2.2, interface address 192.168.1.2     In the area 0 via interface Serial1/0.1     Neighbor priority is 1 (configured 0), State is FULL, 7 state changes !!! بخشی از خروجی حذف شده است ! !!! R2 R2(config)#interface serial 1/0.1 R2(config-subif)#ip ospf priority 10 ! !!! R1 R1#sh ip ospf neighbor 2.2.2.2  Neighbor 2.2.2.2, interface address 192.168.1.2     In the area 0 via interface Serial1/0.1     Neighbor priority is 10 (configured 0), State is FULL, 20 state changes

روش اصلی تغییر Priority اینترفیس ها در OSPF

حال برای رفع مشکل دوم این توپولوژی، اینکه مطمئن شویم هیچگاه روترهای R2 و R3، نقش DR و یا BDR به خود نمی گیرند، باید روی خود روترهای R2 و R3 نیز مقدار priority را به صفر تغییر دهیم. در ذیل با این تغییر نشان داده شده است که از دید هر سه روتر R1، R2 و R3، روتر R1 روتر DR و روترهای R2 و R3 روترهای DROTHER هستند.

!!! R2 R2#sh ip route ospf !!! بخشی از خروجی حذف شده است       10.0.0.0/30 is subnetted, 1 subnets O        10.1.1.0 [110/128] via 192.168.1.1, 00:33:54, Serial1/0.1       172.16.0.0/16 is variably subnetted, 5 subnets, 2 masks O        172.16.1.1/32 [110/65] via 192.168.1.1, 00:33:54, Serial1/0.1 O        172.16.3.1/32 [110/65] via 192.168.1.3, 00:33:54, Serial1/0.1 O        172.16.4.1/32 [110/129] via 192.168.1.1, 00:33:54, Serial1/0.1 ! !!! R3 R3#sh ip route 172.16.2.1 Routing entry for 172.16.2.1/32   Known via "ospf 1", distance 110, metric 65, type intra area   Last update from 192.168.1.2 on Serial1/0, 00:34:53 ago   Routing Descriptor Blocks:   * 192.168.1.2, from 2.2.2.2, 00:34:53 ago, via Serial1/0       Route metric is 65, traffic share count is 1 ! !!! R2 R2#ping 172.16.3.1 source 172.16.2.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 172.16.3.1, timeout is 2 seconds: Packet sent with a source address of 172.16.2.1 ..... Success rate is 0 percent (0/5)

عدم تغییر next-hop توسط روتر DR در مد broadcast وnon-broadcast و اثرات ناشی از آن در شبکه های FrameRelay

در چنین شرایطی حتما باید تغییر کوچکی در پیکربندی frame-relay انجام داد. اینکه به روتر R2 گفته شود که برای دسترسی مستقیم به روتر R3 ترافیک را با DLCI ای خارج نماید که ترافیک، از طریق روتر R1 به R3 برسد یعنی همان DLCI ای که ارتباط VC بین روتر R2 را با روتر R1 ایجاد نموده است و در مثال ما 201  است. همینطور روی روتر R3 می نویسیم که برای دسترسی این روتر به روتر R2 ترافیک را با DLCI با مقدار 301 خارج نماید تا ترافیک از طریق R1 به روتر R2 برسد.

در ذیل با اعمال تغییرات مذکور مشاهده می کنید که مشکل مسیریابی OSPF نیز برطرف می شود

!!! R2 R2(config)#interface serial 1/0.1 R2(config-subif)#frame-relay map ip 192.168.1.3 201 broadcast ! !!! R3 R3(config)#interface serial 1/0 R3(config-if)#frame-relay map ip 192.168.1.2 301 broadcast ! R3#traceroute 192.168.1.2 Type escape sequence to abort. Tracing the route to 192.168.1.2   1 192.168.1.1 108 msec 92 msec 64 msec   2 192.168.1.2 160 msec *  144 msec ! !!! R2 R2#ping 172.16.3.1 source 172.16.2.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 172.16.3.1, timeout is 2 seconds: Packet sent with a source address of 172.16.2.1 !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 88/135/200 ms

رفع مشکل احتمالی ناشی از عدم تغییر next-hop توسط روتر DR در شبکه FrameRelay

حال تغییر اساسی دیگری در پروتکل OSPF بر اساس توپولوژی مورد نظر ایجاد می کنیم. به جای استفاده از شبکه non-broadcast ما بین روترهای R1، R2 و R3 می خواهیم نوع شبکه را به point-to-multipoint تغییر دهیم. در این نوع شبکه، همسایگی به صورت اتوماتیک ایجاد می گردد و نیازی به استفاده از دستور neighbor نمی باشد.

در ذیل نشان داده شده است که ضمن تغییر نوع شبکه از non-broadcast به point-to-multioint، همسایگی هایی که قبلا به صورت دستی ایجاد شده است نیز از پیکربندی روتر حذف شده است. سپس مجددا جدول همسایگی OSPF را بررسی می کنیم. با تغییر نوع شبکه، دستورات neighbor به صورت اتوماتیک حذف می شود.

خروجی جدول همسایگی OSPF نشان می دهد که بین روتر R1 با R2 و همچنین روتر R1 با R3 همسایگی FULL ایجاد شده است و در این پروسه هیچ DR و یا BDR ای نیز انتخاب نشده است

!!! R2 R2#sh ip route ospf !!! بخشی از خروجی حذف شده است       10.0.0.0/30 is subnetted, 1 subnets O        10.1.1.0 [110/128] via 192.168.1.1, 00:33:54, Serial1/0.1       172.16.0.0/16 is variably subnetted, 5 subnets, 2 masks O        172.16.1.1/32 [110/65] via 192.168.1.1, 00:33:54, Serial1/0.1 O        172.16.3.1/32 [110/65] via 192.168.1.3, 00:33:54, Serial1/0.1 O        172.16.4.1/32 [110/129] via 192.168.1.1, 00:33:54, Serial1/0.1 ! !!! R3 R3#sh ip route 172.16.2.1 Routing entry for 172.16.2.1/32   Known via "ospf 1", distance 110, metric 65, type intra area   Last update from 192.168.1.2 on Serial1/0, 00:34:53 ago   Routing Descriptor Blocks:   * 192.168.1.2, from 2.2.2.2, 00:34:53 ago, via Serial1/0       Route metric is 65, traffic share count is 1 ! !!! R2 R2#ping 172.16.3.1 source 172.16.2.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 172.16.3.1, timeout is 2 seconds: Packet sent with a source address of 172.16.2.1 ..... Success rate is 0 percent (0/5)

عدم تغییر next-hop توسط روتر DR در مد broadcast وnon-broadcast و اثرات ناشی از آن در شبکه های FrameRelay

در چنین شرایطی حتما باید تغییر کوچکی در پیکربندی frame-relay انجام داد. اینکه به روتر R2 گفته شود که برای دسترسی مستقیم به روتر R3 ترافیک را با DLCI ای خارج نماید که ترافیک، از طریق روتر R1 به R3 برسد یعنی همان DLCI ای که ارتباط VC بین روتر R2 را با روتر R1 ایجاد نموده است و در مثال ما 201  است. همینطور روی روتر R3 می نویسیم که برای دسترسی این روتر به روتر R2 ترافیک را با DLCI با مقدار 301 خارج نماید تا ترافیک از طریق R1 به روتر R2 برسد.

در ذیل با اعمال تغییرات مذکور مشاهده می کنید که مشکل مسیریابی OSPF نیز برطرف می شود

!!! R1 interface Serial1/0.1 multipoint  ip ospf network point-to-multipoint ! !!! R2 interface Serial1/0.1 multipoint  ip ospf network point-to-multipoint ! !!! R3 interface Serial1/0  ip ospf network point-to-multipoint ! !!! R1 R1#sh ip ospf neighbor Neighbor ID     Pri   State           Dead Time   Address         Interface 4.4.4.4           0   FULL/  -        00:00:33    10.1.1.2        Serial1/0.2 2.2.2.2           0   FULL/  -        00:01:45    192.168.1.2     Serial1/0.1 3.3.3.3           0   FULL/  -        00:01:57    192.168.1.3     Serial1/0.1 ! !!! R2 R2#sh ip ospf neighbor Neighbor ID     Pri   State           Dead Time   Address         Interface 1.1.1.1           0   FULL/  -        00:01:39    192.168.1.1     Serial1/0.1 !

مد point-to-multipoint در OSPF

در حالتی که نوع شبکه به point-to-multipoint تغییر می کند، نکته قابل توجه دیگر این است که وقتی روتر R2 و R3 اطلاعات خود را از طریق روتر R1 جابجا می کنند، روتر R1 خودش را به عنوان next-hop معرفی می کند و بنابراین روتر R2 و R3 برای دسترسی به شبکه های متصل به یکدیگر ترافیک را از طریق روتر R1 به یکدیگر ارسال می کنند.

بنابراین مجددا تاکید می شود که در دو شبکه broadcast و non-braoadcast، روتر DR صرفا جابجا کننده ترافیک بین دیگر روترهاست و خود واسط ترافیک در زمان ارسال داده بین روترها نخواهد بود اما در دیگر حالت های OSPF مانند point-to-multipoint اگر روتری اطلاعات شبکه های دیگر روترها را جابجا می کند، خود به عنوان next-hop عمل می کند و واسط ترافیک در زمان ارسال ترافیک داده ما بین آن روترها خواهد بود.

در. خروجی جدول مسیریابی روتر R2 نشان داده شده است که مسیر ترافیک به مقصد 172.16.3.1 روتر R1 به آدرس 192.168.1.1 است و بنابراین روتر R2 ترافیک را از سمت روتر R1 به روتر R3 تحویل می دهد و ترافیک مستقیما بین R2 و R3 جابجا نمی شود و اصلا نیازی به ایجاد دستور frame-relay map برای ارتباط مستقیم بین R2 و R3 نیست. در خروجی ذیل نشان داده شده است که دستورات frame-relay map که برای ارتباط بین R2 و R3 در بخش قبل ایجاد شده بود، از روترهای R2 و R3 حذف شده است. می بینیم که بدون وجود این دستورات نیز ارتباط بین دو شبکه 172.16.2.0/24 و 172.16.3.0/24 متصل به روترهای R2 و R3 برقرار می شود.

 

!!! R2 R2#sh ip route ospf !!! بخشی از خروجی حذف شده است       10.0.0.0/30 is subnetted, 1 subnets O        10.1.1.0 [110/128] via 192.168.1.1, 00:03:25, Serial1/0.1       172.16.0.0/16 is variably subnetted, 5 subnets, 2 masks O        172.16.1.1/32 [110/65] via 192.168.1.1, 00:03:25, Serial1/0.1 O        172.16.3.1/32 [110/129] via 192.168.1.1, 00:03:25, Serial1/0.1 O        172.16.4.1/32 [110/129] via 192.168.1.1, 00:03:25, Serial1/0.1       192.168.1.0/24 is variably subnetted, 4 subnets, 2 masks O        192.168.1.1/32 [110/64] via 192.168.1.1, 00:03:25, Serial1/0.1 O        192.168.1.3/32 [110/128] via 192.168.1.1, 00:03:25, Serial1/0.1 ! R2(config)#interface serial 1/0.1 R2(config-subif)#no frame-relay map ip 192.168.1.3 201 broadcast ! !!! R3 R3(config)#interface serial 1/0 R3(config-if)#no frame-relay map ip 192.168.1.2 301 broadcast ! !!! R2 R2#traceroute 172.16.3.1 source 172.16.2.1 Type escape sequence to abort. Tracing the route to 172.16.3.1   1 192.168.1.1 104 msec 196 msec 48 msec   2 192.168.1.3 240 msec *  244 msec

مقایسه دو نوع اینترفیس point-to-multipoint و non-broadcast در OSPF در تغییر و یا عدم تغییر next-hop

نوشتن دیدگاه

نام (اجباری)

آدرس پست الکترونیکی (اجباری است اما نمایش داده نمی‌شود)

مرا برای دیدگاه‌های بعدی به یاد بسپار

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

ارسال

لغو