PIM-SM di Seluruh VPN: Periksa BSR, Pemetaan RP, dan Jalur RPF

Tunelnya aktif, ping unicast melewatinya, dan penerima tetap menampilkan layar hitam. Dalam penerapan PIM-SM, gejala itu hampir selalu berarti salah satu dari empat jalur kendali rusak, dan jalur data sendiri tidak pernah menjadi masalah. Telusuri daftar di bawah ini secara berurutan dan berhenti pada langkah pertama yang gagal, karena setiap langkah berikutnya bergantung pada langkah sebelumnya. Saya menyimpan kelima pemeriksaan ini di berkas coretan dan menempelkannya ke terminal saat keluhan multicast masuk, sehingga diagnosis tidak berubah menjadi dugaan.

Mulai dari penerima, bukan dari tunel

Penerima yang tidak pernah meminta grup tidak menghasilkan status apa pun di router mana pun, jadi pastikan join itu ada di segmen yang menghadap penerima sebelum Anda memeriksa hal lain. Pada platform bergaya Cisco, show ip igmp groups di router hop terakhir mencetak grup yang diikuti di samping antarmuka yang mendengarnya. Bila grup tidak ada di keluaran itu, tunel hanyalah pengalih perhatian: permintaan mati di switch akses, di soket host, atau di VLAN yang tidak punya querier.

Dua penyebab biasa menjelaskan sebagian besar join yang hilang yang saya lihat: ketidakcocokan versi IGMP antara host dan router, serta pemilihan querier yang jatuh pada switch yang tidak melakukan routing. Penyebab ketiga lebih halus: grup sudah diikuti tetapi di VLAN yang salah, karena host punya dua kartu jaringan dan aplikasi terikat ke yang salah. Penerima IPv6 punya masalah serupa dengan MLD, di mana show ipv6 mld groups menjawab pertanyaan yang sama. Tidak satu pun dari ini diperbaiki dengan menyentuh tunel, dan itulah tepatnya alasan urutannya penting.

Setelah join terlihat, pastikan PIM diaktifkan baik pada antarmuka yang menghadap penerima maupun pada antarmuka yang menuju titik temu. Router yang punya keanggotaan IGMP tetapi tidak punya PIM pada antarmuka hulunya akan menyimpan grup dalam tabel lokal dan tidak mengirim apa pun ke mana pun.

Apakah himpunan BSR sampai ke sisi seberang?

Pesan Bootstrap Router bergerak hop demi hop di dalam satu domain PIM, dan itulah arah yang rusak saat melewati tunel. RP kandidat mengirim pengumumannya ke BSR terpilih melalui unicast, jadi ruas RP-ke-BSR biasanya bertahan tanpa perubahan pada tunel yang berfungsi. Banjir pesan Bootstrap ke arah sebaliknya bergantung pada setiap antarmuka perantara mengaktifkan PIM, dan pada tidak ada yang menghentikan pesan di batas. RFC 5059 mendefinisikan distribusi itu dan batas cakupan administratif yang boleh memotongnya.

Pernyataan ip pim bsr-border, ACL yang menyaring protokol 103, atau tunel IPsec berbasis kebijakan yang tidak dapat membawa multicast, masing-masing akan memotong banjir sementara unicast tetap utuh. Kombinasi itulah yang membuat kegagalan tampak seperti masalah RP padahal sebenarnya masalah keterjangkauan, dan itu sebabnya saya membaca status BSR sebelum membaca konfigurasi RP.

Pada router sisi jauh, show ip pim bsr-router menyebutkan BSR terpilih dan himpunan RP yang dipelajari; bila keluarannya kosong, sisi jauh berdiri di domainnya sendiri dan tidak ada konfigurasi RP yang akan menyatukan keduanya. Bandingkan rentang grup dan alamat RP di show ip pim rp mapping pada kedua sisi tunel. Pemetaan yang hanya ada secara lokal menghasilkan pohon bersama yang berakhir di tempat yang salah, dan penerima menunggu selamanya.

