When there are multiple receivers on the network then using multicast traffic sounds lượt thích a good idea. It’s more efficient than unicast since we only have lớn have lớn send our traffic once, this saves us precious bandwidth. It’s also more efficient than broadcast since only receives that are actually interested in our traffic will receive it.

Bạn đang xem: Igmp snooping

Routers use PIM (Protocol Independent Multicast) to lớn figure out where to forward multicast traffic but what about switches?

Layer two switches are simple devices. They learn source MAC addresses & insert these in their MAC address tables. When a frame arrives, they kiểm tra for the destination MAC address, perform a lookup in the MAC address table & then forward the frame. This works very well for unicast traffic but it’s a problem for multicast traffic. Take a look at the example below:

*

Above we have a clip server that is streaming multicast traffic to lớn destination 239.1.1.1, the destination MAC address will be 0100.5e01.0101. When the switch receives this traffic then it will vị a lookup for MAC address 0100.5e01.0101. Since this MAC address has never been used as a source, all multicast traffic will be flooded. All hosts will receive our traffic whether they want it or not.

IGMP snooping allows us to lớn constrain our multicast traffic. As the name implies, this is done by listening lớn IGMP traffic between the router and hosts:

When the host sends a membership report for a multicast group then the switch adds an entry in the CAM table for the interface that is connected to the host.When the host sends a leave group for a multicast group then the switch removes an entry in the CAM table for the interface that is connected to lớn the host.

This sounds simple but there is more to this story.

What do we vì chưng when we use IGMP version 1? Our hosts will not send any leave group messages so there’s nothing to snoop. How vì chưng we khuyến mãi with the clip server that never joins any multicast groups but only streams traffic to it?

To answer these questions we’ll have khổng lồ take a closer look at IGMP snooping.

IGMP snooping without L3 aware ASICs

We will start with a simple example. I’ll use the following diagram for this:

*

Above we have a multicast enabled router, a switch và three host devices. Our switch has a CPU và a CAM table (mac address table) which is connected lớn an internal interface that I will call “INT”. We are using a cheap budget switch that is only able lớn look at layer two Ethernet frames. It does have support for IGMP snooping though. Let’s see what happens when we enable IGMP snooping on this switch:

*

Above you can see that one of our hosts (H1) sends a membership report for multicast group 239.1.1.1 that it wants lớn join. Our switch has no idea where to lớn forward this lớn so the first time it will flood it on all interfaces, including the internal interface khổng lồ the CPU. The CPU will take a closer look at the membership report and will create an entry in the CAM table:

*

In the CAM table above you can see an entry for MAC address 0100.5e01.0101 which corresponds with multicast group 239.1.1.1. The interfaces that were added are for H1, R1 and the internal interface. Why did the switch showroom the interface of the router in the CAM table?

Once IGMP snooping is enabled, the switch will detect multicast enabled routers and it does so by listening to the following messages:

IGMP General Query (0100.5e00.0001)OSPF (0100.5e00.0005 và 0100.5e00.0006)PIM version 1 and HSRP (0100.5e00.0006)PIM version 2 (0100.5e00.000d)DVMRP (0100.5e00.0004)

When the switch detects a multicast enabled router then it will add the corresponding entry in the CAM table.

From now on, all multicast traffic that has destination MAC address 0100.5e01.0101 will only be forwarded on interface Gi0/1, Gi0/4 and the internal interface to lớn the CPU.

It sounds like we did a good job constraining our multicast traffic but we still have one problem. Here’s what happens when one of our devices starts streaming multicast traffic:

*

In the example above we see that R1 is sending 10 Mbps of multicast traffic which is forwarded khổng lồ H1 & the CPU. Our CPU is unable khổng lồ process 10 Mbps of traffic so it will choke on it…when this occurs, there’s a couple of things that could occur:

The switch will start dropping unicast and multicast traffic.The CPU might be able khổng lồ drop exceeding multicast traffic but that could also include IGMP membership reports and IGMP group leave messages.

The issue above is common with cheap switches that tư vấn IGMP snooping. It might work with low bandwidth multicast traffic but that’s about it.

IGMP snooping with L3 aware ASICs

To fix this issue, we need switches with special ASICs that are able to lớn look into the frame & differentiate between IGMP and non-IGMP multicast traffic. Here’s what that would look like:

*

Above you can see the changes that were made to lớn the CAM table:

The first entry tells the switch to forward all IGMP traffic with destination 0100.5exx.xxx lớn the internal interface. This allows the CPU to look at the different IGMP messages.The second entry tells the switch to lớn forward all non-IGMP traffic with destination 0100.5e01.0101 (group 239.1.1.1) lớn interface Gi0/1 & Gi0/4.

The switch will now intercept all IGMP messages, they are only sent to lớn the internal interface which puts our switch in total control of all IGMP traffic.

IGMP Group Leave

Let’s continue the story, let’s say that H1 and H2 are listening to multicast group 239.1.1.1. Suddenly, H1 is no longer interested so it will send a leave group message:

*

Leave group messages are always sent lớn multicast group 224.0.0.2 using destination MAC address 0100.5e00.0002. When the switch receives the IGMP leave, it will forward it on the internal interface to the CPU.

In response, the switch will send an IGMP general query on the interface that connects lớn H1:

*

The IGMP general query is only sent on the Gi0/1 interface và we vị this to kiểm tra if there are any other hosts that are interested in multicast group 239.1.1.1 on this interface. There are two possible outcomes:

If another host was connected khổng lồ the Gi0/1 interface which was still interested in receiving traffic for 239.1.1.1 then the switch would just get rid of the group leave message, nothing will change.When the switch doesn’t receive a membership report then the CPU will remove the Gi0/1 interface from the CAM table. Since we still have a second listener (H2), the switch will not forward the leave group message khổng lồ the router.

Xem thêm: Thế Nào Là Cặp Alen Là Gì ? Alen Nghĩa Là Gì Thế Nào Là Cặp Alen

Here’s what the CAM table looks like now:

*

Above you can see that interface Gi0/1 has been removed from the CAM table. No messages have been forwarded khổng lồ the router.

A few minutes later, H2 decides that it also wants lớn leave multicast group 239.1.1.1 so it will send an IGMP leave group message:

*

Above you can see the switch receives the IGMP leave group from H2 which is forwarded to lớn the CPU. Here’s what happens next: