TruGrid SecureRDP - Trace Route Diagnostic Tool
The Trace Route diagnostic in the SecureRDP Toolkit identifies network path issues between this machine and the TruGrid infrastructure (Frontend and Relay). It runs in two phases: hop discovery, then a sustained per-hop probe that measures latency, jitter, and packet loss at every step of the path.
When to use it
Run a Trace Route when:
- Sessions feel slow, laggy, or unstable and you've already confirmed the local network is fine
- Network Monitor or one of the reachability diagnostics flagged an outage (Trace Route auto-fires in these cases - see Auto-fire behavior below)
- You need to give support evidence of where a problem is in the network path, not just that one exists
- Connections are dropping intermittently and you suspect a specific hop or carrier is at fault
Skip Trace Route if you don't yet know whether you have a connectivity problem at all. Start with Broker Reachability or Connector Reachability for a quick yes/no, then escalate to Trace Route if those fail.
How to run it
Manual: Click Trace Route in the Client / Connector row of the Diagnostics panel. The diagnostic runs against both TruGrid Frontend (ws.trugrid.com) and the most recent TruGrid Relay IP found in connector logs. No parameters needed.
Automatic: Trace Route fires automatically when one of the following diagnostics detects a problem:
- Connector Reachability fails
- Broker Reachability fails
- Network Monitor detects an outage on Frontend or Relay (two consecutive failed samples at the 2-second interval, so roughly 4 seconds of sustained loss)
Auto-fire is rate-limited to a maximum of 5 trace routes per diagnostic run with a 5-minute cooldown between fires, so chained outages don't produce a runaway stack of reports.
Reading the report
Each Trace Route report covers both targets (Frontend and Relay) and breaks down into two phases per target.
Phase 1: Hop discovery
A series of ICMP probes with incrementing TTL values identifies every hop on the path to the destination. Each hop's IP address is recorded along with its hostname (when reverse DNS is available) and the RTT of the discovery probe.
If a hop returns no response within the discovery window, it's shown as * * * in the report. This is common and not necessarily a problem - many intermediate routers are configured to drop or deprioritize ICMP TTL-exceeded responses for traffic-shaping reasons. As long as the destination itself eventually responds, the intermediate silence is informational only.
Phase 2: MTR-lite per-hop probe
After the path is discovered, the diagnostic re-probes every known hop in parallel for 30 seconds (30 iterations at 1-second intervals). For each hop it records:
Column | Meaning |
|---|---|
| Probe packets sent during the 30s window (30 expected) |
| Replies received |
| Percentage of probes that received no reply |
| Lowest RTT observed (ms) |
| Highest RTT observed (ms) |
| Mean RTT (ms) |
| Most recent RTT (ms) |
| Standard deviation of RTT across the window (ms) |
Color bands
Loss percentages in the per-hop table are colored to flag attention:
- Green (loss < 5%): normal, no action needed
- Amber (loss 5-20%): elevated, worth investigating if the same hop is consistently affected across multiple reports
- Red (loss > 20%): significant loss, likely contributing to session quality problems
Interpreting the results
A few common patterns and what they mean:
Loss only on intermediate hops, none on the destination: Almost always a false positive. Intermediate routers commonly rate-limit their ICMP responses to protect their control planes. If the destination's loss is low, the connection is fine despite the red entries in the middle of the table.
Loss on the destination itself: Real problem. Either the destination is overloaded, the link to it is congested, or upstream of the destination is dropping traffic. Compare against historical reports to see if it's persistent or transient.
Loss climbs progressively from a single hop onward: That hop is where the problem starts. Every hop after it inherits the upstream loss. The actual fault is at or just before that hop. If the IP belongs to a carrier you can identify, this is solid evidence to give that carrier when opening a support ticket.
High jitter on a hop with low loss: The hop is reachable but inconsistent in its response timing. Often indicates a congested or queued link. Sessions over this path may feel "laggy in bursts" without showing outright drops.
Path differs between Frontend and Relay: Normal. Frontend and Relay are different endpoints with potentially different network paths. A problem on the path to one but not the other narrows the fault localization considerably.
Auto-fire context
When Trace Route fires automatically from another diagnostic, the report's filename is timestamped to the moment of the outage event, and the originating diagnostic's report includes a link to the trace report in its Outages table. This lets you cross-reference outage events with path conditions at the same moment.
Updated on: 28/05/2026
Thank you!