| Author |
Message |
Guest
|
 Posted:
Wed Oct 05, 2005 4:20 pm Post subject:
Maximum MAC multicast filters? |
|
|
Greetings!
There are 2^23 MAC layer multicast addresses.
How many of these addresses can the hardware filters in a typical NIC
handle?
Will a NIC fail into some sort of limited (multicast) promiscuous mode
when I exceed that number?
Will it perhaps fall into full-blown promiscuous mode when I exceed
that number?
What is the name of this parameter? I'd like to be able to find it on
spec sheets (or at least google), but I'm not even sure of what to call
it.
Many thanks.
/chris |
|
| Back to top |
|
 |
News Me
Guest
|
| Posted:
Thu Oct 06, 2005 5:47 am Post subject:
Re: Maximum MAC multicast filters? |
|
|
googlegroups@marget.com wrote:
| Quote: | Greetings!
There are 2^23 MAC layer multicast addresses.
|
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
--
convert UPPERCASE NUMBER to a numeral to reply |
|
| Back to top |
|
|
James Knott
Guest
|
| Posted:
Thu Oct 06, 2005 6:24 am Post subject:
Re: Maximum MAC multicast filters? |
|
|
News Me wrote:
| Quote: | googlegroups@marget.com wrote:
Greetings!
There are 2^23 MAC layer multicast addresses.
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.
|
Isn't there another one for ethernet/token ring? That means there'd be only
2^46 total addresses. That's barely enough to go 'round. ;-) |
|
| Back to top |
|
|
anoop
Guest
|
| Posted:
Thu Oct 06, 2005 8:20 am Post subject:
Re: Maximum MAC multicast filters? |
|
|
James Knott wrote:
| Quote: | News Me wrote:
googlegroups@marget.com wrote:
Greetings!
There are 2^23 MAC layer multicast addresses.
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.
Isn't there another one for ethernet/token ring? That means there'd be only
2^46 total addresses. That's barely enough to go 'round. ;-)
|
No there isn't. MAC addresses are the same regardless of the media.
Anoop |
|
| Back to top |
|
|
glen herrmannsfeldt
Guest
|
| Posted:
Thu Oct 06, 2005 8:20 am Post subject:
Re: Maximum MAC multicast filters? |
|
|
googlegroups@marget.com wrote:
(snip)
| Quote: | How many of these addresses can the hardware filters in a typical NIC
handle?
|
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 |
|
| Back to top |
|
|
James Knott
Guest
|
| Posted:
Thu Oct 06, 2005 4:20 pm Post subject:
Re: Maximum MAC multicast filters? |
|
|
anoop wrote:
| Quote: | Isn't there another one for ethernet/token ring? That means there'd be
only
2^46 total addresses. That's barely enough to go 'round. ;-)
No there isn't. MAC addresses are the same regardless of the media.
|
Sorry, my mistake. I was thinking of the locally assigned address bit.
LAAs are (were?) commonly used on token ring. |
|
| Back to top |
|
|
Guest
|
| Posted:
Thu Oct 06, 2005 10:11 pm Post subject:
Re: Maximum MAC multicast filters? --clarified-- |
|
|
News Me wrote:
| Quote: | googlegroups@marget.com wrote:
There are 2^23 MAC layer multicast addresses.
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.
|
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 |
|
| Back to top |
|
|
Manfred Kwiatkowski
Guest
|
| Posted:
Thu Oct 06, 2005 11:49 pm Post subject:
Re: Maximum MAC multicast filters? --clarified-- |
|
|
In article <1128618718.388739.35130@g49g2000cwa.googlegroups.com>,
googlegroups@marget.com writes:
| Quote: |
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?
|
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.
--
Manfred Kwiatkowski kwiatkowski@zrz.tu-berlin.de |
|
| Back to top |
|
|
Rich Seifert
Guest
|
| Posted:
Fri Oct 07, 2005 2:46 am Post subject:
Re: Maximum MAC multicast filters? --clarified-- |
|
|
In article <1128618718.388739.35130@g49g2000cwa.googlegroups.com>,
googlegroups@marget.com wrote:
| Quote: |
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?
|
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.)
| Quote: |
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.
|
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 |
|
| Back to top |
|
|
News Me
Guest
|
| Posted:
Fri Oct 07, 2005 7:28 am Post subject:
Re: Maximum MAC multicast filters? |
|
|
James Knott wrote:
| Quote: | anoop wrote:
Isn't there another one for ethernet/token ring? That means there'd be
only
2^46 total addresses. That's barely enough to go 'round. ;-)
No there isn't. MAC addresses are the same regardless of the media.
Sorry, my mistake. I was thinking of the locally assigned address bit.
LAAs are (were?) commonly used on token ring.
|
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
--
convert UPPERCASE NUMBER to a numeral to reply |
|
| Back to top |
|
|
Guest
|
| Posted:
Fri Oct 07, 2005 11:09 pm Post subject:
Re: Maximum MAC multicast filters? --clarified-- |
|
|
Manfred Kwiatkowski wrote:
| Quote: | In article <1128618718.388739.35130@g49g2000cwa.googlegroups.com>,
googlegroups@marget.com writes:
What is this parameter called, so that I may shop
for NICs accordingly?
You don't have to. Tell your colleagues to do so. :-)
|
Heh. :-)
| Quote: | 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.
|
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.
| Quote: | 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.
|
Except that I'll be subscribing to 100 groups with one system, 100
other groups with another system...
| Quote: | And perhaps the switch will help, too.
|
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. |
|
| Back to top |
|
|
Guest
|
| Posted:
Fri Oct 07, 2005 11:29 pm Post subject:
Re: Maximum MAC multicast filters? --clarified-- |
|
|
Rich Seifert wrote:
| Quote: | 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).
|
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 :-)
| Quote: | 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.)
I will be
spacing my groups to eliminate unwanted collisions at the MAC layer.
Unless you know the hash function used by that particular NIC, you
cannot "space" your groups to prevent hash collisions.
|
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 |
|
| Back to top |
|
|
glen herrmannsfeldt
Guest
|
| Posted:
Sun Oct 09, 2005 8:20 am Post subject:
Re: Maximum MAC multicast filters? --clarified-- |
|
|
Rich Seifert wrote:
(snip)
| Quote: | 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.)
|
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.
| Quote: | 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.
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.
|
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 |
|
| Back to top |
|
|
|
|
|
|
FAQ
Memberlist
Register
Profile
Log in to check your private messages
Log in