A customer calls: video streaming has been slow since Tuesday. A business client sends a screenshot of a 300 ms ping. From inside your network, every graph is green. The degradation usually sits at the edge of what you control: a saturated peering port, a transit provider re-routing through another exchange, or the destination itself. You need to see the path as the customer sees it, and as it looks from other networks, before deciding whether the fault is yours, your upstream's, or nobody's.
A visual traceroute from several vantage points, your own region, another region, a probe on a competitor's network, shows every hop with latency, jitter, loss and ASN, and maps the point where traffic leaves your AS. Scheduled traces give you the trend before the complaints arrive; the comparison view shows the path before and after a routing change; the export gives you a dated document with hop data to send to a transit provider or a peer instead of arguing on the phone.
Watch your peering and transit edges over time
Schedule traces from Falkenstein, Gravelines or a Globalping probe inside your customer base toward the destinations that generate complaints: major CDNs, cloud regions, popular game hosts, public resolvers. Set alerts on latency, packet loss and route change. A route-change alert is your earliest signal that a session dropped or a policy changed upstream. Read the hop where your ASN hands over. If latency and jitter rise there, at peak, on the same hop every evening, that port is saturated or the peer is rate-limiting. If they rise two hops later inside the transit's network, the issue is theirs, and the export shows it. Compare a quiet-hour trace with a peak-hour trace side by side to size the degradation.
Turn a complaint into a located fault in minutes
Ask the customer for the destination and the time. Trace toward it from the source closest to them and from a probe outside your network. Three outcomes. Both traces are clean: the problem is in the customer's premises, Wi-Fi or CPE, or intermittent; ask them to report when it recurs. Your trace is bad and the outside trace is clean toward the same target: the fault is on your side of the handoff or on your transit path, so look at the hop where the delay starts. Both are bad from the same hop onward: the destination or its provider is degraded, and you can tell the customer so with evidence. Loss on one middle hop that vanishes at the destination is ICMP rate limiting, not something to escalate.
Validate a BGP change from the outside
After announcing a new prefix, moving one to another transit or adding a prepend, check propagation with the BGP Viewer: which origin ASN the route collectors see, through which upstreams, and how many collectors carry it. Then trace toward an address inside the prefix from probes in several countries and compare: inbound traffic should enter your AS through the transit you expect. If probes in one region still arrive through the old path hours later, that upstream has not updated or a route filter rejected your announcement. Keep the trace taken before the change and compare it with the one after; the side-by-side view shows the exact hop where the paths diverge. Asymmetric routing, out through one transit and in through another, is normal, but it should be intentional.
Reading a trace: loss that begins inside a transit
A teaching example, not a real measurement. From a probe on your network toward a video CDN, hops 1 to 3 sit inside your AS at 2 to 4 ms with 0% loss. Hop 4 is the handoff to your transit provider: 5 ms, 0% loss. Hop 5, still in the transit's ASN, reads 6 ms but 30% loss, and hops 6 to 9 show 28 to 32% loss. The loss persists to the destination, so it is real, and it starts inside the transit's network one hop after your edge. The same trace from a Globalping probe on another ISP shows 0% loss: the CDN is healthy. Conclusion: a degraded link or a congested port inside the transit. The export, with timestamps and both traces, goes to their NOC; a scheduled trace tells you when it is fixed.
Tools that complete the picture
BGP Viewer shows who originates a prefix, its upstreams and how many route collectors see it: the first check after any change to your announcements. WHOIS and IP Reputation identify a destination or a customer address when a complaint mentions blocking or a blacklist. DNS Lookup, with the resolver of your choice, confirms that a CDN or anycast service sends your customers to a nearby node. Ping over a period confirms jitter on a link before you open a trace, and Port Check verifies filtering from outside your network.
Frequently asked questions
- Can I trace from a customer's point of view without their device?
- Pick a source close to them: Falkenstein, Gravelines or one of the Globalping probes, some of which sit on residential or other ISP networks. The trace will not include their home hop, but it shows the path from a nearby network to the destination. If that path is clean while the complaint persists, the problem most likely lies between their CPE and your first router.
- How does a route-change alert work?
- A scheduled trace runs at the interval you set. Each run records the sequence of hop addresses, and when it differs from the previous run an alert is sent, subject to a cooldown so a flapping path does not notify you every few minutes. Combine it with latency and loss thresholds to catch both silent re-routes and slow degradations, and open the two traces side by side to see where they diverge.
- Can I prove to a transit provider that the fault is on their side?
- You can hand them a dated trace from your network and one from an outside probe toward the same destination, both showing loss or latency appearing inside their ASN and persisting to the end. Export it as PDF or JSON and attach it to the ticket. It is hop-level evidence with ASN attribution, which is what their NOC needs to look at the right link, even if they dispute the conclusion.