Strictly saying, it depends on many factors (switch model, type of packets/frames, additional tools you may use or not, ...). In it's basic you won't expect CPU usage increase at all because simple L2 broadcasts must come through hardware-based, not CPU-based path. But life sometimes is a little tricky.
The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.
In no event shall Author be liable for any damages whatsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.
The number of users receiving a broadcast (not multicast?) stream would only impact the switch's CPU if the CPU were involved with actual replication of the frame to additional active ports.
As how the switch would know a broadcast frame isn't directed to the switch itself, it doesn't which is why it's suggested a switch's management IP be on a non-user VLAN.
As Joseph said, "The number of users receiving a broadcast (not multicast?) stream would only impact the switch's CPU if the CPU were involved with actual replication of the frame to additional active ports." This means that in a pure environment your switch's CPU does not do anything towards broadcast frames. Even if these frames are addressed for switch itself CPU impact does not depend on number of users. But you need to consider a number of situations:
- previous generation switches (like 2960, 3560, 3750) use internal ring and no special hardware replication engine. Newer switches (3750X, 2960S as a higher models like 4500) use fabric-based architecture and a special replication engine within. Here (in fabric-based switches) you might see some sorts of CPU impact especially in old K2-based 4500s. I've seen that some times.
- there are may way of improper broadcast usage. For example you may want to encapsulate IP multicast into Ethernet broadcast. Why not? Though it is not proper usage, it is not forbidden at all. If your switch is also IP multicast router, then (it is IOS-dependant) multicast replication will be performed by CPU.
- There are not only IP and Ethernet in the world of nets. Ethernet frame contains EtherType field which shows a host what type of protocol is contained inside. I do not know what does a switch make towards a frame that is a broadcast but, for example, is of STP EtherType. Really it is also IOS-dependant. You might also think about Gratuitous ARPs or alike features.
- And, like Joseph said, it is not a good idea to have Management IP of a switch inside user VLAN.
We are pleased to announce availability of Beta software for 16.6.3. 16.6.3 will be the second rebuild on the 16.6 release train targeted towards Catalyst 9500/9400/9300/3850/3650 switching platforms. We are looking for early feedback from custome...