Thanks, these are good points and well-explained. You lost me here though:
"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.
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.
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
"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."
Yes, it's easy to forget that different hosts have different perspective of the network at different times.
Thanks for the image, it's very helpful indeed! I totally understand your point now.
At one time I used to work much much more with these types of details and now work up further in the stack. There is still lots of bridging but its all virtual bridge interfaces on Docker container networks and so things like this dicussion hardly come up anymore for me. This discussion really helped jog my memory and realize I've forgotten some things but also made me realize how fun and fascinating networking is! Cheers!
Comments
Thanks, these are good points and well-explained. You lost me here though:
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.
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
Yes, it's easy to forget that different hosts have different perspective of the network at different times.
Thanks for the image, it's very helpful indeed! I totally understand your point now.
At one time I used to work much much more with these types of details and now work up further in the stack. There is still lots of bridging but its all virtual bridge interfaces on Docker container networks and so things like this dicussion hardly come up anymore for me. This discussion really helped jog my memory and realize I've forgotten some things but also made me realize how fun and fascinating networking is! Cheers!