cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
25175
Views
24
Helpful
11
Replies
Highlighted
Beginner

Block outgoing Multicast on L2 Port

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

1 ACCEPTED SOLUTION

Accepted Solutions
Highlighted

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

HTH, John *** Please rate all useful posts ***

View solution in original post

11 REPLIES 11
Highlighted
Advisor

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

HTH, John *** Please rate all useful posts ***
Highlighted

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?

Highlighted

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

HTH, John *** Please rate all useful posts ***
Highlighted

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:* :-(

Highlighted

Highlighted

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.

Highlighted

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

HTH, John *** Please rate all useful posts ***
Highlighted

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.

Highlighted

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

HTH, John *** Please rate all useful posts ***

View solution in original post

Highlighted

oh yes, thank you, you are right.

Highlighted
Beginner

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