![mac address learning promicious mac address learning promicious](https://image.slideserve.com/1290100/interconnecting-with-hubs-l.jpg)
An Ethernet NIC was always able to listen to one (or a few) unicast MAC addresses and a few multicast MAC addresses (the limits are vendor-dependent) everyone would obviously have to process broadcast frames.Ī typical end-host has a single MAC address.
![mac address learning promicious mac address learning promicious](https://docs.vmware.com/en/VMware-NSX-T-Data-Center/3.0/installation/images/GUID-331F6FB2-B089-4396-8B02-5C8369FE9AB4-high.png)
Frame filtering based on destination MAC address was thus always implemented in hardware (the same is true for almost all multi-access L2 technologies). In the shared media environment of early Ethernet it was very important that the frames not meant for an individual end-station do not burden its CPU. There is no communication between Ethernet hosts and bridges (remember: bridges emulate a single cable and a cable cannot talk to stations attached to it) and thus the switches have no way of knowing whether those frames are important to the end hosts or not (IGMP snooping is one of those kludges that is supposed to make a broken design a bit less dreadful). So what exactly is going on and does it matter?Įthernet was designed as a shared media (remember the thick coax cables with vampire transceivers?) and even though switched Ethernet (aka bridging) gave us more bandwidth, it still emulates the coax cable – frames sent to broadcast, multicast and unknown unicast addresses are flooded to all hosts (the behavior that makes brokenware like Microsoft NLB work). The fact that this Networking 101 level detail is no longer true kind of blows my mind. VMware runs its NICs in promiscuous mode. Chris Marget sent me the following interesting observation: One of the things we learned back at the beginning of Ethernet is no longer true: hardware filtering of incoming Ethernet frames by the NICs in Ethernet hosts is gone.