01-20-2024 09:41 AM
01-20-2024 09:48 AM
Hello @iores
When a switch receives a frame with a destination MAC address that is unknown (not in its MAC address table), the switch engages in a process known as "flooding" or "broadcasting" to find the correct path for the frame. During this process, the switch will temporarily use its CPU to make decisions about forwarding the frame.
01-20-2024 12:32 PM
It would depend on the switch.
As noted by the other posters, an unknown MAC is transmitted on all ports (except ingress port) for that VLAN. This might be done in hardware, or software (CPU). I would hope it's done on the former.
Interestingly, if you read up on the issue of unicast flooding, the problem is generally described by its impact to all the other ports getting the unknown unicast MAC destination traffic (like what would happen on a hub, i.e. losing the benefit of unicast on a switch) but also without mention of the switch's CPU being adversely impacted. (BTW, this is something any Ethernet hub does all the time.)
Basically, and possibly, hardware that supports broadcast and/or multicast replication, across switch ports, would handle unicast flooding across ports too.
01-20-2024 09:48 AM
Hello @iores
When a switch receives a frame with a destination MAC address that is unknown (not in its MAC address table), the switch engages in a process known as "flooding" or "broadcasting" to find the correct path for the frame. During this process, the switch will temporarily use its CPU to make decisions about forwarding the frame.
01-20-2024 09:49 AM
I think Yes' form there cpu send frame as flood to all port in vlan same vlan source port assign.
MHM
01-20-2024 12:32 PM
It would depend on the switch.
As noted by the other posters, an unknown MAC is transmitted on all ports (except ingress port) for that VLAN. This might be done in hardware, or software (CPU). I would hope it's done on the former.
Interestingly, if you read up on the issue of unicast flooding, the problem is generally described by its impact to all the other ports getting the unknown unicast MAC destination traffic (like what would happen on a hub, i.e. losing the benefit of unicast on a switch) but also without mention of the switch's CPU being adversely impacted. (BTW, this is something any Ethernet hub does all the time.)
Basically, and possibly, hardware that supports broadcast and/or multicast replication, across switch ports, would handle unicast flooding across ports too.
01-21-2024 05:24 PM - edited 01-21-2024 05:46 PM
“Basically, and possibly, hardware that supports broadcast and/or multicast replication, across switch ports, would handle unicast flooding across ports too.”
Yep, if the switch forwards in h/w (virtually every “switch” you buy today does), then flooding of BUM (broadcast, unknown unicast, multicast) traffic is done by the h/w too. If every BUM packet had to be punted out of the h/w path and up to the CPU for handling, then it would be trivial for malware to DoS the switch and take it offline by sending wirespeed BUM traffic. (Control-plane policers might mitigate against this by discarding packets, but only by breaking the principle that all BUM must be flooded. Twenty years ago, some switches that learned MAC addresses did so via the CPU, but it was soon discovered that this was a DoS attack vector. Nowadays MAC addresses are learned in h/w.)
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide