رایکا امپرا

 قبل از پرداختن به جزئیات چگونگی انتقال اطلاعات در OSPF نگاهی به انواع بسته ها در OSPF می اندازیم. بسته های OSPF روی IP سوار می شوند و شماره پروتکل آن 89 دسیمال است. نمایی کلی از ساختار بسته OSPF را در ذیل مشاهده می کنید.

 فرمت بسته OSPF

OSPF دارای پنج بسته اصلی به نام های Hello، DBD، LSR، LSU و Ack است که شماره Type آنها در هدر OSPF به ترتیب از 1 تا 5 است. در ذیل ابتدا توصیفی کلی از هر یک از این بسته ها خواهیم داشت و در ادامه نیز به جزئیات آن می پردازیم.

  انواع بسته ها در OSPF

1- بسته Hello: هدف از ارسال و دریافت دوره ای بسته hello، تشکیل همسایگی و همچنین نگهداری همسایگی با روترهای همسایه است.

2- بسته DBD و یا DD: ارسال خلاصه ای از اطلاعات دیتابیس به طوری که روتر همسایه بداند شما چه اطلاعاتی در دیتابیس دارید. در بسته DBD هدر LSA ها که مولفه اصلی دیتابیس را تشکیل می دهند، ارسال می گردد. LSA جزئیات اطلاعات لینک های شبکه و توپولوژی است. در ادامه در مورد LSA بیشتر صحبت خواهیم کرد. در DBD فقط هدر LSA ها منتقل می شود.

3- بسته LSR: هدف از ارسال بسته LSR، ارسال درخواست ارائه جزئیات یک یا چند LSA است که روتر همسایه آن را در بسته DBD اعلام نموده است. به عبارت دیگر از طریق ارسال LSR از روتر همسایه درخواست می کنیم که جزئیات اطلاعات و توپولوژی یک یا چند لینک را اعلام نماید.

4- بسته LSU: در پاسخ به ارسال بسته LSR، روتر جزئیات لینک ها و توپولوژی درخواستی را از طریق LSU ارسال می کند. خود اطلاعات در ساختار داده LSA قرار می گیرد اما یک یا چند LSA در قالب بسته LSU منتقل می شوند. به عبارت دیگر بسته ای که منتقل می شود، LSU نام دارد اما محتویات LSU را یک یا چند LSA تشکیل می دهد. هر LSA نیز مشخص کننده جزئیات توپولوزی یک یا چند لینک است. در بخشی تحت عنوان انواع LSA در OSPF جزئیات را بیشتر مورد بررسی قرار خواهیم داد.

5- بسته Ack: در OSPF اطلاعات LSU فقط یکبار و به صورت مطمئن منتقل می شود. بدین معنی که هر یک از همسایه باید دریافت بسته های LSU را تایید نماید در غیر این صورت بسته LSU مجددا برای آن همسایه ارسال می گردد. بسته Ack برای ارسال تاییدیه استفاده می شود.

