rdos wrote:Unless the switch is rebooted (which is unsual), sending to unknown destinations will always involve sending ARP requests, and everybody on the network needs to handle those and they are always broadcasted. So, filtering does no good in that case since it is broadcasts and ARPs needs to be processed so you know how to reach that particular destination in case you send to it in the future.
I wouldn't assume that things in a network always happen in some order. While I can't think of a scenario in which a switch that has been running for more than one ARP cache validity period would be asked to handle a unicast packet to an unknown MAC address, I am certain someone could find such a case. Maybe something in a corporate environment, involving managed switches and a spanning tree protocol. Anyway, that doesn't change the fact that MAC address filtering is still a thing for most NICs, and Promiscuous Mode is an option that must be enabled.
rdos wrote:I think every NIC will handle the Ethernet CRC (at least the one's I've studied does).
Admittedly, I wasn't sure about the Ethernet CRC myself. But sunnysideup was asking why NIC drivers are so complicated, and checksum offloading is definitely one reason. Some NICs have auxiliary processors that can perform arbitrary changes to network packets, and must be programmed like a CPU. So now you have to write a program in assembly for a completely different architecture and load that into the NIC.
rdos wrote:Maybe the hardest challenge, which I currently cannot handle, is to handle ARP flooding that leads to NIC overload and buffer overflows which will typically turn off the NIC and require some kind of restart on a overloaded network.
Any finite limit can be exceeded. You can be flooded with anything, and there is little you can do about it. By the time the packet is under your control, the damage (of taking up bandwidth) is already done. The best you can do is work on those packets as quickly as possible in hopes to avoid a buffer overrun on the NIC.
