لب عملی: پیکربندی PIM آگاه-از-HSRP برای افزونگی مالتی‌کست

این لب عملی PIM را در یک محیط HSRP پیکربندی می‌کند، و تأیید می‌کند فوروارد‌کردن مالتی‌کست به‌درستی روتر فعال HSRP را دنبال می‌کند به‌جای اینکه غیرقابل‌پیش‌بینی بین هر دو روتر در جفت افزونگی تقسیم شود.

PIM آگاه-از-NSF در HSRPانتخاب Designated Router مالتی‌کستهم‌راستایی روتر فعال HSRP با مالتی‌کست

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

هدف لب

پیکربندی PIM Sparse Mode روی دو روتر که HSRP را برای همان سگمنت LAN اجرا می‌کنند، تأیید اینکه انتخاب Designated Router خود PIM به‌طور پیش‌فرض با روتر فعال HSRP هم‌راستا می‌شود، و تأیید اینکه ترافیک مالتی‌کست به‌طور سازگار از میان روتر فعال فوروارد می‌شود به‌جای تکرار یا از‌دست‌رفتن به‌دلیل عدم‌توافق بین دو مکانیزم افزونگی.

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

HSRP، به‌طور گسترده پیش‌تر در این مجموعه پوشش داده شد، و PIM هرکدام فرآیند انتخاب مستقل خودشان را روی یک سگمنت مشترک اجرا می‌کنند — HSRP یک روتر فعال برای اهداف دروازه پیش‌فرض یونی‌کست انتخاب می‌کند، در حالی که PIM به‌طور مستقل یک Designated Router (DR) برای فوروارد‌کردن مالتی‌کست انتخاب می‌کند. بدون هم‌راستایی عمدی، این دو انتخاب می‌توانند نامنطبق باشند، و باعث شوند ترافیک مالتی‌کست یک مسیر غیرمنتظره نسبت به ترافیک یونی‌کست روی همان LAN بگیرد.

توپولوژی لب

R1 (HSRP فعال، اولویت بالاتر) ---- Gi0/1 ---- Switch1
R2 (HSRP standby) ---- Gi0/1 ---- Switch1

IP مجازی: 192.168.190.1/24
گیرنده متصل از طریق Switch1، در همان VLAN

PIM sparse-mode روی هر دو Gi0/1 R1 و R2،
به‌علاوه اینترفیس‌های رو‌به‌سمت-WAN‌شان به‌سمت
یک منبع/RP در جای دیگری فعال

وظیفه ۱: تأیید حالت Active/Standby HSRP

تأیید کن R1 HSRP active است و R2 standby است، همان‌طور که در لب HSRP قبلی پیکربندی شد.

وظیفه ۲: تأیید انتخاب DR مستقل PIM روی همان سگمنت

بررسی کن PIM کدام روتر را به‌عنوان Designated Router روی سگمنت مشترک Gi0/1 انتخاب کرد.

وظیفه ۳: تأیید معیار انتخاب DR پیش‌فرض PIM

درک کن انتخاب DR در PIM به‌طور پیش‌فرض بر اساس بالاترین آدرس IP است، کاملاً مستقل از حالت HSRP.

وظیفه ۴: تأیید دنبال‌کردن DR در PIM توسط فوروارد‌کردن مالتی‌کست

ترافیک مالتی‌کست تولید کن و تأیید کن به‌طور خاص توسط DR در PIM روی سگمنت فوروارد می‌شود، و بررسی کن آیا این با روتر فعال HSRP هم‌راستاست یا از آن منحرف می‌شود.

وظیفه ۵: هم‌راستاکردن اولویت DR در PIM با HSRP اگر عدم‌تطابقی وجود دارد

اگر DR در PIM با روتر فعال HSRP متفاوت است، اولویت DR در PIM را روی اینترفیس تنظیم کن تا این دو را هم‌راستا کند.

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

R1# show standby brief

Interface  Grp  Pri P State   Active   Standby   Virtual IP
Gi0/1      1    150 P Active  local    192.168.190.3  192.168.190.1
-- R1 به‌عنوان HSRP active تأیید شد، سازگار
-- با لب HSRP قبلی

R1# show ip pim interface gigabitethernet0/1

Address          Interface   PIM  Nbr    Query   DR
                              Count  Intvl
192.168.190.2    Gi0/1        on    2      30    192.168.190.3
-- DR IP نشان‌داده‌شده 192.168.190.3 است --
-- آدرس اینترفیس واقعی R2، نه R1
-- (192.168.190.2) -- PIM R2 را به‌عنوان DR
-- صرفاً چون آدرس IP خام بالاتری روی این
-- سگمنت دارد انتخاب کرد، کاملاً بی‌خبر از
-- نقش‌های active/standby HSRP

-- این معیار انتخاب پیش‌فرض PIM را تأیید
-- می‌کند: بالاترین آدرس IP DR را می‌برد، بدون
-- ملاحظه هیچ حالت HSRP، اولویت، یا هر نقش
-- فوروارد‌کردن یونی‌کستی

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

R2# show ip mroute 239.1.1.1

(*, 239.1.1.1), ...
  Outgoing interface list:
    GigabitEthernet0/1, Forward
-- R2، DR در PIM (اما HSRP standby)، آن چیزی
-- است که واقعاً ترافیک مالتی‌کست را روی سگمنت
-- مشترک فوروارد می‌کند -- یک ناسازگاری بالقوه
-- ارزش یادداشت‌کردن، هرچند لزوماً شکسته نیست،
-- چون نقش‌های فوروارد‌کردن مالتی‌کست و یونی‌کست
-- از نظر منطقی مستقل‌اند

-- برای هم‌راستاکردن عمدی انتخاب DR در PIM با
-- روتر فعال HSRP (R1)، اولویت DR در PIM R1 را
-- بالاتر از R2 افزایش بده:

R1(config)# interface gigabitethernet0/1
R1(config-if)# ip pim dr-priority 200

R2(config)# interface gigabitethernet0/1
R2(config-if)# ip pim dr-priority 100

R1# show ip pim interface gigabitethernet0/1

Address          Interface   PIM  Nbr    Query   DR
                              Count  Intvl
192.168.190.2    Gi0/1        on    2      30    192.168.190.2
-- R1 (192.168.190.2) اکنون DR در PIM است، و
-- با نقشش به‌عنوان HSRP active تطبیق دارد --
-- dr-priority، وقتی پیکربندی شود، همیشه بر
-- شکست‌مساوی پیش‌فرض بالاترین-IP اولویت دارد

نکته کلیدی

انتخاب DR در PIM و انتخاب active/standby در HSRP به‌طور پیش‌فرض فرآیندهای کاملاً مستقلی هستند، و هیچ‌چیزی به‌طور خودکار آن‌ها را همگام نمی‌کند — یک شبکه‌ای که به هر دو تکیه می‌کند باید عمداً ip pim dr-priority را برای تطبیق با روتر فعال HSRP مورد نظر پیکربندی کند، چون رها‌کردن هر دو در تنظیمات پیش‌فرض می‌تواند منجر شود ترافیک مالتی‌کست یک مسیر غیرمنتظره نسبت به ترافیک یونی‌کست روی همان سگمنت بگیرد، یک جزئیات طراحی ظریف که آسان است هنگام پیکربندی HSRP و PIM توسط مهندسان مختلف یا در زمان‌های مختلف نادیده گرفته شود.

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

مقالات مرتبط

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

ادامه