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:
IGMP Snooping with routerAbove 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.


Configurations

Want to take a look for yourself? Here you will find the startup configuration of each device.

H1

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

H2

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

R1

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

S1

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

SW1

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

SW2

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:

IGMP snooping without router

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?

We're Sorry, Full Content Access is for Members Only...

If you like to keep on reading, Become a Member Now! Here is why:

  • Learn any CCNA, CCNP and CCIE R&S Topic. Explained As Simple As Possible.
  • Try for Just $1. The Best Dollar You've Ever Spent on Your Cisco Career!
  • Full Access to our 651 Lessons. More Lessons Added Every Week!
  • Content created by Rene Molenaar (CCIE #41726)

555 Sign Ups in the last 30 days

satisfaction-guaranteed
100% Satisfaction Guaranteed!
You may cancel your monthly membership at any time.
No Questions Asked!

Forum Replies

  1. I have one question related to a scenario similar to the topology shown early in this article with the multicast router.

    Assume you still have the source, various L2 switches as shown, and the router R1, however the receivers for the multicast receivers are actually on the far side of R1. Assume there are one or more routers connected to R1 that are not shown. The receivers we are concerned about are connected to those routers. A loopback on R1 is configured as the RP for the multicast group(s) in question.

    How does SW1 know to forward the multicast traffic out

    ... Continue reading in our forum

  2. Hi Vilhelm,

    IGMP Snooping (querier) is used for multicast traffic within the VLAN. If you want to get multicast traffic from one VLAN to another, you will have to route it. You’ll need a device with multicast routing enabled.

    Rene

  3. Hello Vanya,

    Your traffic should only be flooded if your switches don’t have a “router port” for multicast in your topology. This might depend on your switch model / IOS version though. Most switches will drop membership reports and flood your multicast traffic.

    Adding snooping querier to your interfaces adds a “router port” to the topology so it solves the problem of flooding, not causing it.

    Do you have multiple VLANs? Is it enabled on each VLAN?

    SW1#
    interface vlan 1
     ip igmp snooping querier
    

    There is no need to enable PIM on any interfaces in your case, yo

    ... Continue reading in our forum

  4. For IGMP snooping without a router, it states that “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.” But in the paragraph above it states “switches are flooding all multicast traffic now, treating it like broadcast traffic.” If it’s flooding all ports, then it would seem to me that SW2 would receive the traffic and then in turn H2 would. Please explain why it doesn’t quite work that way. Thank you.

  5. Hello Laz,
    thanks for your reply and your answers. I already studied your mentioned lesson before my post. Main difference between the lessons architecture and mine was, that I had two separate Subnet, whereas in the lesson all equipments were located in the same subnet.

    Best regards, Florian

16 more replies! Ask a question or join the discussion by visiting our Community Forum