This is the multi-page printable view of this section.
Click here to print.
Return to the regular view of this page.
Networking
This section covers how a device connects to the network and to the SPEKTRA Edge
platform: how you describe network configuration, how the device falls back
between connections, how to route through a proxy, what the device needs to reach
on the network, and how time is kept in sync.
Network configuration model
Device networking is described as a Netplan-format YAML document. This is a
clean, declarative way to configure wired, Wi-Fi, and cellular connections, as
well as advanced setups such as bonds, bridges, VLANs, and tunnels.
You can supply the network configuration when you
create an install image (so the device has connectivity from first
boot) and you can update it later from the dashboard. When you push
configuration from the platform, you choose how it combines with what is already
on the device:
| Mode |
Behavior |
| Merge |
The pushed configuration is merged with the device’s existing configuration. |
| Replace |
The pushed configuration replaces the device’s existing configuration. |
Netplan reference
For configuration syntax and examples for each connection type, see the official
Netplan documentation. SPEKTRA Edge accepts standard Netplan YAML.
The device reports its observed network state back to the platform — active
interfaces, IP addresses, and carrier information — which you can view on the
device overview page.
Wired, Wi-Fi, and cellular
All three connection types are configured through the same network
configuration document:
- Wired connections typically use DHCP by default and need no configuration
to come up.
- Wi-Fi connections are configured with the network name and credentials.
- Cellular connections are configured for the modem; a device can also be
associated with a SIM in the platform for inventory and activation tracking.
See the Netplan documentation for the exact YAML for each type.
Connection fallback
A field device often has more than one way to reach the network, and its
configuration can be changed remotely. To keep a configuration mistake or a link
outage from taking a device permanently offline, the OS has several layers of
fallback — network configuration fallback, uplink (interface and cellular)
failover, and proxy fallback. These are covered in detail on the
Connection fallback page.
In this section
1 -
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
2 -
Proxy configuration
If your devices reach the internet through a forward proxy, configure the proxy
so that both the device’s connection to the SPEKTRA Edge platform and your
workloads’ traffic are routed correctly.
What you can set
Proxy configuration consists of the standard proxy settings:
| Setting |
Meaning |
http_proxy |
Proxy URL for plain HTTP traffic. |
https_proxy |
Proxy URL for HTTPS traffic. |
no_proxy |
Hosts and networks that should bypass the proxy (comma-separated). |
In addition, you can specify which network interfaces the device should use to
reach the platform through the proxy, so control-plane traffic uses the intended
path.
Where to set it
You can configure the proxy:
- at image creation, so devices use the proxy from first boot, or
- from the dashboard for a device that is already online.
The proxy applies both to the device’s own communication with the platform and to
container workloads running on the device.
Fallback behavior
The device determines the best route to the platform and will fall back to a
direct connection when the proxy is not usable, so a proxy outage does not
necessarily take a device offline. If you require that all traffic traverse
the proxy, ensure direct egress is blocked at the network level rather than
relying on device configuration.
no_proxy recommendations
Add to no_proxy any destinations that must not go through the proxy, such as:
- on-site services the device talks to directly (local registries, local APIs)
- link-local and private ranges used on the device’s LAN
Next steps
3 -
Connectivity & ports
This page lists what a device needs to reach on the network and what it accepts
on its own interfaces, so you can plan firewall rules for the sites where your
devices run.
Outbound connectivity (required)
A device reaches the SPEKTRA Edge platform over secure, outbound connections.
Devices do not need any inbound connections from the platform — all
communication is initiated by the device.
| Destination |
Port |
Purpose |
| SPEKTRA Edge platform endpoints |
TCP 443 |
Provisioning, configuration, telemetry, log forwarding, and remote access — all over TLS. |
| Time sources |
UDP 123 |
Network time synchronization. See Time synchronization. |
| Public STUN servers |
UDP |
External IP address discovery. |
At minimum, allow outbound TCP 443 to the platform and outbound UDP 123
to your time sources. If you use a proxy, the device’s platform traffic
egresses through it.
Inbound (on the device)
By default a device exposes only what is needed to administer it locally:
| Port |
Purpose |
| TCP 22 |
SSH access. Can be restricted or disabled — see SSH access. |
The device also responds to local network discovery (mDNS) so it can be found by
name on the local segment; this can be turned off with the device discovery
setting.
Any ports your workloads expose are determined by the workloads you deploy,
not by the OS.
Remote access does not require inbound ports
Operator actions such as opening a remote shell, transferring files, or
streaming logs are carried over the device’s existing outbound connection to the
platform. You do not need to open inbound ports to use them. See
Remote access.
Firewall planning checklist
4 -
Time synchronization
Accurate time is important for secure connections, certificate validation, log
correlation, and device attestation. Devices keep their clocks synchronized over
the network using NTP.
Default behavior
Out of the box, a device synchronizes against public time sources, so a device
with internet access keeps accurate time without any configuration.
Setting custom NTP servers
If your environment requires specific time sources — for example, internal NTP
servers on an isolated network — you can provide your own NTP configuration. You
can set it:
- at image creation, so it applies from first boot, or
- by placing an NTP configuration on the device’s configuration storage.
When custom NTP settings are provided, they take effect early in the boot process
so the device’s clock is correct before it contacts the platform.
Recommendations
- On networks without internet access, always configure reachable internal
NTP servers; otherwise the device cannot correct its clock, which can cause
secure connections and attestation to fail.
- Make sure outbound UDP 123 to your time sources is allowed — see
Connectivity & ports.
Clock errors and connectivity
A device whose clock is far off may be unable to establish TLS connections to the
platform and may fail attestation. If a device cannot come online and you suspect
time, verify it can reach an NTP source.