Switches will send packets to all interfaces when using broadcasts or under extreme conditions (full MAC Address Table). This can lead to duplication if there is a loop between two or more switches and if the Spanning Tree Protocol is not used. So the answer is rarely.
Fun story. I was tasked with figuring out a connection problem on a client’s network. STP was enabled, but everyone having problems were all connected to one switch.
Some investigation later and STP’s root port is not the expected root port…
After some investigation, a user took the ethernet cable for their computer (Daisy chained off their VoIP phone), and decided to store it, in the wall jack… Across the office.
That was Jack was on a different switch, and it had a lower port cost than the primary root port between the switches, so naturally, let’s send all inter-switch traffic over to this… Telephone.
Yep. That happened once. The user plugged the cable for their laptop, from the dumb switch, into the same dumb switch and took out most of the network.
That is extraordinarily rare and I’m not even sure if it’s possible anymore. That was potential attack vector in the 90’s where you have a port on network switch, and then you flood the cam table with thousands of bogus mac addresses until you fill it up, then the switch turns into a hub, and you can now sniff all traffic traversing the switch. These days I’m not sure what will happen if you do successfully fill up a switches cam table. Also cam table sizes are are much much larger now. ~128k entry’s vs maybe 1000 back in the day.
You can bring a surprisingly large number of network segments down just by plugging both ends of the same cable into a dumb switch. It probably won’t happen immediately, but eventually you will get a broadcast storm which will propagate until it hits an element smart enough to snuff it out.
From StackOverflow:
https://stackoverflow.com/questions/9196791/duplicate-udp-packets-how-often-it-happens#9220574
If you have no RSTP/MSTP you’re just asking for trouble.
Switching loops are unlikely unless you have bad or non-existent documentation or someone new.
Or users
Fun story. I was tasked with figuring out a connection problem on a client’s network. STP was enabled, but everyone having problems were all connected to one switch.
Some investigation later and STP’s root port is not the expected root port…
After some investigation, a user took the ethernet cable for their computer (Daisy chained off their VoIP phone), and decided to store it, in the wall jack… Across the office.
That was Jack was on a different switch, and it had a lower port cost than the primary root port between the switches, so naturally, let’s send all inter-switch traffic over to this… Telephone.
/Facepalm
The only switching hardware they should have physical access to is a dumb switch if absolutely needed. Then control the cables.
Yep. That happened once. The user plugged the cable for their laptop, from the dumb switch, into the same dumb switch and took out most of the network.
That is extraordinarily rare and I’m not even sure if it’s possible anymore. That was potential attack vector in the 90’s where you have a port on network switch, and then you flood the cam table with thousands of bogus mac addresses until you fill it up, then the switch turns into a hub, and you can now sniff all traffic traversing the switch. These days I’m not sure what will happen if you do successfully fill up a switches cam table. Also cam table sizes are are much much larger now. ~128k entry’s vs maybe 1000 back in the day.
You can bring a surprisingly large number of network segments down just by plugging both ends of the same cable into a dumb switch. It probably won’t happen immediately, but eventually you will get a broadcast storm which will propagate until it hits an element smart enough to snuff it out.
Don’t the big internet-y routers also send packets to multiple interfaces if they don’t know how to correctly handle the target IP address?
You mean under MPLS?
No clue. My college course wasn’t all that deep, and it’s been quite some time.