Multicast in L2 and L3
Layer 2 switches
The default behavior of L2 switches with regards to Multicast traffic is flooding. However when IGMP Snooping is enabled, layer 2 switches detect that Multicast traffic has been received on a particular port and put that port in the Snooping Table. The host connected to this port is potentially “Interested” in receiving Multicast traffic (for a particular group; but wait this is L3 stuff!!).
IGMP Snooping on a switch works when connected hosts send IGMP messages. These messages indicate that a host is interested in receiving MC traffic for a group (join messages) or that a host does not want to receive MC traffic anymore (leave messages)
IGMP Snooping does not apply to Link Local Multicast traffic, WHY? Because no IGMP message is sent to a link local address! I can say that this Multicast traffic is not IGMP traffic. This traffic is therefore flooded. Link Local addresses are in the range of 126.96.36.199 to 188.8.131.52.
Link Local addresses are used by (some) routing protocols and low-level communication between them. Routers do not forward the traffic for these addresses regardless of the packet TTL.
So, in other words, L2 switches flood the link local MC traffic and if IGMP Snooping is enabled on them they snoop IGMP packets.
How Layer 2 switches deal with IGMP traffic?
If you have a couple of switches in your network connected to each other and one of them has a connected host which send and IGMP message, lets say a join message, does the connected switch snoop the incoming port and the other switch snoop the ISL port? Well yes and no!
In the following diagram, Host1 sends IGMP Join Messages to Switch1, Switch1 puts Eth1 in its snooping table (an entry which states that Eth1 has a host attached which is interested in receiving traffic for group G). Many people expect that Switch1 floods this IGMP Join Message which came from Host1 via the ISL to its neighbor switch, Switch2 and Switch2 puts Eth2 in its snooping table in return. But that is NOT the case.
To understand the reason let us go a bit deeper by explaining different types of interfaces with regards to IGMP traffic.
Multicast router interfaces: these interfaces are ultimately leading towards a Multicast router (or an IGMP querier which I explain later)
Multicast group member interfaces: these interfaces are connected to hosts which are interested in receiving Multicast traffic of a group (in other words group members).
How the switch learns about the type of the interface is very simple. If a switch receives IGMP queries, from a PIM router for instance, on an interface, it will add that interface to its table and mark it as a router interface. (I promise to explain IGMP queries later!).
On the other hand if a switch receives an IGMP Join Message (whether it is an unsolicited join or a response to a query!), on an interface, it will add the interface to its table and mark it as a group member interface.
What is an IGMP Query and an IGMP Querier?
A multicast router sends periodic IGMP messages to see which router/switch has an active Multicast receiver, these messages are called IGMP queries and the router which sends them is an IGMP querier. Host which are still active and interested in receiving the traffic response to these queries. If there is no active receiver (for a particular group) in a segment, the Multicast traffic (of that group) will not be forwarded to it.
Let us go back and see Multicast IGMP forwarding rules based on the port types:
IGMP queries received on a router interface in a particular VLAN is forwarded to all ports in that VLAN.
IGMP reports received on a group member interface in a VLAN will be forwarded to all router interfaces on that VLAN. This traffic is NOT forwarded to other hosts (group member ports) on that VLAN.
By understanding these forwarding rules it becomes clear that for a switch to learn about IGMP interfaces and forward IGMP traffic an IGMP router MUST exist in the network.
Now lets add a Multicast router (querier) to the topology and see the results:
Note: all interfaces on both switches are in the same VLAN.
Switch1 receives IGMP general queries from router R1 on interface Eth3 and adds this interface to its table by marking Eth3 as a router interface.
Switch1 forwards these queries out of all its interfaces including Eth2.
Switch2 receives the queries on its interface Eth2 and puts it in its table as a router interface.
Now if Source1 starts to send Multicast traffic to the group which Host1 is a member of, Switch2 and Switch1 will forward the traffic towards Host1.
For more information about Multicast tree formation see my other post Multicast Basics 1.