Tracking Features¶

RansNet SD-WAN routers include a built-in tracking engine that continuously monitors network reachability and automatically reacts to changes. Rather than relying on link-state signals alone (which only detect physical failures), tracking probes real connectivity to a target host — so the router can detect upstream failures, degraded paths, or logical connectivity loss even when a link appears physically up.

When a tracked target becomes unreachable, the router takes a configured action: disabling an interface, withdrawing a route, or resetting a cellular connection. When the target recovers, the action is reversed and the original state is restored.

Use Cases¶

Context	What tracking controls
Interface settings	Enable or disable the interface
Static routing	Inject or withdraw a static route
Traffic steering (PBR)	Inject or withdraw a policy-based route
BGP network advertisement	Advertise or withdraw a BGP prefix
WWAN / SIM	Reset the mobile connection, or switch cellular mode

Common Options¶

All tracking contexts share the same set of probe options:

Field	Description
Tracking Method	`Track Ping` (ICMP) — sends periodic ICMP echo requests to the target. Supports SLA thresholds for nuanced failure detection. `Track TCP` — attempts a TCP connection to verify reachability; use this when ICMP is blocked by the upstream network or firewall.
Track Host IP	The IP address to probe. Typically the next-hop router or a reliable host beyond it (e.g., `8.8.8.8`).
Tracking Interval (s)	How often probes are sent, in seconds (e.g., `30`)
Ping SLA	Enable SLA-based tracking: the action is triggered when latency or packet loss exceeds the configured thresholds, even if the host is technically responding to probes.
Maximum Latency (ms)	Round-trip latency threshold in milliseconds. Probes exceeding this value count as failures (e.g., `100`). Applies only when Ping SLA is enabled.
Maximum Packet Loss (%)	Percentage of lost probe packets before the tracked object is considered down (e.g., `20`). Applies only when Ping SLA is enabled.
Source IP	Source IP address for probe packets. Specify when verifying reachability via a particular path, or when the default source IP is ambiguous on a multi-homed device.
Log	Log tracking state changes and probe results to syslog. Useful during commissioning and troubleshooting.
Reverse	Invert the tracking logic — the configured action triggers when the probe succeeds instead of when it fails. Useful for enabling a backup object only when the primary becomes unavailable.

Tracking Interfaces¶

Interface tracking ties the administrative state of an interface to the reachability of an external host. If the tracked host becomes unreachable, the router disables the interface — removing it from routing and freeing the path for a backup. When connectivity is restored, the interface is re-enabled automatically.

A common use case is an optional or backup WAN interface: keep it disabled under normal conditions, and only bring it up when the primary WAN's upstream target is no longer reachable (using the Reverse option).

Note

Tracking probes run independently of the physical interface state. A tracked object can be deactivated even when the interface is physically up — for example, if the upstream router is reachable at Layer 2 but connectivity beyond it has failed.

GUI Configuration¶

Navigate to Device Settings → Network → Interfaces. Click an interface to open its settings, then click Enable Tracking.

CLI Configuration¶

interface eth0
 ip address dhcp
 track icmp 10.18.18.99 30 src 10.18.18.1 log

Note

Always specify a source IP that belongs to a separate, always-up interface — not the interface being tracked. If you use the tracked interface's own IP as the source, probes will always fail once the interface is disabled, preventing it from ever recovering.

Tracking Static Route¶

Static route tracking allows a route to be conditionally present in the routing table based on reachability. The route is injected when the tracked target is reachable, and withdrawn when it is not.

This pattern is commonly called a floating static route. It is typically deployed alongside a backup default route at a higher administrative distance. Under normal conditions, the tracked primary route wins; if the primary path fails, the tracked route is withdrawn and traffic falls back to the backup automatically.

GUI Configuration¶

Navigate to Device Settings → Network → Static Routing. Click to add or edit a route.

In this example, the default route via 100.100.100.1 is only active when the nexthop is reachable. If the upstream fails, the route is withdrawn and a backup (higher-metric) default takes over.

