Connection fallback
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. |
Disable fallback with care
Disabling fallback means a bad network configuration can make a remote device unreachable until someone visits it physically. Leave fallback enabled unless you have a specific reason and a way to recover the device locally.Uplink failover (interfaces and cellular)
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:
- Wired Ethernet as the primary uplink (DHCP).
- 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
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
- Review what must be reachable in Connectivity & ports.
- Configure a proxy in Proxy configuration.