8

I have a network which has many devices sending data to 224.0.0.225 on a VLAN which spans multiple switches. Each device (aprox 12 of them) is sending reporting data at roughly 500-600 kbps. Each port on the VLAN, whether the receiver sends a join or not, is getting flooded with roughly 6mbps of multicast traffic.

IGMP snooping is enabled on all the switches and the local VLAN.
pim sparse-mode is configred on the mrouter/default gateway.

If I do a show ip igmp snooping groups on the switch, there is no entry in the snooping table.

I know 224.0.0.1 - 224.0.0.255 fall within the link-local reserved IP Multicast range meaning a router will not forward packets within this range. These ranges are also used for routing protocol chatter. eg) EIGRP, OSPF, HSRP...etc

I have two questions:
1) I think the answer is YES - for 224.0.0.1 224.0.0.255...does IGMPv2 ignore this range for snooping and does the switch just forward this to all ports?
2) Is there a way to force IGMP to snoop this multicast traffic and only send it to the ports which request it with an IGMP join?

I have a feeling this is one of those instances where the application/programmers need to design their devices and application to respect scalable non-consumer networks. Thus they should be using a multicast address in the 239.0.0.0/8 range.

Improve this question
2
  • I think the correct answer here is to find whomever chose to abuse the "unassigned" addresses and educate them in the error of their ways with a 2x4. You are correct; the "app" should be using 239/8. Until it is, there is very little you can do about it.
    – Ricky
    Aug 28, 2013 at 3:01
  • 1
    to add to this - Cisco also states this is the intended approach to link-local multicast. cisco.com/en/US/tech/tk828/…
    – knotseh
    Aug 28, 2013 at 22:49

2 Answers 2

Reset to default
8

I've kept digging around the internet....and I think I've answered my own question.
Now I need to go back to the application/device owners/developers and see what we can do or further lock these devices down to their own VLAN.

Please leave comments or answers with any further advice.

RFC 4541 2.1.2:

  1. Packets with a destination IP address outside 224.0.0.X which are not IGMP should be forwarded according to group-based port membership tables and must also be forwarded on router ports.

    This is the main IGMP snooping functionality for the data path. One approach that an implementation could take would be to maintain separate membership and multicast router tables in software and then "merge" these tables into a forwarding cache.

  2. Packets with a destination IP (DIP) address in the 224.0.0.X range which are not IGMP must be forwarded on all ports.

    This recommendation is based on the fact that many host systems do not send Join IP multicast addresses in this range before sending or listening to IP multicast packets. Furthermore, since the 224.0.0.X address range is defined as link-local (not to be routed), it seems unnecessary to keep the state for each address in this range. Additionally, some routers operate in the 224.0.0.X address range without issuing IGMP Joins, and these applications would break if the switch were to prune them due to not having seen a Join Group message from the router.

Improve this answer
1
  • Hi, please consider accepting this answer. I just found this while I was googling for a similar question.
    – Mike Pennington
    Jan 26, 2014 at 17:41
6

There is another caveat: Depending on platform, the switch will punt all link-local multicast to the CPU. This includes for example OSPF traffic.

I noticed this on Ciscos Catalyst 4500 which will send all 224.0.0.x traffic to the CPU. When the CPU is busy it will drop the packets, including your OSPF packets. Have fun debugging why your OSPF session(s) drop.

Also turning off igmp snooping on the platform does not help. At some time Cisco noticed that this is probably not the best idea and introduced the command:

access-list hardware capture mode vlan

This will bridge the multicast packets in hardware.

See http://www.cisco.com/en/US/docs/switches/lan/catalyst4500/12.2/52sg/configuration/guide/secure.html#wp1128851 for details

Improve this answer
4
  • do you know a way of blocking the 224.0.0.x mcast at the port level?
    – knotseh
    Aug 31, 2013 at 18:32
  • Mmmh, it depends. You can apply Control Plane Policing: cisco.com/en/US/docs/switches/lan/catalyst4500/12.2/52sg/… But you are limited to the predefined class-maps. If your traffic is matched by one of the class-maps you're lucky. Edit: Okay reading this again I'm not sure if you're allowed to have your own class-maps in addition to the predefined ones. You would need to test it.
    – Sebastian Wiesinger
    Aug 31, 2013 at 21:56
  • So my access switches are actually 3560x series switches. Once I get my maintenance Window I'm going to try sw block multicast as recommended on a server fault question. Maybe I'll repost this as a question later on
    – knotseh
    Sep 1, 2013 at 1:51
  • So from my initial reading on my phone....looks like it will class all or nothing in terms of link local traffic. Of course if i can block that predefined class map, then it will also drop hsrp which is the only other thing I need to work.
    – knotseh
    Sep 1, 2013 at 2:04

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.