Tip

For deeper upstream validation, track an IP further into the upstream network rather than just the immediate next-hop. This catches scenarios where the next-hop itself is up but connectivity beyond it has failed.

Always specify a Source IP bound to the interface being tracked. In a multi-WAN setup, the probe target may be reachable via an alternate path, causing the probe to succeed even when the intended WAN link has failed — leaving a stale route in the table that attracts traffic it cannot deliver.

CLI Configuration¶

ip route 0.0.0.0/0 nexthop 100.100.100.1 track icmp 100.100.100.1 30

Tracking VRRP¶

VRRP tracking monitors a reachability target and stops or resumes a router's participation in a VRRP group based on the result. When the probe fails, the router withdraws from the group entirely — it stops sending advertisements and releases the VIP if it was MASTER — allowing the highest-priority remaining member to take over. When the probe recovers, participation resumes and the MASTER role is reclaimed.

This is the preferred mechanism for ensuring that a VRRP MASTER only holds the VIP when it has a working upstream path. Without tracking, a router whose WAN link has failed will continue to hold the VIP and attract traffic it cannot forward — a split-brain condition.

GUI Configuration¶

Navigate to Device Settings → Network → Interfaces. Click an interface to open its settings, then expand the VRRP section, edit a VRRP group, and enable Tracking Method.

For a full description of all probe configuration fields, see Common Options.

CLI Configuration¶

interface vlan 1 11
  vrrp-group 11
    priority 120
    virtual_ipaddress 10.10.10.1
    track icmp 1.1.1.1 30

In this example, VRRP group 11 has no explicit enable statement — its active state is governed entirely by the tracking result. The router participates as MASTER when 1.1.1.1 is reachable, and withdraws from the group when the probe fails.

Tip

Track a host that is reachable via the upstream WAN path — such as the ISP gateway or a public DNS server — rather than a host on the LAN. This ensures the VRRP failover reflects actual WAN reachability, not just local link state.

Tracking Policy-Based Route¶

Policy-based routing (PBR) allows traffic to be steered based on criteria beyond the destination address (e.g. source subnet, DSCP mark). PBR tracking works the same way as static route tracking — the PBR rule is only active when the tracked target is reachable.

The key advantage of PBR over static routing in a multi-WAN scenario is precedence. In most deployments, the WAN interfaces use DHCP, which installs kernel-level default routes. Kernel routes supersede static routes, so a static backup default may never be reached. PBR operates above the kernel routing table, so a tracked PBR rule will take effect regardless of what kernel or static routes are present — giving you reliable, deterministic traffic steering even in mixed-WAN environments.

GUI Configuration¶

Navigate to Device Settings → SD-WAN → Traffic Steering. Click to add or edit a rule.

CLI Configuration¶

ip pbr policy 100 src 192.168.8.0/22
ip pbr 100 nexthop 100.100.100.1 track icmp 1.1.1.1 15

In this example, traffic from 192.168.8.0/22 is steered via 100.100.100.1 as long as 1.1.1.1 is reachable. If tracking fails, the PBR rule is withdrawn and traffic follows normal routing.

Tip

PBR route tracking will automatically use the nexthop interface as the tracking source. However, you can still explicitly specify tracking source if needed.

Tracking BGP Route¶

By default, BGP advertises a connected prefix only when the corresponding interface is up. This works well for physical interfaces, but causes a problem on platforms where LAN interfaces are always logically up regardless of physical connectivity.

On HSA-520 series devices, the LAN interface is a VLAN interface — it remains administratively up even when the downstream switch or cable is unplugged. BGP has no visibility into this failure and will continue advertising the LAN prefix to peers, attracting traffic that cannot actually be delivered. BGP tracking solves this by tying prefix advertisement to a tracked host on the LAN segment.

When the tracked LAN host becomes unreachable (indicating a switch failure, cable pull, or downstream device outage), the router withdraws the BGP advertisement immediately, preventing upstream peers from forwarding traffic down a broken path.

