Yes, you are correct. If you do it the way I described previously, you may find that snooping is enabled on the particular VLAN, but it is disabled globally, so no snooping actually takes place!!
I went in and did some more labbing and I have found the following:
In order to get it to work, you need to first enable IGMP snooping globally using the ip igmp snooping command. This will enable the feature globally on the device, and will by default cause all VLANs to participate.
Now if you donât want some VLANs to participate, then you can remove them from the feature by issuing the no ip igmp snooping vlan command. This way snooping will only operate on the remaining VLANs. You can issue the show ip igmp snooping command to then see which VLANs are active. Below you can see a situation where I have enabled snooping only on VLAN1 and disabled it on VLANs 10 and 20, but I still get the multicast router appearing as a querier:
SW1#show ip igmp snooping
Global IGMP Snooping configuration:
-------------------------------------------
IGMP snooping : Enabled
IGMPv3 snooping : Not supported
Report suppression : Enabled
TCN solicit query : Disabled
TCN flood query count : 2
Robustness variable : 2
Last member query count : 2
Last member query interval : 1000
Vlan 1:
--------
IGMP snooping : Enabled
IGMPv2 immediate leave : Disabled
Multicast router learning mode : pim-dvmrp
CGMP interoperability mode : IGMP_ONLY
Robustness variable : 2
Last member query count : 2
Last member query interval : 1000
Vlan 10:
--------
IGMP snooping : Disabled
IGMPv2 immediate leave : Disabled
Multicast router learning mode : pim-dvmrp
Robustness variable : 2
Last member query count : 2
Last member query interval : 1000
Vlan 20:
--------
IGMP snooping : Disabled
IGMPv2 immediate leave : Disabled
Multicast router learning mode : pim-dvmrp
Robustness variable : 2
Last member query count : 2
Last member query interval : 1000
SW1#show ip igmp snooping querier
Vlan IP Address IGMP Version Port
-------------------------------------------------------------
1 192.168.1.254 v2 Gi0/1
I simulated this scenario in Cisco IOU. It looks like IGMP interception doesnât work properly in switch, so one host is receiving otherâs report message so it skips to send itâs report message to IGMP querier. So eventually would remove the host from snooping table as there might be a chance that, that host will not be sending IGMP report messages to the querier as per IGMP report suppression mechanism.
The logs are like following:
Host2:
*Mar 16 15:28:20.840: %SYS-5-CONFIG_I: Configured from console by console
*Mar 16 15:29:14.889: IGMP(0): Received v2 Query on Ethernet0/2 from 192.168.1.254
*Mar 16 15:29:14.889: IGMP(0): Set report delay time to 8.8 seconds for 239.1.1.1 on Ethernet0/2
*Mar 16 15:29:19.529: IGMP(0): Received v2 Report on Ethernet0/2 from 192.168.1.1 for 239.1.1.1
*Mar 16 15:29:19.529: IGMP(0): Received Group record for group 239.1.1.1, mode 2 from 192.168.1.1 for 0 sources
*Mar 16 15:29:19.529: IGMP(0): Cancel report for 239.1.1.1 on Ethernet0/2
SW1:
*Mar 16 15:25:20.716: IGMPSN: Received IGMPv2 Report for group 239.1.1.1 received on Vlan 1, port Et0/1
*Mar 16 15:25:20.717: IGMPSN: group: Received IGMPv2 report for group 239.1.1.1 received on Vlan 1, port Et0/1
*Mar 16 15:25:20.717: IGMPSN: Add v2 group 239.1.1.1 member port Et0/1, on Vlan 1
*Mar 16 15:25:20.717: IGMPSN: group: Added port Et0/1 to group 239.1.1.1
*Mar 16 15:25:20.717: IGMPSN: group: Forwarding 239.1.1.1 report to router ports
SW1#
*Mar 16 15:25:24.876: L2MM: Add member: gda:0100.5e01.0101, removing Et0/2
*Mar 16 15:25:24.876: IGMPSN: mgt: deleted port Et0/2 on gce 0100.5e01.0101, on Vlan 1
SW1#
In addition to this adding the current settings of IGMP snooping in the switch.
SW1#show ip igmp snooping
Global IGMP Snooping configuration:
-------------------------------------------
IGMP snooping : Enabled
IGMPv3 snooping : Not supported
Report suppression : Enabled
TCN solicit query : Disabled
TCN flood query count : 2
Robustness variable : 2
Last member query count : 2
Last member query interval : 1000
Vlan 1:
--------
IGMP snooping : Enabled
CAPWAP enabled : Disabled
IGMPv2 immediate leave : Disabled
Multicast router learning mode : pim-dvmrp
CGMP interoperability mode : IGMP_ONLY
Robustness variable : 2
Last member query count : 2
Last member query interval : 1000
SW1#
Looking at your configuration, report suppression is enabled, so you shouldnât be seeing this behavior. However doing a little more research, I have found that IGMP snooping on Cisco IOU does seem to have some problems. Others have reported that it is not functioning as expected, and it could simply be a bug. Still others have mentoined that IOU only approximates IOS functionality and may not be true to actual device behavior. Take a look at the following posts on the GNS3 forum and Cisco community: https://www.gns3.com/community/featured/iou-and-igmp-snooping
This is mostly on topic. With multicast do host ever send packets to the source. Furthermore, is there a way for an application to request that the source start transmitting.
Within the operation of multicast as a network communication mechanism, the host receiving multicast traffic does not need to communicate directly with the multicast source. Using multicast mechanisms it simply becomes registered to particular multicast groups so that it can receive multicast traffic. This registration requires control plane communication with the multicast routers on the network.
Now having said that, when you do use multicast services, such as streaming video in an enterprise network, you are using some application, either over a web browser, or using a specific software on your device. This software can and does in most cases communicate with the source of the multicast traffic, but not within the framework of multicast. To obtain services, you may need to login, or to choose the media you want to stream to your device. In this process, negotiation is indeed taking place between the host and the source, but on the Application layer within the framework of that particular software. Such communication does not take place within the realm of multicast mechanisms that operate in the background.
Secondly, there is no way, within the multicast mechanisms, for a host to tell a source to start transmitting. When using sparse mode, you can tell the router closest to the source to stop forwarding multicast traffic, but you canât tell the source to do so. Using the application layer of the software being used, this may be possible, but that is not within the realm of the operation of multicast but within the realm of the operation of the software being used.
Hello,
I have gone through the Lesson and the discussion. However, I still have a question.
For example :
on the core Switch I have multiple SVI Interfaces for vlans. The Vlans are allowed through a port-channel to the distribution Layer switches and from distri to access layer.
From my prior design knowledge and reading through this educative lession i have made a plan
to implement the following configuration on the core switch.
Int Vlan 2
Ip pim sparse-mode
Ip add 19.168.2.1 255.255.255.0
igmp snooping querier
Int Vlan 5
Ip pim sparse-mode
Ip add 19.168.5.1 255.255.255.0
igmp snooping querier
Please kindly confirm if I need to add any extra or remove some configurations.
Thanks
Notice: all Ip addresses are not used in any production Network.
The scenario that you are describing is the implementation of multicast without a multicast router. The following lesson describes this in great detail:
Now in this lesson, it describes the use of IGMP in an environment that has a multicast-enabled router, and in contrast, describes a situation without such a router. It includes several solutions to correctly implementing IGMP and multicast in such an environment. One solution is to enable an SVI interface of a switch to function as an IGMP querier. Another solution is to enable PIM on the SVI interface of an L3 switch, essentially introducing a multicast router.
Now in your scenario, you seem to have done both simultaneously. If your switch supports the ip pim sparse-mode command on the SVI interfaces of the VLANs in question, then you donât need to enable the IGMP snooping querier, since by enabling PIM, you essentially enable a multicast ârouterâ on the network.
I believe that your configuration above should function since the igmp snooping querier will simply add no additional functionality to the SVI. Ideally, this command should be removed.
Review the above lesson for more detailed information on this configuration.
I tried to find it in the comments but could not find it.
Query:
When switch receives IGMP leave report msg from the host. The switch sends Group Specific IGMP query to the port on which host is connected just to check if there are any other hosts listening on the port. What source IP address does the switch in the IGMP query msg? Does it use the source IP address of the IGMP router?
Remember that IGMP snooping is a Layer 2 feature, and has a scope of operation that is confined within a specific broadcast domain/VLAN. One of the prerequisites for IGMP snooping to operate in a specific VLAN is that the VLAN interface is assigned an IP address. This can be seen on page two of the following Cisco Documentation as a prerequisite for IGMP snooping:
It is this IP address that is used as the source address for IGMP. Specifically, it says:
Configure an IP address on the VLAN interface. When enabled, the IGMP snooping querier uses the IP address as the query source address.
To determine the current querier IP address, use the following command:
SW1#show ip igmp snooping querier
Vlan IP Address IGMP Version Port
-------------------------------------------------------------
1 192.168.1.254 v2 Gi0/1
The result will show you the source IP address for IGMP snooping messages for each individual VLAN.
HI Rene, minor one but two typos in the following paragraph:
When there are multiple receivers on the network then using multicast traffic sounds like a good idea. Itâs more efficient than unicast since we only have to have to 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.
on a large network I have detected traffic
unnecessary multicast on the network.
to limit / eliminate these traffic I use igmp-snooping or access-list?
By default, a switch will treat multicast traffic the same as broadcast traffic. This is detrimental to network performance for obvious reasons. So if you have multicast traffic on your network that is valid, then the best solution would be to use IGMP snooping. This will limit multicast traffic to the ports that actually need it without eliminating it completely and disabling the services using that traffic. This is definitely an improvement, however, it is not enough to deal with unauthorized multicast services.
If youâre not running any multicast applications and youâre still seeing unauthorized multicast traffic, then you should do the following:
Try to find the source of the traffic. It may be from a service you didnât set up, but may still be needed, like multicast communication for routing protocols such as OSPF or EIGRP. Simply blocking all multicast traffic could cause legitimate operations to fail.
If the source of the traffic is an unauthorized service or host, then the best practice is to eliminate that device or service.
If you still want to limit or filter multicast traffic, you can do so by creating an access list that covers all multicast groups and implementing it on a network interface. This should be done with great caution, as many services need multicast, and this could, as mentioned before, disrupt legitimate services.
An alternative is to use the ip igmp access-group command in combination with IGMP snooping. This will not completely eliminate multicast, but it can be used to restrict hosts to joining only multicast groups that are permitted by a particular standard ACL. This way, by limiting receivers and using IGMP, you can eliminate the unwanted multicast traffic.
More information on this command can be found here:
I followed the lesson and successfully configured igmp snooping on switch. I decided to create an own topology and had an issue that multicast traffics still be flooded out all ports. In the upload image. R4 is the source for group 225.1.2.3. R2, R3 is the receiver, R5 is not joining the multicast group. Except R5, the others router can reach each other by default route. Igmp snooping is configured on switch, use iou image. When ping from R4 to 225.1.2.3 group, traffic still flow on the link between R5 and switch. I read about link-local multicast and decide to use 225.1.2.3, but the issue still there. Is there a bug or something else ?
Since you were able to successfully recreate the lab and you got snooping to work, then I suggest that you compare your lab configuration from the lesson, with the configuration in your switch here. From your description, there is no reason that I can see for the behavior you are describing. Without knowing any more about your particular setup, the only thing I can suggest is a misconfiguration in the switch. Can you take a look and do some troubleshooting to determine the reason for this traffic to R5? Take a look at this Cisco documentation for some guidelines and tips for troubleshooting IGMP and multicast in general:
I lab using Cisco IOL/IOU images and from what I can see, IGMP snooping is enabled, but it doesnât seem suppress the âreport suppressionâ. I still see one of the two hosts cancel its report each time a general query is received. Additionally when each host leaves the group, the Router gets both leave messages.
I did try configuring on the switch no ip igmp snooping report-suppression but that didnât make any difference. The output seems to be the same as in your video so Iâm assuming this is one of those features not fully operational on IOU images.
SW1#show ip igmp snooping
Global IGMP Snooping configuration:
-------------------------------------------
IGMP snooping : Enabled
IGMPv3 snooping : Not supported
Report suppression : Enabled
TCN solicit query : Disabled
TCN flood query count : 2
Robustness variable : 2
Last member query count : 2
Last member query interval : 1000
Vlan 1:
IGMP snooping : Enabled
IGMPv2 immediate leave : Disabled
Multicast router learning mode : pim-dvmrp
CGMP interoperability mode : IGMP_ONLY
Robustness variable : 2
Last member query count : 2
Last member query interval : 1000
SW1#show ip igmp snooping groups
Vlan Group Version Port List
---------------------------------------------------------
1 224.0.1.40 v2 Et0/0
1 239.1.1.1 v2 Et0/1, Et0/2
In my lab E0/1 and E0/1 are ports facing the host. E0/0 is facing the router but I donât see that listed for 239.1.1.1. Anyway thanks for the lesson! Also in earlier lessons when report suppression was demonstrated in debug output, had you disabled IGMP snooping?
Thanks for sharing your experience with us and the details of your lab.
Hmm, thatâs interesting. I assume that this may have to do with the emulation environment you are using. What are using to emulate this?
As for the earlier lessons on IGMPv2 where support suppression is described, Rene uses the debug ip igmp command to view these exchanges. Take a look at the following lesson for more info:
Thanks for the reply Laz. I am using Cisco IOL images in EVE-NG. These are âexperimentalâ images so it might be that they donât support all features.
On the IGMPv2 lesson, would Rene have disabled IGMP snooping in order to see the host routers suppress sending of IGMP Joins? (Due to receiving another routers joIN)? Iâm assuming this is the only way as this doesnât happen when IGMP snooping is enabled. Thanks.
Yes, that is correct, in order for us to see such behavior, IGMP snooping should not be enabled on the switch itself. Although Rene hasnât mentioned it explicitly here, he would have had to do it in order to see such results.
I will suggest to him to mention about this, or at least include a note that specifies that if IGMP snooping were enabled, the behavior would be different.
