>"Imagine you had 2 transceivers you wanted to bridge - if the transceiver dropped all unicast MACs but its own indiscriminately then it would not function properly"
I'm not understanding why bridging makes a difference. In the case of a bridge a host would send out a broadcast i.e a frame with destination MAC ff:ff:ff:ff:ff:ff which is valid for all Ethernet adapters, this is similar whether it's a switched or bridge network no? Maybe I'm missing something obvious?
>"Offloads such as this or other more advanced ones are implemented as optional hardware features (if at all) controlled by upstream signaling."
Which offloads are you referring to here? Just general TCP offload engine stuff? How does that relate?
Thank you! I love talking about bits and bytes on the network wire and it feels like I get to do it less and less the farther I get into my career... funny how that works. At least I haven't been moved into management yet!
> I'm guessing this is exactly why this stuff is handled at L2 and in the kernel module for the NIC?
Yep, generally the OS driver has a backup version of logic to handle everything beyond "packet receive" and "packet send" for exactly these kinds of reasons. On Linux you or any program with the rights can disable NIC filtering offloads by setting an interface to promiscuous e.g. "ip link set eth1 promisc on" and the packets all get punted to the CPU like it was a base level dumb NIC. Pulling an example early here is a patch making sure the broadcom driver for the NIC in the Raspberry Pi actually listens to this declaration and disables the ARP & ND filtering offloads https://patchwork.kernel.org/project/linux-wireless/patch/15...
> I'm not understanding why bridging makes a difference. In the case of a bridge a host would send out a broadcast i.e a frame with destination MAC ff:ff:ff:ff:ff:ff which is valid for all Ethernet adapters, this is similar whether it's a switched or bridge network no? Maybe I'm missing something obvious?
You're only thinking about broadcast MAC destinations but bridges also handle unicast MAC destinations. E.g. imagine NIC 1 (local station assigned MAC 0a:0a:0a:0a:0a:0a) and NIC 2 (local station assigned MAC 0e:0e:0e:0e:0e:0e) are bridged and no state has been learned yet. Off NIC 1 an unknown unicast MAC flood from source MAC 02:02:02:02:02:02 to destination MAC 04:04:04:04:04:04 is received. If the NIC just drops the frame when received on NIC 1 because the destination unicast MAC is 04:04:04:04:04:04 instead of 0a:0a:0a:0a:0a:0a the bridge is non-functional. Letting the broadcasts through is only half the story of bridging.
Ideally the device (either NIC offload or upstream OS/further hardware logic) does some MAC learning as the above conversation goes on so things don't always remain unknown flooding past the first exchange but technically just forwarding the frame out all interfaces in the bridge group is valid too (just extremely inefficient). It's also worth noting usually in the real world higher layer discovery (like 2 IP addresses ARPing for each-other) triggers the unicast MAC learning with the ARP broadcast and unicast response but that's just a nicety of how things typically work, it's not always the case with any conversation between 2 Ethernet endpoints. Just knowing the MACs beforehand and not sending any broadcast is technically just as valid a way to do things at the Ethernet layer, albeit extremely rare in the world of IP.
> Which offloads are you referring to here? Just general TCP offload engine stuff? How does that relate?
More directly things like ARP and WoL offload so the CPU doesn't get interrupts every time some device in the subnet sends an ARP/WoL broadcast, particularly when it ends up being a broadcast intended for a MAC not owned by the local station. Both of those offloads are pretty common in consumer stuff too which is nice and that link I sent above shows a code change related to it for the Raspberry Pi adapter (albeit the Wi-Fi one, which has a whole different world of filters at the Wi-Fi layer before we even get to Ethernet filtering).
TCP offloading and whatnot can be examples as well but the level of abstraction (and varying levels of "what exactly is offloaded") makes it more difficult to discuss than the above examples which can stay within the Ethernet layer (as far as forwarding goes, the payloads may have information beyond that to deal with once delivered). That said I'll leave TCP offload with "the NIC may still need to know the VLAN tag and p-bit to put in the Ethernet header, as well as get the destination MAC of the next hop which could be a gateway or the destination client itself" but skip the examples or further corner cases/combinations since it can get hairy very fast and that already gives enough of an idea about Ethernet bits getting set by the offload too :).
>"You're only thinking about broadcast MAC destinations but bridges also handle unicast MAC destinations. E.g. imagine NIC 1 (local station assigned MAC 0a:0a:0a:0a:0a:0a) and NIC 2 (local station assigned MAC 0e:0e:0e:0e:0e:0e) are bridged and no state has been learned yet. Off NIC 1 an unknown unicast MAC flood from source MAC 02:02:02:02:02:02 to destination MAC 04:04:04:04:04:04 is received. If the NIC just drops the frame when received on NIC 1 because the destination unicast MAC is 04:04:04:04:04:04 instead of 0a:0a:0a:0a:0a:0a the bridge is non-functional. Letting the broadcasts through is only half the story of bridging."
In unknown unicast MAC flooding why would would the destination mac address ever be anything other than ff:ff:ff:ff:ff:ff? In your example the destination is 04:04:04:04:04:04. I'm also not understanding the relation ship between NIC 1(local station assigned MAC 0a:0a:0a:0a:0a:0a), NIC 2 (local station assigned MAC 0e:0e:0e:0e:0e:0e and the mac addresses 02:02:02:02:02:02 and 04:04:04:04:04:04.
Different nodes will have different ideas of what is known and what is unknown so it may be learned unicast on the sending node but unknown unicast on a middle node. E.g. imagine the bridge in the middle had it's table cleared for some reason, such as a reboot, or that client 1 had the destination MAC hardcoded in the sending logic but the bridge did not. In either case the client would know the unicast destination and put it in the packet and then it'd be unknown to the bridge in-between and be flooded. Remember beyond sending and receiving actual Ethernet frames with source/destination MACs in them bridges do not sync their learned MAC tables. The unknown flooding mechanism insures discoverability since the endpoints may not always know when a new bridge is between them or an existing bridge lost the entry.
In general there are 3 types of traffic that are flooded in Ethernet: BUM - Broadcast, Unknown, and Multicast. Broadcasts are explicitly created by setting the destination to ff:ff:ff:ff:ff:ff, unknown are a per node concept about a unicast destination not yet programmed in the local table (but may or may not be programmed elsewhere already), and multicast are reserved 23 bit range of MACs that are to never be programmed as learned so they flood permanently yet can have individual identifiers in the network. Sometimes a higher level protocol such as IGMP can be used to restrict this flooding to only nodes that ask for the specific multicast conversation to be sent to them but that's all optional and came later.
> I'm also not understanding the relation ship between NIC 1(local station assigned MAC 0a:0a:0a:0a:0a:0a), NIC 2 (local station assigned MAC 0e:0e:0e:0e:0e:0e and the mac addresses 02:02:02:02:02:02 and 04:04:04:04:04:04.
The relationship is that there is no relationship :). It doesn't matter that the assigned MACs are 0a:0a:0a:0a:0a:0a and 0e:0e:0e:0e:0e:0e since they aren't used in deciding if the 02:02:02:02:02:02 and 04:04:04:04:04:04 frames should be dropped when received. I.e. they are just there to show that if you did the "is this unicast packet destined to the locally assigned MAC? If not drop it" filtering all the time the interfaces would fail to bridge traffic correctly.
Walls of text can be lame so I created a visual scenario that minimally covers everything we talked about so far regarding learning and unicast MAC forwarding. It starts after the conversation has already started but it'll make sense why it starts there by the end: https://imgur.com/a/6vkaEgj
