Maximum MAC multicast filters?

A single bit in the 48-bit MAC address determines whether the address is unicast or multicast. I think that implies there are a theoretical 2^47 MAC-layer multicast addresses.

NM

Isn't there another one for ethernet/token ring? That means there'd be only

(snip)

Most that I know of use a hash algorithm. Maybe a 64 bit mask so that some unwanted packets will leak through and be filtered at layer 3.

-- glen

No there isn't. MAC addresses are the same regardless of the media.

Anoop

Yes, pardon me. I meant to say:

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?

Thanks! :-)

/chris

Sorry, my mistake. I was thinking of the locally assigned address bit. LAAs are (were?) commonly used on token ring.

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

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

Send replies to: usenet at richseifert dot com

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

LAAs are used by DECnet as well: AA-00-04-00-NN-NN with the last two bytes being the 16-bit DECnet address.

NM

Heh. :-)

Thanks, Manfred -- I wish it were that simple.

Yes, I will be subscribing to lots of groups, but there will also be lots of active groups whose traffic I don't want to see.

Really, there's only one application running here, but it has multiple instances (on different boxes) who don't want each other's data.

Except that I'll be subscribing to 100 groups with one system, 100 other groups with another system...

Yes, I expect the switch to help. If a particular NIC provides a belt and suspenders solution, I'd like to know it's out there, however.

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, 225.0.0.1 and 226.0.0.1 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 :-)

"maybe more, these days" is encouraging though.

Thanks.

/chris

Rich Seifert wrote: (snip)

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?

-- glen