بررسی عمیق انواع ناحیه OSPF: Stub، Totally Stubby، و NSSA

طراحی OSPF چندناحیه‌ای پایه، که پیش‌تر در این مجموعه پوشش داده شد، از قبل اندازه پایگاه‌داده را با نگه‌داشتن LSA های جزئی نوع ۱ و ۲ محلی به ناحیه خودشان کاهش می‌دهد، اما انواع ناحیه تخصصی OSPF فراتر می‌روند، و به‌طور خاص LSA های خارجی نوع ۵ را هدف قرار می‌دهند. این مقاله انواع LSA که باید برای ساخت هر نوع ناحیه تخصصی سرکوب شوند را توضیح می‌دهد، پیکربندی نواحی stub، totally stubby، و not-so-stubby را مرور می‌کند، و مبادلات خاصی که هر انتخاب طراحی شامل می‌شود را پوشش می‌دهد.

ناحیه Stub OSPFناحیه Totally StubbyNSSA

~7 دقیقه مطالعه · آخرین به‌روزرسانی ۲۱ شهریور ۱۴۰۵

فراتر از طراحی چندناحیه‌ای پایه

طراحی چندناحیه‌ای OSPF که پیش‌تر در این مجموعه پوشش داده شد از قبل پایگاه‌داده link-state هر ناحیه را با نگه‌داشتن LSA های جزئی نوع ۱ و ۲ محلی به ناحیه خودشان، که پیش‌تر در این مجموعه درباره انواع LSA بحث شد، کاهش می‌دهد، در حالی که LSA های نوع ۳ خلاصه‌شده از مرزهای ناحیه عبور می‌کنند. انواع ناحیه تخصصی OSPF فراتر می‌روند، و به‌طور خاص LSA های خارجی نوع ۵ را هدف قرار می‌دهند -- مسیرهای یادگرفته‌شده از خارج از OSPF کاملاً از طریق توزیع‌مجدد، که پیش‌تر در این مجموعه بحث شد -- که به‌طور پیش‌فرض می‌توانند در سراسر کل دامنه OSPF سیلاب شوند و جداول مسیریابی را در نواحی‌ای که واقعاً نیازی به آن جزئیات مسیریابی خارجی ندارند به‌طور قابل‌توجهی متورم کنند.

چرا مسیرهای خارجی اغلب در نواحی برگ غیرضروری هستند

یک ناحیه دفتر شعبه کوچک که فقط از میان یک روتر مرزی ناحیه واحد به باقی شبکه سازمانی متصل است را در نظر بگیرید. هر روتر در آن ناحیه شعبه نیاز دارد به مقصدهای خارجی مانند اینترنت برسد، اما نیازی به لیست کامل و جزئی هر مسیر خارجی خاص ندارند -- یک مسیر پیش‌فرض واحد که به‌سمت ABR اشاره می‌کند دقیقاً همان نتیجه عملی را با یک جدول مسیریابی به‌طور چشمگیری کوچک‌تر به دست می‌آورد.

ناحیه Stub: مسدودکردن مسیرهای خارجی

یک Stub Area (ناحیه stub) از ورود LSA های خارجی نوع ۵ به ناحیه کاملاً جلوگیری می‌کند، با ABR که در عوض یک مسیر پیش‌فرض تزریق می‌کند تا روترهای ناحیه همچنان بتوانند به مقصدهای خارجی برسند.

-- پیکربندی باید روی هر روتری درون ناحیه stub،
-- شامل ABR، تطبیق داشته باشد

ABR(config-router)# area 1 stub

Internal-Router(config-router)# area 1 stub

-- هر روتر باید توافق کند ناحیه stub است؛
-- یک عدم‌تطابق از شکل‌گیری درست همسایگی‌های
-- OSPF، که پیش‌تر در این مجموعه بحث شد،
-- بین روترهایی که روی این تنظیم توافق ندارند
-- جلوگیری می‌کند

Router# show ip route

O*IA 0.0.0.0/0 [110/2] via 192.168.1.1, GigabitEthernet0/0
O IA 192.168.2.0/24 [110/3] via 192.168.1.1, GigabitEthernet0/0

-- توجه کنید: هیچ مسیر O E2 (خارجی) اصلاً ظاهر
-- نمی‌شود -- فقط مسیر پیش‌فرض تزریق‌شده و
-- مسیرهای بین-ناحیه‌ای معمولی باقی می‌مانند

ناحیه Totally Stubby: مسدودکردن مسیرهای بین-ناحیه نیز

