هدف لب
پیکربندی یک روتر شعبه به‌عنوان یک 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 بی‌سروصدا اطلاعات مسیریابی معتبر را در طول همگرایی از دست بدهد.