Question with the send-only source.
I know you said cheap switches would just flood, but higher switches will send to the router.
For the second option namely sending it only to the router, how dose the switch learn what port the router is on? Since the source is sending there would have been no membership queries for the igmp snooping to learn about the router’s port.
So the question is how dose the switch learns about the router’s port in the send-only case?
Hello Patrick
In the Configuration section of the lesson, you can see the process that is followed by the router and switch with the debugging that has been enabled.
Specifically, as soon as multicast routing is enabled on the router, it sends out an IGMP packet. The switch receives that packet and realizes it is a router on that port. Thus, it will set the IGMP snooping querier as the IP address of the router. You can see all of this in the lesson like so:
SW1#
IGMPSN: router: Received IGMP pak on Vlan 1, port Gi0/1
IGMPSN: router: Is not a router port on Vlan 1, port Gi0/1
IGMPSN: router: Is not a router port on Vlan 1, port Gi0/1
IGMPSN: router: Created router port on Vlan 1, port Gi0/1
IGMPSN: router: Learning port: Gi0/1 as rport on Vlan 1
The received IGMP packet on Gi0/1 indicates to the switch that the router is on that port. Take a look at the resulting querier that has been set up on the switch:
SW1#show ip igmp snooping querier
Vlan IP Address IGMP Version Port
-------------------------------------------------------------
1 192.168.1.254 v2 Gi0/1
So at this point, the switch knows the IP address of the multicast router (querier) as well as the port to which it is connected.
So in the send only source scenario, the switch is aware of the querier on the network, and can choose to send such multicast traffic only to the router.
I hope this has been helpful!
Laz
Got it, thank you! That makes things much clearer for me.
Ok, I am a bit confused, you mentioned an “internal interface” Is this the same thing as a Switch virtual interface?
My understanding is that the switch virtual interface is used to manage the switch. My confusion here is with the internal interface assuming that is an SVI would that mean IGMP would not work without it? From the wording of the lesson, it sounds like the cam table points frames to the Switch virtual interface.
Hello Patrick
No, the internal interface in this instance is not the same thing as an SVI. The internal interface is simply a logical construct used within the context of IGMP snooping to describe how the CPU learns about MAC addresses and the interfaces to which they correspond so that it can populate the MAC address table or CAM table.
An SVI, on the other hand, if it exists in an IGMP snooping scenario, will behave much the same as the physical interfaces of the switch shown in the lesson. It may also participate as the IGMP snooping querier, that is, the Layer 3 interface found on that particular network segment, just like the R1 router.
For more about the SVI interface, take a look at this NetworkLessons Note.
I hope this has been helpful!
Laz
Thank you for clearing that up for me.
Hi Renne,
How does the router actually forward the Multicast packet to the multicast source?
if in this case, it is only listening for igmp on 224.0.0.x (to forward to all igmp in any multicast group)?
Hello Champion
Hmm, I’m not sure I understand your question. The router doesn’t forward multicast packets to the source. It forwards multicast packets sent by the source to the intended multicast destinations based on the multicast group (multicast IP address) that is in the destination of the multicast packets. In such cases, IGMP is used by hosts to indicate that they are interested in receiving multicast traffic for that particular multicast group.
Now when it comes to the use of the 224.0.0.x series of multicast addresses, these are a specialized range of addresses (from 224.0.0.0 to 224.0.0.255) which are reserved for use by network protocols on a local network segment. See the following Cisco documentation about these addresses:
These addresses will never be routed by any routers. As stated in Rene’s post, these addresses are ignored by IGMP, and are actually treated as broadcast traffic when received by a switch.
I hope this has been helpful!
Laz
Thanks Lagapides.
I got it now.
Regards
Hi,
I need to enable fast leave/ immediate leave on several cisco 9300 switches.
I can’t see this option available under each interface and it only seems available globally and only then with an access list tied to it.
Does anyone know if there is anyway to enable it under each specific interface ?
Or is there a way to enable globally on the switch without an access list and then switch it off on the trunks?
I need to use this without having access lists and/or to be able to enable it per interface.
I don’t see these option on the 9300’s.
Thanks
Is there a way to force IGMP snooping to process local multicast traffic in the 224 range?
Edit: The switch is Filtering Unregistered Multicast Traffic on each port but we want to allow specific addresses in the 224 range.
Hello Sean
I have been unable to find the command reference for the 9300 switch that includes this particular command. I’ve been looking at the following Cisco site:
From what I can find here, the fast-leave keyword is not available, at least on the platforms/versions that I have looked at. Can you share the model of your switch as well as the IOS version it is running?
Now having said that, I have found some more info that may help you to achieve what you’re looking for.
First of all, looking at some other platforms, such as the 7600 series, the command is available under the VLAN interface configuration mode only. Check to see if that is the case in your platform as well. The related command reference can be found here.
One additional option that you can use as a workaround, which I cannot verify as I don’t have immediate access to a 9300 platform, is the following:
You may be able to enable fast-leave globally and then selectively disable it on the interfaces you choose. This can be done like so:
First, enable IGMP fast-leave globally:
(config)# ip igmp snooping fast-leave
Next, create a dummy access-list with a deny statement for a multicast address that is not in use in your network:
(config)# ip access-list extended dummy-igmp-acl
(config-ext-nacl)# deny ip any host 224.0.0.254
(config-ext-nacl)# permit ip any any
Now, apply the dummy access-list to the VLAN or VLANs on which you want to disable fast-leave:
(config)# vlan configuration [vlan-id]
(config-vlan-config)# ip igmp snooping access-group dummy-igmp-acl
Replace [vlan-id] with the VLAN ID on which you want to disable fast-leave. This configuration will have the effect of enabling the feature globally but disabling it for the specified VLAN(s), essentially making it work on a per-interface basis.
Try it out and let us know if this works for you.
I hope this has been helpful!
Laz
Hello Trenton
First of all, when you mention the 224 range, I assume you’re talking about the 224.0.0.0/24 range, which is reserved for link-local multicast traffic, and not the 224.0.0.0/4 range, which is the full multicast range of addresses.
Regardless, suppose you want to allow specific multicast addresses while continuing to filter unregistered multicast traffic on a Cisco switch. In that case, you can create an IGMP access group to define a filter list for the desired multicast addresses. You can do this like so:
Let’s say I want to allow the 224.0.1.15 and 224.0.1.18 groups on VLAN 12, even though they represent unregistered multicast traffic, i.e., no host has requested multicast traffic from these sources. I’ve chosen the address arbitrarily. To create an IGMP access group and allow these groups, you can do the following:
switch(config)# ip access-list extended AllowUnregMulticast
switch(config-ext-nacl)# permit igmp any host 224.0.1.15
switch(config-ext-nacl)# permit igmp any host 224.0.1.18
You can then create an IGMP access group that references this access list:
switch(config)# ip igmp access-group AllowUnregMulticast
Then you can apply this IGMP access group to the desired VLAN:
switch(config)# ip igmp snooping vlan 12 access-group AllowUnregMulticast
This configuration will allow the switch to process the specified multicast addresses, while still filtering unregistered multicast traffic on the configured VLAN.
For more information about the igmp access-group command, take a look at this Cisco command reference:
I hope this has been helpful!
Laz
Hey Lazaros,
Thank you for the response! I missed important information and I apologize for that. We are also running IOS XE and the ip igmp access-group command is not available. Is there any other recommended alternatives ? I was thinking about statically creating groups and forwarding them to the correct ports but I would rather find another way.
Hello Trenton
Yes, alternatively, you can use a VLAN access map to filter out multicast traffic based on the desired address. Here is a sample configuration to achieve this. As in my previous post, let’s say I want to allow the 224.0.1.15 and 224.0.1.18 groups on VLAN 12:
Create an access list that matches the addresses I want:
switch(config)# ip access-list extended AllowUnregMulticast
switch(config-ext-nacl)# permit igmp any host 224.0.1.15
switch(config-ext-nacl)# permit igmp any host 224.0.1.18
switch(config-ext-nacl)# exit
switch(config)#
Then I create a VLAN access map and match the ACL I created before and forward that matched traffic, and drop unmatched traffic:
switch(config)# vlan access-map FilterMulticast 10
switch(config-access-map)# match ip address AllowUnregMulticast
switch(config-access-map)# action forward
switch(config-access-map)# exit
switch(config)# vlan access-map FilterMulticast 20
switch(config-access-map)# action drop
switch(config-access-map)# exit
switch(config)#
Finally, you can now apply the VLAN access map to the VLAN you want to filter multicast traffic for:
switch(config)# vlan filter FilterMulticast vlan-list 12
Keep in mind that the exact commands and available options may vary depending on the specific Cisco switch model and IOS version, but you can experiment with it and let us know. For more information on VLAN access maps, take a look at the following lesson:
I hope this has been helpful!
Laz
Thank you so much, I will give this a try. The only worry I have while sitting at home is that IGMP Snooping will trump the VLAN access map for Multicast addresses in the 224.0.0.0/24 range. I will let you know how this goes. Thanks again.
Hello Trenton
The truth is I haven’t actually applied this in a real multicast topology, but in principle, it should be fine. Take a look and let us know your results, I’d be interested to find out how it went…
Laz
Lazaros,
So it looks like I was chasing the rabbits tail down a rabbit hole. We have services/appliances sending out traffic in the 224.0.0.0/24 range and I was was wondering why IGMP Snooping wasn’t processing that traffic; however, the switch forwards all that traffic to all ports within the broadcast domain so with proper design we should be able to optimize the traffic flow. I was thrown off by the debug logs associated with IGMP Snooping. 
Hello Trenton
Thanks for following up on the topic! It’s very helpful for us and for all our readers to see, and it’s much appreciated.
Laz
Hello, everyone.
I am sligthly confused by these two sections:
Why is the term “L3-aware ASIC” specifically mentioned here? L3 means that the ASIC can also make routing decisions, correct? However, after viewing these two sections, I don’t see any routing mentioned at all, so what does the term “L3-aware ASIC” have to do with IGMP Snooping in this case? Regardless of whether the ASIC supports only L2 or both L2 and L3, it shouldn’t make much of a difference here if the switch isn’t going to perform routing, or?
One more thing. This explanation here (The first section)
In the next section with an ASIC, my understanding is that IGMP traffic is sent to the control plane, to the CPU for processing. However, multicast traffic for the specific groups is forwarded by using an ASIC, correct?
So what’s up with the MAC address table? I don’t think I quite understand what it says.
Anything you learn via IGMP Snooping is represented by the specific entry - 0100:5e01:0101 in this case, right?
So if traffic is destined for that multicast group that the switch learned about, it will only forward it out of the ports with the interested listeners. However, why is it classified as “non-IGMP”? The hosts can still send IGMP traffic (membership reports) to their own multicast group and that will be matched by the second entry in the CAM table. So this isn’t exactly “non-IGMP”, or is it?
Thank you.
David