Totally Stubby Area (ناحیه کاملاً stub) اختصاصی سیسکو مفهوم ناحیه stub را فراتر می‌برد، و نه‌تنها LSA های خارجی نوع ۵ بلکه LSA های خلاصه نوع ۳ از نواحی دیگر را نیز مسدود می‌کند -- و فقط یک مسیر پیش‌فرض واحد و مسیرهای محلی و مستقیماً متصل خود ناحیه را باقی می‌گذارد.

-- فقط ABR به کلیدواژه "no-summary" نیاز دارد؛
-- روترهای داخلی همچنان صرفاً "area X stub"
-- استفاده می‌کنند

ABR(config-router)# area 1 stub no-summary

Internal-Router(config-router)# area 1 stub
-- (بدون تغییر از پیکربندی stub معمولی)

Router# show ip route

O*IA 0.0.0.0/0 [110/2] via 192.168.1.1, GigabitEthernet0/0
C    192.168.10.0/24 is directly connected, GigabitEthernet0/1

-- اکنون حتی مسیرها به سایر نواحی درون همان
-- دامنه OSPF کاملاً رفته‌اند -- جایگزین‌شده
-- با مسیر پیش‌فرض واحد، که کوچک‌ترین جدول
-- مسیریابی ممکن برای این ناحیه را نتیجه می‌دهد

از آنجا که پیکربندی ناحیه کاملاً stub اختصاصی سیسکو است، باید فقط در شبکه‌هایی که کاملاً تجهیزات سیسکو را در سراسر آن ناحیه خاص اجرا می‌کنند استفاده شود -- یک محیط چندفروشنده به‌جای آن نیاز به تکیه بر نواحی stub استاندارد داشت.

محدودیت بنیادینی که هر دو نوع Stub به اشتراک می‌گذارند

محدودیت حیاتی: نه یک ناحیه stub و نه یک ناحیه
totally stubby نمی‌تواند شامل یک ASBR
(Autonomous System Boundary Router) باشد --
نوع روتر مسئول توزیع‌مجدد مسیرهای خارجی به
OSPF، که پیش‌تر در این مجموعه بحث شد

این از نظر ساختاری منطقی است: از آنجا که
LSA های خارجی نوع ۵ کاملاً از ورود به این
انواع ناحیه مسدود شده‌اند، یک ASBR که دقیقاً
همان LSA ها را از درون ناحیه تولید می‌کند
هیچ جایی برای واقعاً رفتن آن اطلاعات نداشت

NSSA: بهره‌های Stub با پشتیبانی توزیع‌مجدد محلی

محدودیت در برابر شامل‌شدن یک ASBR به یک مسئله واقعی برای یک سناریوی رایج دنیای واقعی تبدیل می‌شود: یک ناحیه دفتر شعبه که همچنان به بهره‌های جدول مسیریابی کاهش‌یافته یک ناحیه stub نیاز دارد، اما همچنین اتصال اینترنت محلی خودش یا منبع مسیر خارجی دیگری دارد که نیازمند توزیع‌مجدد مستقیماً به آن ناحیه خاص است. NSSA (Not-So-Stubby Area) دقیقاً همین سناریو را حل می‌کند.

ABR-and-ASBR(config-router)# area 1 nssa

Internal-Router(config-router)# area 1 nssa

-- این ناحیه اکنون مانند یک ناحیه stub رفتار
-- می‌کند (مسدود‌کردن مسیرهای خارجی نشأت‌گرفته
-- از جای دیگری در دامنه OSPF) در حالی که
-- همچنان اجازه می‌دهد توزیع‌مجدد محلی از
-- درون این ناحیه خاص رخ دهد

LSA های نوع ۷: مکانیزم خاص NSSA

NSSA این تناقض ظاهری را با استفاده از یک نوع LSA جدید که به‌طور خاص برای این هدف اختراع شده حل می‌کند: مسیرهای توزیع‌مجدد‌شده درون یک NSSA به‌عنوان Type 7 LSAs (LSA های نوع ۷) به‌جای نوع ۵ معمولی حمل می‌شوند، و تا زمانی که ABR آن‌ها را تبدیل کند درون خود NSSA محدود باقی می‌مانند.

انتشار مسیر NSSA واقعاً چگونه کار می‌کند:

۱. یک ASBR درون NSSA یک مسیر خارجی را توزیع‌مجدد
   می‌کند، و یک LSA نوع ۷ تولید می‌کند (به‌جای
   نوع ۵ معمولی)

