IGMP Snooping without Router

As we have seen in the IGMP snooping lesson, switches will listen to IGMP messages and learn on which interfaces they have to forward multicast traffic. Without IGMP snooping, switches will flood multicast traffic everywhere, treating it like broadcast traffic.

IGMP snooping works pretty well but it does require a multicast router in the network. When you want to implement it in a simple network, where you only have one VLAN and multiple switches, you can run into two possible issues:

• Multicast traffic gets flooded everywhere.
  AND/OR
• Some receivers don’t receive any multicast traffic.

In this lesson I will explain why IGMP snooping requires a multicast router, what happens when you don’t have one and how to solve it.

Configuration

Scenario with Multicast Router

Let’s start with an example where do we have a multicast-enabled router. Here’s the topology that I will use:
Above we have R1, our multicast router. H1 and H2 are receivers, S1 is the source. The two switches have IGMP snooping enabled by default and we are using default VLAN 1.

hostname H1
!
ip cef
!
interface FastEthernet0/0
 ip address 192.168.1.1 255.255.255.0
!
end

hostname H2
!
ip cef
!
interface FastEthernet0/1
 ip address 192.168.1.2 255.255.255.0
!
end

hostname R1
!
ip cef
!
ip multicast-routing 
!
interface FastEthernet0/0
 ip address 192.168.1.254 255.255.255.0
 ip pim sparse-mode
!
end

hostname S1
!
ip cef
!
interface FastEthernet0/0
 ip address 192.168.1.200 255.255.255.0
!
end

hostname SW1
!
interface FastEthernet0/1
!
interface FastEthernet0/2
!
interface FastEthernet0/3
!
interface FastEthernet0/24
!
end

hostname SW2
!
interface FastEthernet0/4
!
interface FastEthernet0/24
!
end

Let’s make sure that IGMP snooping is enabled on both switches:

SW1#show ip igmp snooping | include snoop  
IGMP snooping                : Enabled

SW2#show ip igmp snooping | include snoop
IGMP snooping                : Enabled

And let’s verify that both switches have learned the multicast router through its general queries:

SW1#show ip igmp snooping querier 
Vlan      IP Address               IGMP Version   Port             
-------------------------------------------------------------
1         192.168.1.254            v2            Fa0/1 

SW2#show ip igmp snooping querier 
Vlan      IP Address               IGMP Version   Port             
-------------------------------------------------------------
1         192.168.1.254            v2            Fa0/24 

Everything is looking good. Before I configure the hosts to join a multicast group, let’s enable some debugs on the switches:

SW1#debug ip igmp snooping 239.1.1.1
group IP address debugging is on for 239.1.1.1

SW2#debug ip igmp snooping 239.1.1.1
group IP address debugging is on for 239.1.1.1

And on the hosts:

H1#debug ip igmp 
IGMP debugging is on

H2#debug ip igmp 
IGMP debugging is on

This will allow us to see what is going on behind the scenes. Let’s configure H1 to join multicast group 239.1.1.1:

H1(config)#interface FastEthernet 0/0
H1(config-if)#ip igmp join-group 239.1.1.1

On H1 we can see that it generates a membership report for 239.1.1.1:

H1#
IGMP(0): WAVL Insert group: 239.1.1.1 interface: FastEthernet0/0Successful
IGMP(0): Send v2 Report for 239.1.1.1 on FastEthernet0/0
IGMP(0): Received v2 Query on FastEthernet0/0 from 192.168.1.254
IGMP(0): Set report delay time to 2.2 seconds for 239.1.1.1 on FastEthernet0/0
IGMP(0): Send v2 Report for 239.1.1.1 on FastEthernet0/0

Here’s what happens on SW1 when it receives the report from H1:

SW1#
IGMPSN: group: Received IGMPv2 report for group 239.1.1.1 received on Vlan 1, port Fa0/3
L2MM: Add member: gda:0100.5e01.0101, adding Fa0/1
IGMPSN: mgt: added port Fa0/1 on gce 0100.5e01.0101, Vlan 1
IGMPSN: group: Created group 239.1.1.1
IGMPSN: Add v2 group 239.1.1.1 member port Fa0/3, on Vlan 1
L2MM: Add member: gda:0100.5e01.0101, adding Fa0/3
IGMPSN: mgt: added port Fa0/3 on gce 0100.5e01.0101, Vlan 1
IGMPSN: group: Added port Fa0/3 to group 239.1.1.1
IGMPSN: group: Forwarding 239.1.1.1 report to router ports

Above you can see that SW1 receives the membership report from H1, adds interface FastEthernet 0/3 so that it forwards traffic from 239.1.1.1 to it and it forwards the membership report towards R1.

Let’s configure H2 to join the same multicast group:

H2(config)#interface FastEthernet 0/1
H2(config-if)#ip igmp join-group 239.1.1.1

