معیار بیشینه OSPF: منع عبور از شعبه بدون حذف آن
یک شعبه میتواند در دسترس بماند و در همان حال هزینهٔ عبور ناخواستنی اعلام کند. مسیر را گامبهگام طی کنید، router-LSA را بخوانید و حالت مسیر آخر را بیازمایید.
دو دفتر از طریق شعبهای به هم متصل میشوند که باید ترافیک خودش و بسیار اندکی غیر آن را حمل کند. شعبه به مسیرهایی به هر دو سایت نیاز دارد و هیچیک از دو سایت نباید آن را بهعنوان مسیر میان خود ترجیح دهد. حذف شعبه از توپولوژی مشکل عبور را حل میکرد و شرط را نقض میکرد، زیرا شعبه هنوز باید به هر دو سایت برسد و هر دو سایت هنوز باید به شعبه برسند.
آنچه میخواهید یک ترجیح است، بیانشده در پروتکل مسیریابی، که شعبه را کاملاً در دسترس نگه میدارد و آن را برای هر چیزی که از آن میگذرد گزینهای ضعیف میکند. مسئله را به همان ترتیبی که روترها میبینند طی کنید.
از مسیری که میخواهید اجتناب کنید آغاز کنید
توپولوژی را آنگونه که پروتکل میبیند رسم کنید، نه آنگونه که نمودار میبیند. کدام رابطها مجاورت میسازند، کدامها در یک ناحیهاند، و کدام یک از آن مجاورتها اگر شعبه ترجیح داده میشد ترافیک میان دو دفتر را حمل میکرد؟ این سه پرسش جداست و نمودار به هیچیک از آنها بهطور قابل اعتماد پاسخ نمیدهد.
سپس مسیر جایگزین را بیابید. اگر تنها مسیر میان دو دفتر از شعبه میگذرد، هیچ معیاری نمیتواند ترافیک را از آن دور کند، زیرا ترافیک جایی برای رفتن ندارد. افزونگی جزئیات این طراحی نیست؛ پیششرط آن است. مسیر دومی که فقط روی کاغذ وجود دارد به حساب نمیآید.
show ip ospf neighbor
show ip ospf interface brief
show ip route 10.40.0.0
این سه نما به پرسشهای متفاوتی پاسخ میدهند: چه کسی مجاور است، کدام رابطها مشارکت دارند و با چه هزینهای، و دستگاه اکنون کدام مسیر را انتخاب میکند. استقرار تونل چهارمی را میافزاید: خطی روی نمودار اثبات آن نیست که مجاورت از روی آن شکل گرفته و مجاورتِ شکلگرفته اثبات آن نیست که ارسال همان مسیر را دنبال میکند. در طراحیهای تونلی است که این شکاف بیشتر دیده میشود.
معیار بیشینه چه چیزی اعلام میکند
RFC 6987 روتری را توصیف میکند که پیوندهای غیراستاب خود را با معیار بیشینهٔ پیوند اعلام میکند، که بهصورت 0xffff تعریف شده است. روتر هنوز خود و پیوندهایش را توصیف میکند؛ فقط آنها را در بالای بازه قیمتگذاری میکند، بنابراین هر روتر دیگری مسیری از آن را گران محاسبه میکند.
این تغییری در router-LSA است، نه حذف توپولوژی. تمایز مهم است: پاککردن router-LSA خودِ اطلاعات توپولوژی را پس میگیرد، که میتواند روابط لازم برای رسیدن به روتر و پیشوندهای پشت آن را نیز پس بگیرد. نگهداشتن اعلامیه و بالابردن قیمتش آن روابط را حفظ میکند. تمام تفاوت میان این تکنیک و حذف همین است.
مکانیزم RFC 6987 هم هیچ ربطی به انواع ناحیه یا به انتخاب روتر تعیینشده ندارد. ناحیهٔ استاب دستهای از اعلامیههای وضعیت پیوند را در مرز ناحیه مسدود میکند و روتر استاب پیوندهای خودش را قیمتگذاری میکند. واژههای مشابه، سازوکار بیربط.
چرا دسترسی میماند و عبور نمیماند
روترهای دیگر هنوز مسیری به پیشوندهای متصل شعبه دارند، زیرا شعبه هنوز آنها را اعلام میکند و پیوندها هنوز وجود دارند. آنچه تغییر میکند هزینهٔ کل هر مسیری است که در راه رفتن به جای دیگر از شعبه میگذرد. پیشوندها جابهجا نمیشوند؛ فقط قیمت عبور از روتر تغییر میکند.
برای ترافیکی که مبدأ یا مقصدش خود شعبه است، پیوند گران هنوز روی تنها مسیر معقول است، پس استفاده میشود. برای ترافیک میان دو دفتر، مسیر جایگزین اکنون در هزینه پیروز میشود و شعبه بدون ناپدیدشدن از توپولوژی از تصمیم ارسال خارج میشود. دو جهت، دو پاسخ متفاوت، و هر دو نشان میدهد که مکانیزم کار میکند.
این همان رفتاری است که باید بررسی شود نه فرض. به router-LSA که شعبه تولید میکند نگاه کنید، سپس به مسیری که روتر دیگری برای مقصدی پشت شعبه و برای مقصدی در دفتر دیگر انتخاب میکند. دو پاسخ باید متفاوت باشند و اگر نیستند، تغییر معیار به تصمیمی که فکر میکنید نمیرسد.
مشکل مسیر آخر
همان RFC صریح است که این تکنیک استفاده را ممنوع نمیکند. وقتی مسیر جایگزین از کار میافتد، روترها به مسیر گران از میان شعبه بازمیگردند، زیرا هنوز مسیر معتبری است و پروتکل مسیر پرهزینه را به نبود مسیر ترجیح میدهد.
اینکه این بازگشت پذیرفتنی است یا نه، پرسش سیاستی است که باید پیش از استقرار پاسخ دهید. شعبهای روی یک پیوند بالاسری کوچک که ناگهان ترافیک میاندفتری حمل میکند ممکن است بدتر از یک قطعی باشد، و ممکن است دقیقاً همان چیزی باشد که در پنجرهٔ نگهداری میخواهید. هر دو پاسخ مشروعاند؛ سکوت نیست.
اگر شرط ممنوعیت سخت باشد نه ترجیح، طراحی معیار بهتنهایی آن را تولید نمیکند. به اعمال ارسال نیاز دارید که با قصد همخوان باشد، بههمراه رفتاری تعریفشده برای حالتی که ترافیک بههرحال میرسد. اعلام یک مسیر بهعنوان قابل استفاده و سپس انداختن ترافیک، حفرهٔ سیاهی میسازد که تشخیصش از حلقهٔ مسیریابی دشوارتر است.
برای OSPFv3، RFC بیت R را راه دیگری برای کنار گذاشتن مشارکت در عبور میداند. فرض نکنید که همان رفتار مسیر آخر تکنیک معیار بیشینه را به ارث میبرد، و تنظیمات را میان دو خانوادهٔ نشانی کپی نکنید که گویی یک ویژگیاند.
آن را در شرایط عادی و خرابی اثبات کنید
دو بار بیازمایید: یک بار با هر دو مسیر موجود و یک بار با مسیر ترجیحی حذفشده. آزمایش نخست نشان میدهد ترجیح کار میکند و دومی نشان میدهد شبکه وقتی ترجیح قابل رعایت نیست چه میکند. حذف آزمایش دوم نیمهٔ مهم را بررسینشده میگذارد.
show ip ospf database router 10.0.0.3
show ip route 172.20.8.0
traceroute 172.20.8.1
نمای پایگاه داده معیار اعلامشده را نشان میدهد، جستوجوی مسیر گام بعدی انتخابشده را نشان میدهد و ردگیری نشان میدهد بستهها واقعاً کجا رفتند. وقتی این سه همخوان باشند، طراحی تأییدشده دارید نه پیکربندی درستنما.
سپس مسیر ترجیحی را بازگردانید و تأیید کنید که شعبه به حمل تنها ترافیک خودش برمیگردد. گام بازگردانی بخشی از آزمایش است نه نظافت، زیرا طراحیای که فقط تا تغییر بعدی کار میکند طراحی نیست. هر دو نتیجه را بنویسید، از جمله بازگشت، چون دومی پاسخی است که کسی ساعت سه بامداد به آن نیاز خواهد داشت.