All known unicast/multicast frames shouldn't cause loops since they have a known destination. So they can use all the available bandwidth. What am I missing?

  • The actual destination in a broadcast is every interface, and an unknown unicast destination is unknown, so it is sent to every interface..
    – Ron Maupin
    Apr 15 '20 at 12:27
  • Did any answer help you? If so, you should accept the answer so that the question doesn't keep popping up forever, looking for an answer. Alternatively, you can post and accept your own answer.
    – Ron Maupin
    Dec 17 '20 at 16:48

Source MACs are very often learned through broadcasts sent from that source. If you forward each broadcast through one of a choice of links, that link becomes the one associated with the source. If the link is non-optimal, so will the traffic towards that node by forwarded.

Imagine a ring of four switches. Which way should broadcasts be forwarded? How should the bridges learn the source MACs? You quickly end up with a bunch of flows across switches that shouldn't be in the path, causing unneccessary traffic in the network and needlessly congesting links.

What you'd need is that the distance of each MAC address is somehow passed from switch to switch. Since a TTL concept doesn't exist for Ethernet, that isn't possible.

Shortest Path Bridging is an alternative concept to STP where a spanning tree is created for each destination MAC, utilizing all redundant paths. Sadly, that hasn't really caught on yet in the industry.

Also, link aggregation (LAG) and multi-chassis link aggregation (MC-LAG) are techniques that try to utilize redundant links between switches. Standard LAG is limited to switch pairs and MLAG solutions are proprietary, so most networkers look for something else.

Most approaches prefer to use routed links and ECMP to distribute traffic - which can work quite well if done properly.

  • I was thinking about alternative approaches to STP, since it wastes a lot of bandwidth. For example: why not actually use TTL in Ethernet layer, and after an unknown unicast frame visited a switch install a drop entry for that VLAN-DMAC (for 30 seconds or so). But then comes the issue of application layer retransmissions that would just get dropped :D... oh well
    – manish ma
    Apr 15 '20 at 11:27
  • @sergeyrar "Why not actually use TTL in Ethernet" - Ethernet doesn't have a TTL field and if you add that it isn't Ethernet any more. Basically, the Ethernet concept is to transport/forward frames across a network unchanged. A TTL field would break that. Initially, a shared wire or dumb repeaters/hubs where used that had no capability of changing the TTL. But you're getting the idea. ;-)
    – Zac67
    Apr 15 '20 at 11:32
  • @sergeyrar, "I was thinking about alternative approaches to STP, since it wastes a lot of bandwidth." Actually, it can be a lot less than you think. Unknown unicast addresses are learned very quickly (it only takes one frame), and broadcast is nearly deprecated (ARP still uses it for IPv4, but IPv6 has no broadcast). There are many companies that will test software, and if it uses broadcast, they will not use the software. Multicast is the modern way to do such things. Cisco best practices also limit the broadcast domain.
    – Ron Maupin
    Apr 15 '20 at 12:25
  • 1
    @RonMaupin I think sergeyrar was referring to potential bandwidth that is wasted on the blocked, idle links, and he was trying to utilize them.
    – Zac67
    Apr 15 '20 at 17:04

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.