Multicast MAC addresses that always flood

That is correct behavior, as far as I'm concerned, and I do the same thing with my stuff.

Reason being, hosts do not have to "join" IP multicast groups in the range 224.0.0.0/24. Those multicasts never go off link, therefore, they never traverse multicast routers. For example, hosts never explicitly "join" the 224.0.0.1 "all hosts" multicast group, using IGMP. There would be no point to it, because there's no multicast router that can do anything with those multicasts (except maybe use them as a host itself).

So, if a host does not explicitly "join" these groups, how would IGMP snooping work? It wouldn't. IGMP snooping works by intercepting IGMP "join" reports. Since those IGMP reports never occur, those

224.0.0.0/24 multicasts would never flow unless they are always flooded through L2 switches.

Possibly, if you implement a layer 2 multicast join protocol, you could improve on this behavior. But such L2 protocols have traditionally not been implemented widely, as far as I have determined.

Bert

The "chapter and verse" are in RFC 1112 and RFC 3171, by the way.

RFC 1112 Appendix I, page 12 (and elsewhere in this RFC): "Second, a report delay timer is never set for a host's membership in the all- hosts group (224.0.0.1), and that membership is never reported."

RFC 3171 Section 3.0: "Local Network Control Block (224.0.0/24) Addresses in the Local Network Control block are used for protocol control traffic that is not forwarded off link. Examples of this type of use include OSPFIGP All Routers (224.0.0.5) [RFC2328]."

"Not forwarded off link" means that the multicast never goes across a multicast router. Therefore, IGMP does not apply, since IGMP is only used between hosts and their local router, or between routers within a given IP subnet.

Bert

Bert,

Thanks for the citations. I'd been looking for references to the MAC addresses, and that explains why I didn't find anything. I should have started with the IPs.

I guess the L2 non-suppression mechanism is an extrapolation done by the (clever/diabolical) designer of a multicast suppressing bridge: If IGMP isn't interested in a group, then IGMP snooping MUST NOT try to manage that group's frames.

It still feels like there's a couple of big leaps in play here:

- from the "all-hosts" address to the whole /24

- from "not forwarded off link" to "IGMP does not apply"

But I'm mostly satisfied :-)

I'm preparing a document that includes some "don't use these groups" tips. I was hoping to include a simple citation for why not to use X.

0.0.X and X.128.0.X, but I guess it will be more than a simple footnote.

Thanks for digging into the RFCs for me!

[skip]

But should not the IGMP snooping *prevent* flooding multicast on all ports, except the ones being member of IGMP groups?

IGMP snooping should not prevent flooding for just this small range:

224.0.0.0/24, which map into the addresses cited above.

I'd been thinking it was just paranoid thinking that led bridge designers to skip suppression on these addresses, but as Bert pointed out, there's a good reason why IGMP snooping must not intervene.

Consider the "all routers" multicast group. If you're the router on a segment, you're listening on that group... Where would you send an IGMP host report about it? Afterall *you* are the router on the segment!

So, for this small range of groups (which carry critical network control traffic) there's likely/definitely not going to be any IGMP traffic to monitor.

/chris