حال بیایید با جزئیات بیشتر به تحلیل پروسه انتقال اطلاعات در OSPF بپردازیم. وقتی حالت همسایگی بین دو روتر همسایه به 2way تغییر می کند، پروسه انتقال اطلاعات آغاز می شود. اولین مرحله در این پروسه که حالت Exstart نیز نامیده می شود، انتخاب Master و Slave است. روتری که router-id بزرگتری دارد به عنوان Master انتخاب می شود و این روتر همان روتری است که انتقال بسته DBD را بین دو روتر همسایه آغاز می کند و فقط روتر Master است که می تواند Sequence Number را افزایش دهد. تاکید می شود که در بسته DBD فقط هدر LSA منتقل می شود تا نمایانگر دیتابیس باشد. بعد از آنکه روتر Master خلاصه اطلاعات دیتابیس خود را ارسال نمود و در پاسخ نیز روتر Slave خلاصه اطلاعات دیتابیس خود را در قالب بسته DBD را ارسال نمود، هر یک از روترها می داند که چه اطلاعاتی از دیتابیس همسایه در دیتابیس دیگری وجود ندارد. در مرحله دوم هر یک از روترها اطلاعات مورد نیاز خود را در قالب بسته LSR از روتر همسایه درخواست می کند. درخواست LSR وقتی ارسال می شود که روتر LSA خاصی را در جدول دیتابیس نداشته باشد و یا آنکه با Sequence Number پایین تری در جدول دیتابیس وجود داشته باشد. کوچکتر بودن Sequence Number بدین معنی است که اطلاعات دیتابیس به روز نیست و بنابراین روتر آن LSA را نیز از همسایه درخواست می کند. sequence number به ازاء هر LSA وقتی افزایش می یابد که تغییری در LSA و یا اطلاعات لینک ایجاد گردد. در مرحله سوم و در پاسخ به بسته LSR، بسته LSU ارسال می شود. بسته LSU شامل یک یا چند LSA است. LSA جزئیات اطلاعات لینک ها و چگونگی اتصالات آنها را نشان می دهد. در مورد بسته LSU یک نکته مهم وجود دارد و آن اینکه به محض اینکه روتری بسته LSU را دریافت می کند، آن را روی دیگر اینترفیس هایش پخش و یا flood می کند. به همین دلیل است که در تعریف OSPF گفته می شود که هر روتر اطلاعات لینک های خود را به کلیه روترهای شبکه ارسال می کند و این ارسال صرفا به روترهای همسایه محدود نمی شود. منظور از Flood کردن این است که LSU دریافتی در هر روتر به کلیه دیگر روترهای همسایه پخش می شود و این پروسه در کل شبکه ادامه می یابد. فراموش نکنیم که پروسه انتقال DBD حالت همسایگی را به Exchange و انتقال LSR و LSU حالت همسایگی را به Loading تغییر می دهد. از آنجایی که انتقال اطلاعات در OSPF به صورت مطمئن صورت می پذیرد، هر روتر LSU دریافتی را با ارسال Ack تایید می نماید. این مرحله، آخرین مرحله پروسه انتقال اطلاعات در OSPF است. اتمام پروسه انتقال اطلاعات و یکی شدن دیتابیس روترهای همسایه، همسایگی را به حالت نهایی Full تغییر می دهد.

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

 حالت های همسایگی در OSPF

در شکل فوق مفهوم جدیدی با عنوان DR Election مشاهده می کنید که در شبکه های broadcast و non-broadcast کاربرد دارد و جزو پروسه هایی است که در تشکیل همسایگی اتفاق می افتد. جزئیات انتخاب DR و BDR و اصلا کاربرد و ضرورت وجودی آنها در ادامه بحث خواهد شد.

با کمک شکل بالا و جدول زیر حالت های همسایگی را از ابتدای ارسال hello تا یکی شدن دیتابیس OSPF مرور نمایید.

 

توصیف	حالت همسایگی
بدین معنی است که در زمان dead time از این همسایه hello دریافت نشده است	down
بدین معنی است که این روتر در حال ارسال hello به همسایه مورد نظر است.این حالت فقط وقتی معنی دارد که همسایگی دستی تعریف شده باشد که در شبکه های از نوع non-broadcast کاربرد دارد و در بخش انواع شبکه ها در ospf در همین فصل در مورد آنها صحبت خواهیم نمود	attempt
حالت Init بدین معنی است که از این همسایه hello دریافت شده است اما همسایه هنوز از این روتر دریافت نکرده است و یا آنکه پارامترهای همسایگی مطابقت ندارد. اگر پارامترهای همسایگی مطابقت نداشته باشد، در این حالت به صورت دائمی باقی می ماند	init
این حالت همسایگی بدین معنی است که دو روتر همسایه همدیگر را شناسایی نموده اند و پارامترهای همسایگی نیز مطابقت دارد.	2way
در این حالت انتخاب Master و Slave در ارسال بسته DBD در حال انجام است	ExStart
در این حالت روترهای همسایه در حال انتقال بسته DBD و یا اطلاعات مربوط به هدرهای LSA هستند.	Exchange
به بخشی از پروسه که بسته های LSR، LSU و Ack ارسال و دریافت می گردد، حالت Loading گفته می شود	Loading
در این حالت دیتابیس دو روتر همسایه یکی شده است و روترها آماده انتخاب بهترین مسیرها هستند	Full

حالت های همسایگی در OSPF

در خروجی دستورات debug در OSPF همه بسته ها و حالت های همسایگی از زمان شروع پروسه همسایگی تا انتقال کامل اطلاعات دیتابیس و تشکیل همسایگی FULL قابل مشاهده است.

