LFCE 6 🐧 Network Topologies — Star, Mesh, Hub-and-Spoke
Network topology is not an abstract diagram exercise. It is the physical and logical arrangement that determines how packets travel, where failures propagate, and what it costs to scale. For a Linux engineer preparing for the LFCE, topology knowledge underpins every routing decision, every firewall rule placement, and every troubleshooting path you will trace. The exam objectives explicitly include network topology as a foundational networking concept . You cannot configure a system to route IP traffic dynamically without understanding whether the underlying design is a star, a mesh, or a hub-and-spoke arrangement.
This chapter examines the three topologies that dominate modern infrastructure design. Star topology represents the centralized LAN model—every device reaches a central switch. Mesh topology represents the distributed model—nodes connect directly, with full or partial redundancy. Hub-and-spoke represents the hybrid WAN and cloud model—spokes communicate through a central hub, often across geographic boundaries. Each topology makes a different trade-off between cost, resilience, and performance. Understanding those trade-offs is what separates a technician who follows instructions from an engineer who designs the network.
Key point: Topology determines failure domains. A star dies when the center dies. A full mesh survives any single failure but costs n(n-1)/2 links. Hub-and-spoke concentrates traffic and control at the hub, making the hub both the single point of failure and the single point of management.
Why these topologies exist
The centralized management problem.
Early Ethernet networks used a bus topology—a single coaxial cable with all nodes tapping into it. The bus was cheap but fragile: a loose terminator or a broken cable segment could bring down the entire network . Star topology solved this by giving every device its own dedicated link to a central device, typically a switch. A failure on one link isolates one device; the rest continue operating . This centralization also simplified management: the switch became the single point for monitoring, policy enforcement, and expansion. The trade-off is absolute dependence on the center. If the switch fails, every attached device loses connectivity . Star topology is the default LAN design for exactly this reason—it is manageable, predictable, and cheap to expand.
The single-path problem.
Star topology works well within a building, but it offers no redundancy. Every communication path passes through the center. If that path fails, or if the center becomes congested, there is no alternative. Mesh topology addresses this directly. In a full mesh, every node connects to every other node, providing multiple paths between any two endpoints . If one link fails, traffic routes around it. This is the topology of the internet’s core and of high-availability data center fabrics. The cost is prohibitive for anything but a small number of nodes: the number of links grows quadratically, and each node needs an interface for every other node . Partial mesh, where some nodes are fully interconnected and others connect only to a subset, is the practical compromise.
The geographic distribution problem.
Star topology assumes proximity—you can run a cable from every device to the switch. Mesh topology assumes a dense cluster—you can justify a link between every pair. Neither assumption holds when an organization has offices in Oslo, Frankfurt, and Singapore. Hub-and-spoke topology emerged to connect geographically dispersed sites without requiring a direct link between every pair . Each spoke site connects to a central hub, and spoke-to-spoke traffic traverses the hub. This mirrors the star topology but at WAN scale, and it introduces the same vulnerability: the hub is the single point of failure for all inter-site communication. Cloud providers formalize this pattern with virtual networks, peering gateways, and dynamic routing gateways, making hub-and-spoke the standard architecture for enterprise cloud connectivity .
a. Star topology — the centralized LAN
A star topology connects every device to a single central device, traditionally a switch or hub. Each device has a dedicated point-to-point link to the center, and all communication between devices passes through that center .
# Conceptual star topology configuration on a Linux switch (bridge)
# Every port belongs to the same bridge; the bridge acts as the center
ip link add name br0 type bridge # Create the central bridge device
ip link set dev eth0 master br0 # Attach the first device link to the bridge
ip link set dev eth1 master br0 # Attach the second device link
ip link set dev eth2 master br0 # Attach the third device link
ip link set dev br0 up # Bring the central bridge upIn a switched star, the central device learns MAC addresses and forwards frames only to the intended destination port, eliminating the broadcast behavior of an old hub . The failure of a peripheral link isolates only that peripheral. The failure of the bridge itself isolates everything.
The star’s strength is isolation at the edge. The star’s weakness is concentration at the center. Redundant star designs—two center switches with redundant links—mitigate the weakness without abandoning the topology .
b. Mesh topology — full and partial redundancy
Mesh topology connects nodes directly to one another. In a full mesh, every node has a direct link to every other node. In a partial mesh, some nodes have multiple links while others have fewer .
# Partial mesh routing configuration on a Linux router
# Multiple paths to the same destination enable failover
ip route add 10.20.0.0/16 via 192.168.1.2 metric 100 # Primary path through neighbor A
ip route add 10.20.0.0/16 via 192.168.1.3 metric 200 # Backup path through neighbor BThe number of links in a full mesh grows as n(n-1)/2. For five nodes, that is ten links. For ten nodes, forty-five. For fifty nodes, over twelve hundred. This quadratic growth is why full mesh is reserved for small, critical clusters—database replication groups, high-availability router pairs, or backbone fabrics . Partial mesh reduces the count while preserving redundancy where it matters most.
Mesh topology is not a LAN design in the traditional sense. It is a routing design. Every node must be a router, or every node must have a path to a router. The Linux kernel’s routing table, with multiple routes and metrics, is the mechanism that makes mesh forwarding possible.
c. Hub-and-spoke topology — WAN and cloud connectivity
Hub-and-spoke is a star topology extended across WAN links. Spoke sites connect to a central hub, and all inter-spoke traffic passes through the hub . In cloud architectures, the hub is typically a virtual network with an internet gateway and a dynamic routing gateway, while spokes are peered virtual networks or on-premises sites .
# Hub-and-spoke routing on a Linux hub router
# Forward traffic from spoke A to spoke B through the hub
ip route add 10.1.0.0/24 via 10.0.0.2 # Route to spoke A
ip route add 10.2.0.0/24 via 10.0.0.3 # Route to spoke B
# Enable forwarding so the hub can relay between spokes
sysctl -w net.ipv4.ip_forward=1
# The hub router receives from spoke A (10.0.0.2) and forwards to spoke B (10.0.0.3)
# without spoke A and spoke B having a direct route to each otherThe hub-and-spoke topology centralizes policy. A single firewall at the hub can inspect all inter-site traffic. A single routing table at the hub knows every destination. This simplicity is also the topology’s limitation: the hub must handle all inter-spoke traffic, and hub failure disconnects every spoke from every other spoke. Redundant hubs—active-passive or active-active—are the standard mitigation in production designs .
Complete Example Session
# ============================================
# PART 1: STAR TOPOLOGY SIMULATION WITH LINUX BRIDGE
# ============================================
# A Linux bridge acts as a central switch. All veth pairs connect to it.
ip link add name star-br type bridge
ip link set dev star-br up
# Create three virtual devices (veth pairs) representing hosts
ip link add veth0 type veth peer name veth0-br
ip link add veth1 type veth peer name veth1-br
ip link add veth2 type veth peer name veth2-br
# ============================================
# PART 2: ATTACH ALL HOST LINKS TO THE CENTER
# ============================================
ip link set dev veth0-br master star-br
ip link set dev veth1-br master star-br
ip link set dev veth2-br master star-br
# Bring up all interfaces
ip link set dev veth0 up
ip link set dev veth1 up
ip link set dev veth2 up
ip link set dev veth0-br up
ip link set dev veth1-br up
ip link set dev veth2-br up
# ============================================
# PART 3: VERIFY STAR CONNECTIVITY
# ============================================
# Assign addresses and test that veth0 can reach veth1 through the bridge
ip addr add 192.168.100.1/24 dev veth0
ip addr add 192.168.100.2/24 dev veth1
ping -c 2 192.168.100.2
# ============================================
# PART 4: SIMULATE CENTER FAILURE
# ============================================
# Bring the bridge down: all connectivity between hosts ceases
ip link set dev star-br down
ping -c 1 192.168.100.2 # Fails: star center is down
# ============================================
# PART 5: RESTORE AND OBSERVE ISOLATION
# ============================================
ip link set dev star-br up
# Bring one host link down: only that host loses connectivity
ip link set dev veth1-br down
ping -c 1 192.168.100.2 # Fails: veth1 is isolated
ping -c 1 192.168.100.1 # Still works from veth0 to veth0
# ============================================
# PART 6: MESH ROUTING WITH MULTIPLE PATHS
# ============================================
# Create a partial mesh with two routers and redundant paths
ip netns add router-a
ip netns add router-b
ip netns add router-c
# Router A connects to B directly and to C directly
# Router B connects to A and to C (partial mesh)
ip link add veth-ab type veth peer name veth-ba
ip link set veth-ab netns router-a
ip link set veth-ba netns router-b
# ============================================
# PART 7: MESH ROUTE CONFIGURATION
# ============================================
# From router A, reach C's network via B with a metric
ip netns exec router-a ip route add 10.30.0.0/24 via 10.10.0.2 metric 100
# Add a backup path through a different neighbor
ip netns exec router-a ip route add 10.30.0.0/24 via 10.10.0.3 metric 200
# ============================================
# PART 8: HUB-AND-SPOKE ROUTING
# ============================================
# Hub router forwards between spokes; spokes have no direct route
# On the hub:
sysctl -w net.ipv4.ip_forward=1
ip route add 10.1.0.0/24 via 10.0.0.2 # Route to spoke A
ip route add 10.2.0.0/24 via 10.0.0.3 # Route to spoke B
# Spoke A's default route points to the hub; spoke A cannot reach spoke B directly
ip route add default via 10.0.0.1
# ============================================
# PART 9: VERIFY HUB RELAY
# ============================================
# Traffic from spoke A to spoke B must traverse the hub
# On spoke A: traceroute to spoke B shows the hub as the first hop
traceroute -n 10.2.0.1
# Output: 1 10.0.0.1 (the hub) 2 10.2.0.1 (spoke B)
# ============================================
# PART 10: TOPOLOGY COMPARISON SUMMARY
# ============================================
# Star: single center, edge isolation, center failure kills all
# Mesh: multiple paths, link failure routes around, cost is quadratic
# Hub-and-spoke: central hub relays between spokes, hub is both
# the policy point and the single point of failureThe ten parts demonstrated star topology using a Linux bridge, simulated center failure, configured partial mesh routing with redundant paths, and implemented hub-and-spoke forwarding where inter-spoke traffic must pass through a central router.
Quick Reference
Topology Comparison
| Property | Star | Full Mesh | Hub-and-Spoke |
|---|---|---|---|
| Link count | n | n(n-1)/2 | n-1 (spokes to hub) |
| Failure domain | Center kills all | Any single link survives | Hub kills inter-spoke |
| Cost | Low | Very high | Moderate |
| Scalability | High (add ports) | Low (quadratic) | Moderate (hub capacity) |
| Management | Centralized | Distributed | Centralized |
| Typical use | LAN access | Backbone, HA cluster | WAN, cloud VCN |
Linux Commands
| Command | Purpose |
|---|---|
ip link add name br0 type bridge | Create a star center (bridge) |
ip link set dev eth0 master br0 | Attach a host link to the star center |
ip route add <net> via <gw> metric <n> | Add a mesh path with priority |
sysctl -w net.ipv4.ip_forward=1 | Enable hub relay forwarding |
traceroute -n <dest> | Verify hub traversal |
Best Practices
✅ Do This:
# Star: verify edge isolation before blaming the center
ip link show | grep -E 'state (DOWN|UNKNOWN)' # ✅
# Mesh: always set metrics on multiple paths
ip route add 10.0.0.0/8 via 192.168.1.1 metric 100 # ✅
# Hub: enable forwarding before adding routes
sysctl -w net.ipv4.ip_forward=1 # ✅
# Spoke: default route points to hub
ip route add default via 10.0.0.1 # ✅
# Verify hub relay with traceroute
traceroute -n 10.2.0.1 # ✅
# Redundant hub: add a secondary hub route with higher metric
ip route add 10.0.0.0/8 via 10.0.0.2 metric 200 # ✅❌ Don’t Do This:
# Star: assume one dead link means the center is down
# Check the individual link before replacing the switch # ❌
# Mesh: add routes without metrics (unpredictable selection)
ip route add 10.0.0.0/8 via 192.168.1.1 # ❌
# Hub: add spoke routes without forwarding enabled
ip route add 10.1.0.0/24 via 10.0.0.2 # ❌
# Spoke: add a direct route to another spoke (breaks hub model)
ip route add 10.2.0.0/24 via 10.0.0.3 # ❌
# Hub: assume a single hub is sufficient for production
# No redundancy plan for the single point of failure # ❌
# Mesh: build full mesh for more than a handful of nodes
# Quadratic link count makes it unmanageable # ❌Common Pitfalls
| Pitfall | Why It Happens | Fix |
|---|---|---|
| Star center failure takes down all | No redundant switch or bridge | Deploy redundant center with STP or MLAG |
| Mesh route blackhole after link failure | No dynamic routing protocol | Use OSPF/BGP or static backup routes with metrics |
| Hub-and-spoke spoke cannot reach another spoke | Hub forwarding disabled or missing route | Enable ip_forward and add spoke routes on hub |
| Star topology broadcast storm | A loop between two center switches | Enable STP on bridges |
| Mesh link count explodes | Full mesh attempted beyond small cluster | Switch to partial mesh or hub-and-spoke |
| Hub becomes bottleneck | All inter-spoke traffic converges | Deploy redundant hubs or direct spoke peering for high-traffic pairs |
Real-World Examples
1. Star: access switch in a server rack
# All servers connect to one top-of-rack switch
ip link set dev eth0 master br0
ip link set dev eth1 master br02. Mesh: redundant router pair with two paths
ip route add 10.0.0.0/8 via 192.168.1.1 metric 10
ip route add 10.0.0.0/8 via 192.168.1.2 metric 203. Hub: cloud VCN with internet gateway
# Hub VCN has the gateway; spokes peer to hub
ip route add default via 10.0.0.14. Spoke: on-premises site connecting to cloud hub
# Site-to-site VPN tunnel to the hub
ip route add 172.16.0.0/12 via 10.0.0.15. Star: bridge with STP enabled
ip link set dev br0 type bridge stp_state 16. Mesh: OSPF for dynamic path selection
# OSPF discovers mesh paths automatically
vtysh -c "router ospf" -c "network 10.0.0.0/8 area 0"7. Hub: verify relay with traceroute
traceroute -n 10.2.0.1 # First hop should be the hub8. Star: isolate a failing port
ip link set dev eth2 down # Only eth2's host loses connectivity9. Hub-and-spoke: redundant hub with VRRP
# Two hubs share a virtual IP; spokes point to the VIP
ip route add default via 10.0.0.25410. Partial mesh: data center fabric
# Leaf-spine is a partial mesh: every leaf connects to every spine
ip route add 10.100.0.0/16 via 10.0.0.1 metric 100
ip route add 10.100.0.0/16 via 10.0.0.2 metric 200Visual
Star Topology
┌──────────────────────────────────────────────────────────────┐
│ STAR: EVERY DEVICE REACHES THE CENTER │
│ │
│ Host A Host B Host C │
│ │ │ │ │
│ │ │ │ │
│ └───────────────┼───────────────┘ │
│ │ │
│ ┌──────┴──────┐ │
│ │ SWITCH │ ← Single point of │
│ │ (center) │ failure and control │
│ └──────┬──────┘ │
│ │ │
│ ┌───────────────┼───────────────┐ │
│ │ │ │ │
│ Host D Host E Host F │
│ │
│ Edge link fails: one host isolated │
│ Center fails: all hosts isolated │
└──────────────────────────────────────────────────────────────┘Full Mesh vs Partial Mesh
┌──────────────────────────────────────────────────────────────┐
│ MESH: DIRECT PATHS BETWEEN NODES │
│ │
│ FULL MESH (4 nodes, 6 links): │
│ A────────B │
│ │╲ ╱│ │
│ │ ╲ ╱ │ │
│ │ ╳ │ │
│ │ ╱ ╲ │ │
│ │╱ ╲│ │
│ C────────D │
│ │
│ PARTIAL MESH (4 nodes, 4 links): │
│ A────────B │
│ │ │ │
│ │ │ C───D (C and D connect only to B) │
│ │ │ │
│ C────────┘ │
│ │
│ Full mesh: n(n-1)/2 links. Partial: selective redundancy. │
└──────────────────────────────────────────────────────────────┘Hub-and-Spoke
┌──────────────────────────────────────────────────────────────┐
│ HUB-AND-SPOKE: ALL SPOKE TRAFFIC PASSES THROUGH THE HUB │
│ │
│ Spoke A Spoke B │
│ │ │ │
│ │ │ │
│ └─────────┬─────────┘ │
│ │ │
│ ┌─────┴─────┐ │
│ │ HUB │ ← Policy point │
│ │ ROUTER │ Single point of failure │
│ └─────┬─────┘ │
│ │ │
│ ┌─────────┴─────────┐ │
│ │ │ │
│ Spoke C Spoke D │
│ │
│ A to C: A → Hub → C. No direct spoke-to-spoke path. │
│ Hub fails: all inter-spoke communication stops. │
└──────────────────────────────────────────────────────────────┘Summary
| Item | Value |
|---|---|
| Star topology | All nodes connect to one center; edge failure isolates one node; center failure isolates all |
| Mesh topology | Nodes connect directly; full mesh has n(n-1)/2 links; partial mesh reduces cost |
| Hub-and-spoke | Spokes connect to a hub; inter-spoke traffic traverses the hub |
| Star use case | LAN access, server racks, campus networks |
| Mesh use case | Backbone routing, HA clusters, data center fabrics |
| Hub-and-spoke use case | WAN, cloud VCN peering, enterprise branch connectivity |
| Star center | Switch or bridge; Linux: ip link add type bridge |
| Mesh mechanism | Routing table with multiple paths and metrics |
| Hub mechanism | IP forwarding plus routes to every spoke network |
| Critical vulnerability | Star center and hub are single points of failure without redundancy |
Key takeaways:
- Topology determines failure scope. A star center failure takes down every attached device. A hub failure stops all inter-spoke traffic. A mesh link failure is routed around if a backup path exists.
- Link count is the mesh constraint. Full mesh grows quadratically. Beyond a handful of nodes, partial mesh or hub-and-spoke is the only practical design.
- Star is a LAN design; hub-and-spoke is a WAN design. The same centralization principle applies, but hub-and-spoke crosses geographic boundaries and introduces routing between sites.
- Linux bridges implement star centers. A bridge with multiple ports attached is a software switch. The center is a single failure domain unless bridged redundantly.
- IP forwarding makes the hub a hub. Without
net.ipv4.ip_forward=1, the hub cannot relay between spokes regardless of its routing table. - Metrics create mesh failover. Two routes to the same destination with different metrics give the kernel a primary and a backup path.
- Redundancy is a design choice, not a topology. A star can be made resilient with redundant centers. A hub-and-spoke can be made resilient with redundant hubs. The topology defines the default failure mode; the design overrides it.
Remember: Star, mesh, and hub-and-spoke are not competing ideals. They answer different questions. Star asks: how do I connect many devices cheaply and manageably? Mesh asks: how do I guarantee a path exists even when a link fails? Hub-and-spoke asks: how do I connect distributed sites without building a full mesh between them? The LFCE engineer must recognize which question the infrastructure is answering, because that recognition determines where to place firewalls, how to configure routing, and what to check first when connectivity fails.
Stop using slow, ad-bloated tool sites! 🤮
🔎 Search “KandZ Tools” on Google to use many professional utilities for free.
KandZ.me is the ultimate minimalist hub for:
✅ Finance (Mortgage, Interest, Inflation)
✅ Tech (Base64, JSON, Dev Suite, IP)
✅ Health (BMI, BMR, TDEE)
✅ Productivity (Timer, Workspace, QR)
⚡️ Fast & Private
🔒 No data leaves your device
💎 100% Free
🔗 Use it now: https://tools.kandz.me
🔖 Bookmark it—you’ll need it later!