Connection fallback

How a device stays reachable after a bad config push, link outage, or proxy failure.

Devices are often deployed where connectivity is imperfect: a misapplied network change, a flaky uplink, or a proxy that goes down. SPEKTRA Edge OS has several fallback behaviors that keep a device reachable and recoverable. This page explains the three that matter most: network configuration fallback, uplink (interface and cellular) failover, and proxy fallback.

Network configuration fallback

When you push a new network configuration to a device, there is always a risk that the new configuration is wrong and takes the device offline — which would also prevent you from pushing a correction.

To guard against this, a device can fall back to a known-good network configuration that was established when the device was set up. If a platform-supplied configuration leaves the device unable to reach the platform, the device can revert to this baked-in configuration so it can be reached again.

You can control this behavior:

Setting Effect
Fallback enabled (default) If platform-supplied network configuration fails, the device reverts to its known-good configuration.
Fallback disabled The device always uses the platform-supplied configuration and never reverts.

A device can have more than one uplink — for example wired Ethernet plus cellular, or wired plus Wi-Fi. When multiple uplinks are configured, the device prefers the primary uplink and uses the others as backups, switching to a working uplink when the preferred one is unavailable.

A common, robust pattern is:

  1. Wired Ethernet as the primary uplink (DHCP).
  2. Wi-Fi or cellular as a backup that takes over when the wired link is down.

Cellular is especially useful as a last-resort uplink because it does not depend on local site infrastructure. Associate a SIM with the device during hardware registration, configure the cellular connection in your network YAML, and the device can fall back to it to stay manageable.

Proxy fallback

When a device is configured to reach the platform through a proxy, it still needs to stay reachable if that proxy becomes unavailable. The device evaluates the available paths to the platform and uses a working one, so a single failed proxy does not necessarily cut the device off from management.

This means you can introduce a proxy for normal operation without making it a single point of failure for device management, provided a viable path to the platform remains.

Putting it together

The three mechanisms guard different failures, so they stack: each one catches what the ones above it cannot.

flowchart TD
    GOAL(["Device must stay<br/>reachable by the platform"])

    GOAL --> L1{"Is the pushed network<br/>configuration working?"}
    L1 -->|"no"| F1["Revert to the known-good<br/>configuration from setup"]

    L1 -->|"yes"| L2{"Is the preferred<br/>uplink up?"}
    L2 -->|"no"| F2["Fail over to a backup uplink<br/>(Wi-Fi or cellular)"]

    L2 -->|"yes"| L3{"Is the proxy<br/>reachable?"}
    L3 -->|"no"| F3["Use another viable path<br/>to the platform"]

    L3 -->|"yes"| OK(["Managed normally"])

For a remote, hard-to-reach device, a resilient setup combines all three:

  • Keep network configuration fallback enabled so a bad push self-corrects.
  • Provide a backup uplink (cellular is ideal) so a single link failure does not isolate the device.
  • If you use a proxy, ensure a viable path to the platform remains so proxy problems do not block management.

Next steps