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

[Johnny Billquist]

On 2012-06-08 19:02, Paul_Koning at Dell.com wrote:

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.

I have forgotten most of what I might have known of modern NICs, I think...

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.

Thanks for making me re-read the DELQA manual again. :-)
I'm not totally clear on this point. This might be getting a little too technical and offtopic here, but basically, reading the manual, it might appear that having several unicast addresses in the setup might only be respected if you are running your DELQA in DEQNA mode, and the manual warn against potential performance issues if you do this.
But I had forgotten quite a lot of the DEQNA/DELQA anyway, including that you were supposed to fill the table with your own address to make it full. Gah! I've never liked the Q-bus ethernet controllers. And they are so buggy...

	Johnny