Accelerate your SASE deployment with the SASE Week Backstage Series. Explore sessions

close
close
  • Why Netskope chevron

    Changing the way networking and security work together.

  • Our Customers chevron

    Netskope serves more than 3,400 customers worldwide including more than 30 of the Fortune 100

  • Our Partners chevron

    We partner with security leaders to help you secure your journey to the cloud.

A Leader in SSE.
Now a Leader in Single-Vendor SASE.

Learn why Netskope debuted as a leader in the 2024 Gartner® Magic Quadrant™️ for Single-Vendor Secure Access Service Edge

Get the report
Customer Visionary Spotlights

Read how innovative customers are successfully navigating today’s changing networking & security landscape through the Netskope One platform.

Get the eBook
Customer Visionary Spotlights
Netskope’s partner-centric go-to-market strategy enables our partners to maximize their growth and profitability while transforming enterprise security.

Learn about Netskope Partners
Group of diverse young professionals smiling
Your Network of Tomorrow

Plan your path toward a faster, more secure, and more resilient network designed for the applications and users that you support.

Get the white paper
Your Network of Tomorrow
Introducing the Netskope One Platform

Netskope One is a cloud-native platform that offers converged security and networking services to enable your SASE and zero trust transformation.

Learn about Netskope One
Abstract with blue lighting
Embrace a Secure Access Service Edge (SASE) architecture

Netskope NewEdge is the world’s largest, highest-performing security private cloud and provides customers with unparalleled service coverage, performance and resilience.

Learn about NewEdge
NewEdge
Netskope Cloud Exchange

The Netskope Cloud Exchange (CE) provides customers with powerful integration tools to leverage investments across their security posture.

Learn about Cloud Exchange
Aerial view of a city
The platform of the future is Netskope

Intelligent Security Service Edge (SSE), Cloud Access Security Broker (CASB), Cloud Firewall, Next Generation Secure Web Gateway (SWG), and Private Access for ZTNA built natively into a single solution to help every business on its journey to Secure Access Service Edge (SASE) architecture.

Go to Products Overview
Netskope video
Next Gen SASE Branch is hybrid — connected, secured, and automated

Netskope Next Gen SASE Branch converges Context-Aware SASE Fabric, Zero-Trust Hybrid Security, and SkopeAI-powered Cloud Orchestrator into a unified cloud offering, ushering in a fully modernized branch experience for the borderless enterprise.

Learn about Next Gen SASE Branch
People at the open space office
Designing a SASE Architecture For Dummies

Get your complimentary copy of the only guide to SASE design you’ll ever need.

Get the eBook
Make the move to market-leading cloud security services with minimal latency and high reliability.

Learn about NewEdge
Lighted highway through mountainside switchbacks
Safely enable the use of generative AI applications with application access control, real-time user coaching, and best-in-class data protection.

Learn how we secure generative AI use
Safely Enable ChatGPT and Generative AI
Zero trust solutions for SSE and SASE deployments

Learn about Zero Trust
Boat driving through open sea
Netskope achieves FedRAMP High Authorization

Choose Netskope GovCloud to accelerate your agency’s transformation.

Learn about Netskope GovCloud
Netskope GovCloud
  • Resources chevron

    Learn more about how Netskope can help you secure your journey to the cloud.

  • Blog chevron

    Learn how Netskope enables security and networking transformation through secure access service edge (SASE)

  • Events and Workshops chevron

    Stay ahead of the latest security trends and connect with your peers.

  • Security Defined chevron

    Everything you need to know in our cybersecurity encyclopedia.

Security Visionaries Podcast

The Future of Security: Quantum, AI, and Macro-political Change
Emily Wearmouth and Max Havey speak with Netskope CEO Sanjay Beri and CTO Krishna Narayanaswamy about the future of security.

Play the podcast Browse all podcasts
The Future of Security: Quantum, AI, and Macro-political Change
Latest Blogs

Read how Netskope can enable the Zero Trust and SASE journey through secure access service edge (SASE) capabilities.

Read the blog
Sunrise and cloudy sky
SASE Week 2024 On-Demand

Learn how to navigate the latest advancements in SASE and zero trust and explore how these frameworks are adapting to address cybersecurity and infrastructure challenges

Explore sessions
SASE Week 2024
What is SASE?

Learn about the future convergence of networking and security tools in today’s cloud dominant business model.

Learn about SASE
  • Company chevron

    We help you stay ahead of cloud, data, and network security challenges.

  • Careers chevron

    Join Netskope's 3,000+ amazing team members building the industry’s leading cloud-native security platform.

  • Customer Solutions chevron

    We are here for you and with you every step of the way, ensuring your success with Netskope.

  • Training and Accreditations chevron

    Netskope training will help you become a cloud security expert.

Supporting sustainability through data security

Netskope is proud to participate in Vision 2045: an initiative aimed to raise awareness on private industry’s role in sustainability.

Find out more
Supporting Sustainability Through Data Security
Help shape the future of cloud security

At Netskope, founders and leaders work shoulder-to-shoulder with their colleagues, even the most renowned experts check their egos at the door, and the best ideas win.

Join the team
Careers at Netskope
Netskope’s talented and experienced Professional Services team provides a prescriptive approach to your successful implementation.

Learn about Professional Services
Netskope Professional Services
Secure your digital transformation journey and make the most of your cloud, web, and private applications with Netskope training.

Learn about Training and Certifications
Group of young professionals working

Using Traceroute to Measure Network Latency and Packet Loss

Aug 31 2021