GUI Configuration¶

Navigate to the BGP configuration section (under SD-WAN or Dynamic Routing, depending on your deployment), and open the advertised network entry:

CLI Configuration¶

router 65051
 ...
 network 192.168.5.254/24 track icmp 192.168.5.6 30

Set the tracked IP to a known-static host on the LAN (e.g. a server or a managed switch with a fixed IP). When that host becomes unreachable, the prefix is withdrawn from BGP within one tracking interval.

Tracking WWAN/SIM Connections¶

Connection Reset Behavior¶

WWAN tracking behaves differently from interface tracking. Rather than permanently disabling the interface on failure, the system briefly resets the cellular connection and immediately attempts to re-establish it. This is intentional.

Cellular networks are not perfectly stable — as a device moves between coverage areas, it can remain radio-associated with a distant tower while losing routable connectivity through that tower's backhaul. From the router's perspective, the interface is "up" but traffic goes nowhere. A connection reset forces the modem to re-register, pick up a nearby tower, and re-establish a fresh PDP context, restoring connectivity within seconds.

This behavior also benefits devices using multi-profile SIMs — a single SIM card with multiple carrier profiles loaded. When one profile fails, the reset cycle allows the system to try the next available profile automatically, without manual intervention.

GUI Configuration

Navigate to Device Settings → Network → WWAN.

CLI Configuration

interface wwan0
 track icmp 1.1.1.1 30

Note

WWAN tracking has two additional tracking methods beyond ICMP and TCP: RSRQ (Reference Signal Received Quality) and SINR (Signal-to-Interference-plus-Noise Ratio). Both reflect radio signal quality rather than upper-layer IP reachability, making them useful for detecting degraded radio conditions before connectivity is fully lost. See Choosing RSRQ vs SINR below for guidance on which to use.

SIM Failover (Primary → Backup, by SLA)¶

On dual-SIM branch routers, WWAN tracking can trigger a failover to the backup SIM when the active connection fails its tracking check or SLA thresholds — not only when the SIM loses registration. Add the failover keyword to the WWAN interface's track command.

CLI Configuration

interface wwan0
 track icmp 1.1.1.1 30 failover

To fail over on SLA degradation — when latency or packet loss breaches the target even though the host still responds:

interface wwan0
 track icmp 1.1.1.1 30 max 100 20 failover

Key points:

failover — on tracking (or SLA) failure, the router switches to the backup/standby SIM. Available only on wwan0/wwan1.
Once failover occurs, the router stays on the backup SIM until the next reboot. It does not automatically switch back to re-test the primary SIM.

Note

On single-module (active/standby) devices the same modem must redial on the other SIM slot, so each switch takes up to ~2 minutes; on dual-module (active/active) devices the switch is a kernel-level route change (~2–3 seconds). See SIM Failover Behavior for the underlying mechanism.

Warning

The optional restore keyword (e.g., track icmp 1.1.1.1 30 restore 300 failover) makes the router periodically switch back to re-test the primary SIM. Use it with caution: because each SIM switch on single-module devices takes up to ~2 minutes, repeatedly restoring to re-check the primary can severely degrade overall connectivity — and if the primary is still bad, the router fails over again, forming a flapping loop. Leaving restore unconfigured (the default) keeps the connection stable on the backup SIM until you intervene or reboot.

SIM Failover (Primary → Backup, by signal quality)¶

Reachability alone does not always tell the full story — a SIM can still pass ICMP/TCP tracking while sitting on a degraded radio link that will fail intermittently or throttle throughput. To catch this earlier, track the primary SIM's own signal quality and fail over to the backup SIM once it drops below an acceptable threshold — even though the connection is technically still reachable. Two methods are available: RSRQ and SINR.

Choosing RSRQ vs SINR¶

	RSRQ (Reference Signal Received Quality)	SINR (Signal-to-Interference-plus-Noise Ratio)
