Mengintip IGMP dan menghubungkan alamat multicast-lokal


8

Saya memiliki jaringan yang memiliki banyak perangkat yang mengirim data ke 224.0.0.225 pada VLAN yang mencakup beberapa sakelar. Setiap perangkat (sekitar 12 dari mereka) mengirim data pelaporan sekitar 500-600 kbps. Setiap port pada VLAN, apakah penerima mengirim sambungan atau tidak, akan dibanjiri dengan lalu lintas multicast sekitar 6mbps.

Pengintaian IGMP diaktifkan pada semua sakelar dan VLAN lokal.
pim sparse-mode dikonfigurasi pada mrouter / gateway default.

Jika saya melakukan show ip igmp snooping groupson switch, tidak ada entri di tabel pengintai.

Saya tahu 224.0.0.1 - 224.0.0.255 termasuk dalam jangkauan IP multicast yang disediakan oleh link-local yang berarti router tidak akan meneruskan paket dalam kisaran ini. Rentang ini juga digunakan untuk obrolan protokol routing. mis. EIGRP, OSPF, HSRP ... dll

Saya punya dua pertanyaan:
1) Saya pikir jawabannya adalah YA - untuk 224.0.0.1 224.0.0.255 ... apakah IGMPv2 mengabaikan kisaran ini untuk pengintaian dan apakah saklar hanya meneruskan ini ke semua port?
2) Apakah ada cara untuk memaksa IGMP untuk mengintai lalu lintas multicast ini dan hanya mengirimnya ke port yang memintanya bergabung dengan IGMP?

Saya merasa ini adalah salah satu contoh di mana aplikasi / programmer perlu merancang perangkat dan aplikasi mereka untuk menghormati jaringan non-konsumen yang dapat diskalakan. Dengan demikian mereka harus menggunakan alamat multicast di kisaran 239.0.0.0/8.


Saya pikir jawaban yang benar di sini adalah untuk menemukan siapa pun yang memilih untuk menyalahgunakan alamat "yang tidak ditugaskan" dan mendidik mereka dalam kesalahan cara mereka dengan 2x4. Anda benar; "aplikasi" harus menggunakan 239/8. Sampai saat ini, ada sangat sedikit yang dapat Anda lakukan tentang itu.
Ricky Beam

1
untuk menambah ini - Cisco juga menyatakan ini adalah pendekatan yang dimaksudkan untuk tautan-lokal multicast. cisco.com/en/US/tech/tk828/…
knotseh

Jawaban:


7

Saya terus menggali di internet .... dan saya pikir saya sudah menjawab pertanyaan saya sendiri.
Sekarang saya harus kembali ke pemilik aplikasi / perangkat / pengembang dan melihat apa yang bisa kita lakukan atau mengunci lebih jauh perangkat ini ke VLAN mereka sendiri.

Silakan tinggalkan komentar atau jawaban dengan saran lebih lanjut.

RFC 4541 2.1.2 :

1) Paket dengan alamat IP tujuan di luar 224.0.0.X yang bukan IGMP harus diteruskan sesuai dengan tabel keanggotaan port berbasis grup dan juga harus diteruskan pada port router.

  This is the main IGMP snooping functionality for the data path.
  One approach that an implementation could take would be to
  maintain separate membership and multicast router tables in
  software and then "merge" these tables into a forwarding cache.

2) Paket dengan alamat IP tujuan (DIP) dalam kisaran 224.0.0.X yang bukan IGMP harus diteruskan pada semua port.

  This recommendation is based on the fact that many host systems do
  not send Join IP multicast addresses in this range before sending
  or listening to IP multicast packets.  Furthermore, since the
  224.0.0.X address range is defined as link-local (not to be
  routed), it seems unnecessary to keep the state for each address
  in this range.  Additionally, some routers operate in the
  224.0.0.X address range without issuing IGMP Joins, and these
  applications would break if the switch were to prune them due to
  not having seen a Join Group message from the router.

Hai, tolong pertimbangkan menerima jawaban ini. Saya baru saja menemukan ini ketika saya mencari pertanyaan serupa di Google.
Mike Pennington

6

Ada peringatan lain: Tergantung pada platform, saklar akan menyodok semua link-local multicast ke CPU. Ini termasuk misalnya lalu lintas OSPF.

Saya perhatikan ini pada Ciscos Catalyst 4500 yang akan mengirim semua 224.0.0.x traffic ke CPU. Ketika CPU sibuk, itu akan menjatuhkan paket, termasuk paket OSPF Anda. Bersenang-senang men-debug mengapa sesi OSPF Anda drop.

Juga mematikan pengintaian igmp pada platform tidak membantu. Pada suatu waktu Cisco memperhatikan bahwa ini mungkin bukan ide terbaik dan memperkenalkan perintah:

access-list hardware capture mode vlan

Ini akan menjembatani paket multicast dalam perangkat keras.

Lihat http://www.cisco.com/en/US/docs/switches/lan/catalyst4500/12.2/52sg/configuration/guide/secure.html#wp1128851 untuk detail


apakah Anda tahu cara memblokir siaran 224.0.0.x di tingkat port?
knotseh

Mmmh, itu tergantung. Anda dapat menerapkan Control Plane Policing: cisco.com/en/US/docs/switches/lan/catalyst4500/12.2/52sg/… Tapi Anda terbatas pada peta kelas yang telah ditentukan sebelumnya. Jika lalu lintas Anda dicocokkan dengan salah satu peta kelas, Anda beruntung. Sunting : Oke baca ini lagi, saya tidak yakin apakah Anda diizinkan memiliki peta kelas sendiri selain yang sudah ditentukan sebelumnya. Anda perlu mengujinya.
Sebastian Wiesinger

Jadi switch akses saya sebenarnya adalah switch seri 3560x. Setelah saya mendapatkan Jendela pemeliharaan, saya akan mencoba sw block multicast seperti yang disarankan pada pertanyaan kesalahan server. Mungkin saya akan memposting ulang ini sebagai pertanyaan nanti
knotseh

Jadi dari pembacaan awal saya di ponsel saya .... sepertinya akan mengklasifikasikan semua atau tidak sama sekali dalam hal menghubungkan lalu lintas lokal. Tentu saja jika saya dapat memblokir peta kelas yang sudah ditentukan sebelumnya, maka itu juga akan menjatuhkan hsrp yang merupakan satu-satunya hal lain yang perlu saya kerjakan.
knotseh
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.