Lab: 47 Difference between Hub ‐spoke & Mesh topology(assymetric routing) - TanveeKhanDB/OCI GitHub Wiki
What is Hub -spoke & Mesh topology:
Hub-and-Spoke:
A central hub VCN acts as the traffic controller. All spoke VCNs (Dev, UAT, Prod, DR) connect only to the hub — never directly to each other. All inter-spoke traffic must pass through the hub. Think of it like an airport — all flights go through the main hub, not directly city to city.
Internal flow dig
Types of Hub-and-Spoke in OCI enterprise:
-
Full hub-and-spoke— hub VCN has firewall/NVA, all traffic inspected centrally. -
Partial hub-and-spoke— some spokes bypass hub for low-risk traffic. -
Transitive hub-and-spoke— spoke-to-spoke traffic routes through hub via DRG
Mesh Topology:
Every VCN connects directly to every other VCN. No central dependency. Think of it like a highway grid — you can go from any city to any other city directly without passing through a central point.
Internal flow dig
Types of Mesh in OCI enterprise:
Full mesh— every VCN peers with every other (N×(N-1)/2 peering connections)Partial mesh— only select VCNs peer directly, others use hubDynamic mesh— connections established on demand via DRG route policies
What is Asymmetric routing
Asymmetric routing happens when traffic takes one path to the destination and a different path back. This commonly causes problems with stateful firewalls because the return traffic is not associated with the original session. Enterprise best practices include designing for symmetric routing, using consistent route tables, synchronizing firewall state in HA deployments, and continuously monitoring traffic paths.
Asymmetric routing problem in both topologies and exactly how to fix it:
Asymmetric routing — 4 enterprise fixes in OCI:
Fix 1 — Single active firewall: Route all traffic through exactly one NVA/firewall in the hub. Never split ingress and egress across two separate devices.
Fix 2 — OCI Route Table policy: Configure ingress and egress route tables on each subnet to force the same next-hop device — ensuring return traffic follows the same firewall as the request.
Fix 3 — Stateless security rules: In OCI Security Lists, add explicit rules for both directions (ingress AND egress) so even if paths differ slightly, both sides are permitted at the rule level.
Fix 4 — OCI Network Path Analyzer validation: After any architecture change, run NPA between source and destination to visually confirm the path is symmetric and no hop is blocking the return flow