IOU1#debug ip ospf adj IOU1#debug ip ospf hello OSPF hello events debugging is on ! *Aug 20 14:56:53.455: OSPF: Send hello to 224.0.0.5 area 0 on Serial2/0 from 10.1.1.1 *Aug 20 14:56:53.455: OSPF: Serial2/0: Interface state change to UP, new ospf state P2P IOU1(config-if)# *Aug 20 14:56:53.955: OSPF: Build router LSA for area 0, router ID 10.1.1.1, seq 0x80000005, process 1 IOU1(config-if)# *Aug 20 14:57:02.739: OSPF: Send hello to 224.0.0.5 area 0 on Serial2/0 from 10.1.1.1 IOU1(config-if)# *Aug 20 14:57:09.767: OSPF: Rcv hello from 10.1.1.2 area 0 from Serial2/0 10.1.1.2 *Aug 20 14:57:09.767: OSPF: Send immediate hello to nbr 10.1.1.2, src address 10.1.1.2, on Serial2/0 *Aug 20 14:57:09.767: OSPF: Send hello to 224.0.0.5 area 0 on Serial2/0 from 10.1.1.1 *Aug 20 14:57:09.767: OSPF: End of hello processing *Aug 20 14:57:09.775: OSPF: Rcv DBD from 10.1.1.2 on Serial2/0 seq 0x26B4 opt 0x52 flag 0x7 len 32  mtu 1500 state INIT *Aug 20 14:57:09.775: OSPF: 2 Way Communication to 10.1.1.2 on Serial2/0, state 2WAY *Aug 20 14:57:09.775: OSPF: Serial2/0 Nbr 10.1.1.2: Prepare dbase exchange *Aug 20 14:57:09.775: OSPF: Send DBD to 10.1.1.2 on Serial2/0 seq 0x20BF opt 0x52 flag 0x7 len 32 *Aug 20 14:57:09.775: OSPF: NBR Negotiation Done. We are the SLAVE *Aug 20 14:57:09.775: OSPF: Serial2/0 Nbr 10.1.1.2: Summary list built, size 2 *Aug 20 14:57:09.775: OSPF: Send DBD to 10.1.1.2 on Serial2/0 seq 0x26B4 opt 0x52 flag 0x2 len 72 *Aug 20 14:57:09.775: OSPF: Rcv hello from 10.1.1.2 area 0 from Serial2/0 10.1.1.2 *Aug 20 14:57:09.775: OSPF: End of hello processing *Aug 20 14:57:09.795: OSPF: Rcv DBD from 10.1.1.2 on Serial2/0 seq 0x26B5 opt 0x52 flag 0x1 len 72  mtu 1500 state EXCHANGE *Aug 20 14:57:09.795: OSPF: Exchange Done with 10.1.1.2 on Serial2/0 *Aug 20 14:57:09.795: OSPF: Send LS REQ to 10.1.1.2 length 12 LSA count 1 *Aug 20 14:57:09.795: OSPF: Send DBD to 10.1.1.2 on Serial2/0 seq 0x26B5 opt 0x52 flag 0x0 len 32 *Aug 20 14:57:09.807: OSPF: Rcv LS UPD from 10.1.1.2 on Serial2/0 length 64 LSA count 1 *Aug 20 14:57:09.807: OSPF: Synchronized with 10.1.1.2 on Serial2/0, state FULL *Aug 20 14:57:09.807: %OSPF-5-ADJCHG: Process 1, Nbr 10.1.1.2 on Serial2/0 from LOADING to FULL, Loading Done IOU1(config-if)# *Aug 20 14:57:09.811: OSPF: Rcv LS REQ from 10.1.1.2 on Serial2/0 length 36 LSA count 1 *Aug 20 14:57:10.307: OSPF: Build router LSA for area 0, router ID 10.1.1.1, seq 0x80000006, process 1

مانیتورینگ و debug کردن بسته های OSPF از شروع تشکیل همسایگی تا پایان انتقال اطلاعات و تشکیل همسایگی FULL

انتقال اطلاعات در شبکه های broadcast و non-broadcast

