promiscuous mode, was Re: [HECnet] Multinet Tunnel Connections to SG1::

[Paul_Koning at Dell.com]

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