لب عملی: پیکربندی یک ناحیه NSSA در OSPF

این لب عملی ناحیه ۱ را به‌عنوان یک NSSA پیکربندی می‌کند، یک مسیر خارجی محلی را مستقیماً از درون آن ناحیه توزیع‌مجدد می‌کند و تأیید می‌کند به‌عنوان یک LSA نوع ۷ پیش از ترجمه‌شدن به نوع ۵ در ABR منتشر می‌شود، در حالی که مسیرهای بین-ناحیه‌ای از جای دیگری دقیقاً مانند یک ناحیه stub استاندارد مسدود باقی می‌مانند.

پیکربندی NSSA در OSPFترجمه نوع ۷ به نوع ۵ASBR درون یک ناحیه شبیه-Stub

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

هدف لب

پیکربندی ناحیه ۱ به‌عنوان یک NSSA، توزیع‌مجدد یک مسیر ایستا مستقیماً روی روتر درون آن ناحیه (که آن را یک ASBR می‌کند)، تأیید اینکه LSA نوع ۷ حاصل درون NSSA محدود باقی می‌ماند، و تأیید اینکه ABR آن را به نوع ۵ پیش از تبلیغش به ستون‌فقرات ترجمه می‌کند.

هدف لب (چرا مهم است)

لب قبلی نشان داد یک ناحیه stub استاندارد اصلاً نمی‌تواند شامل یک ASBR باشد. این لب نشان می‌دهد NSSA دقیقاً همان محدودیت را حل می‌کند، و اجازه می‌دهد خود R1 یک مسیر محلی را توزیع‌مجدد کند در حالی که ناحیه ۱ همچنان از بهره‌های جدول مسیریابی کاهش‌یافته یک ناحیه شبیه-stub بهره می‌برد.

توپولوژی لب

R1 (ناحیه ۱، برگ، تبدیل می‌شود به یک ASBR)
  ---- R2 (ABR) ---- R3 (ناحیه ۰، ستون‌فقرات)

R1 یک شبکه با اهمیت-محلی برای توزیع‌مجدد دارد:
198.51.100.0/24 (شبیه‌سازی یک اتصال اینترنت
محلی یا منبع مسیر خارجی دیگر)

وظیفه ۱: پیکربندی ناحیه ۱ به‌عنوان یک NSSA

ناحیه ۱ را به‌عنوان یک NSSA روی هم R1 و هم R2 پیکربندی کن، و هر پیکربندی stub قبلی را جایگزین کن.

وظیفه ۲: توزیع‌مجدد یک مسیر محلی روی R1

یک مسیر ایستا به یک شبکه ساختگی روی R1 پیکربندی کن، سپس آن را به OSPF توزیع‌مجدد کن، و R1 را یک ASBR کن.

وظیفه ۳: تأیید ظاهرشدن مسیر به‌عنوان یک LSA نوع ۷ درون ناحیه ۱

پایگاه‌داده OSPF R1 یا R2 را برای نوع LSA خارجی-NSSA بررسی کن.

وظیفه ۴: تأیید دریافت مسیر توسط R3 به‌عنوان یک LSA نوع ۵ ترجمه‌شده

تأیید کن R3، در ناحیه ستون‌فقرات، همان مسیر را می‌بیند اما به‌عنوان یک LSA خارجی نوع ۵ استاندارد.

وظیفه ۵: تأیید همچنان‌مسدودبودن مسیرهای بین-ناحیه‌ای

تأیید کن مسیر خارجی قبلی توزیع‌مجدد‌شده در R3 (از لب قبلی) همچنان به R1 نمی‌رسد، چون NSSA همچنان از ورود LSA های نوع ۵ نشأت‌گرفته-از-خارج به ناحیه جلوگیری می‌کند.

راه‌حل و تأیید

R1(config)# router ospf 1
R1(config-router)# no area 1 stub
R1(config-router)# area 1 nssa

R2(config)# router ospf 1
R2(config-router)# no area 1 stub no-summary
R2(config-router)# area 1 nssa

R1(config)# ip route 198.51.100.0 255.255.255.0 null0
R1(config)# router ospf 1
R1(config-router)# redistribute static subnets

-- R1 اکنون یک ASBR است، چیزی که صراحتاً تحت
-- پیکربندی stub ساده یا totally stubby در
-- لب قبلی ممنوع بود

R2# show ip ospf database nssa-external

            Type-7 AS External Link States (Area 1)

Link ID         ADV Router      Age   Seq#       Checksum
198.51.100.0    1.1.1.1         12    0x80000001 0x00a1c1
-- تأیید می‌کند مسیر به‌عنوان نوع ۷ درون
-- ناحیه ۱ حمل شد، دقیقاً همان‌طور که پیش‌تر
-- در این مجموعه درباره NSSA بحث شد

R3# show ip ospf database external

            Type-5 AS External Link States

