PIM-SM multicast dan HSRP / VRRP


10

Saya perlu mengatur PC untuk mendengarkan umpan data multicast (PIM-SM). Sumber multicast dan (anycast) titik pertemuan berada di belakang "alamat HSRP / VRRP" di sisi lain dari tautan WAN. (Instruksi sebenarnya mengatakan "HSRP / VRRP")

Sesuai dokumentasi yang diterima, saya telah menyiapkan router dengan rute statis ke alamat HSRP / VRRP, dan pihak lain telah menambahkan rute ke jaringan saya. Lalu lintas Unicast berfungsi dengan baik, tetapi saya tidak menerima lalu lintas multicast. Wireshark menunjukkan tidak ada PIM bergabung yang dikirim oleh router saya.

Apa yang salah?

Jawaban:


7

Pesan PIM tidak bersumber dari HSRP VIP sehingga pemeriksaan RPF gagal karena HSRP VIP adalah tetangga RPF Anda. Ada dua cara untuk mengatasi ini.

  1. Atur protokol routing dinamis antara router Anda dan router sisi lain sehingga HSRP tidak diperlukan.

  2. Konfigurasikan mroutes statis ke sisi lain antarmuka IP aktual seperti:

    ip mroute 0.0.0.0 0.0.0.0 1.1.1.1


2

Masalahnya adalah bahwa router jarak jauh mengumumkan diri mereka dengan pesan Hello PIM dari alamat IP mereka sendiri dan router saya mendaftarkan alamat ini sebagai tetangga PIM.

Namun gateway dalam tabel routing berisi alamat virtual HSRP. Ketika router ingin bergabung dengan grup multicast, router mencari rute ke Rendezvous Point yang memiliki alamat virtual HSRP sebagai hop berikutnya. Karena alamat HSRP next-hop ini bukan salah satu tetangga PIM yang dikenal, PIM-SM RFC menentukan tidak ada Bergabung yang harus dikirim.

Mengubah rute statis untuk menggunakan alamat IP aktual dari salah satu router HSRP membuat pekerjaan multicast, tetapi tentu saja ini membuat HSRP tidak berguna.

Saya belum menguji VRRP karena pihak lain tidak ingin mengubah jaringan. VRRP mungkin tidak akan memiliki masalah ini karena tidak menggunakan IP router virtual, tetapi menggunakan alamat IP asli dari master router.


RFC 2362 yang sekarang sudah usang sebenarnya menyatakan "Pesan Join / Prune hanya dikirim jika tetangga RPF adalah tetangga PIM." Saya tidak dapat menemukan hal yang persis sama di RFC 4601 saat ini, tetapi dikatakan "Secara umum, pesan PIM Bergabung / Pangkas hanya boleh diterima untuk diproses jika itu berasal dari tetangga PIM yang dikenal."
Gerben

1
... akan lebih baik untuk mengedit info tambahan ke dalam pertanyaan awal Anda jika Anda telah belajar lebih banyak sejak menulis Q. Atau jika ini dimaksudkan sebagai jawaban untuk pertanyaan Anda sendiri (yang sangat dapat diterima), perlu banyak pekerjaan masuk akal.
Craig Constantine

Anda akan melihat perilaku yang sama dengan VRRP karena sebagian besar implementasi modern menggunakan VIP.
netdad

2

Mungkin menggunakan mroute statis yang menunjuk ke alamat IP antarmuka 'nyata', kemudian rute statis normal menunjuk ke HSRP. maka setidaknya Anda mendapatkan HSRP untuk unicast. ATAU arahkan rute mroute atau statis ke antarmuka alih-alih alamat IP.


Dalam hal ini, pengaturan dibuat hanya untuk menampilkan informasi yang masuk melalui multicast, tetapi jika tidak, ini bisa menjadi peningkatan.
Gerben

2

Dengan asumsi Anda berada di lingkungan Cisco .... apakah Anda telah mengaktifkan ip pim sparse-mode semua antarmuka antara perangkat itu dan RP?

Juga jangan lupa untuk memilikinya ip pim autorp listenersehingga menemukan RP secara otomatis.

Juga - jika Anda memiliki tautan berlebihan antara Anda dan RP ... Perutean PIM (atau cabang) tidak mengikuti jalur yang sama dengan tabel perutean biasa. Mereka AKAN memeriksa RPF (reverse path forwarding) untuk memastikan sumber aliran multicast datang dari arah yang benar. Tetapi dimungkinkan untuk memiliki tautan HSRP siaga menjadi DR (router yang ditunjuk) di sisi PIM rumah. Anda dapat mengubah perilaku ini dengan menetapkan prioritas DR. ip pim dr-priority xsemakin tinggi X semakin tinggi nilainya.

Anda juga dapat memeriksa untuk melihat apakah router melihat multicast bergabung dengan mengeluarkannya show ip mroutejuga harus mencantumkan RP.

show ip pim neigh juga akan memberi tahu Anda jika melihat tetangga multicast hulu

Saya percaya VRRP mengikuti konsep yang sama tetapi saya tidak 100% yakin karena saya jarang menggunakan gateway default multi-vendor.


"Mereka" ada di Cisco, "kami" ada di Juniper.
Gerben
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.