- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
08-03-2012 06:38 AM - edited 03-04-2019 05:09 PM
Hi all.
is it possible to block outgonig multicast L2 frames on an Ethernet port in outgoing direction on a 2960 Switch?
I tried the "switchport block multicast" command, but the description of this feature relates to only "unknown" multicast!?
But what means "unknown multicast"???
Even if activated, I see a lot of multicast traffic going out that port: IGMP, PIM, SSDP, HSRP, OSPF, .. and also pings and VLC streams to multicastaddresses (ip igmp snooping disabled).
I also tried to map a "mac access-list" to that port, but the "mac access-group" interface command is restricted to only incoming traffic.
Reason: we assume, that there are a couple of specific enddevices, that might react strange to some multicast. Therefor we would like to block outgoing multicast on that specific ports.
I tested it on a 2960 12.2(53)SE2
Any idea?
Thanks in advance
Hakan
Solved! Go to Solution.
- Labels:
-
Other Routing
Accepted Solutions

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
08-06-2012 07:53 AM
Also, you may want to change your deny line to "any 0100.5e00.0000 0000.00ff.ffff" if you're wanting to block all traffic...
HTH,
John

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
08-03-2012 07:04 AM
Hakan,
I don't have a switch to test with, but it sounds like you could configure igmp snooping along with the switchport block multicast and you should be set. Unknown multicasts act like broadcasts and flood every port. You could use the block multicast command on the switchport to cover that, and then use igmp snooping to have the switch know what hosts actually want multicast traffic. If a host is not sending a report for a group, that port is not listed in the valid receivers table on the switch. If your hosts that "may react strange" to multicast isn't trying to join a group, then in theory you should never send an igmp report to the switch.
HTH,
John
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
08-03-2012 07:37 AM
Hi John,
with my first tests, igmp snooping was enabled. The only difference in the result was, that I didn't see the VLC stream (to 239.x.x.x). Every other mentioned MC-Traffic was present anyway.
As soon as I disable igmp snooping, the stream also appears on that port.
1) ip igmp snooping + no switchport block multicast
does show every Multicast traffic, except the VLC stream
2) ip igmp snooping + switchport block multicast
does show every Multicast traffic, except the VLC stream
3) no ip igmp snooping + no switchport block multicast
does show every Multicast traffic, including the VLC stream
4) no ip igmp snooping + switchport block multicast
does show every Multicast traffic, including the VLC stream
As you can see 1+2 and 3+4 leads to the same result. Therefore I can not really understand the "switchport block multicast" function. If active or not, there is no difference in result!
By the way: A ping to a 224.0.0.x address is not blocked by igmp snooping, any else, e.g. 224.1.2.3, or 239.1.2.3 is blocked. Therefore I see all the network management stuff (OSPF, HSRP, etc.) even with igmp snooping enabled.
Do I understand you right, that "switchport block multicast" works in relation with igmp snooping???
But if so, I would not need it, because igmp snooping does it already, as seen above.
But anyway: is it possible, to block every traffic with a destination MAC address 01005e* to pass the interface?

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
08-03-2012 08:02 AM
The switchport block multicast isn't necessary for igmp snooping; they're different functions. You could try this:
switchport storm-control multicast level 0
switchport block multicast
HTH,
John
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
08-06-2012 05:19 AM
hmm, no, this doesn't work as well.
But as far as I know, the storm-control command, does match only to incoming traffic, not to outgoing, or not?
Now I found this interesting thread about the difference between igmp snooping and switchport block multicast:
https://learningnetwork.cisco.com/thread/10061
As far as I understand, the switchport block multicast matches only to frames without an IP header. And an "unknown" multicast means addresses that are "not well-known". This explains, why I see IGMP, HSRP, OSPF, etc. even with configured block multicast, because 1. they are known, and 2. they are L3.
Now I did a new test. Without block multicast I see a lot of well-known multicast as mentioned before. When I turn on block multicast, I see all this traffic as well. The only packets, that were seen without block multicast, but not after enabling it, were packets to an 33:33:00:x:x:x IPv6mcast address (e.g. DHCPv6 and SSDP messages). I guess, because this addesses are "unknown".
Multicast to private Multicast adresses is seen, as far as I disable igmp snooping, but not when turning igmp snooping on. This is actually independently of switchport block mulsticast.
Well, I learned something interesting new now, but unfortunately, this does not match my requirement, because all I want do to, is block any multicast, that is destined to 01:00:5e:* :-(
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
08-06-2012 05:33 AM
try IGMP Profile
hope this help
if helpful rate
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
08-06-2012 06:25 AM
thank's but this would not work. In the config. guide is written:
"IGMP filtering controls only IGMP membership join reports and has no relationship to the function that directs the forwarding of IP multicast traffic."
I think any IGMP Feature would not work, because we are talking about L2 Multicast.
What would help would be an MAC ACL that denys any to 01:00:5e.x.x.x, but it is not possible to bind that ACL in out direction on the interface.

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
08-06-2012 06:45 AM
I'm not sure how feasible this is in your situation, but maybe you should consider creating a vlan for this one port and making it a l3 vlan. Then you can control what comes in/out of the vlan on the svi that was created for the 1 port.
John
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
08-06-2012 07:21 AM
Well, that could be an idea. But the relevant network is already a firewalled vlan, with some special devices, that have to communicate directly with each other at subnet-level.
But I found another possible solution. I tested the MAC ACL on a 4510R-E/Sup6e, and there it is possible to map the ACL also in out direction.
mac access-list extended Block-L2-Multicast
deny any 0100.5e00.0000 0000.0011.1111
permit any any
c2960(config-if)#mac access-group Block-L2-Multicast ?
in Apply to Ingress
(3560 and 3750 are also limited to ingress)
c4510r(config-if)#mac access-group Block-L2-Multicast ?
in Apply to Ingress
out Apply to Egress
Therefore, if we find no other solution (maybe on the enddevice) to fix the problem, we could try it with a 45x series hardware.

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
08-06-2012 07:53 AM
Also, you may want to change your deny line to "any 0100.5e00.0000 0000.00ff.ffff" if you're wanting to block all traffic...
HTH,
John
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
08-06-2012 11:51 PM
oh yes, thank you, you are right.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
07-03-2013 04:49 AM
An alternative Solution;
Create vlan interface for the multicast required vlan and assign an IP address.
Join that interface vlan to the required multicast group with the following vlan interface command;
'ip igmp join-group 225.1.1.1'
Then enable igmp snooping querier with the following global command;
'ip igmp snooping querier'
After these steps, switch will create a multicast group client list and multicast packets will be delivered to only ports, which joined that multicast group.
Erkan
