When a L2 loop is created that brings down the network what contributes more toward the network being unusable, bandwidth consumption or CPU hogging?
Also, in broadcast storms (via ARP requests) are the same ARP requests continually sent around the loop with more and more being generated, eventually totally consumming BW, or does something else happen?
technically it would be both, bandwidth consumption and CPU hogging.
lets think about this...
if you have a loop in the network and you have a PC connected that puts one packet on the network, if the loop exists, it would send the packet round and round and round.
what this would do is two fold:
a) it would consume bandwidth not usually required for the transmission
b) more importantly, it would make the CPU(s) of the components have to process the packet, over and over and over and over.....
it would be a never ending process if the loop could not be mitigated.
now in reality, how much bandwidth would this take up, only as much as required by the data looping over and over.
i think bandwidth would take a second place to CPU consumption as even the smallest packet in a loop can cause all ability of the network to process just this one bit of data....over and over and over...etc.
as far as an arp request, if there is a loop, same scenario; the packet would travel round and round and round.
if there were more arps put onto the wire there are two possibilities.
1) they get dropped because the network cannot process them due to its consumption with processing the first packet in a loop.
2) the additional arp adds to the problem by adding yet more data to be looped; causing yet more cpu and more bandwidth unavailable.
in a nutshell, cpu will be your biggest problem in a looped configuration.
please see the following link for more STP troubleshooting info:
For the first question: It depends. When your network is a high performance solution, it will completely saturate the network with traffic, mostly broadcasts. All other nodes will over-utilize their cpu due to this high amount of broadcast traffic. In a somewhat less performant environment, the network load will be (slightly) less than 100 percent. Still, it is the high amount of broadcast traffic that causes all other nodes in the network to stop processing their actual tasks.
When an arp-request arrives at a bridge or a switch, it will be regenerated on the other interface(s). In case of a loop it is the same packet that circles round the loop time after time. Under loop conditions, a single broadcast may bring a network down. However, each new broadcast will receive the same treatment so eventually there may be several broadcast datagrams from different sources circling the loop and claiming all network bandwidth. I believe this answers your second question.
I was leaning toward CPU hogging as being a bigger contributor too, however I'm still not clear if the original arp request is recycled or if it is duplicated upon being received by the originator and sent along with the original arp request, creating two identical arp request, then four, then eight, and so on. If this were true then I can see how the BW would be consummed very quickly.
I've created L2 loops that would not allow me to telnet into a switch. I would have to physically disconnect a redundant link to break the loop to gain switch access again, which happens immediately. This lead to my L2 loops questions. Hope I'm making sense.
This is actually a pretty cool feature, i didn't even know it existed until I was looking for a solution to advertise a subnet (prefix in BGP talk), only if a certain condition existed. This is exactly what conditional advertisements does
j ai une question j ai achete un routeur cisco 887VA-k9 , je le configuré avec la configuration ci- dessous
si je le lier avec mon pc portable sur l un de ses ports directement ça marche toute est bien ( la connexion internet + m...
Attached policy provides CLI access to the Cisco 4G router over text messaging. Two files are in the attached .tar file:
2. PDF with instructions on how to load and use the .tcl file.