Disable multi-casting across VLANs?

waldronks · ‎09-27-2010

Is there a command I can put into my core switch to disable multi-casting that is going across VLANs in my network? I'm assuming this is the problem I'm having and would love some input. Each time a technician in my network images more than one computer at a time, traffic spikes from that location and we notice an increase on the network's bandwidth. It seems there is a better way we can manage this...

Thanks in advance!!

Peter Paluch · ‎09-27-2010

Hello,

I am not sure if I understand you correctly: do you want to stop multicasts within a particular VLAN, or being routed between two or more VLANs?

Stopping multicast traffic between VLANs should be a matter of either deactivating the multicast routing on respective interfaces, or if better selectivity is needed, using simple ACLs on SVIs to filter out unwanted traffic.

To stop multicasts within a particular VLAN, well, that's a different story. One of tools that could be used very nicely for this is the VLAN access map than filters all trafic being delivered in a particular VLAN. VLAN access maps are supported on Catalyst 3560 series and higher, however. There is no support for them on 2950/2960/3550 switches.

Also, the storm-control feature could be used to limit the amount of multicast traffic passing through a switchport.

The problem, obviously, is that when you block multicasts, you may be blocking your technician's imaging software. Also, it should be worth verifying that it is precisely the imaging software that is causing such a huge spike. The fact is that with multicast, there should be almost no difference if one or thousand stations are being re-imaged so I am somewhat reserved to the idea that blocking the multicast alone will help. This, in my opinion, requires a deeper analysis.

Best regards,

Peter

waldronks · ‎09-28-2010

Hi Peter,

Yes, I am attempting to stop the multicasts from being routed between two or more VLANs. I'm not completely positive that this is the main issue.

However, after disabling my trunk port the last time computers were imaged, I noticed there wasn't a spike.

If I were to add the storm-control command to the switch, does it need to go on the trunked port or just the interfaces that are imaging?

Thanks,

~Kristy

Peter Paluch · ‎09-28-2010

Hello Kristy,

Frankly, there is something fishy going on here, and these are my reasons:

You have indicated that it seems to make a difference whether one or more computers are being restored. With true multicast, this would not be the case - a single multicast stream would be sufficient and possibly identical for an arbitrary count of computers being restored.
The multicast should not leak into other VLAN if there are no explicit receivers in that VLAN. The logical question is then: if the multicast really leaked into another VLAN, what were the subscribers? And, conversely, if there were no subscribers for that multicast stream in the second VLAN, why was the multicast routed into it?

Of course, the multicast will be flooded over all trunks in your topology for which at least the source VLAN is allowed. But still, this all seems to be lacking some definitive identification of what is really happening. Can you perhaps be more specific in describing the "spike"? Where did you detect it? Was it an access port or a trunk? How did you notice that spike - by what mechanism? Was also the CPU load increased on the devices? Is it possible to have a close look at the network flows generated by the imaging software? What exact multicast IP address is being used?

Stopping the multicast traffic from being rerouted is only an unwarranted workaround but okay, let's see how that can be done. There is a couple of possibilities. If the imaging software allows it, simply setting the TTL to 1 in all multicast flows generated by it will prevent the multicasts from leaking into other VLANs. If setting the TTL to 1 is not an option then the easiest way to block multicast from being rerouted is using an extended ACL, preferably on the SVI of the VLAN where the multicast is originated, to prevent it from being forwarded.

The storm-control is not interesting in this case and I would personally avoid using it.

My recommendation is to try to learn more about those load spikes and learning more about the nature of that imaging application.

Best regards,

Peter