PIM-SM merentas VPN: Semak BSR, Pemetaan RP dan Laluan RPF

Tunel sudah aktif, ping unicast melaluinya, tetapi penerima masih menunjukkan skrin hitam. Dalam penggunaan PIM-SM gejala itu hampir selalu bermaksud salah satu daripada empat laluan kawalan rosak, dan laluan data sendiri tidak pernah menjadi masalah. Telusuri senarai di bawah mengikut urutan dan berhenti pada langkah pertama yang gagal, kerana setiap langkah seterusnya bergantung pada yang sebelumnya. Saya menyimpan kelima-lima semakan ini dalam fail draf dan menampalnya ke terminal apabila aduan multicast masuk, yang menghalang diagnosis daripada menjadi tekaan.

Mulakan dengan penerima, bukan tunel

Penerima yang tidak pernah meminta kumpulan itu tidak menghasilkan sebarang keadaan pada mana-mana penghala, jadi sahkan sambungan itu wujud pada segmen menghadap penerima sebelum anda memeriksa apa-apa lagi. Pada platform gaya Cisco, show ip igmp groups pada penghala hop terakhir mencetak kumpulan yang disertai di sebelah antara muka yang mendengarnya. Apabila kumpulan itu tiada dalam output tersebut, tunel hanyalah pengalih perhatian: permintaan itu mati di suis akses, di soket hos atau dalam VLAN tanpa querier.

Dua punca biasa menerangkan kebanyakan sambungan hilang yang saya lihat: ketidakpadanan versi IGMP antara hos dan penghala, serta pemilihan querier yang jatuh pada suis yang tidak menghala. Punca ketiga lebih halus: kumpulan sudah disertai tetapi pada VLAN yang salah, kerana hos mempunyai dua kad rangkaian dan aplikasi terikat pada yang salah. Penerima IPv6 mempunyai masalah setara dengan MLD, di mana show ipv6 mld groups menjawab soalan yang sama. Tiada satu pun daripada ini dibetulkan dengan menyentuh tunel, dan itulah sebabnya urutan itu penting.

Sebaik sahaja sambungan kelihatan, sahkan bahawa PIM didayakan pada antara muka menghadap penerima dan pada antara muka yang menuju ke titik pertemuan. Penghala yang mempunyai keahlian IGMP tetapi tiada PIM pada antara muka hulunya akan menyimpan kumpulan dalam jadual setempat dan tidak menghantar apa-apa ke mana-mana.

Adakah set BSR sampai ke seberang?

Mesej Bootstrap Router bergerak hop demi hop dalam satu domain PIM, dan arah itulah yang rosak merentas tunel. RP calon menghantar pengumuman mereka kepada BSR terpilih melalui unicast, jadi bahagian RP-ke-BSR biasanya bertahan tanpa berubah dalam tunel yang berfungsi. Banjir mesej Bootstrap ke arah bertentangan bergantung pada setiap antara muka perantaraan mempunyai PIM didayakan, dan pada tiada apa yang menghentikan mesej itu di sempadan. RFC 5059 mentakrifkan pengedaran itu dan sempadan skop pentadbiran yang dibenarkan memendekkannya.

Pernyataan ip pim bsr-border, ACL yang menapis protokol 103, atau tunel IPsec berasaskan dasar yang tidak dapat membawa multicast, setiap satunya akan memotong banjir sambil membiarkan unicast utuh. Gabungan itulah yang membuatkan kegagalan kelihatan seperti masalah RP sedangkan ia sebenarnya masalah kebolehcapaian, dan itulah sebabnya saya membaca keadaan BSR sebelum membaca konfigurasi RP.

Pada penghala di sisi jauh, show ip pim bsr-router menyatakan BSR terpilih dan set RP yang dipelajari; jika output kosong, sisi jauh duduk dalam domainnya sendiri dan tiada konfigurasi RP akan mendamaikan kedua-duanya. Bandingkan julat kumpulan dan alamat RP dalam show ip pim rp mapping pada kedua-dua belah tunel. Pemetaan yang wujud secara setempat sahaja menghasilkan pokok kongsi yang berakhir di tempat yang salah, dan penerima menunggu selama-lamanya.

