Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations gkittelson on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
Broadcast storm 2
- Thread starter murrayw
- Start date
-
2
- #3
LawnBoy
MIS
- Mar 12, 2003
- 2,881
This is where managed switches really shine. A managed switch will give you stats of each port. Even if you determine what IP is generating the flood, you still don't know where the device is physically so you can unplug it.
Hopefully you're experiencing a flood and not a bcast storm, which is caused by a topological loop on a switch.
Hopefully you're experiencing a flood and not a bcast storm, which is caused by a topological loop on a switch.
Not all broadcast storms are caused by a topological loop on a switch.
If you have software manipulated a MAC address then you could have a broadcast ARP storm (as an example), this you will not see on a defined port on the switch so therefore having a managed switch is no help what so ever, unless it has been segregated with VLAN's and then you will have seperate broadcast domains on the switch.
If you have software manipulated a MAC address then you could have a broadcast ARP storm (as an example), this you will not see on a defined port on the switch so therefore having a managed switch is no help what so ever, unless it has been segregated with VLAN's and then you will have seperate broadcast domains on the switch.
I may well be looking at this from the wrong angle here, but unless you have VLAN segregation, the broadcast traffic will dissipate through EVERY port on the switch.
Only with VLAN seperation can the broadcast traffic be narrowed down to 1 port?????
Only with VLAN seperation can the broadcast traffic be narrowed down to 1 port?????
LawnBoy
MIS
- Mar 12, 2003
- 2,881
Yes, it does propagate to every port.
I had a dept. create a topo loop on their switch (I'm not running STP because of some legacy Db apps) and while the whole switch did freak out, the switch logged the two ports that had the conflict as having excessive bcasts first.
The switch would flush it's ARP tables and begin to rebuild them, and those two ports would again report problems first.
It was pretty ugly, when that edge switch would flush it's table it caused the core switch upstream to also flush, which caused other edge switches downstream from the core to flush, on and on and on. By the time I arrived there was almost no data moving on the network as these ARP flushes swept through the switches.
The only way I could determine where the problem started was through the logs kept by the switches. And if I had not set all switches up on NTP those logs wouldn't have helped.
I had a dept. create a topo loop on their switch (I'm not running STP because of some legacy Db apps) and while the whole switch did freak out, the switch logged the two ports that had the conflict as having excessive bcasts first.
The switch would flush it's ARP tables and begin to rebuild them, and those two ports would again report problems first.
It was pretty ugly, when that edge switch would flush it's table it caused the core switch upstream to also flush, which caused other edge switches downstream from the core to flush, on and on and on. By the time I arrived there was almost no data moving on the network as these ARP flushes swept through the switches.
The only way I could determine where the problem started was through the logs kept by the switches. And if I had not set all switches up on NTP those logs wouldn't have helped.
- Status
Similar threads