What it measures	Cell quality — a combined view of received power (RSRP) and overall received signal (RSSI), reflecting how loaded/congested the serving cell is	How cleanly the modem can decode the signal against noise and interference — the metric closest to actual achievable throughput and modulation rate
Typical range	Negative dB (e.g., `-3` to `-20`); less negative is better	Wider range, can be negative or positive (e.g., `-20` to `+30`); higher is better
Best suited for	LTE connections, and detecting cell congestion/loading	5G NR connections, and detecting genuine link-quality degradation
Known limitation	On 5G NR, wide channel bandwidths dilute interference across far more resource elements, and NR deployments typically have fewer neighboring cells competing for spectrum than a dense LTE grid — so RSRQ often stays in a narrow, nearly-flat range and becomes a weak discriminator of real link quality

Tip

For 5G NR connections, prefer SINR. It's more sensitive to real degradation and correlates directly with the throughput you'll actually get. RSRQ is well-proven on LTE but tends to sit flat on NR, making it a poor trigger for failover on 5G links. For LTE-only deployments, RSRQ remains a solid, widely-used choice.

Since track rsrq and track sinr can run at the same time on one interface (see the key points below), you can also configure both for defense-in-depth — whichever detects the fault first triggers the failover.

CLI Configuration — RSRQ

interface wwan0
 enable
 track rsrq -15 60 failover log
!

Set -15 to your own target RSRQ threshold (in dB) — see Signal Quality Reference for typical Excellent/Good/Fair/Poor ranges to help choose a value. The router checks RSRQ every 60 seconds; once a fresh reading is at or below the configured minimum, failover switches to the backup SIM. The log keyword records every tracking cycle — pass or fail — to the system log, which is essential for confirming the feature is active and for diagnosing why (or when) a failover occurred.

CLI Configuration — SINR

interface wwan0
 enable
 track sinr 0 60 failover log
!

Set 0 to your own target SINR threshold (in dB) — see Signal Quality Reference for typical Excellent/Good/Fair/Poor ranges. Behavior is otherwise identical to RSRQ tracking: the router checks SINR every 60 seconds, and failover triggers once a fresh reading is at or below the configured minimum.

Key points:

track rsrq <threshold> <interval> failover log / track sinr <threshold> <interval> failover log — both available only on wwan0/wwan1. <threshold> is in dB; for both metrics a higher value is better, so failover triggers when a valid reading is at or below the threshold.
Same failover behavior as SLA-based tracking above: once failover occurs, the router stays on the backup SIM until the next reboot, unless a restore interval is also configured (see the warning above).
If the modem cannot produce a fresh reading at all (for example, a disconnected antenna, or a transient radio/module glitch), tracking does not fail over on the first missed cycle. It skips up to two consecutive cycles with no reading, then treats the third consecutive missing reading as a tracking failure and triggers SIM failover — see the log examples below. This avoids a false failover triggered by a single momentary reporting gap or a garbled modem response caught mid-transition.
track icmp, track tcp, track rsrq, and track sinr can all be configured at the same time on the same interface — each runs as an independent check, and any one of them failing with failover configured triggers SIM failover. Use this to combine reachability tracking with one or both signal-quality methods rather than choosing just one.

Watching Tracking Status in the Logs

With log enabled, use show logging system (optionally show logging system include track to filter) to watch tracking activity in real time. With both antennas connected and signal healthy, each tracking cycle logs a pass:

Sat Aug 22 09:57:37 2026 user.info track_iface_wwan0: Sat Aug 22 09:57:37 UTC 2026 start tracking interface wwan0
Sat Aug 22 09:57:37 2026 user.info track_iface_wwan0: tracked host: 
Sat Aug 22 09:57:37 2026 user.info track_iface_wwan0: track source: 
Sat Aug 22 09:57:37 2026 user.info track_iface_wwan0: track method: rsrq
Sat Aug 22 09:57:37 2026 user.info track_rsrq_wwan0: RSRQ tracking passed. current=-6dB, configured min=-11dB (current meets minimum - no failover).
Sat Aug 22 09:57:37 2026 user.info track_iface_wwan0: tracking passed for wwan0.

