IGMP filtering can be applied to a layer 3 interface or a layer 2 interface. The syntax to be able to apply this is different for each case. The lesson describes this syntax. Depending on if your interface Gi0/1/0 is layer 2 or layer 3 (I assume it is layer 2 by the context), the way of implementation is different.
For a layer 2 interface, you must create an IGMP profile, and then apply it to the interface.
Take a look at the lesson to see how it should be applied. You can also look at this more detailed Cisco documentation which describes it:
Thanx for your reply, I got your point. As per your suggestion, I have to apply a layer 2 igmp access-list on the port g0/1/0. But i also want to filter some tcp and udp traffic on this port. Previously i applied an extended outbound access-list on this port and found matches when run “show access-list” command for tcp and udp traffic but igmp matches were not there. So shall i apply igmp layer 2 filtering for igmp and for other filtering an extended access-list on the same port.
I am having concern about IGMP Snooping Filter. Could you please explain how the switch process L3 header of IP packets while the filter applied to L2 port. From my understanding in this specific example the switch is acting as L2 device but not L3 device, so it should handle the packets up to L2 headers based on source and destination MAC address, however in the IGMP snooping filter the L3 address specified for filtering multicast traffic. Appreciate, if you could provide more info about my concern.
In the lesson, we have two types of IGMP filtering being shown. One involves the implementation on a routed interface, while the other on a Layer 2 interface.
For the Layer 2 interface, your concern makes sense. How can a Layer 2 interface “know” about things that are happening at Layer 3? Well, if a switch has the capability of creating and applying IGMP profiles, it must indeed decapsulate each frame and examining the Layer 3 IP header. It must do this to determine if the multicast address being used belongs to the range of addresses defined in the profile.
Yes that sounds good. You should filter regular user traffic using an access list as you have described it, but for IGMP filtering, if it is a layer 2 port, filtering should be done by creating an IP IGMP profile and applying it using the ip igmp filter command as shown in the lesson.
Thanks for your reply. I am having another question. Trying to simulate IGMP filtering in Cisco IOS switch which is Cisco 3600 in GNS, however it looks like ip igmp profile command is not accepted by switch. Could you please provide some advice for this simulation?
Are you attempting to apply it to a Cisco 3600 series device such as the 3650 catalyst? It also depends upon the IOS version you are using as well. The specific command may not be available on that particular IOS for that particular platform. For the 3650, this command was introduced in IOS XE 3.3SE according to this Cisco command reference documentation.
Make sure that your IOS/platform supports the feature. If the command is unavailable, it most likely doesn’t support it…
You may also find the Cisco Feature Navigator useful as well to determine if your IOS/platform supports the feature.
I am having a bit of trouble understanding the use of this feature.
If I am filtering at the router level, Is this stop someone say on a subnet on the router from joining the multicast group? I guess it would be the same with the switch. But rather than on a subnet level could be an added per port to prevent certain devices from trying to join.
When it comes to applying an IGMP filter for a router, keep in mind that it is applied on a per-interface basis. The filtering that takes place is the filtering of actual IGMP join messages, so it is control-plane packets that are filtered. It is not restricted to particular subnets since multicast group addresses can be routed.
Similarly, when applied to a switch with IGMP snooping, it is applied either to a Layer 2 interface, a VLAN, or a layer 3 SVI interface. In this case, the particular multicast group addresses are filtered when they pass through the location where IGMP filter is applied. Once again, the filtering is applied on the IGMP join messages and is applied on any such join messages regardless of whether they are on the same or a different subnet.
Laz, Rene,
Can you please help understanding something in detail:
I’ve noticed that you have configured a standard ACL to block H1 to join the mcast group:
R1(config)#ip access-list standard LIMIT_IGMP
R1(config-std-nacl)#deny host 239.2.2.2
On a standard ACL, you block the source IP address but here you want to block the destination IP.
Does this work because of the “igmp” kw when applying the ACL?
I’ve tried to do the same but using an extended ACL and, as expected, it also worked (but I needed to define the mcast IP as destination IP)
R1#sh access-lists
Standard IP access list limit_igmpt
Extended IP access list BLOCKMCASTGROUP
10 deny ip any host 239.2.2.2 (9 matches)
20 permit ip any 224.0.0.0 15.255.255.255 (74 matches)
R1# show run int gig0/0
interface GigabitEthernet0/0
ip address 192.168.1.254 255.255.255.0
ip access-group BLOCKMCASTGROUP in
ip pim dense-mode
ip igmp access-group BLOCKMCASTGROUP
duplex auto
speed auto
media-type rj45
end
Yes, a standard access list will indeed match the source IP address. However, this is the case only when you apply the ACL on an interface. In this particular case, you are using the ip igmp access-group command to reference the ACL to match a particular multicast IP address. In this case, the multicast group will be matched. As stated in this Cisco command reference for the ip igmp access-group command:
Use the ip igmp access-group command to filter groups from Internet Group Management Protocol (IGMP) reports by use of a standard access list … This command is used to restrict hosts on a subnet to joining only multicast groups that are permitted by a standard IP access list…
So in this scenario there is really no concept of source or destination address. It simply restricts a host from joining the multicast group indicated in the ACL.
As stated in the same command reference indicated above, when using an extended ACL the command is used to:
…restrict hosts (receivers) on a subnet to membership to only the (S,G) channels that are permitted by an extended IP access list.
Note that only IGMPv3 accommodates the extended access lists which allow you to leverage source-specific multicast (SSM). In the extended access list, you can indicate the source of the multicast traffic as an additional parameter. Does that make sense?