لب عملی: گذار به Shortest-Path Tree در PIM Sparse Mode

این لب عملی گذار خودکار روتر آخرین-گام یک گیرنده از درخت مشترک ریشه‌شده-در-RP به یک shortest-path tree مستقیم به‌سمت منبع را یک‌بار که حجم ترافیک از آستانه پیش‌فرض عبور کند مشاهده می‌کند، و تأیید می‌کند هر دو نوع درخت در مراحل مختلف در جدول مسیریابی مالتی‌کست ظاهر می‌شوند.

گذار به Shortest-Path Treeآستانه SPTرفتار روتر آخرین-گام

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

هدف لب

مشاهده رفتار پیش‌فرض گذار SPT روی R3 (روتر آخرین-گام از لب قبلی)، و تأیید اینکه در ابتدا ترافیک را از طریق درخت مشترک از میان RP فوروارد می‌کند، سپس به‌طور خودکار به یک shortest-path tree مستقیم به‌سمت منبع یک‌بار که آستانه پیش‌فرض SPT فراتر رود گذار می‌کند.

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

لب قبلی فوروارد‌کردن درخت-مشترک پایه از میان RP را برقرار کرد. در استقرارهای واقعی، مسیریابی همه ترافیک از میان RP برای همیشه اغلب غیربهینه است اگر RP روی مستقیم‌ترین مسیر بین منبع و گیرنده نباشد — رفتار پیش‌فرض PIM Sparse Mode این را به‌طور خودکار با تغییر روتر آخرین-گام به یک مسیر مستقیم یک‌بار که حجم ترافیک تغییر را توجیه کند بهینه می‌کند.

توپولوژی لب

همان توپولوژی لب قبلی:
منبع ---- R1 ---- R2 (RP) ---- R3 ---- گیرنده

آستانه پیش‌فرض SPT روی Cisco IOS 0 kbps است،
به این معنا که گذار تقریباً بلافاصله روی
اولین بسته در بسیاری پیاده‌سازی‌ها رخ می‌دهد --
این لب مکانیزم را صراحتاً نشان می‌دهد

وظیفه ۱: تأیید حالت اولیه فوروارد‌کردن درخت-مشترک

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

وظیفه ۲: تأیید رخداد گذار SPT

پس از اینکه ترافیک برای مدت کوتاهی جریان یافته، جدول mroute R3 را دوباره برای یک ورودی خاص-منبع جدید که نشان‌دهنده ساخته‌شدن یک مسیر مستقیم است بررسی کن.

وظیفه ۳: مقایسه اینترفیس RPF پیش و پس از گذار

تأیید کن اینترفیس RPF (Reverse Path Forwarding) برای ورودی خاص-منبع با اینترفیس ورودی ورودی درخت-مشترک متفاوت است، اگر مسیر مستقیم از مسیر RP متفاوت باشد.

وظیفه ۴: تأیید باقی‌ماندن ورودی درخت مشترک در کنار ورودی جدید SPT

تأیید کن ورودی اصلی (*, G) حتی پس از گذار حاضر باقی می‌ماند، همچنان برای اهداف سیگنالینگ استفاده می‌شود.

وظیفه ۵: درک فلگ نشان‌دهنده وضعیت SPT

فلگ‌های روی ورودی‌های mroute که به‌طور خاص حالت مرتبط-با-SPT را نشان می‌دهند بررسی کن.

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

منبع> [شروع به فرستادن ترافیک مالتی‌کست به
         239.1.1.1 می‌کند]

-- بلافاصله پس از شروع ترافیک:

R3# show ip mroute 239.1.1.1

(*, 239.1.1.1), uptime 00:05:20, RP is 2.2.2.2
  Incoming interface: GigabitEthernet0/0
  Outgoing interface list:
    GigabitEthernet0/1, Forward

(Source-IP, 239.1.1.1), uptime 00:00:02
  Incoming interface: GigabitEthernet0/0
  Outgoing interface list:
    GigabitEthernet0/1, Forward
-- هر دو ورودی از‌قبل حاضرند -- چون منبع و RP
-- اتفاقاً از طریق همان اینترفیس در این
-- توپولوژی رسیده می‌شوند، گذار هنوز از خود
-- اینترفیس به‌طور بصری واضح نیست

R3# show ip mroute 239.1.1.1 | include Flags

(*, 239.1.1.1), ..., flags: SJC
(Source-IP, 239.1.1.1), ..., flags: SJT
-- فلگ "T" روی ورودی (S, G) به‌طور خاص نشان
-- می‌دهد این ورودی از Shortest-Path Tree
-- استفاده می‌کند -- غیبتش روی ورودی (*, G)
-- تأیید می‌کند آن یکی همچنان ورودی درخت-مشترک
-- باقی می‌ماند

R1# show ip mroute 239.1.1.1

(Source-IP, 239.1.1.1), uptime 00:00:03, flags: FT
  Incoming interface: GigabitEthernet0/0
  Outgoing interface list:
    GigabitEthernet0/1, Forward
-- R1 نیز فلگ "T" را نشان می‌دهد، و تأیید
-- می‌کند فوروارد‌کردن SPT در طول مسیر
-- نزدیک‌ترین به منبع نیز فعال است

R3# show ip mroute 239.1.1.1

(*, 239.1.1.1), uptime 00:10:45, RP is 2.2.2.2
  Incoming interface: GigabitEthernet0/0
  Outgoing interface list:
    GigabitEthernet0/1, Forward

(Source-IP, 239.1.1.1), uptime 00:05:27, flags: JT
  Incoming interface: GigabitEthernet0/0
  Outgoing interface list:
    GigabitEthernet0/1, Forward
-- ورودی درخت-مشترک (*, G) همچنان مدتی طولانی
-- پس از گذار حاضر است -- برای اهداف سیگنالینگ
-- باقی می‌ماند (یک گیرنده جدید که می‌پیوندد
-- همچنان به آن نیاز خواهد داشت)، در حالی که
-- ورودی (S, G) اکنون به‌طور فعال ترافیک واقعی
-- را از طریق SPT حمل می‌کند

نکته کلیدی

فلگ "T" روی یک ورودی mroute (S, G) شاخص قطعی این است که ترافیک برای آن منبع اکنون از طریق Shortest-Path Tree به‌جای درخت مشترک ریشه‌شده-در-RP فوروارد می‌شود — این گذار به‌طور خودکار و به‌طور پیش‌فرض روی Cisco IOS رخ می‌دهد، و ماندگاری ورودی (*, G) پس از آن یک آرتیفکت باقی‌مانده نیست بلکه بخش عمدی طراحی است، چون همچنان به هر گیرنده آینده‌ای که به گروه از طریق درخت مشترک می‌پیوندد پیش از بالقوه فعال‌کردن گذار SPT خودش خدمت می‌کند.

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

مقالات مرتبط

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

ادامه