۲. LSA های نوع ۷ فقط درون خود NSSA سیلاب
   می‌شوند، و هرگز مستقیماً به نواحی دیگر عبور نمی‌کنند

۳. ABR هر LSA نوع ۷ را به یک LSA خارجی نوع ۵
   استاندارد ترجمه می‌کند پیش از تبلیغش به باقی
   دامنه OSPF (معمولاً به ناحیه ستون فقرات)

این گام ترجمه روی ABR مکانیزم کلیدی است که NSSA را کار می‌کند: اجازه می‌دهد مسیرهای خارجی از درون ناحیه‌ای در غیر این صورت شبیه-stub نشأت بگیرند در حالی که همچنان پایگاه‌داده داخلی خود ناحیه را از تعداد بالقوه بزرگ مسیرهای خارجی‌ای که ممکن است در جای دیگری از دامنه OSPF وجود داشته باشند آزاد نگه می‌دارد.

تأیید ترجمه نوع ۷ به نوع ۵

ABR# show ip ospf database nssa-external

            Type-7 AS External Link States (Area 1)

Router# show ip ospf database external

            Type-5 AS External Link States

-- همان مسیر زیربنایی به‌عنوان نوع ۷ درون NSSA
-- ظاهر می‌شود، و به‌عنوان نوع ۵ وقتی توسط ABR
-- ترجمه شده و به باقی دامنه OSPF منتشر شده باشد

مقایسه سه نوع ناحیه تخصصی

ناحیه Stub:
  مسدود می‌کند: نوع ۵ (مسیرهای خارجی)
  اجازه می‌دهد: نوع ۳ (مسیرهای بین-ناحیه‌ای)
  نمی‌تواند شامل یک ASBR باشد

ناحیه Totally Stubby (اختصاصی سیسکو):
  مسدود می‌کند: نوع ۵ و نوع ۳
  اجازه می‌دهد: فقط یک مسیر پیش‌فرض واحد
  نمی‌تواند شامل یک ASBR باشد

NSSA:
  مسدود می‌کند: نوع ۵ از جای دیگری در دامنه
  اجازه می‌دهد: نوع ۳، و مسیرهای خارجی
    نشأت‌گرفته-محلی از طریق نوع ۷ (ترجمه‌شده
    به نوع ۵ در ABR)
  می‌تواند شامل یک ASBR باشد -- این مزیت
    تعریف‌کننده NSSA نسبت به یک ناحیه stub
    ساده است

چرا انتخاب نوع ناحیه درست نیازمند درک مبادلات است

هرکدام از این انواع ناحیه تخصصی همان مسئله زیربنایی را حل می‌کنند -- کاهش اطلاعات مسیریابی غیرضروری در نواحی‌ای که به آن‌ها نیاز ندارند -- اما با قابلیت‌ها و محدودیت‌های به‌تدریج متفاوت. انتخاب درست بین یک ناحیه استاندارد، یک ناحیه stub، یک ناحیه totally stubby، و یک NSSA نیازمند درک نه‌فقط نحو هر پیکربندی، بلکه دقیقاً کدام انواع LSA هر طراحی مسدود یا اجازه می‌دهد، و به‌طور خاص آیا آن ناحیه نیاز دارد توزیع‌مجدد مسیر محلی از طریق ASBR خودش را پشتیبانی کند -- عامل تصمیم‌گیر که NSSA را به‌جای یک ناحیه stub ساده‌تر و محدودکننده‌تر ضروری می‌کند.

نوشته و پژوهش‌شده توسط دکتر شاهین صیامی

مقالات مرتبط

عیب‌یابی سیستماتیک شبکه: یک روش‌شناسی که همه‌چیز را به هم پیوند می‌دهد

هر پروتکل و فناوری‌ای که در سراسر این مجموعه پوشش داده شد فقط زمانی مفید است که یک مسئله شامل آن واقعاً بتواند تحت فشار دنیای واقعی به‌طور کارآمد تشخیص و رفع شود. این مقاله یک روش‌شناسی عیب‌یابی سیستماتیک ساخته‌شده حول لایه‌های OSI ارائه می‌دهد، اعمالش روی یک مسئله اتصال واقع‌بینانه را مرور می‌کند، و نشان می‌دهد دستورات تأیید خاصی که در سراسر این کل مجموعه پوشش داده شدند چگونه در یک فرآیند تشخیصی ساختاریافته جا می‌گیرند.

ادامه

NETCONF، YANG، و پایتون: پیکربندی برنامه‌ای شبکه در مقیاس