Here’s what happens on SW2:

SW2#
IGMPSN: group: Received IGMPv2 report for group 239.1.1.1 received on Vlan 1, port Fa0/4
L2MM: Add member: gda:0100.5e01.0101, adding Fa0/24
IGMPSN: mgt: added port Fa0/24 on gce 0100.5e01.0101, Vlan 1
IGMPSN: group: Created group 239.1.1.1
IGMPSN: Add v2 group 239.1.1.1 member port Fa0/4, on Vlan 1
L2MM: Add member: gda:0100.5e01.0101, adding Fa0/4
IGMPSN: mgt: added port Fa0/4 on gce 0100.5e01.0101, Vlan 1
IGMPSN: group: Added port Fa0/4 to group 239.1.1.1
IGMPSN: group: Forwarding 239.1.1.1 report to router ports

SW2 does something similar. It will forward traffic from 239.1.1.1 to the FastEthernet0/4 interface from now on. You can also see that it forwards this membership report on its router port. This is an important step…let’s see what happens on SW1 now:

SW1#
IGMPSN: group: Received IGMPv2 report for group 239.1.1.1 received on Vlan 1, port Fa0/24
IGMPSN: Add v2 group 239.1.1.1 member port Fa0/24, on Vlan 1
L2MM: Add member: gda:0100.5e01.0101, adding Fa0/24
IGMPSN: mgt: added port Fa0/24 on gce 0100.5e01.0101, Vlan 1
IGMPSN: group: Added port Fa0/24 to group 239.1.1.1
IGMPSN: group: Forwarding 239.1.1.1 report to router ports

The output above is important to understand. SW1 receives the membership report that SW2 has forwarded so it now knows that it has to forward traffic for 239.1.1.1 on the FastEthernet 0/24 interface.

We can also verify this with the following show command:

SW1#show ip igmp snooping groups 
Vlan      Group                    Type        Version     Port List
-----------------------------------------------------------------------
1         224.0.1.40               igmp        v2          Fa0/1
1         239.1.1.1                igmp        v2          Fa0/1, Fa0/3, 
                                                           Fa0/24

SW2#show ip igmp snooping groups 
Vlan      Group                    Type        Version     Port List
-----------------------------------------------------------------------
1         239.1.1.1                igmp        v2          Fa0/4, Fa0/24

Above we can see the interfaces that SW1 and SW2 will forward traffic from 239.1.1.1 to.

Let’s try a quick ping:

S1#ping 239.1.1.1 repeat 1000
Type escape sequence to abort.
Sending 1000, 100-byte ICMP Echos to 239.1.1.1, timeout is 2 seconds:

Reply to request 0 from 192.168.1.2, 4 ms
Reply to request 0 from 192.168.1.1, 4 ms

Our ping is successful, life is good!

Scenario without Router

So what happens when there is no multicast router in the network? Let’s find out! We will use the exact same topology except the router is gone:

The switches don’t know of a router port now.

Let’s configure the two hosts to leave and rejoin our multicast group:

H1(config)#interface FastEthernet 0/0
H1(config-if)#no ip igmp join-group 239.1.1.1
H1(config-if)#ip igmp join-group 239.1.1.1

H2(config)#interface FastEthernet 0/1
H2(config-if)#no ip igmp join-group 239.1.1.1
H2(config-if)#ip igmp join-group 239.1.1.1

Here’s what you will see in the debug:

SW1#
IGMPSN: group: Received IGMPv2 report for group 239.1.1.1 received on Vlan 1, port Fa0/3
IGMPSN: No mroute detected: Drop IGMPv2 report for group 239.1.1.1 received on Vlan 1, port Fa0/3

SW2#
IGMPSN: group: Received IGMPv2 report for group 239.1.1.1 received on Vlan 1, port Fa0/4
IGMPSN: No mroute detected: Drop IGMPv2 report for group 239.1.1.1 received on Vlan 1, port Fa0/4

This is rather harsh…the switches don’t know any multicast routers so they decide to drop the membership reports from the hosts.

What does this mean? Let’s try another ping:

S1#ping 239.1.1.1 repeat 1000
Type escape sequence to abort.
Sending 1000, 100-byte ICMP Echos to 239.1.1.1, timeout is 2 seconds:

Reply to request 0 from 192.168.1.2, 4 ms
Reply to request 0 from 192.168.1.1, 4 ms

Our pings are still working. The problem here is that the switches are flooding all multicast traffic now, treating it like broadcast traffic.