SINR tracking logs the same way, tagged track_sinr_wwan0 instead of track_rsrq_wwan0:

Sat Aug 22 09:57:52 2026 user.info track_iface_wwan0: track method: sinr
Sat Aug 22 09:57:52 2026 user.info track_sinr_wwan0: SINR tracking passed. current=13dB, configured min=0dB (current meets minimum - no failover).
Sat Aug 22 09:57:52 2026 user.info track_iface_wwan0: tracking passed for wwan0.

In most cases — for example, gradual telco signal deterioration — the modem continues to produce valid readings that simply decline over time. As soon as one of those readings is at or below the configured minimum, that single cycle fails and the router performs SIM failover immediately, the same as SLA-based tracking above.

A different corner case shows up in lab testing when signal is lost abruptly — for example, by physically disconnecting the antennas — rather than degrading gradually. In that situation the modem may be unable to produce any reading at all, rather than reporting a poor-but-valid one. Tracking does not fail over on the first missed reading; it logs a skip and only fails over once no reading has been produced for three consecutive cycles (shown here for RSRQ; SINR behaves identically under the track_sinr_wwan0 tag):

Sat Aug 22 10:05:37 2026 user.info track_iface_wwan0: Sat Aug 22 10:05:37 UTC 2026 start tracking interface wwan0
Sat Aug 22 10:05:37 2026 user.info track_iface_wwan0: tracked host: 
Sat Aug 22 10:05:37 2026 user.info track_iface_wwan0: track source: 
Sat Aug 22 10:05:37 2026 user.info track_iface_wwan0: track method: rsrq
Sat Aug 22 10:05:37 2026 user.info track_rsrq_wwan0: no fresh RSRQ reading available for wwan0 (configured min=-11dB) - skipping this cycle (1/3).
Sat Aug 22 10:05:38 2026 user.info track_iface_wwan0: no tracking result for wwan0 this cycle. doing nothing.
Sat Aug 22 10:07:38 2026 user.info track_iface_wwan0: Sat Aug 22 10:07:38 UTC 2026 start tracking interface wwan0
Sat Aug 22 10:07:38 2026 user.info track_iface_wwan0: tracked host: 
Sat Aug 22 10:07:38 2026 user.info track_iface_wwan0: track source: 
Sat Aug 22 10:07:38 2026 user.info track_iface_wwan0: track method: rsrq
Sat Aug 22 10:07:38 2026 user.info track_rsrq_wwan0: no fresh RSRQ reading available for wwan0 (configured min=-11dB) - skipping this cycle (2/3).
Sat Aug 22 10:07:38 2026 user.info track_iface_wwan0: no tracking result for wwan0 this cycle. doing nothing.
Sat Aug 22 10:09:38 2026 user.info track_iface_wwan0: Sat Aug 22 10:09:38 UTC 2026 start tracking interface wwan0
Sat Aug 22 10:09:38 2026 user.info track_iface_wwan0: tracked host: 
Sat Aug 22 10:09:38 2026 user.info track_iface_wwan0: track source: 
Sat Aug 22 10:09:38 2026 user.info track_iface_wwan0: track method: rsrq
Sat Aug 22 10:09:38 2026 user.info track_rsrq_wwan0: no RSRQ reading available for wwan0 for 3 consecutive cycles (configured min=-11dB) - treating as tracking failure.
Sat Aug 22 10:09:38 2026 user.info track_iface_wwan0: tracking failed. Failover SIM card.

Note

On single-module (active/standby) devices, the SIM failover that follows (deregistering, power-cycling the modem, re-registering on the other slot, and coming back up with a new IP) is the same ~2-minute redial process described in SIM Failover Behavior — signal-quality tracking simply adds an earlier trigger condition on top of it.

Switch Cellular Mode (5G → 4G)¶

