Multicast MAC addresses that always flood

Have a question or want to start a discussion? Post it! No Registration Necessary.  Now with pictures!

Threaded View

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.



Re: Multicast MAC addresses that always flood

Quoted text here. Click to load it

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


Re: Multicast MAC addresses that always flood

Quoted text here. Click to load it

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.


Re: Multicast MAC addresses that always flood

Quoted text here. Click to load it


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

Thanks for digging into the RFCs for me!

Re: Multicast MAC addresses that always flood

Albert Manfredi wrote:
Quoted text here. Click to load it

Quoted text here. Click to load it

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


Re: Multicast MAC addresses that always flood

Quoted text here. Click to load it

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

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.


Site Timeline