Bagaimana sakelar yang dikelola menangani Broadcast Multicast dan Unicast?

Dalam skenario tipikal, switch jaringan perlu menangani pesan broadcast, multicast, dan unicast secara bersamaan.

Saya ingin mengerti

Pada sakelar terkelola yang khas (1Gb Ethernet / 10Gb Ethernet),

a) bagaimana pesan broadcast / multicast / unicast ditangani secara berbeda?

b) berapa bandwidth dan latensi penanganan pesan broadcast / multicast / unicast?

c) bagaimana pengaruh berbagai jenis pesan mempengaruhi satu sama lain?

d) Mengapa beralih dari siaran ke multicast akan (atau mungkin, jika dilakukan dengan benar) mengurangi beban saat sakelar?

Ini sangat tergantung pada arsitektur switch tertentu yang dimaksud. Kisaran harga yang lebar untuk "switch terkelola" 48-port (mis. Di bawah $ 300 hingga lebih dari $ 10.000) akan memberi tahu Anda ada sesuatu yang berbeda secara mendasar yang terjadi di dalam. Jika Anda tidak membayar terlalu banyak untuk switch Anda (dan saya harap Anda tidak melakukannya), sangat mungkin fitur multicast (dan fitur "perusahaan" lainnya) diturunkan ke perangkat lunak (jika semuanya didukung).

Penerusan unicast dasar menjadi agak murah untuk dilakukan dalam perangkat keras, jadi saya berharap setiap switch Ethernet modern bekerja dengan cukup baik di penerusan unicast dasar di bawah beban ringan.

Ketika Anda mulai menambahkan lebih banyak fitur ke perangkat keras, biaya naik secara signifikan. Sebagai contoh, penerusan frame unicast sangat berbeda daripada melakukan replikasi paket berdasarkan keadaan multicast dinamis. Keduanya adalah tugas yang sangat khusus. Dibutuhkan bit perangkat keras tertentu untuk melakukan keduanya dengan baik. Sebagian besar pengguna switch kelas bawah tidak memiliki kebutuhan multicast yang besar. Membayar untuk perangkat keras khusus multicast adalah pemborosan bagi para pengguna ini.

Tetapi sebagian besar jaringan menggunakan multicast kecil . Sebagai akibatnya, sudah umum bagi produsen untuk mengimplementasikan fitur multicast dan fitur yang kurang umum digunakan dalam perangkat lunak. Misalnya, perangkat keras penerusan unicast akan diperintahkan untuk meneruskan apa pun dengan alamat MAC multicast ke port internal tempat mereka diterima oleh subsistem CPU (atau setidaknya semacam mikrokontroler). Kemudian proses perangkat lunak dapat melihat bingkai, berkonsultasi dengan tabel penerusan multicast, mereplikasi bingkai dan menyerahkan beberapa salinan kembali ke perangkat keras, satu per port yang akan diteruskan. Jelas banyak fitur yang dapat ditambahkan pada saat ini dalam perangkat lunak tanpa mempengaruhi biaya sakelar secara signifikan.

Dalam sistem seperti itu, kinerjanya tidak akan pernah mendekati unicast. Kinerja CPU jelas akan memiliki dampak, tetapi jika Anda mengirim lalu lintas "pengecualian" yang tidak dapat diteruskan dalam perangkat keras, Anda salah melakukannya . Anda perlu membeli sakelar yang berbeda.

Dalam kasus terburuk, saklar yang benar-benar rendah tidak akan memiliki perlindungan sumber daya sehingga CPU yang sama yang dibanting dengan lalu lintas multicast akan lupa bahwa itu juga bertanggung jawab untuk merawat dan memberi makan segala sesuatu yang lain dalam saklar. Jika CPU terlalu sibuk mereplikasi lalu lintas multicast untuk membuat tabel unicast diperbarui dalam perangkat keras (atau apa pun yang seharusnya dilakukan CPU), Anda akan memiliki berbagai masalah.

1. Sama seperti sakelar yang tidak dikelola; mungkin dengan tambahan kompleksitas vLAN dan sejenisnya.
2. Ini spesifik implementasi, tetapi umumnya tidak ada perbedaan. Badai paket dapat menyebabkan latensi, tetapi itu tidak terkait dengan jenis paket secara khusus.
3. Sama seperti # 2: Implementasi spesifik dan umumnya tidak ada perbedaan.
4. "Memuat" bukan istilah yang didefinisikan dengan baik, saya pikir maksud Anda pemanfaatan port. Multicast hanya diteruskan ke port-port yang berlangganan grup tempat Broadcast dikirim ke setiap port (tergantung kompleksitas yang ditambahkan seperti vLAN).