لب عملی: جلوگیری از حلقه‌های مسیریابی توزیع‌مجدد

این لب عملی توپولوژی توزیع‌مجدد متقابل لب قبلی را با یک روتر مرزی دوم گسترش می‌دهد، یک حلقه مسیریابی یا مسیر غیربهینه ایجادشده وقتی هر دو روتر مرزی متقابلاً بدون هماهنگی توزیع‌مجدد می‌کنند را نشان می‌دهد، سپس آن را با استفاده از distribute list ها و تگ‌های مسیر رفع می‌کند.

حلقه مسیریابی توزیع‌مجددتگ‌گذاری مسیرجلوگیری از حلقه با Distribute-List

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

هدف لب

افزودن یک روتر مرزی دوم به توپولوژی لب قبلی، مشاهده یک حلقه مسیریابی یا مسیر غیربهینه شکل‌گرفته وقتی هر دو روتر مرزی متقابلاً بدون هماهنگی توزیع‌مجدد می‌کنند، سپس اعمال تگ‌گذاری مسیر و distribute list ها برای جلوگیری از توزیع‌مجدد یک مسیر بازگشتی به پروتکلی که از آن نشأت گرفته.

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

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

توپولوژی لب

دامنه OSPF -- R2 (مرزی ۱) -- دامنه EIGRP
     |                                  |
     +-------- R4 (مرزی ۲) ---------+

هم R2 و هم R4 توزیع‌مجدد متقابل بین OSPF و
EIGRP انجام می‌دهند، و دو مسیر بین دامنه‌ها
ایجاد می‌کنند

وظیفه ۱: پیکربندی R4 به‌عنوان یک نقطه توزیع‌مجدد متقابل دوم

R4 را با همان توزیع‌مجدد متقابل R2 از لب قبلی، بدون هیچ جلوگیری از حلقه هنوز، پیکربندی کن.

وظیفه ۲: مشاهده رفتار مسیریابی حاصل

جدول‌های مسیریابی را برای نشانه‌های انتخاب مسیر غیربهینه یا نوسان مسیر ناشی از حلقه توزیع‌مجدد بررسی کن.

وظیفه ۳: اعمال تگ‌های مسیر در طول توزیع‌مجدد

هم R2 و هم R4 را طوری پیکربندی کن که مسیرها را همان‌طور که از OSPF به EIGRP، و از EIGRP به OSPF توزیع‌مجدد می‌شوند تگ‌گذاری کنند.

وظیفه ۴: پیکربندی یک Distribute List که تگ را تطبیق می‌دهد

روی هر روتر مرزی، یک route-map که توزیع‌مجدد مسیرهای حامل تگ نشان‌دهنده نشأت‌گرفتنشان از پروتکل دیگر را رد می‌کند پیکربندی کن.

وظیفه ۵: تأیید رفع‌شدن حلقه

تأیید کن مسیرها دیگر به پروتکل اصلی‌شان توزیع‌مجدد نمی‌شوند، و اینکه انتخاب مسیر پایدار می‌شود.

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

R4(config)# router ospf 1
R4(config-router)# redistribute eigrp 100 metric-type 1 subnets
R4(config)# router eigrp 100
R4(config-router)# redistribute ospf 1 metric 10000 100 255 1 1500

-- توزیع‌مجدد متقابل یکسان با R2، و ایجاد یک
-- مسیر دوم بین دامنه‌ها -- بدون هماهنگی بین
-- دو روتر مرزی هنوز

R1# show ip route 192.168.40.0

O E1  192.168.40.0/24 [110/20] via 10.1.1.2
                       [110/20] via 10.1.1.4
-- اکنون دو مسیر برای رسیدن به LAN R3 وجود
-- دارد -- یکی از هر روتر مرزی -- و در
-- توپولوژی‌های پیچیده‌تر دقیقاً همین الگو
-- می‌تواند باعث شود مسیرها به‌طور مکرر بین
-- OSPF و EIGRP جهش کنند همان‌طور که هر روتر
-- مرزی دوباره چیزی که تازه از دیگری یاد گرفته
-- را تبلیغ می‌کند

R2(config)# route-map TAG-FROM-OSPF permit 10
R2(config-route-map)# set tag 100
R2(config)# router ospf 1
R2(config-router)# redistribute eigrp 100 metric-type 1 subnets route-map TAG-FROM-OSPF

-- صبر کن -- تگ‌گذاری روی توزیع‌مجدد به داخل
-- یک پروتکل رخ می‌دهد، و علامت می‌زند مسیر از
-- کجا آمده، پس می‌تواند شناسایی و مستثنی شود
-- وقتی به بیرون از آن پروتکل در جای دیگری از
-- توپولوژی توزیع‌مجدد می‌شود

R2(config)# route-map TAG-FROM-EIGRP permit 10
R2(config-route-map)# set tag 200
R2(config)# router eigrp 100
R2(config-router)# redistribute ospf 1 metric 10000 100 255 1 1500 route-map TAG-FROM-EIGRP

