Pánové, připadám si tady jako na fóru jaknapocitac.cz

Klíčová funkce k řízení multicastu na switchích se nazývá igmp snooping. Ještě to tady nepadlo. Switch s podporou igmp snoopingu kontroluje procházející igmp zprávy (igmp query - dotazy od routeru, nejčastěji rendezvouz point; igmp report o příslušnosti ke skupině od posluchačů, příp. igmp leave, tedy opuštění skupiny) a podle nich aktualizuje tabulku posluchačů na konkrétních portech, a to nezávisle na klasické CAM tabulce s MAC adresami.
A protože jsou igmp zprávy obyčejné IP pakety, musí mít swich s igmp snoopingem i omezenou znalost třetí vrstvy. Obyčejný L2 switch tedy nestačí.
Docela mě baví ta mantra, kterou tady každý opakuje, že "multicast je na switchi broadcast". Ono to tak je, ale málokdo ví proč. Inu problém tkví ve statickém mapování multicastových MAC na IP. Zapomeňte na ARP, u multicastu má každá IP vlastní MAC (i když ani to není úplně pravda, ale to by bylo na dlouhé vyprávění...). Hloupý switch se k multicastu chová v podstatě jako k unknown-unicastu - přepošle rámec na všechny porty a čeká, z kterého se mu vrátí odpověď, aby si to mohl poznačit ve svojí CAM tabulce. Vzhledem k tomu, že multicast jsou UDP datagramy, nic se samozřejmě nevrátí.
* Multicast je tedy pro switch unknown-unicast bez odpovědi *
A i kdyby se náhodou odpověď vrátila, switch by viděl na několika portech stejné MAC adresy (hence koncept one-to-many), s čímž si switche stejně normálně neporadí.