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

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

پیکربندی روتر Stub در EIGRPمحدودسازی محدوده Queryمحدودیت‌های مسیر Stub

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

هدف لب

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

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

در یک توپولوژی hub-and-spoke EIGRP با بسیاری روتر شعبه، یک تغییر توپولوژی واحد روی hub می‌تواند پرس‌وجوهای EIGRP را به هر spoke گسترش دهد، که هرکدام باید پیش از تکمیل محاسبه DUAL hub پاسخ دهند — یک فرآیند آهسته در مقیاس. مسیریابی stub در EIGRP صراحتاً به hub می‌گوید روترهای شعبه خاصی را پرس‌وجو نکند، چون هیچ مسیر جایگزینی برای ارائه ندارند، و محدوده پرس‌وجو را به‌طور چشمگیر کاهش می‌دهد.

توپولوژی لب

Hub ---- R1 (شعبه، برای پیکربندی به‌عنوان stub)
Hub ---- R2 (شعبه دیگر، stub نیست، یک
             پرس‌وجو فعال خواهد کرد)

LAN R1: 192.168.50.0/24
Hub همچنین به یک روتر سوم R3 متصل می‌شود که
شکست لینکش پرس‌وجوی آزمایشی این لب را فعال
می‌کند

وظیفه ۱: پیکربندی R1 به‌عنوان یک Stub در EIGRP

R1 را به‌عنوان یک stub در EIGRP که فقط مسیرهای متصل را تبلیغ می‌کند پیکربندی کن.

وظیفه ۲: تأیید شناسایی R1 به‌عنوان یک Stub توسط Hub

تأیید کن جدول همسایه hub R1 را به‌عنوان یک روتر stub پرچم‌گذاری‌شده نشان می‌دهد.

وظیفه ۳: تأیید محدودشدن مسیرهای تبلیغ‌شده R1

تأیید کن R1 فقط LAN متصل خودش را تبلیغ می‌کند، نه هر مسیری که ممکن است از جای دیگری یاد گرفته باشد.

وظیفه ۴: فعال‌کردن یک تغییر توپولوژی در جای دیگری از شبکه

یک شکست لینک روی اتصال R3 به hub را شبیه‌سازی کن، رویدادی که معمولاً پرس‌وجوهای EIGRP را فعال می‌کرد.

وظیفه ۵: تأیید مستثنی‌بودن R1 از فرآیند Query

تأیید کن خروجی debug روی hub نشان می‌دهد R1 هرگز به‌عنوان بخشی از محاسبه‌مجدد مسیر تحت‌تأثیر پرس‌وجو نشد.

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

R1(config)# router eigrp 100
R1(config-router)# eigrp stub connected

-- "connected" R1 را به تبلیغ فقط شبکه‌های
-- مستقیماً-متصل خودش محدود می‌کند -- سایر
-- انواع stub (static، summary، receive-only)
-- برای محدودیت‌های تبلیغ متفاوت وجود دارند،
-- اما connected رایج‌ترین برای یک سناریوی
-- دفتر-شعبه ساده است

Hub# show ip eigrp neighbors detail

EIGRP-IPv4 Neighbors for AS(100)
H   Address         Interface   Hold Uptime
0   10.1.1.2        Se0/0/0      12  00:02:15
   Version 20.0/3.0, Retrans: 0, Retries: 0
   Stub Peer Advertising ( CONNECTED )Routes
-- hub صراحتاً R1 را به‌عنوان تبلیغ‌کننده فقط
-- مسیرهای متصل شناسایی می‌کند، اطلاعاتی
-- یادگرفته‌شده در طول خود دست‌دهی اولیه همسایه

Hub# show ip route eigrp | include 192.168.50

D    192.168.50.0/24 [90/2681856] via 10.1.1.2, Serial0/0/0
-- LAN متصل R1 همچنان به‌طور معمول تبلیغ و
-- یادگرفته می‌شود -- stub محدود می‌کند کدام
-- مسیرهایی که R1 از سایر منابع جلوتر فوروارد
-- می‌کند، نه شبکه‌های مستقیماً-متصل خودش

Hub# debug eigrp fsm

R3(config)# interface serial0/0/1
R3(config-if)# shutdown

-- (شبیه‌سازی شکست لینک R3، که معمولاً باعث
--  می‌شد hub همسایگان را برای یک مسیر جایگزین
--  به هرچیزی که R3 تبلیغ می‌کرد پرس‌وجو کند)

Hub# show ip eigrp topology active

-- (بررسی اینکه آیا هیچ مسیری وارد حالت
--  active/query شد)

*Jun 25 14:22:01.204: DUAL: Find FS for
dest 192.168.60.0/24. FD is 2681856, RD
is 2681856
*Jun 25 14:22:01.208: DUAL: Peer 10.2.2.2:
metric 4294967295 not FS. Old FD: 2681856
*Jun 25 14:22:01.210: DUAL: New topology
entry for 192.168.60.0/24
*Jun 25 14:22:01.212: DUAL: RT installed
192.168.60.0/24 via 10.3.3.2

-- توجه کنید فرآیند query، و پیام‌های debug
-- مرتبطش، فقط آدرس R2 (10.2.2.2) و R3 را
-- درگیر می‌کنند -- 10.1.1.2 (R1، stub) هرگز
-- در هیچ‌کجای این تبادل ظاهر نمی‌شود، و تأیید
-- می‌کند به‌درستی کاملاً از گسترش پرس‌وجو
-- مستثنی شد

نکته کلیدی

پیکربندی یک روتر شعبه به‌عنوان یک stub در EIGRP یک بهینه‌سازی محدوده-query است که روی یک اعلام صادقانه ساخته شده: شعبه به hub می‌گوید "من هیچ مسیر جایگزینی برای ارائه ندارم، پس هرگز در طول یک query زحمت پرسیدن از من را نکش" — این دقیقاً چرایی این است که روترهای stub باید فقط هرگز روی شعبه‌های بن‌بست مشروع و بدون نقش ترانزیت پیکربندی شوند، چون اعمالش روی یک روتر که واقعاً مسیرهای جایگزین دارد باعث می‌شود hub بی‌سروصدا اطلاعات مسیریابی معتبر را در طول همگرایی از دست بدهد.

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

مقالات مرتبط

لب عملی: پیکربندی حالت 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 پوشش‌داده‌شده در لب قبلی که اجازه می‌دهد سوئیچ‌ها بسیار دورتر از هم قرار بگیرند مقایسه می‌کند.

ادامه

لب عملی: پیکربندی StackWise Virtual

این لب عملی دو سوئیچ فیزیکی را با استفاده از یک Stackwise Virtual Link اختصاصی به یک سوئیچ منطقی StackWise Virtual واحد پیکربندی می‌کند، و تأیید می‌کند هر دو عضو به‌عنوان یک صفحه کنترل واحد ارائه می‌شوند و شکست یک عضو رفتار failover قابل‌پیش‌بینی فعال می‌کند.

ادامه