Tomohiro

I’ve worked on both star and mesh topologies, and while star is simple and cost-efficient, it introduces single points of failure at the hub, which can be risky as your network grows. Mesh topologies, on the other hand, are far more reliable because every node is connected to multiple others. 

However, the trade-off is complexity—both in terms of management and network latency. With mesh, there’s a lot of traffic management, especially if you're dealing with a large number of nodes.
              

Chen

Exactly! Mesh topologies are great for fault tolerance because any node can reroute traffic if a connection goes down, but they can introduce significant overhead, especially if not optimized correctly. 

In my experience, network efficiency decreases as the number of nodes increases. You need robust routing protocols to avoid unnecessary packet duplication, and that can increase latency. 

I think a hybrid topology can strike the right balance, allowing you to maintain redundancy without overcomplicating the network
              

Luis

In a hybrid setup, you can localize the advantages of star topology within segments of the network that don’t need heavy redundancy, and use mesh for the critical parts of the infrastructure. In terms of cost, this setup has worked well for us. 

We kept the star layout for internal, non-mission-critical systems while using mesh for external-facing services where uptime is essential. It’s a cost-effective approach without sacrificing too much on redundancy.
              

Chen

Luis, that’s the same approach we’ve been considering—segmenting the network based on the criticality of different functions. For high-availability systems, a mesh is obviously the way to go, but it can be overkill for internal, low-traffic sections. 

Are you using any specific routing protocols to manage traffic within the mesh segments? We’re evaluating OSPF (Open Shortest Path First) and BGP (Border Gateway Protocol), but I’m curious what’s worked for you.
              

Hiroshi

We’ve used OSPF for internal mesh routing because it’s more suited for intra-domain environments. OSPF efficiently manages the dynamic changes in our internal mesh, handling routing updates without much manual intervention. It reduces latency by ensuring that the shortest path is always selected. 

BGP, in my experience, is better suited for larger, more complex external networks that span multiple domains. It might be overkill unless you’re dealing with extensive, multi-organization traffic flows.
              

Luis

We’ve gone with OSPF too. It works well for internal dynamic routing and keeps the overhead manageable. We also use it in conjunction with MPLS (Multiprotocol Label Switching) for our mesh segments to prioritize traffic, especially for mission-critical applications. MPLS helps with traffic engineering and allows us to maintain consistent low-latency performance, even during peak usage periods.
              

Ivan

Interesting that you mention MPLS, Luis. I’ve had clients use it for traffic prioritization, but there’s been pushback lately because of SD-WAN solutions. SD-WAN can provide better visibility and control over traffic routing, especially when managing multiple cloud services or remote sites. 

Do you think SD-WAN could be a viable replacement for MPLS in your mesh topology?
              

Hiroshi

I’ve been hearing the same about SD-WAN. It offers flexibility, especially in hybrid cloud environments where you need to optimize traffic between on-prem and cloud services. SD-WAN provides more intelligent path control based on application priorities, which can reduce overall costs compared to MPLS. 

However, MPLS still excels in providing guaranteed QoS (Quality of Service), so it might be a while before SD-WAN completely replaces it in mission-critical environments.