Depending on the switch platform and/or IOS version, it is possible that you see different results. My Cisco Catalyst 3560 switches running IOS 12.2(55)SE10 decide to drop the IGMP report and flood the traffic destined to 239.1.1.1. It is also possible that your switches do accept the IGMP reports. When this happens, you will see that H1 will receive the multicast traffic since S1 and H1 are both connected to the same switch. H2 will not receive anything. SW2 will receive the IGMP report from H2 but doesn’t know a router port, so it doesn’t forward the IGMP report towards SW1. Since SW1 never sees a membership report on its FastEthernet 0/24 interface, it will never forward multicast traffic there.

Solutions

How do we solve this issue?

The short answer is that we need a multicast router port. There are a couple of different solutions we can try, let me show you all of them.

Solution 1: IGMP snooping querier

There is a specific command for IGMP snooping that we can use to let one of the switches become a querier, acting like a multicast router. Here’s how:

SW1(config)#interface vlan 1
SW1(config-if)#ip address 192.168.1.253 255.255.255.0

SW1(config)#ip igmp snooping querier

Here’s what the debug tells us:

SW1#
IGMPQR: vlan_id 1: leaving Disabled state and entering Querier state
IGMPQR: vlan_id 1: timer GQ_PIM Timer expired in Querier state
IGMPQR: vlan 1: GQ with src addr 192.168.1.253 sent
IGMPSN: group: Received IGMPv2 report for group 239.1.1.1 received on Vlan 1, port Fa0/24
IGMPSN: group: Created group 239.1.1.1
IGMPSN: Add v2 group 239.1.1.1 member port Fa0/24, on Vlan 1
L2MM: Add member: gda:0100.5e01.0101, adding Fa0/24
IGMPSN: mgt: added port Fa0/24 on gce 0100.5e01.0101, Vlan 1
IGMPSN: group: Added port Fa0/24 to group 239.1.1.1
IGMPSN: group: Forwarding 239.1.1.1 report to router ports
IGMPSN: group: Received IGMPv2 report for group 239.1.1.1 received on Vlan 1, port Fa0/3
IGMPSN: Add v2 group 239.1.1.1 member port Fa0/3, on Vlan 1
L2MM: Add member: gda:0100.5e01.0101, adding Fa0/3
IGMPSN: mgt: added port Fa0/3 on gce 0100.5e01.0101, Vlan 1
IGMPSN: group: Added port Fa0/3 to group 239.1.1.1

Above you can see that SW1 has generated a general query. This allows SW2 to learn a multicast router port, we can verify this since we receive a membership report on the FastEthernet0/24 interface.

Here’s what it looks like on SW2:

SW2#
IGMPSN: group: Received IGMPv2 report for group 239.1.1.1 received on Vlan 1, port Fa0/4
L2MM: Add member: gda:0100.5e01.0101, adding Fa0/24
IGMPSN: mgt: added port Fa0/24 on gce 0100.5e01.0101, Vlan 1
IGMPSN: group: Created group 239.1.1.1
IGMPSN: Add v2 group 239.1.1.1 member port Fa0/4, on Vlan 1
L2MM: Add member: gda:0100.5e01.0101, adding Fa0/4
IGMPSN: mgt: added port Fa0/4 on gce 0100.5e01.0101, Vlan 1
IGMPSN: group: Added port Fa0/4 to group 239.1.1.1
IGMPSN: group: Forwarding 239.1.1.1 report to router ports

SW2 learns that FastEthernet0/24 is a router port and forwards the membership report on that interface.

We can also see it with the show command:

SW1#show ip igmp snooping querier 
Vlan      IP Address               IGMP Version   Port             
-------------------------------------------------------------
1         192.168.1.253            v2            Switch 

SW2#show ip igmp snooping querier 
Vlan      IP Address               IGMP Version   Port             
-------------------------------------------------------------
1         192.168.1.253            v2            Fa0/24 

And we can see the interfaces where we forward traffic destined to 239.1.1.1 to:

SW1#show ip igmp snooping groups 
Vlan      Group                    Type        Version     Port List
-----------------------------------------------------------------------
1         239.1.1.1                igmp        v2          Fa0/3, Fa0/24

SW2#show ip igmp snooping groups 
Vlan      Group                    Type        Version     Port List
-----------------------------------------------------------------------
1         239.1.1.1                igmp        v2          Fa0/4, Fa0/24

Problem solved. If your goal is to make multicast work within a VLAN without a multicast router, there’s nothing else you need to know. This command is the best solution and simple to implement.

Solution 2: PIM on SVI interface

An alternative to the ip igmp snooping querier command is to enable PIM on one of your SVI interfaces. Once you do this, your switch will act as a multicast router and will send general queries. Not all switches will support this though:

SW1(config)#no ip igmp snooping querier

SW1(config)#interface Vlan 1
SW1(config-if)#ip pim sparse-mode

On my Cisco Catalyst 3560 switches, “ip pim sparse-mode” is a hidden command. If you are unsure if your switch supports PIM on SVI interfaces, give it a try anyway.

Let’s verify our work:

