Broadcast Domains and Loops

Answered Question
Oct 1st, 2010

The assumption for the question below is that redundant L2 trunks are configured, which would require STP to prevent a loop....

Which is largely the reason for the creation of bridging loops - broadcast traffic originated by the end-user machines that gets endlessly forwarded by Ethernet switches (like ARP), or is it the broadcasting of unknown unicasts originated by the switches themselves?

I would think its the broadcast traffic originated by the end-users because unknown unicasts will eventually reach the intended machine and the response packet will educate the switches that were reflexively broadcasting earlier, thereby killing the loop. The caveat of course is that the intended machine respond. If not, the broadcast storm will go on and on. On the other hand, an ARP reply to an ARP broadcast (which is a user generated broadcast) will still not break the loop.

MY RATIONALE: There is a difference in that unknown unicasts are broadcast (sent out) all ports (except the one in which it came in on)  but the destination MAC address is a unicast address and is not  changed. It is the forwarding behavior of the switches that changes when unknown  unicasts must be forwarded. On the other hand, broadcast frames from  end-users, like ARP queries, have a destination MAC address that is itself a  broadcast address (ffff.ffff.ffff), so even an ARP reply will not kill  the loop. Correct?

But either way, can one say that it is the inherent nature of Ethernet itself as a LAN broadcast protocol, which assumes a flat logical topology, that is the underlying cause?

Thoughts?

I have this problem too.
0 votes
Correct Answer by Peter Paluch about 6 years 2 months ago

Hello,

Lots of ideas in your post Let's go over them one by one.

Which is largely the reason for the creation of bridging loops - broadcast traffic originated by the end-user machines that gets endlessly forwarded by Ethernet switches (like ARP), or is it the broadcasting of unknown unicasts originated by the switches themselves?

Any frame that is delivered by flooding can create a storm. Such frames are broadcast frames, multicast frames and unicast frames whose destination is unknown. Note that these frames do not have to be originated by switches. They may well be originated by any connected station. As to the question what is the most commonly seen frame in such unicast/multicast/broadcast storms - I cannot say. Every network having redundant L2 links already runs STP or is already beaten to death by the storm I think that the type of frame causing a storm does not make any substantial difference - because the storms are not prevented by avoiding such frames but primarily by eliminating the L2 loops altogether. You cannot blame a particular frame type for creating problems in your network - a loop is a problem of the Layer2 switching topology, it is not created or prevented by limiting yourself to only a subset of all possible frames that can be transported over a switched network.

I would think its the broadcast traffic originated by the end-users 
because unknown unicasts will eventually reach the intended machine and 
the response packet will educate the switches that were reflexively 
broadcasting earlier, thereby killing the loop. The caveat of course is 
that the intended machine respond. If not, the broadcast storm will go 
on and on. On the other hand, an ARP reply to an ARP broadcast (which is
 a user generated broadcast) will still not break the loop.

Let's forget about STP for a while. You indeed seem to suppose that the loop is created and broken by the addressing information in MAC address tables. This would be more correct if we were speaking about L3 switching with IP routing tables. The logic in L2 is different, however, because it is a default and expected behavior that an unknown unicast/multicast/broadcast frame is forwarded out all ports except the ingress one. In essence, the default state of empty MAC address tables mandates that there will be a L2 loop if there are L1 loops. To put it plainly, with redundant links, the loop is there and it will still be there - just no frames may be currently caught in the loop. We do not identify a loop and its existence by the frames already circling in rounds but rather whether there is a possibility of a frame to circle indefinitely. In loop-free networks, there is no way how a frame could make a full round.

The elimination of L2 loops is therefore done not by eliminating traffic that can be caught in a loop but rather by eliminating the L2 loops themselves. This is obviously done by the family of STP protocols.

Perhaps you are asking about plain switches without STP support - well, in that case, things are unpleasant. A storm of frames destined to multicast or broadcast destination will go forever because no multicast or broadcast MAC address can be learned on a port (there is no station with its own source MAC address of broadcast or multicast). A storm of frames to an unknown unicast will be broken if that unknown destination replies and the reply goes back through at least one (ideally all) switches involved in the loop. There are situations when this would not be the case - think of asymmetrical routing where the route from A to B is different than the return path from B to A.

MY RATIONALE: There is a difference in that unknown unicasts are 
broadcast (sent out) all ports (except the one in which it came in on)  
but the destination MAC address is a unicast address and is not  
changed. It is the forwarding behavior of the switches that changes when
 unknown  unicasts must be forwarded. On the other hand, broadcast 
frames from  end-users, like ARP queries, have a destination MAC address
 that is itself a  broadcast address (ffff.ffff.ffff), so even an ARP 
reply will not kill  the loop. Correct?

Yes, you are correct in the sense that if a frames already became engaged in a forwarding loop, this looping (but not the existence of the L2 loop alone!) can be stopped only for the unknown unicast frames when the unknown-so-far destination responds because that will stop the switches from flooding the frame. Broadcast and multicast frames caught in a loop cannot be stopped this way because their destination mandates they are flooded, and so they are.

But either way, can one say that it is the inherent nature of Ethernet 
itself as a LAN broadcast protocol, which assumes a flat logical 
topology, that is the underlying cause?

