PIM-SM در سراسر VPN: بررسی BSR، نگاشت RP و مسیرهای RPF

تونل بالاست، پینگ‌های یونی‌کست از آن عبور می‌کنند و گیرنده هنوز صفحه سیاه نشان می‌دهد. در یک استقرار PIM-SM این نشانه تقریباً همیشه یعنی یکی از چهار مسیر کنترلی شکسته است و مسیر داده هرگز مشکل نبوده. فهرست زیر را به ترتیب پیش ببرید و در اولین مرحله‌ای که شکست می‌خورد توقف کنید، چون هر مرحله بعدی به مرحله قبل وابسته است. من این پنج بررسی را در یک فایل پیش‌نویس نگه می‌دارم و وقتی شکایتی درباره multicast می‌رسد در ترمینال می‌چسبانم، که مانع تبدیل تشخیص به حدس و گمان می‌شود.

از گیرنده شروع کنید، نه از تونل

گیرنده‌ای که هرگز گروه را درخواست نکرده هیچ حالتی روی هیچ روتری ایجاد نمی‌کند، پس پیش از بررسی هر چیز دیگری تأیید کنید که عضویت در سگمنت رو به گیرنده وجود دارد. در بسترهای به سبک Cisco، فرمان show ip igmp groups روی روتر آخرین پرش گروه‌های عضو‌شده را در کنار رابطی که آن‌ها را شنیده چاپ می‌کند. وقتی گروه در آن خروجی نیست، تونل یک حواس‌پرتی است: درخواست در سوئیچ دسترسی، در سوکت میزبان یا در VLAN بدون querier مرده است.

دو علت پیش‌پاافتاده بیشتر عضویت‌های گم‌شده‌ای را که دیده‌ام توضیح می‌دهد: ناسازگاری نسخه IGMP میان میزبان و روتر، و انتخاب querier که روی سوئیچی افتاده که مسیریابی نمی‌کند. علت سوم ظریف‌تر است: گروه عضو شده اما در VLAN اشتباه، چون میزبان دو کارت شبکه دارد و برنامه به کارت اشتباه متصل شده. گیرنده‌های IPv6 مشکل معادل را با MLD دارند، جایی که show ipv6 mld groups به همان پرسش پاسخ می‌دهد. هیچ‌یک از این‌ها با دست زدن به تونل درست نمی‌شود، و دقیقاً به همین دلیل ترتیب اهمیت دارد.

وقتی عضویت دیدنی شد، تأیید کنید که PIM هم روی رابط رو به گیرنده و هم روی رابطی که به نقطه تلاقی می‌رود فعال است. روتری که عضویت IGMP دارد اما روی رابط بالادستی خود PIM ندارد، گروه را در جدولی محلی نگه می‌دارد و هیچ‌چیز به هیچ‌جا نمی‌فرستد.

آیا مجموعه BSR به طرف دور می‌رسد؟

پیام‌های Bootstrap Router پرش به پرش درون یک دامنه PIM حرکت می‌کنند و همان جهتی است که در سراسر تونل می‌شکند. RPهای نامزد آگهی‌های خود را با یونی‌کست به BSR انتخاب‌شده می‌فرستند، پس بخش RP تا BSR معمولاً در تونلی که کار می‌کند بدون تغییر می‌ماند. سیل پیام‌های Bootstrap در جهت دیگر به فعال بودن PIM روی هر رابط میانی و به این بستگی دارد که چیزی پیام‌ها را در یک مرز متوقف نکند. RFC 5059 آن توزیع و مرزهای دامنه اداری را تعریف می‌کند که اجازه دارند آن را کوتاه کنند.

یک دستور ip pim bsr-border، یک ACL که پروتکل 103 را فیلتر می‌کند، یا یک تونل IPsec مبتنی بر سیاست که نمی‌تواند multicast را حمل کند، هر یک سیل را قطع می‌کنند در حالی که یونی‌کست دست‌نخورده می‌ماند. همین ترکیب است که خرابی را شبیه مشکل RP نشان می‌دهد در حالی که در واقع مشکل دسترسی‌پذیری است، و به همین دلیل وضعیت BSR را پیش از پیکربندی RP می‌خوانم.

روی روتر طرف دور، show ip pim bsr-router نام BSR انتخاب‌شده و مجموعه RP آموخته‌شده را می‌آورد؛ اگر خروجی خالی باشد، طرف دور در دامنه خودش نشسته و هیچ مقدار پیکربندی RP آن دو را آشتی نمی‌دهد. محدوده‌های گروه و آدرس‌های RP را در show ip pim rp mapping در دو طرف تونل مقایسه کنید. نگاشتی که فقط محلی وجود دارد درختی مشترک می‌سازد که در جای اشتباه پایان می‌یابد و گیرنده تا ابد منتظر می‌ماند.

