There are 2^23 MAC layer multicast addresses that map to IP multicast addresses as described by RFC 1112.
So, with that cleared up, here is the practical implication of my question:
I want to subscribe to lots of layer 3 multicast groups.
With each group subscription, my OS instructs my NIC to pass the corresponding layer 2 address.
As I subscribe to more and more layer 3 multicast groups, the filter table in my NIC is keeping track of more and more layer 2 addresses which should be handed up the stack.
I can't imagine the NIC can keep track of all 2^23 addresses in the range: 01:00:5e:00:00:00 - 01:00:5e:7f:ff:ff
So then, what is the practical limit?
Bear in mind: I understand that there are 2^28 multicast groups, so that each multicast MAC address represents 2^5 groups. Also, I can believe (as someone has suggested) that the NIC may use some sort of hash to keep track of these things. There's potential for unwanted traffic leakage in both cases.
But unwanted traffic leakage may not be nearly as dramatic as fallback into full-blown promiscuous mode. -- Especially because I will be spacing my groups to eliminate unwanted collisions at the MAC layer.
The question remains: How many?
And, secondarily: What is this parameter called, so that I may shop for NICs accordingly?
It depends on the particular NIC. Some use a "perfect" multicast filter, i.e., they include a full 48 bit comparator for some number of addresses. (The comparators can be set for unicast or multicast addresses; it makes no difference.) Practical end-station NICs may have
10-16 or so (or maybe more, these days).
As noted in another post, many NICs use an imperfect hash to filter multicasts, typically hashing the 48 bits to 6 (and thus providing 64 multicast "buckets"). Of course, as you subscribe to more and more multicast groups, the buckets all tend to open up. Once all 64 are opened, you are effectively in a full "promiscuous multicast" (but not promiscuous unicast) mode. Even with fewer than 64 opened, if one of your desired multicasts happens to hash to the same bucket as some heavily-trafficked, undesired multicast, your NIC will have to receive all of those frames and perform additional filtering in software. (BTW, this additional filtering is at Layer *2*, not Layer 3 as implied in an a previous reply-post.)
Unless you know the hash function used by that particular NIC, you cannot "space" your groups to prevent hash collisions. Usually, the hash is some number of bits of the CRC shift-register, as it appears at the point where the 48-bit DA has been received.
-- Rich Seifert Networks and Communications Consulting 21885 Bear Creek Way (408) 395-5700 Los Gatos, CA 95033 (408) 228-0803 FAX
You don't have to. Tell your colleagues to do so. :-) As long as nobody shoves ghost images through your LAN, all the multicast is for you anyway and you earn nothing by a perfect block. On the other hand, all those not interested in multicast will not get any no matter what. Only those who subscibe to multicast themselves will on average see some n*m/hash-table-size groups not for them. E.g. if you take 100 groups and sombody else subscribes to 1, he will hardly get more than 2 or 3 wrong with
64 hash entries. And perhaps the switch will help, too.
This behavior (a limit of 10-16 multicast filters and overflow into "promiscuous multicast" mode) is what I'd like to avoid.
I presume this parameter for "some number of addresses" isn't something that's got a common name? I'd like to be able to ask system vendors what that number is, and if it's got a name, then all the better :-)
I didn't mean that I'd be spacing them to avoid hashing collisions, but to avoid collisions in the overlap of the 2^28 multicast groups onto the 2^23 multicast MAC addresses.
I won't be using, say, 184.108.40.206 and 220.127.116.11 because they both land on 01:5e:7f:00:00:01
Ideally, I'll be able to choose a NIC with a larger hash table, or possibly one with the 48 bit comparator, provided that it filters enough groups. The 10-16 you mention as typical isn't going to cut it :-)
What I meant was that it was (likely) done in software instead of hardware. With more and more being put into NIC hardware that may not make as much sense as it did before. While layer 2 is mostly hardware and layer 3 mostly software, the division isn't quite perfect.
A good reason for the destination address to come before the source address. It makes more sense, but why is it that on letters and envelopes the source address comes before the destination address?