Skip to content

SMART_NETWORKING.md

Latest commit

 

History

History
82 lines (56 loc) · 3.67 KB

SMART_NETWORKING.md

File metadata and controls

82 lines (56 loc) · 3.67 KB
Raw

Last Updated: 2026-01-30 | Created: 2026-01-30 (v1.1.2-patch.33.7)

📡 Smart Networking & Host Mode Architecture

Learn how the SD-WAN Traffic Generator automatically adapts to your lab network.

Overview

SD-WAN labs require high-fidelity networking. To simulate real-world behavior like DHCP, ARP, and Interface Pinning, the application has transitioned to a "Smart Networking" architecture powered by Host Mode.

🚀 The "Zero-Config" Experience

When you first install the application, config/interfaces.txt is empty. Instead of failing, the system uses a multi-stage Smart Detection logic across all engines (Bash, TypeScript, and Python).

How Auto-Detection Works:

  1. Gateway Check: It queries the Linux routing table (ip route) to find the interface associated with the default gateway.
  2. Physical Check: If no gateway is found, it scans for the first active physical interface (skipping loopbacks).
  3. Fallback: As a last resort, it defaults to eth0.

Result: On a standard Ubuntu server, the lab will "see" your physical wire (e.g., enp2s0) and start generating traffic immediately without any manual configuration.

🏠 Why Host Mode?

By default, Docker uses "Bridge Mode," which creates a private virtual network. This is great for web apps but terrible for SD-WAN labs because:

  • Containers can't see physical interfaces.
  • Scapy (used for IoT) can't perform raw socket operations on the host wire.
  • Traffic always appears to come from the Docker Bridge IP instead of the host.

The Host Mode Advantage:

By using network_mode: host in docker-compose.yml:

  • Realism: Every packet generated by the lab actually goes out the physical wire.
  • IoT: Simulated devices (Hue bulbs, Nest thermostats) can perform real DHCP handshakes with your physical router.
  • Precision: You can pin specific traffic to specific WAN interfaces (WAN1, WAN2) for failover testing.

🛠️ Manual Override

If you want to force the lab to use a specific interface, you can override the smart detection.

1. Simple Override (Global)

Create config/interfaces.txt and put your interface name there:

enp2s0

This pins Background Traffic, Voice, and Connectivity Probes to this interface.

1. Simple Override (Global)

Create config/interfaces.txt and put your interface name there (one per line):

enp2s0

This pins Background Traffic, Voice, and Connectivity Probes to this interface.

2. Hot-Reload Support

The application now supports Hot-Reload. If you manually edit interfaces.txt while the container is running, the Web UI will detect the change and instantly notify the IoT and Voice modules. No restart required.

⚠️ Important Safety Notes

"One Truth" Policy

As of version v1.1.2-patch.33.11, the legacy network block in iot-devices.json has been removed. All networking is now centralized in interfaces.txt. This prevents "ghost logic" bugs where different modules might try to use different interfaces.

Port Conflicts

In Host Mode, the container shares the host's IP address.

  • The Web UI listens on port 8080 by default.
  • If your host already has a service on 8080, change the PORT variable in docker-compose.yml.
  • Generators (Traffic, Voice) are "clients" and do not listen on ports, so they have zero risk of conflicts.

Compatibility

  • Linux: Full Host Mode support (Recommended).
  • macOS/Windows: Docker Desktop handles networking differently; "Smart Detection" will naturally fallback to eth0, which is the correct behavior for those platforms.

Last Updated: 2026-01-30
Version: 1.1.2-patch.33.16