لب عملی: پیکربندی مسیریابی مالتی‌کست PIM در حالت Sparse

این لب عملی PIM Sparse Mode را در سراسر سه روتر با یک Rendezvous Point تعیین‌شده پیکربندی می‌کند، تأیید می‌کند join IGMP یک گیرنده یک درخت مشترک به RP می‌سازد، و ترافیک از یک منبع را که از طریق فوروارد‌کردن مبتنی‌بر-RP به گیرنده می‌رسد تأیید می‌کند.

پیکربندی PIM Sparse ModeRendezvous Pointتأیید Join در IGMP

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

هدف لب

پیکربندی PIM Sparse Mode روی سه روتر، تعیین یکی به‌عنوان Rendezvous Point، تأیید اینکه join IGMP یک گیرنده یک درخت مشترک به RP می‌سازد، و تأیید اینکه ترافیک مالتی‌کست از یک منبع از طریق فوروارد‌کردن مبتنی‌بر-RP به گیرنده می‌رسد.

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

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

توپولوژی لب

منبع ---- R1 ---- R2 (RP) ---- R3 ---- گیرنده

گروه مالتی‌کست: 239.1.1.1
Loopback0 R2: 2.2.2.2/32 (استفاده‌شده به‌عنوان
آدرس RP)

وظیفه ۱: فعال‌کردن PIM Sparse Mode روی هر اینترفیس مرتبط

مسیریابی مالتی‌کست IP را به‌طور سراسری و PIM sparse-mode را روی هر اینترفیس در طول مسیر فعال کن.

وظیفه ۲: تعیین R2 به‌عنوان Rendezvous Point

هر سه روتر را طوری پیکربندی کن که آدرس loopback R2 را به‌عنوان RP ایستا برای بازه گروه مالتی‌کست استفاده کنند.

وظیفه ۳: پیکربندی گیرنده برای پیوستن به گروه

اینترفیس R3 رو‌به‌سمت گیرنده را طوری پیکربندی کن که به‌طور ایستا به گروه مالتی‌کست بپیوندد، و یک join IGMP را شبیه‌سازی کن.

وظیفه ۴: تأیید شکل‌گیری درخت مشترک به‌سمت RP

تأیید کن R3 یک ورودی (*, G) که به‌سمت RP اشاره می‌کند پیش از اینکه هر ترافیک منبعی حتی فرستاده شده باشد نشان می‌دهد.

وظیفه ۵: فرستادن ترافیک مالتی‌کست و تأیید تحویل

ترافیک از منبع به‌سمت گروه تولید کن و تأیید کن به گیرنده می‌رسد.

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

R1(config)# ip multicast-routing
R1(config)# interface gigabitethernet0/0
R1(config-if)# ip pim sparse-mode
R1(config-if)# exit
R1(config)# interface gigabitethernet0/1
R1(config-if)# ip pim sparse-mode

R2(config)# ip multicast-routing
R2(config)# interface gigabitethernet0/0
R2(config-if)# ip pim sparse-mode
R2(config-if)# exit
R2(config)# interface gigabitethernet0/1
R2(config-if)# ip pim sparse-mode
R2(config-if)# exit
R2(config)# interface loopback0
R2(config-if)# ip pim sparse-mode

R3(config)# ip multicast-routing
R3(config)# interface gigabitethernet0/0
R3(config-if)# ip pim sparse-mode
R3(config-if)# exit
R3(config)# interface gigabitethernet0/1
R3(config-if)# ip pim sparse-mode

R1(config)# ip pim rp-address 2.2.2.2
R2(config)# ip pim rp-address 2.2.2.2
R3(config)# ip pim rp-address 2.2.2.2

-- هر سه روتر باید روی همان آدرس RP ایستا
-- توافق داشته باشند -- یک عدم‌تطابق اینجا
-- یعنی روترهای متفاوت درخت‌هایی به‌سمت نقاط
-- rendezvous متفاوت و ناسازگار می‌سازند

R3(config)# interface gigabitethernet0/1
R3(config-if)# ip igmp join-group 239.1.1.1

-- شبیه‌سازی ایستای join IGMP یک گیرنده برای
-- اهداف لب، به‌جای یک کلاینت مالتی‌کست واقعی
-- که یک گزارش عضویت IGMP واقعی می‌فرستد

R3# show ip mroute 239.1.1.1

(*, 239.1.1.1), uptime 00:01:15
  Incoming interface: GigabitEthernet0/0,
    RPF nbr 10.2.2.2
  Outgoing interface list:
    GigabitEthernet0/1, Forward
-- ورودی درخت-مشترک (*, G) از‌قبل وجود دارد،
-- و از طریق اینترفیس ورودی به‌سمت RP اشاره
-- می‌کند -- ساخته‌شده صرفاً از join گیرنده،
-- پیش از اینکه هر ترافیک منبع واقعی جریان یافته باشد

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

R1# show ip mroute 239.1.1.1

(Source-IP, 239.1.1.1), uptime 00:00:05
  Incoming interface: GigabitEthernet0/0
  Outgoing interface list:
    GigabitEthernet0/1, Forward
-- یک ورودی خاص-منبع (S, G) اکنون روی R1 وجود
-- دارد، و تأیید می‌کند ترافیک به‌طور فعال از
-- منبع به‌سمت RP و جلوتر به‌سمت گیرنده فوروارد
-- می‌شود

گیرنده> [جریان مالتی‌کست را دریافت می‌کند]

-- تأیید‌شده: ترافیک از منبع با موفقیت به
-- گیرنده می‌رسد، و از منبع -> R1 -> R2 (RP)
-- -> R3 -> گیرنده سفر می‌کند

نکته کلیدی

ورودی (*, G) درخت مشترک ریشه‌شده در RP را نمایندگی می‌کند، که در لحظه‌ای که یک گیرنده می‌پیوندد ساخته می‌شود صرف‌نظر از اینکه یک منبع حتی هنوز فعال است یا نه، در حالی که ورودی (S, G) ترافیک خاص-منبع واقعاً در حال جریان را نمایندگی می‌کند — دیدن یک ورودی (*, G) بدون (S, G) متناظر تأیید می‌کند یک گیرنده علاقه‌مندی‌اش را ابراز کرده اما هیچ ترافیکی نرسیده، تمایزی مفید هنگام عیب‌یابی اینکه آیا یک مسئله مالتی‌کست در سیگنالینگ گیرنده است یا در تحویل ترافیک واقعی منبع.

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

مقالات مرتبط

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

ادامه