Selaraskan pemetaan RP pada kedua-dua belah tunel

RP statik, BSR dan anycast-RP ialah tiga cara menjawab soalan yang sama, dan mencampurkannya merentas tunel ialah cara yang boleh dipercayai untuk membina domain yang tidak pernah menumpu. Jika hujung utama menggunakan BSR dan cawangan menggunakan ip pim rp-address statik yang menunjuk ke alamat lain, cawangan membina pokok kongsinya menuju RP yang tidak tahu penerima itu wujud. Pemetaan mesti bersetuju pada julat kumpulan dan juga pada alamat, kerana julat yang lebih khusus mengalahkan yang lebih luas.

Anycast-RP wujud semata-mata supaya dua tapak boleh berkongsi satu alamat RP, dan ia wajar disebut di sini kerana ia mengubah maksud «RP yang sama». Dua RP yang mengumumkan satu alamat adalah konsisten dari segi reka bentuk; dua RP yang mengumumkan alamat berbeza untuk julat yang sama tidak, tidak kira betapa sihatnya setiap tapak kelihatan sendiri.

Untuk multicast khusus sumber dalam 232.0.0.0/8, RP tidak pernah ditanya, jadi pemetaan RP kosong bukan secara automatik satu kerosakan. Tentukan model perkhidmatan mana yang digunakan aplikasi sebelum mengejar RP yang tidak pernah diperlukan.

Baca carian RPF menuju sumber

PIM membina pokok dengan menterbalikkan laluan unicast, jadi semakan yang penting ialah laluan kembali ke sumber, atau kembali ke RP untuk pokok kongsi. Sambungan yang tiba pada antara muka yang tidak dianggap hulu oleh penghala akan digugurkan, dan puncanya direkodkan sebagai kegagalan RPF dan bukan kegagalan tunel. Pada penghala cawangan dengan laluan lalai melalui tunel dan laluan yang lebih khusus melalui WAN, antara muka RPF boleh dengan mudah menjadi WAN walaupun sumber hanya boleh dicapai melalui tunel. Itulah sebab tunggal paling biasa sesuatu sambungan digugurkan secara senyap.

show ip rpf 192.0.2.10 mencetak antara muka yang dipilih, hop seterusnya dan laluan yang menghasilkan keputusan itu, yang biasanya cukup untuk melihat ketidakpadanan. Laluan multicast statik seperti ip mroute 192.0.2.0 255.255.255.0 tunnel0 mengatasi carian unicast untuk awalan itu, dan ia pembetulan yang sah apabila topologi multicast benar-benar berbeza daripada topologi unicast. Perlakukan ia sebagai konfigurasi yang perlu didokumenkan, bukan tampalan yang digunakan semasa insiden lalu dilupakan.

Sahkan sambungan dengan arahan, bukan dengan ping

Ping membuktikan unicast berfungsi, yang anda sudah tahu. Pengesahan hujung ke hujung ialah urutan yang menunjukkan sambungan, pemetaan, jiran dan pokok dalam urutan itu, dan setiap arahan menjawab soalan yang berbeza.

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

Entri (S,G) yang terisi dengan antara muka masuk sebenar dan senarai keluar yang tidak kosong bermaksud satah kawalan telah menyelesaikan tugasnya. Entri yang antara muka masuknya dibaca sebagai Null, atau pembilang berlabel RPF failed yang terus menaik, menunjuk kembali ke bahagian sebelumnya dan bukan ke tunel.

Jika kelima-lima arahan kelihatan betul dan penerima masih tidak melihat apa-apa, yang menjadi syak ialah dasar tunel itu sendiri: ACL kripto atau peraturan tembok api yang membenarkan protokol penghalaan unicast tetapi bukan PIM, IGMP atau trafik kumpulan itu sendiri. Pada tunel IPsec berasaskan dasar, multicast tidak dibawa sama sekali, jadi jawapannya ialah reka bentuk GRE atau VTI dan bukan satu lagi pengecualian penapis. Catatkan semakan mana antara kelima-lima itu yang gagal sebelum mengubah apa-apa, kemudian ubah lapisan itu sahaja.