RansNet cellular routers can automatically fall back from 5G to 4G LTE when end-to-end connectivity is lost over the 5G path — even when the 5G radio itself appears operational.

When 5G radio coverage is simply unavailable (the RAN is out of range or powered down), the modem falls back to LTE automatically without any tracking configuration. This section addresses a different and more subtle failure mode: the modem is registered on a 5G cell and the radio link is active, but the 5G core network (5GC) has a fault. Traffic enters the 5G RAN but is silently dropped before reaching the internet. From the router's perspective, the wwan interface is up and the modem reports a healthy 5G connection — but no data flows.

A simple connection reset does not resolve this. The modem will re-associate with the same 5G cell and re-attach to the same faulty 5GC. The correct response is to switch the radio access technology to LTE, which uses a completely separate core network (the 4G EPC) and an independent backhaul path, bypassing the faulty 5GC entirely.

Configuring nr-mode with a tracking probe automates this: if the probe target becomes unreachable while in 5G mode, the router switches the modem to LTE and remains on LTE until the next reboot.

CLI Configuration

interface wwan0
 nr-mode NR5G track icmp 1.1.1.1 30 failover LTE

Key points:

nr-mode NR5G — sets the preferred radio access mode to 5G NR
track icmp 1.1.1.1 30 — probes 1.1.1.1 every 30 seconds; probe failure indicates end-to-end connectivity loss
failover LTE — switches the modem to LTE mode on probe failure; the router remains on LTE until reboot and does not attempt to switch back to 5G automatically

Note

Once failover to LTE occurs, the router stays on LTE until the next reboot. It will not attempt to recover back to 5G mode automatically, to avoid flapping between modes. Choose a probe target that is reachable over the 5G path — such as a public DNS server (1.1.1.1, 8.8.8.8).

Tracking System Reachability¶

System reachability tracking is a last-resort watchdog mechanism that operates at the router level rather than at the interface or route level. Instead of withdrawing a route or disabling an interface on failure, it reboots the router — the assumption being that the device has entered a state it cannot self-recover from, and that a clean restart is the safest way to restore connectivity.

This is appropriate in scenarios where interface and route tracking have not resolved the problem — for example, a software deadlock, a hung process, a routing table inconsistency, or a connectivity issue (e.g., an auto-sensing fault with an adjacent device or a stale cellular attachment) that leaves the router unable to forward traffic despite all interfaces appearing up. Because a reboot is disruptive, system tracking should be configured with a long probe interval and strict failure thresholds to avoid unnecessary restarts.

GUI Configuration¶

Navigate to Device Settings → System → Other Settings, then open the Tracking tab.

The configuration fields are the same as the Common Options described above. In the example shown, the router probes 1.1.1.1 every 300 seconds using ICMP, with Ping SLA thresholds of 100 ms latency and 20% packet loss. Source IP is bound to 192.168.8.1.

Note

The router requires 2 consecutive probe failures before triggering a reboot. With a 300-second interval, this means the target must be continuously unreachable for at least 10 minutes before any action is taken.

CLI Configuration¶

ip track icmp 1.1.1.1 300 max 100 20 src 192.168.8.1 log

Key points:

ip track — configures system-level tracking; unlike interface or route tracking, this command is global and not tied to any specific object
icmp 1.1.1.1 300 — probes 1.1.1.1 with ICMP every 300 seconds
max 100 20 — Ping SLA thresholds: probe fails if round-trip latency exceeds 100 ms or packet loss exceeds 20%
src 192.168.8.1 — binds probe packets to this source IP, ensuring they follow the intended path
log — enables verbose tracking messages in syslog; probe results, failure counts, and the reboot trigger are always logged at warning/critical level regardless of this option

Tip

System reachability tracking triggers a full router reboot — a disruptive action that should only fire when all other recovery options have been exhausted. Use a long probe interval (e.g., 300 seconds) with a stable, always-reachable target. Overly short intervals on an unreliable uplink risk repeated reboots that can make the device difficult to recover remotely.