همانطور که قبلا گفته شد هر دو روتری که از طریق hello یکدیگر را شناسایی می کنند، بعد از تشکیل همسایگی 2way شروع به انتقال اطلاعات بین یکدیگر می کنند. نکته اینجاست اگر بیش از یک روتر روی لینکی وجود داشته باشد، انتقال اطلاعات بین دو به دوی آنها جداگانه صورت می گیرد. تصور کنید n روتر در یک لینک لایه 2 ای قرار دارند که همه hello یکدیگر را دریافت می کنند. در این حالت هر روتر n-1 روتر دیگر را به عنوان روترهای همسایه در آن لینک تشخیص داده و با هر یک از آنها تشکیل همسایگی 2way می دهد. بنابراین n روتر داریم که هریک n-1 پروسه تشکیل همسایگی را تا حالت همسایگی 2way دنبال می کند. به عبارت دیگر n(n-1) پروسه همسایگی وجود دارد. حال هر یک از روتر ها باید شروع به انتقال اطلاعات با هریک از همسایه ها نماید که در این صورت n(n-1) پروسه انتقال اطلاعات خواهیم داشت که این پروسه می تواند بسیار سنگین و غیر قابل تحمل باشد. مثلا تصور کنید 1000 شعبه سازمانی در سرتاسر کشور روی بستر لایه 2 مانند VPLS به یکدیگر متصل باشند که در این صورت 999000 پروسه انتقال اطلاعات بین شعب خواهیم داشت. بدیهی است این حجم اطلاعات و پردازش غیر قابل تحمل بوده و مقیاس پذیر نمی باشد.

پروسه انتقال اطلاعات OSPF در شبکه های broadcast و non-broadcast

اما نگران نباشید. OSPF برای این مشکل راه حلی در نظر گرفته است. در صورتی که چندین روتر روی لینک مشترک از نوع broadcast و یا non-broadcast قرار داشته باشند، ضرورتی ندارد تا روترها دو به دو انتقال اطلاعات انجام دهند. بلکه یکی از آنها به عنوان نامزد انتخاب شده و همه روترها انتقال اطلاعات را با آن روتر نامزد انجام می دهند و آن روتر نیز مسئول انتقال اطلاعات دیتابیس بین روترهای آن لینک خواهد بود. به عبارت دیگر همه اطلاعات دیتابیس خود را صرفا به روتر نامزد منتقل می کنند و آن روتر نیز اطلاعات دریافتی را به دیگر روترهای آن لینک ارسال می نماید. بدین شیوه تعداد پروسه انتقال اطلاعات از n(n-1) به n-1 کاهش می یابد که تاثیر آن در افزایش کارایی بسیار قابل توجه است. در مثال فوق تعداد پروسه انتقال اطلاعات از 999000 به 999 کاهش می یابد که بسیار قابل توجه است.

روتری که به عنوان مرکز انتقال اطلاعات بین دیگر روترهای همان لینک انتخاب و یا نامزد می شود، DR و یا Designated Router نامیده می شود. بدیهی است در چنین شرایطی اگر روتر DR خراب شود، پروسه OSPF به طور کلی در آن لینک دچار خدشه خواهد شد. برای رفع این مشکل روتر دیگری نیز به عنوان پشتیبان DR در نظر گرفته می شود تا در صورتی خراب DR، جایگزین آن شود تا پشتیبان دیگری انتخاب شود. به پشتیبان DR، روتر BDR و یا Backup Designated Router گفته می شود.

در حالت عادی روترهای OSPF بسته های LSU را به آدرس 224.0.0.5 ارسال می نمایند تا همه روتر های OSPF در آن لینک آن را دریافت نمایند اما در حالتی که نوع شبکه broadcast و یا non-broadcast باشد که در آن یکی از روترها به عنوان DR انتخاب می شود، همه روتر ها اطلاعات LSU را به آدرس 224.0.0.6 ارسال می نمایند که فقط DR و BDR به آن گوش می دهند و روتر DR اطلاعات LSU دریافتی را به آدرس 224.0.0.5 روی همان لینک ارسال می کند تا همه دیگر روترهای OSPF که به این آدرس گوش می دهند، آن را دریافت نمایند. در جملات فوق ممکن است نوع شبکه های broadcast و non-broadcast برای شما مبهم باشد که در بخش انواع شبکه ها در OSPF در مورد آن صحبت خواهیم نمود.

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

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

در صورتی که priority بین چند روتر یکسان باشد، روتری به عنوان DR انتخاب می شود که router-id بزرگتری داشته باشد.