REST API ها و فرمت‌های JSON/YAML که پیش‌تر در این مجموعه پوشش داده شدند یک رویکرد به اتوماسیون شبکه را نشان می‌دهند، اما NETCONF و YANG یک جایگزین ساختاریافته‌تر و مبتنی‌بر-استاندارد فراهم می‌کنند که به‌طور خاص برای پیکربندی دستگاه شبکه ساخته شده. این مقاله توضیح می‌دهد چه چیزی NETCONF را از یک REST API ساده متمایز می‌کند، اینکه مدل‌های YANG چگونه دقیقاً تعریف می‌کنند داده پیکربندی چگونه به‌نظر می‌رسد را پوشش می‌دهد، و استفاده از پایتون برای تعامل برنامه‌ای با دستگاه‌های شبکه را مرور می‌کند.

ادامه

اصول IPsec VPN: امن‌سازی ترافیک در سراسر شبکه‌های نامورد‌اعتماد

اتصال دو سایت در سراسر اینترنت عمومی ترافیک را در معرض رهگیری قرار می‌دهد مگر اینکه به‌درستی رمزگذاری شود، و IPsec چارچوب استانداردی برای ساخت تونل‌های امن و احراز‌هویت‌شده بین سایت‌ها فراهم می‌کند. این مقاله فرآیند مذاکره دومرحله‌ای IKE را توضیح می‌دهد، تمایز بین پروتکل‌های AH و ESP را پوشش می‌دهد، پیکربندی یک VPN سایت-به-سایت پایه IPsec را مرور می‌کند، و دستورات تأیید ضروری را پوشش می‌دهد.

ادامه

اصول MPLS: توضیح سوئیچینگ برچسب

مسیریابی IP سنتی نیازمند این است که هر روتر در طول یک مسیر یک جستجوی کامل جدول مسیریابی روی هر بسته انجام دهد، اما MPLS رویکردی اساساً متفاوت را با گرفتن آن تصمیم فوروارد‌کردن یک‌بار و متصل‌کردن یک برچسب ساده که هر روتر بعدی می‌تواند به‌جای آن استفاده کند اتخاذ می‌کند. این مقاله مفهوم اصلی سوئیچینگ-برچسب را توضیح می‌دهد، اینکه پروتکل توزیع برچسب چگونه جداول فوروارد‌کردن برچسبی که این را ممکن می‌کنند می‌سازد را مرور می‌کند، و بهره‌های عملی‌ای که MPLS در شبکه‌های ارائه‌دهنده واقعی فراهم می‌کند را پوشش می‌دهد.

ادامه

Route Reflector و Confederation های BGP: مقیاس‌دهی iBGP فراتر از Full Mesh

نیازمندی full-mesh iBGP، که به‌طور مختصر پیش‌تر در این مجموعه ذکر شد، با رشد یک سیستم خودمختار به یک مسئله جدی مقیاس‌دهی تبدیل می‌شود، که نیازمند تعدادی جلسه است که به‌طور درجه‌دوم با تعداد روتر افزایش می‌یابد. این مقاله دقیقاً توضیح می‌دهد چرا full mesh مقیاس‌پذیر نیست، اینکه route reflector ها چگونه این را با شل‌کردن قوانین معمول انتشار-مسیر BGP حل می‌کنند مرور می‌کند، و confederation ها را به‌عنوان یک رویکرد جایگزین که یک AS واحد را به سیستم‌های خودمختار زیرمجموعه کوچک‌تر تقسیم می‌کند پوشش می‌دهد.

ادامه

دستکاری مسیر BGP: Route Map ها و Community ها برای مهندسی ترافیک

الگوریتم انتخاب بهترین-مسیر پایه BGP، که پیش‌تر در این مجموعه پوشش داده شد، از یک توالی ثابت از ویژگی‌ها پیروی می‌کند، اما شبکه‌های واقعی نیاز دارند به‌طور فعال روی اینکه کدام مسیر انتخاب می‌شود تأثیر بگذارند به‌جای پذیرش منفعلانه نتیجه پیش‌فرض. این مقاله توضیح می‌دهد route map ها چگونه اطلاعات مسیریابی BGP را فیلتر و تغییر می‌دهند، Local Preference و MED را به‌عنوان دو اهرم اصلی برای تأثیرگذاری روی انتخاب مسیر پوشش می‌دهد، و community های BGP را به‌عنوان یک مکانیزم تگ‌گذاری انعطاف‌پذیر برای هماهنگی سیاست در سراسر کل شبکه معرفی می‌کند.

ادامه