4 ms·

> Have you ever asked yourself why there would be 140,737,488,355,328 (half of all) MAC addresses reserved for broadcast if it had no utilities over setting ff:

> Have you ever asked yourself why there would be 140,737,488,355,328 (half of all) MAC addresses reserved for broadcast if it had no utilities over setting ff:ff:ff:ff:ff:ff? Mostly because of a historic accident. > Because ARP uses ff:ff:ff:ff:ff:ff you either need to use an ACL on the protocol type in the ingress pipeline or trap all broadcasts to the CPU (both are inefficient in their own ways). Since you're talking about switches, they can just snoop on ARP and avoid broadcasts entirely. Some switches do that. And the last time I checked, multicast on most (all?) modern switches is also implemented by punting packets to the CPU.

zamadatix 9d ago
> Mostly because of a historic accident. This is where assumption fails, in the original formulation it was even called the multicast bit (instead of the I/G bit) and broadcast was considered a special subset of the multicast use case. Quite the opposite of how you have framed things as an accident of having so many broadcast addresses. (pdf warning) https://archive.computerhistory.org/resources/text/DEC/ethernet/dec_intel_xerox.ethernet.the_ethernet_a_local_area_network.1980.102630389.pdf https://archive.computerhistory.org/resources/text/DEC/ether... ironically, this is > Since you're talking about switches, they can just snoop on ARP and avoid broadcasts entirely. ARP broadcast suppression is definitely a thing but it requires more than just snoop, you still need some form of replication of the information to the other switches in the network and you need the actual suppression+generation functionality (ARP snoop alone just lets an L2 switch build an ARP table, it doesn't define what to do with it). In the best case this is itself done via multicast, in a middle case it's thrown into BGP or similar and distributed that way (if all of your nodes are routers), and in the worst case it falls back to broadcast across the network for anything not known on a local port. ARP broadcast suppression is also harder than with the multicast address for the reason above. Snooping also does nothing for the NICs connected to "basic" L2 switches not doing ARP broadcast suppression while the multicast MAC still does (even when not actually forwarded via multicast).

zamadatix 9d ago

> Mostly because of a historic accident. This is where assumption fails, in the original formulation it was even called the multicast bit (instead of the I/G bit) and broadcast was considered a special subset of the multicast use case. Quite the opposite of how you have framed things as an accident of having so many broadcast addresses. (pdf warning) https://archive.computerhistory.org/resources/text/DEC/ethernet/dec_intel_xerox.ethernet.the_ethernet_a_local_area_network.1980.102630389.pdf https://archive.computerhistory.org/resources/text/DEC/ether... ironically, this is > Since you're talking about switches, they can just snoop on ARP and avoid broadcasts entirely. ARP broadcast suppression is definitely a thing but it requires more than just snoop, you still need some form of replication of the information to the other switches in the network and you need the actual suppression+generation functionality (ARP snoop alone just lets an L2 switch build an ARP table, it doesn't define what to do with it). In the best case this is itself done via multicast, in a middle case it's thrown into BGP or similar and distributed that way (if all of your nodes are routers), and in the worst case it falls back to broadcast across the network for anything not known on a local port. ARP broadcast suppression is also harder than with the multicast address for the reason above. Snooping also does nothing for the NICs connected to "basic" L2 switches not doing ARP broadcast suppression while the multicast MAC still does (even when not actually forwarded via multicast).