Samakan pemetaan RP di kedua sisi tunel

RP statis, BSR, dan anycast-RP adalah tiga cara menjawab pertanyaan yang sama, dan mencampurnya di seluruh tunel adalah cara andal membangun domain yang tidak pernah bertemu. Jika ujung utama memakai BSR dan cabang memakai ip pim rp-address statis yang menunjuk ke alamat lain, cabang membangun pohon bersamanya menuju RP yang tidak tahu penerima itu ada. Pemetaan harus sepakat pada rentang grup maupun pada alamat, karena rentang yang lebih spesifik mengalahkan yang lebih luas.

Anycast-RP ada justru agar dua situs dapat berbagi satu alamat RP, dan layak disebut di sini karena mengubah makna «RP yang sama». Dua RP yang mengumumkan satu alamat konsisten secara desain; dua RP yang mengumumkan alamat berbeda untuk rentang yang sama tidak, seberapa sehat pun setiap situs tampak sendiri-sendiri.

Untuk multicast khusus sumber di dalam 232.0.0.0/8, RP tidak pernah ditanyai, jadi pemetaan RP yang kosong bukan otomatis suatu kesalahan. Putuskan model layanan mana yang dipakai aplikasi sebelum mengejar RP yang tidak pernah diperlukan.

Baca pencarian RPF menuju sumber

PIM membangun pohon dengan membalik jalur unicast, jadi pemeriksaan yang penting adalah rute kembali ke sumber, atau kembali ke RP untuk pohon bersama. Join yang tiba pada antarmuka yang tidak dianggap hulu oleh router akan dibuang, dan alasannya dicatat sebagai kegagalan RPF, bukan kegagalan tunel. Pada router cabang dengan rute default melalui tunel dan rute yang lebih spesifik melalui WAN, antarmuka RPF bisa dengan mudah menjadi WAN meskipun sumber hanya terjangkau melalui tunel. Itulah alasan tunggal paling umum sebuah join dibuang tanpa suara.

show ip rpf 192.0.2.10 mencetak antarmuka yang dipilih, hop berikutnya, dan rute yang menghasilkan keputusan itu, yang biasanya cukup untuk melihat ketidakcocokannya. Rute multicast statis seperti ip mroute 192.0.2.0 255.255.255.0 tunnel0 menimpa pencarian unicast untuk prefiks itu, dan itu perbaikan yang sah ketika topologi multicast benar-benar berbeda dari topologi unicast. Perlakukan sebagai konfigurasi yang harus didokumentasikan, bukan tambalan yang diterapkan saat insiden lalu dilupakan.

Pastikan join dengan perintah, bukan dengan ping

Ping membuktikan unicast bekerja, yang sudah Anda ketahui. Konfirmasi ujung ke ujung adalah rangkaian yang menunjukkan join, pemetaan, neighbor, dan pohon dalam urutan itu, dan setiap perintah menjawab pertanyaan yang berbeda.

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 antarmuka masuk yang nyata dan daftar keluar yang tidak kosong berarti bidang kendali telah menyelesaikan tugasnya. Entri yang antarmuka masuknya terbaca Null, atau penghitung berlabel RPF failed yang terus naik, menunjuk kembali ke bagian sebelumnya dan bukan ke tunel.

Jika kelima perintah tampak benar dan penerima tetap tidak melihat apa pun, tersangka yang tersisa adalah kebijakan tunel itu sendiri: ACL kripto atau aturan firewall yang mengizinkan protokol routing unicast tetapi tidak PIM, IGMP, atau lalu lintas grup itu sendiri. Pada tunel IPsec berbasis kebijakan, multicast tidak diangkut sama sekali, jadi jawabannya adalah desain GRE atau VTI, bukan pengecualian filter lain. Catat pemeriksaan mana dari kelima itu yang gagal sebelum mengubah apa pun, lalu ubah hanya lapisan tersebut.