نگاشت RP را در دو طرف تونل هم‌سان کنید

RP ایستا، BSR و anycast-RP سه راه برای پاسخ به یک پرسش‌اند و آمیختن آن‌ها در سراسر تونل راهی مطمئن برای ساختن دامنه‌ای است که هرگز همگرا نمی‌شود. اگر سر اصلی از BSR استفاده کند و شعبه از ip pim rp-address ایستا که به آدرس دیگری اشاره می‌کند، شعبه درخت مشترک خود را به سوی RPی می‌سازد که هیچ خبری از وجود گیرنده ندارد. نگاشت باید هم در محدوده گروه و هم در آدرس هم‌سان باشد، چون محدوده دقیق‌تر بر گسترده‌تر پیروز می‌شود.

Anycast-RP دقیقاً برای این وجود دارد که دو سایت بتوانند یک آدرس RP را شریک شوند، و ارزش دارد اینجا نام برده شود چون معنای «همان RP» را عوض می‌کند. دو RP که یک آدرس را اعلام می‌کنند طبق طراحی سازگارند؛ دو RP که برای همان محدوده آدرس‌های متفاوت اعلام می‌کنند سازگار نیستند، هر‌چند هر سایت به‌تنهایی سالم به نظر برسد.

برای multicast مخصوص منبع درون 232.0.0.0/8، هرگز از RP پرسیده نمی‌شود، پس نگاشت RP خالی به‌طور خودکار عیب نیست. پیش از دنبال کردن RPی که هرگز لازم نبود، تصمیم بگیرید برنامه از کدام مدل سرویس استفاده می‌کند.

جست‌وجوی RPF را به سوی منبع بخوانید

PIM درخت را با معکوس کردن مسیر یونی‌کست می‌سازد، پس بررسی مهم مسیر بازگشت به منبع است، یا بازگشت به RP برای درخت مشترک. عضویتی که روی رابطی برسد که روتر آن را بالادستی نمی‌داند دور انداخته می‌شود و دلیل به‌عنوان شکست RPF ثبت می‌شود نه شکست تونل. روی روتر شعبه با مسیر پیش‌فرض از روی تونل و مسیر دقیق‌تر از روی WAN، رابط RPF به‌راحتی می‌تواند همان WAN باشد حتی اگر منبع فقط از راه تونل در دسترس باشد. این تنها شایع‌ترین دلیل دور انداختن بی‌صدای یک عضویت است.

show ip rpf 192.0.2.10 رابط انتخاب‌شده، پرش بعدی و مسیری که تصمیم را ساخت چاپ می‌کند و معمولاً برای دیدن ناسازگاری کافی است. یک مسیر multicast ایستا مانند ip mroute 192.0.2.0 255.255.255.0 tunnel0 جست‌وجوی یونی‌کست را برای آن پیشوند نادیده می‌گیرد و وقتی توپولوژی multicast واقعاً با توپولوژی یونی‌کست تفاوت دارد، اصلاحی مشروع است. آن را پیکربندی‌ای بدانید که باید مستند شود، نه وصله‌ای که هنگام یک حادثه اعمال و بعد فراموش شود.

عضویت را با فرمان‌ها تأیید کنید، نه با پینگ

پینگ ثابت می‌کند یونی‌کست کار می‌کند، که از قبل می‌دانستید. تأیید سرتاسری دنباله‌ای است که عضویت، نگاشت، همسایه و درخت را به همین ترتیب نشان می‌دهد و هر فرمان به پرسش متفاوتی پاسخ می‌دهد.

show ip igmp groups 239.1.1.1
show ip pim rp mapping
show ip pim neighbor
show ip rpf 192.0.2.10
show ip mroute 239.1.1.1

یک ورودی پر (S,G) با رابط ورودی واقعی و فهرست خروجی غیرخالی یعنی صفحه کنترل کار خود را تمام کرده است. ورودی‌ای که رابط ورودی‌اش Null خوانده می‌شود، یا شمارنده‌ای با برچسب RPF failed که مدام بالا می‌رود، به بخش قبلی اشاره می‌کند نه به تونل.

اگر هر پنج فرمان درست به نظر برسند و گیرنده هنوز چیزی نبیند، مظنون باقی‌مانده سیاست خود تونل است: یک ACL رمزنگاری یا قاعده دیوار آتش که پروتکل مسیریابی یونی‌کست را مجاز می‌داند اما PIM، IGMP یا خود ترافیک گروه را نه. روی تونل IPsec مبتنی بر سیاست، multicast اصلاً حمل نمی‌شود، پس پاسخ طراحی GRE یا VTI است نه یک استثنای دیگر در فیلتر. پیش از تغییر هر چیزی بنویسید کدام‌یک از پنج بررسی شکست خورد، سپس فقط همان لایه را تغییر دهید.