In this article, we explain the main concepts of Traceroute and how it can be used to measure network latency and packet loss. We also address the main limitations of such a tool that makes it unfit for accurate measurements.

What do you use Traceroute for?

Traceroute is a very useful tool for network monitoring and problems diagnostics. With traceroute you can:

  • discover the network path between a source and a destination
  • measure the network latency to reach each hop on the path
  • measure the packet loss at each hop

It is extremely useful to measure the network quality (congestions, …). It can also detect any network path variation that may occur through BGP peering/routing configuration changes.

How does Traceroute work?

The main principle of traceroute is shown hereunder:

The whole traceroute principle is based on the TTL (Time To Live) field of the IP packet header. This field is mainly used to avoid loops in networks, where packets could be routed indefinitely in a loop under certain circumstances. When a host sends a packet on a network, its initial TTL value is between generally 32 and 255, depending on the operating system used. Each time the packet hits a router and must be routed, the TTL value decreases by 1. When a packet with a TTL value of 1 hits a router, this latter cannot route the packet anymore (it would mean a TTL=0). So it drops the packet (to avoid potential looping problem). It also informs the source about this by sending a specific ICMP error message back to the source (ICMP error message “TTL Exceeded In Transit”).

So traceroute relies on the fact that routers will send this ICMP error message back to the source in case of a TTL value reaching 1. When performing a traceroute, this is what happens:

  1. The source sends a first IP packet with a TTL header field value of 1.
  2. The packet hits the first router in the network path. The router drops the packet due to this TTL value and sends an ICMP error message back to the source.
  3. The source has discovered the first router! So let’s go to the next one. For this, it sends a packet with a TTL value of 2.
  4. The packet hits the first router, is routed normally, and the TTL values is decreased by 1 (new TTL value = 1).
  5. The packet hits the second router in the path. The router drops it due to the TTL value of 1. Again an ICMP error message is sent back to the source, which discovers the second router in the path.
  6. … and so on up until the packet reaches the final destination.
  7. The type of message this final destination will send to the source depends on the specific traceroute implementation used (see next topic).

Different traceroute flavors

With traceroute, the IP packets are not sent as is. They are typically transported in a upper transport layer protocol like UDP, or directly in ICMP packets.

Traceroute in Windows

The standard Windows implementation of traceroute uses ICMP as protocol to send IP packets.

Let’s see how it works in practice:

These pictures show a Windows traceroute to google.com.

One line corresponds to a discovered router. By default, a Windows traceroute sends three packets per hop. You can see this through the 3 network latency values provided per line.

In this example, the packet has reached the destination after 7 consecutive hops. The last line (8) corresponds to the final destination itself.

Let’s now see in details what happened by using Wireshark. We analyze the fifth discovered router.

The left side screenshot shows that the source (192.168.1.31) sends an ICMP “Echo (ping) request” packet to the destination (216.58.208.110) with an IP header TTL field value of 5.

The right side screenshot shows the answer from the discovered intermediate router (91.183.245.122). This latter sends an ICMP error message “Time-to-live exceeded” back to the source. As additional data, it also sends back the packet that triggered this error message.

When the packet finally hits the destination, the packet does not have to be routed anymore. So the destination does not send any ICMP error message back to the source. This is shown hereunder.

At the left side, you can see that the source still sends ICMP packets with incremental IP field TTL value (8 in this case). Nevertheless, as the destination does not have to route the packet anymore, it does not care about the TTL value. Instead, it responds to the ICMP Echo request solicitation by sending an ICMP Echo reply back to the source.

Traceroute in Linux

The standard Linux traceroute uses UDP as transport protocol to send IP packets.

Let’s see how it works in practice:

Without looking at more details, this looks exactly the same as a Windows traceroute: 3 tests per TTL value providing the network latency to each routing hop, up to the destination.

Let’s see what exactly happened this time:

At the left side, you see the details of the fifth line of the traceroute, that is a UDP packet sent with an IP header TTL field of 5. At the right side, you see that an intermediate router sends an ICMP error message back (“TTL exceeded in transit”) to the source. You can check the reason of this ICMP error message from this ICMP packet to be sure this message has been triggered by the initial UDP packet.

When the packet finally hits the destination, the packet does not have to be routed anymore. So the destination does not send any ICMP error message back to the source. Nevertheless, as Linux uses UDP by default and not ICMP like Windows, the destination will not answer with an ICMP Echo reply back to the source. Instead, it answers by letting the source know it does not listen to the destination UDP port.

As you can see on the screenshot above, the final destination (172.217.168.206) sends an ICMP error message “Destination unreachable – Port unreachable” back to the source. It informs the source it does not listen to the destination UDP port (33.468 in our case).

Generally, traceroute based on UDP transport protocol uses destination ports above 33.435.

Main challenges/limitations with traceroute

If you want to quickly discover a route to a destination and have a first idea of the network performance, traceroute is certainly one of your best friends. Nevertheless, you should be aware of some major limitations that we can categorize as follows:

  • nodes discovery
  • path discovery
  • performance metrics

Network nodes discovery

In order to identify all intermediate nodes up to the destination, they should send ICMP error messages back to the source. If one of them does not respond, it will not be identified. You can still know that there is a router in the path, but cannot clearly identify it.

On the screenshot above, the fourth hop router is not identified. This is symbolized by the * .

Lot of network nodes will not respond to ICMP solicitation for security reason. A firewall may simply filter some traffic without sending ICMP packet back to hide its presence.

Network path discovery

As you know by now, traceroute is based on packet probes with incremental IP header TTL field value. So the following scenario may perfectly happen: