Why are rings not a favorite option in IT networks?

Question

I'm an engineer in the automation field. I've been switching slowly to networking. I've started in the automation world 12 years ago.

With an automation mindset, we use rings (like MRP rings) everywhere. However, I've noticed that IT network engineers hate rings and they never use it. I'm wondering why?!!

I mean it's a great way of providing redundancy with low cost.

Are there specific reasons why rings are (almost) never used in IT networks?

---

Thank you all for all of your answers. As a conclusion from all answers:

1. Rings typically require same speed and same type of physical links among ring nodes. This is a non-desired limitation in the IT networks.
2. Each node in the ring should have enough capacity for all other nodes of the ring. Again... a limitation.
3. For a tree network, if one or more nodes fails (as long as it's not the backbone), this will not affect the rest of the nodes.
4. Tree structure offers much less hops (two) compared to a very high number of hops in the rings
5. Rings sometimes used in IT, typically in backbone

Therefore Rings in automation world offer basic redundancy where static, simple and low-BW networks are usually the case.

Answer 1

Historically, there were several competing technologies using ring structures like Token Ring or FDDI, but due to higher cost, lower performance, or simply slower development they've all vanished.

Modern, ubiquitous Ethernet uses switches to bridge all network ports together, so any ring or other looped topology creates a bridge loop, bringing down the network unless it is explicitly dealt with. Redundant links require a means to mitigate the bridge loops they form, most prominently by blocking redundant ports through a spanning tree protocol (MSTP, RSTP, obsolete STP or proprietary RPVST+) or by using routing algorithms with switching (Shortest Path Bridging or TRILL).

Accordingly, the 'native' topology for Ethernet is a tree (sometimes called a 'multi-star'). Advantages of tree vs ring include: smaller network diameter, higher efficiency, lower latency.

Using a fat tree, with increasing bandwidth towards the root, that topology can also be scaled extremely well. (Just imagine 100 switches in a three-tier tree - or in a ring...)

A ring network with one of the links blocked by xSTP:

If one of the switches fails, the blocked link changes to forwarding and five switches continue. If another switch dies, the network breaks in half.

The diameter of that network is five hops, delays accordingly. All traffic between non-adjacent switches needs to cross all intermediate switches and links - if there's no ample bandwidth, congestion is more likely than in a tree. Adding more switches increases that problem. Also, more than seven switches can exceed STP's design limit and might not (re)converge.

A tree network (collapsed core):

If one of the access switches fails, nothing else happens. If the single core switch dies, everything is offline. If there's a redundant core switch then that network is hard to bring down.

Note the diameter of just two hops. That diameter doesn't even change when you add some more switches. If you need to add more switches than the core can connect, then you add a distribution tier. That way, the tree can easily grow to more than 1500 switches (of 40+ ports) with a diameter of just four.

A three-tier hierarchical network from Cisco Networking Academy Connecting Networks Companion Guide: Hierarchical Network Design

PS: The way that question was asked made me think of the data link layer only. On the network layer, routers can make much better use of meshed networks than bridges/switches.

While you can more easily use any network-layer topology you like and that makes sense for you, the diameter, efficiency and latency arguments from above also apply. However, there may be more important aspects when designing your network. A ring of (few) core routers can make a lot of sense for a large network.

Answer 2

The downside with ring networks as opposed to for example star networks, is that in a ring topology, any link in the ring needs to have enough capacity for all nodes on that ring, in order to be able to handle the outage of any link. So as your ring grows, the required capacity on each and every link in the ring needs to grow as well. This scales very badly.

Answer 3

Historically, we did use ring topologies - e.g. token ring. It didn't have redundancy. Whenever the ring broke, the whole network went down.

Bus topologies (Ethernet over coaxial) were a bit better in regard to only a single cable to care about. It, too, went down as a whole when something went wrong anywhere.

The data rates are generally much higher than in the automation and one should take care of things like signal propagation, termination and reflections.

Star-like and tree-like topologies like Ethernet over twisted pairs came with much more fail-safety and much more graceful failure: if something on the network is broken, the rest can run just as usual and it was obvious what to fix.

Another bonus of the star-like networks that came with more intelligent (switching) hubs is that they don't require all devices to have the same properties like in the bus/ring topologies. They could have different data rates (10 or 100 or 1000 or 2500 or 5000 or 10000 MBit/s) and even different media (copper and optical fiber mix very well). The switching hub makes all these differences transparent.

---

Where we DO have ring-like and grid-like topologies in modern networking are the backbone connections. A campus-wide network backbone is usually at least a ring. A cell tower quite often has more than one backhaul connection. An internet service providers usually have city-wide grids. Etc, etc, etc...

Those redundant links are either used for reliability (to route around failures) or for bigger capacities, or both.

Of course, complex topologies require complex routing protocols as well.

Answer 4

I mean it's a great way of providing redundancy with low cost.

That is true if and only if multiple faults don't happen at the same time and one fault is fixed before the next fault happens.

Computers come and go all the freaking time, people move to different offices, people have laptops which they pack up at the end of the day. Some people turn their computers off at night.

In a typical office situation, any network technology where faults with, or the removal of, end systems can disrupt the network will be far more fragile than one built around a central infrastructure device, even if that central infrastructure device is a single point of failure.

This is why twisted pair Ethernet with its hubs and point-to-point links was a breath of fresh air compared to prior technologies like coaxial Ethernet and token ring. At the end-user level rings suck.

Rings at the infrastructure level have less risk from multiple simultaneous faults, but then you get into the capacity issues that Zac and Teun mention.

Answer 5

Are there specific reasons why rings are (almost) never used in IT networks?

They are stable enough without it. There's simply no big push to have more redundancy. Remember that a ring will only protect you against some fairly specific types of failures - which is rare. MTBF for switches is on the order of tens of years:

And in a dynamic environment, ring networks such as MRP increase the risk of downtime in my experience. MRP is great for a static setup, not so much if you have changing components in it.

So TL;DR: There's no demand for it. Switches doesn't fail often enough.