SW1#show ip igmp snooping querier 
Vlan      IP Address               IGMP Version   Port             
-------------------------------------------------------------
1         192.168.1.253            v2            Router 

Above you can see that SW1 sees its own IP address as the querier. Note that the port now shows up as “Router”.

With SW1 producing general queries, both switches now know where to forward multicast traffic to:

SW1#show ip igmp snooping groups 
Vlan      Group                    Type        Version     Port List
-----------------------------------------------------------------------
1         239.1.1.1                igmp        v2          Fa0/3, Fa0/24

SW2#show ip igmp snooping groups
Vlan      Group                    Type        Version     Port List
-----------------------------------------------------------------------
1         224.0.1.40               igmp        v2          Fa0/24
1         239.1.1.1                igmp        v2          Fa0/4, Fa0/24

Both switches know where to forward multicast traffic to.

Solution 3: Static mrouter port

What if we don’t want SW2 to dynamically learn the mrouter port? We can also configure a static entry. First let’s remove PIM on SW1:

SW1(config)#interface Vlan 1
SW1(config-if)#no ip pim sparse-mode

Now we can use the following command on SW2:

SW2(config)#ip igmp snooping vlan 1 mrouter interface FastEthernet 0/24

This tells SW2 to use FastEthernet0/24 as the mrouter port. When it receives membership reports, it will forward them on this interface. We can verify it with the following show command:

SW2#show ip igmp snooping mrouter 
Vlan    ports
----    -----
   1    Fa0/24(static)

Note that it shows up as “static”. Let’s verify if this works…I’ll configure H2 to leave and rejoin the multicast group:

H2(config)#interface FastEthernet 0/1
H2(config-if)#no ip igmp join-group 239.1.1.1
H2(config-if)#ip igmp join-group 239.1.1.1 

Here’s the debug output:

SW2#
IGMPSN: group: Received IGMPv2 report for group 239.1.1.1 received on Vlan 1, port Fa0/4
L2MM: Add member: gda:0100.5e01.0101, adding Fa0/24
IGMPSN: mgt: added port Fa0/24 on gce 0100.5e01.0101, Vlan 1
IGMPSN: group: Created group 239.1.1.1
IGMPSN: Add v2 group 239.1.1.1 member port Fa0/4, on Vlan 1
L2MM: Add member: gda:0100.5e01.0101, adding Fa0/4
IGMPSN: mgt: added port Fa0/4 on gce 0100.5e01.0101, Vlan 1
IGMPSN: group: Added port Fa0/4 to group 239.1.1.1
IGMPSN: group: Forwarding 239.1.1.1 report to router ports

Above you see that SW2 forwards the membership report to SW1. This allows SW1 to learn that it should forward multicast traffic to SW2.

This solution works but it’s not very scalable…

Solution 4: Static multicast entry

Another static option. We can manually configure the switches and tell them where they have to forward multicast traffic to. Let’s remove the previous command first:

SW2(config)#no ip igmp snooping vlan 1 mrouter interface FastEthernet 0/24

Now I will create two static entries in the MAC address table:

SW1(config)#mac address-table static 0100.5e01.0101 vlan 1 interface FastEthernet 0/3 FastEthernet 0/24

SW2(config)#mac address-table static 0100.5e01.0101 vlan 1 interface FastEthernet 0/4

The MAC address that you see above matches destination 239.1.1.1.1. SW1 will forward this traffic on its FastEthernet 0/3 and 0/24 interfaces. SW2 will forward it on its FastEthernet 0/4 interface.

We can verify this by checking the MAC address table:

SW1#show mac address-table multicast 
Vlan    Mac Address       Type        Ports
----    -----------       ----        -----
   1    0100.5e01.0101    USER        Fa0/3 Fa0/24 

SW2#show mac address-table multicast 
Vlan    Mac Address       Type        Ports
----    -----------       ----        -----
   1    0100.5e01.0101    USER        Fa0/4 

This solution works but it’s not scalable at all. On each switch, you’ll have to manually add/edit these entries.

Solution: disable IGMP snooping

Last but not least, you can disable IGMP snooping and treat multicast traffic like broadcast traffic…flooding it everywhere:

SW1(config)#no ip igmp snooping 

SW2(config)#no ip igmp snooping 

That’s it.

Conclusion

You have now learned how IGMP snooping relies on a mrouter port in the network and seen a “before” and “after” scenario. If you don’t have a multicast router in your network, it’s best to enable the IGMP snooping querier option (solution 1) so that your switch starts sending general queries, allowing other switches to learn a mrouter port.

You have also seen some of the other solutions. These might be useful to know on a CCIE lab exam where they want you to solve a L2 multicast problem while prohibiting you from using certain solutions.

I hope this lesson has been useful, if you have any questions feel free to leave a comment.