Link ID         ADV Router      Age   Seq#       Checksum
198.51.100.0    2.2.2.2         10    0x80000001 0x00b2d2
-- توجه کنید Advertising Router از شناسه R1
-- (1.1.1.1) به شناسه R2 (2.2.2.2) تغییر کرد --
-- R2، ABR، خودش ترجمه نوع ۷ به نوع ۵ را انجام
-- داد، و به منبع تبلیغ‌کننده این مسیر از
-- دیدگاه ستون‌فقرات تبدیل شد

R3# show ip route ospf | include 198.51.100.0

O E2  198.51.100.0/24 [110/20] via 10.2.2.1
-- R3 این را به‌عنوان یک مسیر خارجی معمولی
-- می‌بیند، بی‌خبر از اینکه درون یک NSSA
-- نشأت گرفته

R1# show ip route ospf | include 203.0.113.0

-- (بدون خروجی -- همچنان مسدود، دقیقاً مانند
--  ناحیه stub ساده در لب قبلی، چون NSSA اجازه
--  ورود LSA های نوع ۵ نشأت‌گرفته-از-جای‌دیگری
--  در دامنه را به ناحیه نمی‌دهد، حتی اگر
--  نشأت‌گرفته-محلی را مجاز کند)

نکته کلیدی

رفتار NSSA طبق طراحی نامتقارن است: اجازه می‌دهد یک مسیر نشأت‌گرفته از یک ASBR درون خود NSSA ناحیه را ترک کند (از طریق ترجمه نوع ۷ به نوع ۵ در ABR)، در حالی که همچنان از ورود LSA های نوع ۵ نشأت‌گرفته از جای دیگری در دامنه OSPF جلوگیری می‌کند — این دقیقاً همان ترکیبی است که NSSA را به انتخاب درست نسبت به یک ناحیه stub ساده هروقت یک ناحیه برگ به breakout اینترنت محلی یا سایر توزیع‌مجدد محلی نیاز داشته باشد تبدیل می‌کند.

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

مقالات مرتبط

لب عملی: پیکربندی Storm Control

این لب عملی آستانه‌های storm control را روی یک پورت سوئیچ برای محدودکردن ترافیک پخش و مالتی‌کست پیکربندی می‌کند، یک طوفان پخش را شبیه‌سازی می‌کند، و تأیید می‌کند سوئیچ ترافیک اضافی را پیش از اینکه بتواند شبکه را غرق کند سرکوب می‌کند.

ادامه

لب عملی: پیکربندی PVLAN Edge (پورت‌های Protected)

این لب عملی PVLAN Edge (پورت‌های protected) را روی دو پورت access درون همان VLAN پیکربندی می‌کند، و آن‌ها را از یکدیگر در لایه ۲ ایزوله می‌کند در حالی که هر دو اتصال معمولی به یک پورت آپ‌لینک را حفظ می‌کنند، و یک ویژگی ایزوله‌سازی سبک که هیچ VLAN جداگانه‌ای نیاز ندارد را نشان می‌دهد.

ادامه

لب عملی: پیکربندی Flex Links

این لب عملی Flex Links را بین دو آپ‌لینک روی یک سوئیچ access پیکربندی می‌کند، و failover زیر-ثانیه‌ای بدون تکیه اصلاً به Spanning Tree فراهم می‌کند، و تأیید می‌کند ترافیک به‌طور خودکار وقتی اصلی شکست بخورد به لینک پشتیبان تغییر می‌کند.

ادامه

لب عملی: پیکربندی UDLD

این لب عملی UDLD را در حالت aggressive روی یک لینک فیبر بین دو سوئیچ پیکربندی می‌کند، یک شکست فیبر یک‌طرفه را شبیه‌سازی می‌کند، و تأیید می‌کند UDLD عدم‌تطابق را تشخیص می‌دهد و پورت تحت‌تأثیر را پیش از اینکه یک حلقه لایه ۲ بتواند تشکیل شود خاموش می‌کند.

ادامه

لب عملی: پیکربندی Loop Guard

این لب عملی Loop Guard را روی پورت‌های غیر-designated یک سوئیچ در یک توپولوژی افزونه پیکربندی می‌کند تا از یک شکست لینک یک‌طرفه که باعث یک حلقه لایه ۲ می‌شود جلوگیری کند، و از‌دست‌رفتن یک‌طرفه BPDU را شبیه‌سازی می‌کند و تأیید می‌کند پورت تحت‌تأثیر وارد یک حالت مسدود loop-inconsistent می‌شود به‌جای گذار نادرست به forwarding.

ادامه

لب عملی: پیکربندی BPDU Guard و BPDU Filter

این لب عملی BPDU Guard را به‌طور سراسری برای پورت‌های فعال‌شده-PortFast پیکربندی می‌کند و رفتار متمایز و ریسکی‌تر BPDU Filter را نشان می‌دهد، و مقایسه می‌کند هرکدام چگونه پاسخ می‌دهند وقتی یک سوئیچ به یک پورت access که باید فقط دستگاه‌های کاربر-نهایی را ببیند متصل می‌شود.

ادامه