به طور کل در انتخاب DR موارد زیر رعایت می گردد:

• روتری به عنوان DR انتخاب می گردد که priority بزرگتری داشته باشد. مقدار priority روتر در هر لینک، در hello ارسالی روی آن لینک منتقل می گردد. مقدار priority بین 1 تا 255 است. روتری که priority آن را صفر قرار می دهیم، هیچگاه DR و یا BDR نخواهد شد
• در صورت یکسان بود priority بین چندین روتر، روتری به عنوان DR انتخاب می گردد که router-id بزگتری داشته باشد. فیلد router-id نیز در بسته hello منتقل می گردد.
• پروسه انتخاب DR رقابتی نیست. بدین معنی که پس از انتخاب روتر DR، دیگر روترها سعی بر عوض کردن روتر DR نخواهند داشت. به عبارت دیگر اگر روتر DR قبلا انتخاب شده باشد، دیگر روتری سعی نمی کند خود را به عنوان DR معرفی کند. router-id روتر DR در بسته hello ارسال می شود.
• روتری که از نظر priority و یا router-id در موقعیت دوم قرار داشته باشد به عنوان BDR در نظر گرفته می شود. روتر BDR نیز همانند DR بسته های به آدرس مقصد 0.0.6 را دریافت می کند اما اطلاعات دریافتی را منتقل نمی کند. زمانی که روتر DR به هر دلیلی خراب شود، روتر BDR به عنوان DR جدید انتخاب خواهد شد و روتر سومی به عنوان BDR انتخاب خواهد شد.

 پروسه انتخاب DR و BDR چه زمانی اتفاق می افتد؟ پروسه انتخاب DR و BDR زمانی شروع می شود که روتر به حالت همسایگی 2way با همسایه می رسد. اگر روی hello دریافتی از قبل روتر DR مشخص شده باشد که در این صورت تکلیف روتر مشخص است و روتر نیز در hello ارسالی، router-id همان روتر را به عنوان DR قرار می دهد. در غیر این صورت مقدار DR، 0.0.0.0 است که در این صورت روتر به اندازه مدت زمان wait time منتظر می ماند تا همه شانس DR شدن را داشته باشند. مقدار wait time به صورت پیش فرض با مقدار dead time یکی است. انتخاب DR بعد از حالت همسایگی 2way و قبل از انتقال DBD صورت می گیرد.

اگر چنانچه روی لینک broadcast و یا non-brodcast چندین روتر وجود داشته باشد و بخواهید OSPF را روی آنها اجرا نمایید در این صورت، اولین روتری که OSPF روی آن اجرا می شود به عنوان DR انتخاب خواهد شد. روتر مورد نظر حداکثر به مدت زمان wait time منتظر می ماند تا همه شانس شرکت در پروسه انتخاب DR را داشته باشند. اما از آنجایی که تا آن زمان روی روتر دیگری هنوز OSPF اجرا نشده است و hello با priority و router-id بزرگتر دریافت نشده است، همان روتر اول router-id خود را به عنوان DR در بسته hello قرار می دهد. پس از آن نیز هر روتر جدیدی که در OSPF اجرا می گردد، همان روتر اول را که به عنوان DR انتخاب شده است و آدرس آن نیز در بسته hello وجود دارد، به عنوان DR می پذیرد.

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

برای درک بهتر مفاهیم این بخش به مثال زیر توجه کنید که 4 روتر در لینک اترنت که از نوع broadcast است، قرار گرفته اند و در بازه زمانی کوتاه روی هر 4 روتر OSPF اجرا شده است. در مقدار priority تغییری داده نشده است و priority همه روترها مقدار پیش فرض 1 است. بدیهی است روترهایی به عنوان DR و BDR انتخاب خواهند شد که بالاترین مقدار router-id را داشته باشند که در این مثال روترهای با router-id با مقدار 3.3.3.3 و 4.4.4.4 هستند. در خروجی دستور debug ip ospf adj در روتر IOU1، تعیین این دو روتر به عنوان DR و BDR تایید می شود. در این خروجی همچنین نشان داده شده است که پروسه ارسال DBD بعد از تعیین روترهای DR و BDR آغاز می شود.

انتخاب DR و BDR در OSPF در شبکه های broadcast

