Multicast MAC addresses that always flood

Cisco bridges running a multicast suppression mechanism will always flood multicast frames destined for 01-00-5E-00-00-00 to


This looks like an attempt to preserve operation of (inter)network control traffic using the reserved address block, and seems reasonably paranoid.

Is this codified as a requirement anywhere? Chapter and verse?

The only references to it that I can find are in Cisco documentation, and in RFC4541, where it appears as a question, but doesn't make clear where the requirement comes from.



Reply to
Loading thread data ...

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 Those multicasts never go off link, therefore, they never traverse multicast routers. For example, hosts never explicitly "join" the "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 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.


Reply to
Albert Manfredi

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 (, 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 ( [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.


Reply to
Albert Manfredi


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!

Reply to


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

Reply to

IGMP snooping should not prevent flooding for just this small range:, 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.


Reply to
chris Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.