On Jun 8, 2012, at 10:50 AM, Johnny Billquist wrote:
On 2012-06-08 16:42, Paul_Koning at
Dell.com wrote:
...
That's true if you have a NIC and driver that only allows one individual address per
physical MAC. Most modern NICs allow multiple individual addresses since the address
filter is an exact match on N (say, 16 or so) addresses, and it doesn't care whether
those are individual or multicast. The host OS drivers may or may not export that
feature. If they do, then you don't need promiscuous mode. If they don't, or
if the NIC is old enough that it can't do this, then you do.
Interesting. I wasn't aware that NICs had filters that didn't make a difference
between multicast and unicast anymore... Seems potentially bad if you start using IP
multicast, since that can easily become a whole bunch of multicast addresses, and then I
guess you'll have to turn on promiscuous mode anyway.
A typical modern NIC has (a) a modest-sized list of exact match filters, (b) a hash (CRC)
based multicast filter, and usually (c) a separate flag to enable broadcast. So if you
have at most, say, 16 unicast + multicast addresses enabled, it uses (a); if you have at
most 16 unicast but too many multicast addresses, it uses (b) to do an approximate filter
of the multicasts with the exact match done in the driver, and if you ask for more than 16
unicasts it will tell you that it can't do that.
The old DEC controllers for PDP-11s have a list of multicast addresses that you want to
receive, so they do filter on multicast, but that list is for multicast only. There is
only one unicast address.
(Those controllers also have a separate multicast promiscuous mode, except it don't
work on the DEQNA and DELQA...)
Johnny
That's not quite true. DEC, not surprisingly, was the first to identify the need for
multiple unicast support in NICs, so the DECnet Ethernet datalink spec calls for it and
all except the very oldest DEC NICs support that. Specifically, QNA and LQA do,
because they take a 16 entry address filter. The QNA manual says that you put in the MAC
address, broadcast, multicast addresses, plus extra copies of the MAC address, but in fact
the device is perfectly happy to accept additional individual addresses. I believe VMS
(and possibly other OSs) took advantage of this to allow LAT to come up first with the ROM
based MAC address, then enable DECnet with its address without disturbing LAT.
paul