!!! IOU1 !!! بخشی از خروجی حذف شده است *Aug 23 07:25:50.739: OSPF: Rcv hello from 2.2.2.2 area 0 from Ethernet0/0 192.1                                                      68.1.2 *Aug 23 07:25:50.739: OSPF: 2 Way Communication to 2.2.2.2 on Ethernet0/0, state                                                       2WAY !!! بخشی از خروجی حذف شده است *Aug 23 07:25:56.707: OSPF: Rcv hello from 3.3.3.3 area 0 from Ethernet0/0 192.168.1.3 *Aug 23 07:25:56.707: OSPF: 2 Way Communication to 3.3.3.3 on Ethernet0/0, state 2WAY !!! بخشی از خروجی حذف شده است *Aug 23 07:26:04.667: OSPF: Rcv hello from 4.4.4.4 area 0 from Ethernet0/0 192.168.1.4 *Aug 23 07:26:04.667: OSPF: 2 Way Communication to 4.4.4.4 on Ethernet0/0, state  2WAY !!! بخشی از خروجی حذف شده است *Aug 23 07:26:22.839: OSPF: end of Wait on interface Ethernet0/0 *Aug 23 07:26:22.839: OSPF: DR/BDR election on Ethernet0/0 !!! بخشی از خروجی حذف شده است *Aug 23 07:26:53.047: OSPF: Elect BDR 3.3.3.3 *Aug 23 07:26:53.047: OSPF: Elect DR 4.4.4.4 *Aug 23 07:26:53.047:        DR: 4.4.4.4 (Id)   BDR: 3.3.3.3 (Id) *Aug 23 07:26:53.047: OSPF: Ethernet0/0 Nbr 3.3.3.3: Prepare dbase exchange *Aug 23 07:26:53.047: OSPF: Send DBD to 3.3.3.3 on Ethernet0/0 seq 0x1C93 opt 0x52 flag 0x7 len 32 !!! بخشی از خروجی حذف شده است

 جزئیات پروسه  اتخاب DR و BDR در OSPF

در ادامه، جدول همسایگی روتر IOU1 تا روتر IOU4 نشان داده شده است.   چند نکته در خروجی جدول همسایگی قابل مشاهده است. اول آنکه priority همه روتر ها به صورت پیش فرض 1 است. دوم اینکه روترهای 3.3.3.3 و 4.4.4.4 به ترتیب به عنوان BDR و DR انتخاب شده اند. در پایان اینکه نوع همسایگی روترهای DROTHER با یکدیگر (دو روتر IOU1 و IOU2) از نوع 2way و نوع همسایگی بین دیگر روتر های شبکه FULL است.

IOU1#sh ip ospf neighbor   Neighbor ID     Pri   State           Dead Time   Address         Interface 2.2.2.2           1   2WAY/DROTHER    00:00:35    192.168.1.2     Ethernet0/0 3.3.3.3           1   FULL/BDR        00:00:37    192.168.1.3     Ethernet0/0 4.4.4.4           1   FULL/DR         00:00:32    192.168.1.4     Ethernet0/0 ! IOU2#sh ip ospf neighbor   Neighbor ID     Pri   State           Dead Time   Address         Interface 1.1.1.1           1   2WAY/DROTHER    00:00:39    192.168.1.1     Ethernet0/0 3.3.3.3           1   FULL/BDR        00:00:33    192.168.1.3     Ethernet0/0 4.4.4.4           1   FULL/DR         00:00:38    192.168.1.4     Ethernet0/0 ! IOU3#sh ip ospf neighbor   Neighbor ID     Pri   State           Dead Time   Address         Interface 1.1.1.1           1   FULL/DROTHER    00:00:36    192.168.1.1     Ethernet0/0 2.2.2.2           1   FULL/DROTHER    00:00:38    192.168.1.2     Ethernet0/0 ! IOU4#sh ip ospf neighbor   Neighbor ID     Pri   State           Dead Time   Address         Interface 1.1.1.1           1   FULL/DROTHER    00:00:31    192.168.1.1     Ethernet0/0 2.2.2.2           1   FULL/DROTHER    00:00:32    192.168.1.2     Ethernet0/0 3.3.3.3           1   FULL/BDR        00:00:33    192.168.1.3     Ethernet0/0

جدول همسایگی OSPF در شبکه های broadcast

نوشتن دیدگاه

نام (اجباری)

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

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

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

ارسال

لغو