Correct. The Ethernet was from designed the beginning as a broadcast, with the physical layer being first a bus and then a star emulating the bus (hubs). Any looped configuration was considered as violation of the design rules for Ethernet network and the Ethernet alone does not have any safeguard mechanisms to detect and recover from such gross violations. L2 switches optimize the flows of traffic if that is possible but they still carry on the basics of Ethernet broadcast frame delivery, and thus they are also prone to L2 loops.

Best regards,

Peter

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (1 ratings)
Loading.
Correct Answer
Peter Paluch Sat, 10/02/2010 - 01:40

Hello,

Lots of ideas in your post Let's go over them one by one.

Which is largely the reason for the creation of bridging loops - broadcast traffic originated by the end-user machines that gets endlessly forwarded by Ethernet switches (like ARP), or is it the broadcasting of unknown unicasts originated by the switches themselves?

Any frame that is delivered by flooding can create a storm. Such frames are broadcast frames, multicast frames and unicast frames whose destination is unknown. Note that these frames do not have to be originated by switches. They may well be originated by any connected station. As to the question what is the most commonly seen frame in such unicast/multicast/broadcast storms - I cannot say. Every network having redundant L2 links already runs STP or is already beaten to death by the storm I think that the type of frame causing a storm does not make any substantial difference - because the storms are not prevented by avoiding such frames but primarily by eliminating the L2 loops altogether. You cannot blame a particular frame type for creating problems in your network - a loop is a problem of the Layer2 switching topology, it is not created or prevented by limiting yourself to only a subset of all possible frames that can be transported over a switched network.

I would think its the broadcast traffic originated by the end-users 
because unknown unicasts will eventually reach the intended machine and 
the response packet will educate the switches that were reflexively 
broadcasting earlier, thereby killing the loop. The caveat of course is 
that the intended machine respond. If not, the broadcast storm will go 
on and on. On the other hand, an ARP reply to an ARP broadcast (which is
 a user generated broadcast) will still not break the loop.

Let's forget about STP for a while. You indeed seem to suppose that the loop is created and broken by the addressing information in MAC address tables. This would be more correct if we were speaking about L3 switching with IP routing tables. The logic in L2 is different, however, because it is a default and expected behavior that an unknown unicast/multicast/broadcast frame is forwarded out all ports except the ingress one. In essence, the default state of empty MAC address tables mandates that there will be a L2 loop if there are L1 loops. To put it plainly, with redundant links, the loop is there and it will still be there - just no frames may be currently caught in the loop. We do not identify a loop and its existence by the frames already circling in rounds but rather whether there is a possibility of a frame to circle indefinitely. In loop-free networks, there is no way how a frame could make a full round.

The elimination of L2 loops is therefore done not by eliminating traffic that can be caught in a loop but rather by eliminating the L2 loops themselves. This is obviously done by the family of STP protocols.

Perhaps you are asking about plain switches without STP support - well, in that case, things are unpleasant. A storm of frames destined to multicast or broadcast destination will go forever because no multicast or broadcast MAC address can be learned on a port (there is no station with its own source MAC address of broadcast or multicast). A storm of frames to an unknown unicast will be broken if that unknown destination replies and the reply goes back through at least one (ideally all) switches involved in the loop. There are situations when this would not be the case - think of asymmetrical routing where the route from A to B is different than the return path from B to A.

MY RATIONALE: There is a difference in that unknown unicasts are 
broadcast (sent out) all ports (except the one in which it came in on)  
but the destination MAC address is a unicast address and is not  
changed. It is the forwarding behavior of the switches that changes when
 unknown  unicasts must be forwarded. On the other hand, broadcast 
frames from  end-users, like ARP queries, have a destination MAC address
 that is itself a  broadcast address (ffff.ffff.ffff), so even an ARP 
reply will not kill  the loop. Correct?

Yes, you are correct in the sense that if a frames already became engaged in a forwarding loop, this looping (but not the existence of the L2 loop alone!) can be stopped only for the unknown unicast frames when the unknown-so-far destination responds because that will stop the switches from flooding the frame. Broadcast and multicast frames caught in a loop cannot be stopped this way because their destination mandates they are flooded, and so they are.

But either way, can one say that it is the inherent nature of Ethernet 
itself as a LAN broadcast protocol, which assumes a flat logical 
topology, that is the underlying cause?

Correct. The Ethernet was from designed the beginning as a broadcast, with the physical layer being first a bus and then a star emulating the bus (hubs). Any looped configuration was considered as violation of the design rules for Ethernet network and the Ethernet alone does not have any safeguard mechanisms to detect and recover from such gross violations. L2 switches optimize the flows of traffic if that is possible but they still carry on the basics of Ethernet broadcast frame delivery, and thus they are also prone to L2 loops.

Best regards,

Peter

ex-engineer Sat, 10/02/2010 - 08:03

Peter:

Marvelous, marvelous and stupendous!

Just one small point of clarification....

You are right that a physical loop already exists given the redundant physical link. When I was referring to the "creation of a loop," what I meant was the conditon in which the existing physical loop was being exploited by opportunistic traffic that was riding it - the storm itself,

Thanks!

Actions

This Discussion