cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2380
Views
5
Helpful
3
Replies

networking multicast switch behavior

markel
Level 1
Level 1

I am learning to multicast for ipv4 and have a few questions.

Okay, I understand that with multicast, every member in the group is aware of a mac address that will be recognized as a multicast frame.

When it comes to a switch, I know that a broadcast uses FF for all the octets, and this value will never be in the cam table, so it gets flooded out all ports. If a switch does not know the dest mac, it will flood it out all ports.

So my question is since the dest of a multicast uses this agreed particular mac address, the switch would not have it in its cam table since the cam table only uses the source address of frames.

This would mean that if the switch gets a multicast frame, it will flood it out all ports since it's not in the cam table.

Am I missing something here? I thought the point of multicasting was to send packets to hosts in a group selectively. But the behavior of a switch does not seem possible since no matter what everyone on the network is going to get the packet.

3 Replies 3

Hi

   We dont confuse Broadcast with Multicast. Multicast has a specific mac address 00:01:5E.x.x.x  and the switch will able to identify it.  Then we have IGMP protocol also running on the switch and IGMP snooping configured on its ports.

Take a look here.

 

https://www.youtube.com/watch?v=2iFmmSrpor8 

Jon Marshall
Hall of Fame
Hall of Fame

 

The short answer is IGMP snooping. 

 

If the switch is not running IGMP snooping or there is no IGMP querier then multicasts are indeed treated as broadcasts and are flooded to all ports in the vlan (except the one it was received on). 

 

But switches can listen to IGMP host requests to join a multicast group using IGMP snooping and so can record which ports the multicast stream should be sent out on. 

 

Jon

Joseph W. Doherty
Hall of Fame
Hall of Fame

By original design, Ethernet multicast was "seen" by all hosts in the same L2 broadcast domain.  Multicast "flooding" was stopped at multicast router boundaries, but again, once one host, behind a multicast router wanted a non-local multicast stream, all the hosts, again same L2 broadcast domain, "see" all that multicast's frames too.  (BTW, local multicast was also "flooded" to all hosts within same L2 broadcast domain.)

Also by design, hosts not interested in particular multicast streams, ignored the frames and/or packets, often, down at the NIC.  Somewhat like a NIC, "seeing" unicast frames/packets, it's not interested in, ignores them too.

For the foregoing to make sense, you need to realize/remember how Ethernet worked before there were switches.

Switches (basically multi-port bridges), originally (and some still) keep from flooding unicast to all ports (same VLAN), if destination MAC's port known, but continue to "flood" all multicast (again, to all hosts within the same L2 broadcast domain).

IGMP snooping was developed, so that some (smart/enhanced/managed) switches, could also send multicast frames only to the ports, in the same L2 broadcast domain, that want them.  (Basically, another destination MAC to port table, but now using multicast destination MACs.)

How IGMP snooping works, is an interesting study (well it was to me, laugh), as it's a bit more involved than one might think (because, so is, IGMP).

Also interesting (again, at least to me) is the not as well known PIM snooping, which addresses a somewhat similar issue, but one not nearly as common as IGMP snooping.