R4 به‌طور یکسان با همان مقادیر تگ (100 برای
نشأت‌گرفته-از-OSPF، 200 برای نشأت‌گرفته-از-
EIGRP) پیکربندی شد

R2(config)# route-map BLOCK-EIGRP-TAG deny 10
R2(config-route-map)# match tag 200
R2(config)# route-map BLOCK-EIGRP-TAG permit 20
R2(config)# router ospf 1
R2(config-router)# redistribute eigrp 100 metric-type 1 subnets route-map BLOCK-EIGRP-TAG

-- این توزیع‌مجدد به داخل OSPF هر مسیری که
-- از‌قبل تگ 200 دارد (به‌معنای اینکه در OSPF
-- نشأت گرفته، به EIGRP از طریق روتر مرزی
-- دیگر رفته، و در غیر این صورت اینجا دوباره
-- به OSPF حلقه می‌زد) را رد می‌کند

R2(config)# route-map BLOCK-OSPF-TAG deny 10
R2(config-route-map)# match tag 100
R2(config-route-map)# permit 20
R2(config)# router eigrp 100
R2(config-router)# redistribute ospf 1 metric 10000 100 255 1 1500 route-map BLOCK-OSPF-TAG

-- R4 با عبارات deny تطبیق-تگ معادل پیکربندی شد

R1# show ip route 192.168.40.0

O E1  192.168.40.0/24 [110/20] via 10.1.1.2
-- فقط یک مسیر باقی می‌ماند، چون مسیر تگ‌شده
-- اکنون به‌درستی از دوباره-معرفی‌شدن از طریق
-- روتر مرزی دوم مستثنی است

نکته کلیدی

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

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

مقالات مرتبط

لب عملی: پیکربندی مسیریابی Stub در EIGRP

این لب عملی یک روتر شعبه را به‌عنوان یک stub در EIGRP پیکربندی می‌کند، و تأیید می‌کند فقط مسیرهای متصل و خلاصه خودش را تبلیغ می‌کند در حالی که روتر hub به‌درستی از پرس‌وجوکردن stub در طول یک تغییر توپولوژی در جای دیگری از شبکه اجتناب می‌کند.

ادامه

لب عملی: پیکربندی حالت Named در EIGRP

این لب عملی یک پیکربندی EIGRP کلاسیک موجود را به حالت named EIGRP بازپیکربندی می‌کند، و عبارات network و پیکربندی خاص-اینترفیس را در یک سلسله‌مراتب address-family ساختاریافته‌تر سازمان‌دهی می‌کند، و تعادل عملکردی با سبک پیکربندی کلاسیک استفاده‌شده در سراسر لب‌های EIGRP قبلی این مجموعه را تأیید می‌کند.

ادامه

لب عملی: پیکربندی ERSPAN در سراسر یک شبکه مسیریابی‌شده

این لب عملی Encapsulated RSPAN (ERSPAN) را برای آینه‌کردن ترافیک در سراسر یک شبکه مسیریابی‌شده-لایه-۳ به‌جای یک ترانک لایه ۲ واحد پیکربندی می‌کند، و مفهوم RSPAN از لب قبلی را فراتر از مرزهای یک VLAN یا دامنه سوئیچ‌شده واحد گسترش می‌دهد.

ادامه

لب عملی: پیکربندی RSPAN در سراسر سوئیچ‌ها

این لب عملی Remote SPAN (RSPAN) را با استفاده از یک VLAN RSPAN اختصاصی حمل‌شده در سراسر یک ترانک پیکربندی می‌کند، و اجازه می‌دهد ترافیک آینه‌شده روی یک سوئیچ توسط یک دستگاه گرفتن متصل به یک سوئیچ کاملاً متفاوت نظارت شود، و مفهوم SPAN محلی پوشش‌داده‌شده در یک لب قبلی را در سراسر شبکه گسترش می‌دهد.

ادامه

لب عملی: پیکربندی In-Service Software Upgrade (ISSU) روی یک Stack

این لب عملی یک In-Service Software Upgrade را در سراسر یک stack StackWise انجام می‌دهد، و ایمیج IOS هر عضو را یکی‌یکی ارتقا می‌دهد در حالی که stack در سراسر آن به فوروارد‌کردن ترافیک ادامه می‌دهد، و صفر خرابی را در مقایسه با رویکرد مخل reload استفاده‌شده در لب‌های ارتقای IOS قبلی تأیید می‌کند.

ادامه

لب عملی: پیکربندی Stacking سنتی StackWise در Catalyst

این لب عملی stacking سنتی Catalyst (StackWise) را در سراسر سه سوئیچ با استفاده از کابل‌های stack پیکربندی می‌کند، و نیازمندی تک-لایه و مجاورت فیزیکی‌اش را با جفت StackWise Virtual پوشش‌داده‌شده در لب قبلی که اجازه می‌دهد سوئیچ‌ها بسیار دورتر از هم قرار بگیرند مقایسه می‌کند.

ادامه