Mesh Networking - Dimensigon

Real-World Use Case: Global Multi-Region Infrastructure

A SaaS company runs data processing clusters across 5 regions (US, EU, Asia, AWS, on-prem). Networks are unreliable, nodes fail regularly, and adding/removing infrastructure is frequent. Traditional hierarchical systems fail.

1. Dynamic Route Discovery

┌─ REGION: US-EAST (3 nodes)
node-us-1: 10.1.1.10:20194 ─┐
node-us-2: 10.1.1.11:20194 ─┼─ Route: 2 hops
node-us-3: 10.1.1.12:20194 ─┘
┌─ REGION: EU-WEST (2 nodes)
node-eu-1: 10.2.1.20:20194 ─┐
node-eu-2: 10.2.1.21:20194 ─┘
Automatic Routes Discovered:
US-EAST → EU-WEST: node-us-1 → node-eu-1 (1 hop via gateway)
US-EAST → US-EAST: node-us-1 → node-us-2 (direct, 0 hops)
node-eu-1 DOWN → Routes auto-update!

How It Works

Heartbeats - Each node broadcasts a heartbeat every 5 seconds
Route Learning - Nodes learn optimal paths dynamically from heartbeats
Failover - If a route dies, alternate routes activate in seconds
No Config - Routes discovered automatically; no manual config files

No Kubernetes, no Consul, no etcd. Just nodes finding each other.

2. Automatic Topology Healing

Scenario: Node Fails

Time 0:00 - cluster-node-3 becomes unresponsive (network partition or crash)

Time 0:05 - Other nodes notice heartbeat missing

Time 0:10 - Routes recalculated, traffic rerouted

Time 0:15 - All active nodes have updated mesh view

Result: Zero manual intervention. Orchestrations continue across remaining nodes.

This is critical for production: you don't want oncall getting paged because one node is slow.

Mesh State Transitions

// HEALTHY state
[Mesh Online] - 5/5 nodes active
  node-1: HEALTHY (route: 0 hops)
  node-2: HEALTHY (route: 1 hop via node-1)
  node-3: HEALTHY (route: 1 hop via node-1)
  node-4: HEALTHY (route: 2 hops via node-1, node-2)
  node-5: HEALTHY (route: 1 hop via node-4)

// DEGRADED state (node-3 fails)
[Mesh Degraded] - 4/5 nodes active
  node-1: HEALTHY (route: 0 hops)
  node-2: HEALTHY (route: 1 hop via node-1)
  node-3: UNREACHABLE ⚠️
  node-4: HEALTHY (route: 2 hops via node-1, node-2)
  node-5: HEALTHY (route: 1 hop via node-4)

// RECOVERED state (node-3 rejoin)
[Mesh Online] - 5/5 nodes active
  Routing tables updated automatically
  No replay required
  No manual reconciliation

3. Transparent Proxying & Inter-Node Communication

How Dimensigon Proxies Work

Each node acts as both a client and proxy:

Local Execution - Tasks execute locally on the node
Remote Execution - Tasks transparently route to other nodes
Automatic Routing - Mesh finds optimal paths through intermediary nodes
No Central Router - Every node is a router; no single point of failure

Unlike Ansible Tower (centralized control node model), Dimensigon's peer-to-peer approach means your infrastructure is resilient to node failures.

Transparent Routing Example

// Ansible Tower Model (Centralized)
Control Node (Tower) → ssh → Node-1
         ↓            ssh → Node-2
         └─ Single point of failure!

// Dimensigon Model (Decentralized)
Node-1 ←→ Node-2 ←→ Node-3
  ↓        ↓        ↓
Node-4 ←→ Node-5 ←→ Node-6

// Execute on Node-6 from Node-1
$ dshell orch run deploy-app --target=node-6

// Mesh automatically routes:
// Node-1 → Node-2 → Node-3 → Node-6
// (or any other available path)
// No central control node needed!

4. Multi-Cloud & On-Prem Hybrid

Hybrid Setup Example

# Bootstrap cluster (can be any node)
$ dimensigon new production

# Gen token on on-prem node
$ dimensigon token --expire 3600

# Join AWS nodes from CLI
$ dimensigon join on-prem-node.internal:20194 <TOKEN>

# Join Azure nodes
$ dimensigon join on-prem-node.internal:20194 <TOKEN>

# Join GCP nodes
$ dimensigon join on-prem-node.internal:20194 <TOKEN>

# View the mesh
$ dimensigon status

✓ MESH ACTIVE
  Nodes: 8
  Topology: Fully Connected
  Redundancy: 3+ hops
  Latency: on-prem→AWS 45ms, on-prem→Azure 65ms, on-prem→GCP 120ms

No Vendor Lock-In

Join nodes from any cloud (AWS, Azure, GCP)
Mix on-prem and cloud seamlessly
Run orchestrations across all clouds with single command
If AWS region fails, traffic reroutes through GCP/Azure automatically

The mesh doesn't care where nodes are. It just connects them efficiently.

5. Dimensigon vs Ansible Tower: Architectural Comparison

Architecture Comparison

ANSIBLE TOWER (Centralized Control)
┌─────────────────┐
│ Control Node    │  ← Single point of failure
│ (Tower)         │  ← Must be highly available
└────────┬────────┘
         │ SSH to each node
    ┌────┼────┬─────┐
    ▼    ▼    ▼     ▼
  Node1 Node2 Node3 Node4

Issues with Silos:
• Separate Tower instances for each silo
• Complex inter-silo communication
• Manual proxy configuration
• No automatic failover between silos

DIMENSIGON (Decentralized Mesh)
   Region-1       Region-2
   (AWS)          (Azure)
    ┌─────┐       ┌─────┐
    │ N-1 │◄──┐   │ N-5 │
    │ N-2 │   ├─►│ N-6 │
    │ N-3 │◄──┤   │ N-7 │
    └─────┘   │   └─────┘
              └─ Gateway Nodes
              (Transparent routing)

Silo Interconnection Benefits:
✓ All nodes equal (no control node)
✓ Automatic gateway discovery
✓ Self-healing on node failure
✓ No manual firewall rules
✓ Resilient to region failures

Why Mesh Beats Silos

Multi-Silo Problem: Traditional setups with Ansible Tower create isolated silos requiring manual bridge configuration.

Tower Model: Each silo has its own control node, complex inter-silo communication
Dimensigon Model: Single mesh spans all silos automatically
Failover: If silo-1 node dies, traffic reroutes through silo-2 transparently
Scaling: Add regions without reconfiguring anything

Dimensigon interconnects silos elegantly. No control nodes. No manual bridges. Just mesh.

🔗

Self-Healing

Network failures are handled automatically. Nodes rejoin when they recover.

🌍

Zero Config Routing

Routes are learned dynamically. No manual IP/DNS management.

⚡

Sub-Second Failover

When a node fails, alternate routes activate in milliseconds.

☁️

Cloud Agnostic

Works on any cloud, on-prem, or hybrid setup without modification.

Build Your Mesh Back to Features

Self-Healing P2P Networks