Use Ping and Traceroute to Troubleshoot Salesforce Network Latency and Slowness

This article explains how to run ping and traceroute commands on Windows and macOS to find out whether network latency causes slowness when you use Salesforce, and how to read the results. A ping measures round trip time and packet loss to a Salesforce host. A traceroute shows the network path and timing for each hop between your computer and Salesforce.

Execute Traceroute and Ping in Microsoft Windows

On the Windows taskbar, click the Start button and select Run.
Type cmd in the text box.
Click OK. A command prompt window appears.
In the command prompt window, type the following command to trace the route to Salesforce, and press Enter: tracert login.salesforce.com
To send 100 echo ping requests, type the following command and press Enter: ping -n 100 login.salesforce.com
Repeat steps 4 and 5 for your My Domain. For example: tracert MyDomainName.my.salesforce.com and ping MyDomainName.my.salesforce.com

The Windows tracert command is only a single snapshot of the network at a point in time. Run the command multiple times to collect a fair sampling of data. Running the command while the slowness occurs provides the most useful snapshot.

After you complete this process, take a screenshot of the command output, or copy and paste the results into a text editor or reply email. If you have an ongoing case with your internal network team or Salesforce Support, these logs help identify the source of a potential network issue.

Run Extended Packet Size Tests in Windows

Salesforce transmits packets of various sizes when communicating with your machine. If you have completed the basic traceroutes and pings to salesforce.com described above, follow these instructions to run more extensive packet transmission tests.

On the Windows taskbar, click the Start button and select Run.
Type cmd in the text box.
Click OK. A command prompt window appears.
In the command prompt window, type each of the following commands, one at a time, and press Enter. Allow each command to fully process before entering the next command.

Note: In all steps, the character before 1200, 1300, and 1400 is a lowercase "dash L".

ping -f -n 25 -l 1200 login.salesforce.com
ping -f -n 25 -l 1300 login.salesforce.com
ping -n 25 -l 1400 login.salesforce.com

These commands send 25 ping requests each with packet sizes of 1200, 1300, and 1400 bytes to test how larger packets travel the network path.

Repeat step 5, replacing the URL with your My Domain. For example: ping -f -n 25 -l 1200 MyDomainName.my.salesforce.com, ping -f -n 25 -l 1300 MyDomainName.my.salesforce.com, and ping -n 25 -l 1400 MyDomainName.my.salesforce.com

Take a screenshot of the command output once all commands complete, or copy and paste the results into a text editor or reply email.

Execute Traceroute in macOS

Apple macOS includes a traceroute function that you can run from the command line using the Terminal application, which ships with every version of macOS.

Open a terminal session using Terminal.
Run these traceroute commands: traceroute login.salesforce.com and traceroute MyDomainName.my.salesforce.com
Copy and paste the results into a text editor or reply email.

Note: To run a traceroute to your Live Agent server, use the same steps, but point to your Live Agent server instead of the Salesforce instance URL. To find your Live Agent server, go to Setup and type "Live Agent Settings" in Quick Find. The endpoint URL looks similar to `https://d.la1w1.salesforceliveagent.com/chat/rest/`. Remove `https://` and `/chat/rest/`, then run a traceroute on only the `d.la1w1.salesforceliveagent.com` portion of the address.

Interpret Ping Results

The output of a ping looks similar to this example, which pings na17.salesforce.com:

Reply from 96.43.151.188. Bytes=32 Time=104ms. TTL=242
Reply from 96.43.151.188. Bytes=32 Time=104ms. TTL=242
Reply from 96.43.151.188. Bytes=32 Time=104ms. TTL=242
Reply from 96.43.151.188. Bytes=32 Time=104ms. TTL=242
Reply from 96.43.151.188. Bytes=32 Time=104ms. TTL=242

Ping Statistics for 96.43.151.188:
Packets: Sent = 100 , Received = 100 Lost = 0 (0% loss),
Approximate round trip times in milli-seconds :
Minimum = 104ms, Maximum = 107ms, Average = 104ms

The above results show a fast connection with no packet loss. Indications of an issue include:

Packet loss of 10% or more. There was 0% loss in the above example.
A discrepancy between minimum, maximum, and average round trip times (RTT). In the above example, the minimum RTT was 104ms, the maximum was 107ms, and the average was 104ms. These results indicate little variance in latency over the period when pings were captured. If the results instead show a minimum of 100ms and a maximum of 500ms, this indicates latency issues that intermittently degrade the connection.

Interpret Traceroute Results

A traceroute shows performance statistics for each hop in the network path your computer takes to reach Salesforce, which helps identify where issues may occur.

Traceroute Terminology

Hop Number: The specific hop number in the path from the sender to the destination.
Round Trip Time (RTT): The time it takes for a packet to get to a hop and back, displayed in milliseconds (ms). By default, tracert sends three packets to each hop, so the output lists three round trip times per hop. RTT is sometimes also called latency. The physical distance between hops is an important factor that can affect RTT. For a more detailed description of RTT and its effects, see Effects of Round Trip Time and Bandwidth on Performance.
Name: The fully qualified domain name (FQDN) of the system. The FQDN often indicates where the hop is physically located. If the Name does not appear in the output, the FQDN was not found. A missing FQDN does not necessarily indicate a problem.
IP Address: The Internet Protocol (IP) address of the router or host associated with the Name.

Components of a Traceroute

The first line of the tracert output describes what the command is doing. It lists the destination system (salesforce.com), the destination IP address, and the maximum number of hops used in the traceroute (30).

The first hop is the initial stop your traffic makes after it leaves your computer. It is likely either a 10.X.X.X number or a 192.168.X.X number. These ranges are reserved for private networks and are also fairly common further down a traceroute. Early hops with these address prefixes are typically within your company's internal network. Further down the route, they indicate that traffic is going through the ISP's internal network (Internet Service Provider) before exiting.

Identify Common Issues in a Traceroute

The three numbers you see are the individual times to reach that specific hop. These numbers do not represent the difference in time between the current hop and the previous hop. They represent the cumulative time taken up to that hop. When you review a traceroute, look for the first point where there is a high degree of variation between times (for example: 50 ms, 283 ms, 29 ms) or where times are consistently much higher than the preceding hop's.

You may also see an asterisk (*) as an entry. An asterisk indicates that no reply was received from the server. This is not necessarily a sign of an issue, especially once you reach Salesforce. Certain networks do not reply to the packets used in traceroutes for security or prioritization reasons, and Salesforce does the same once you are inside the data center. One hop with one timeout is probably not a problem as long as the connection consistently completes.

Your normal traceroute and ping results vary based on the geographic location of both your system and the data center. For example, if you are in Australia and connect to an eastern US data center, a 250-300ms round trip time is not out of the ordinary because the connection must physically travel through undersea cables. However, a 300ms round trip time from Australia to the Tokyo data center is unusual.

Traceroute results that show increased latency on a middle hop, which remains similar all the way through to the destination, do not indicate a network problem. A traceroute that shows dramatically increased latency on a middle hop, which then increases steadily through to the destination, can indicate a potential network issue. Packet loss or asterisks (*) on many of the middle hops may indicate a possible network issue if the destination is unreachable or latency climbs considerably in subsequent hops. A steady trend of increasing latency typically indicates congestion or a problem between two points in the network, and it requires one or more parties to correct the problem.

For more details on interpreting traceroutes, see the PDF titled "A Practical Guide to (Correctly) Troubleshooting with Traceroute" at major.io.

Asterisks or "Request Timed Out" Messages

If an asterisk (*) appears for RTT, a packet was not returned within the expected time frame. One or two asterisks for a hop do not necessarily indicate packet loss at the final destination.

When three asterisks appear, you see a "Request timed out" message on one or more hops in the path. This does not necessarily indicate a network or ISP issue. Most of the time, it means those hops do not prioritize ICMP (Internet Control Message Protocol) packets, which ping and traceroute use. Because the destination was reachable, there was no forwarding loss at any of the middle hops, and the consistent, low latency at the end of the connection supports a conclusion that there are no network issues.

You may receive three asterisks followed by "Request timed out" for the following reasons:

ICMP packet deprioritization.
The destination's firewall or another security device is blocking the request.
There is a problem on the return path from the target system. Round trip time measures the time it takes for a packet to travel from your system to a destination system and back. The forward route and the return route often follow different paths. If there is a problem on the return route, it may not be evident in the command output.
There is a connection problem at that particular system or the next system.

Odd Routing Decisions

ISPs constantly update their networks by tweaking routing decisions and adding new lines to keep the network healthy and to optimize around certain traffic patterns. Occasionally, these changes route your requests to Salesforce through a less than ideal path. For example, if you access a Salesforce instance in North America from California but your traffic is routed through Singapore and back before reaching the application, you see increased load times. You can identify these routing issues in the traceroute by examining the hop names, which ISPs tend to label with location-based information, and by looking for an RTT spike of 100-200ms over the span of one hop, which is typical behavior of an intercontinental hop.

If you are based in the same region as your data center (North America for NAXX instances, Asia for APXX, Europe and Africa for EUXX) and you notice a large jump in your traceroutes, go to ipddress.com and enter the troublesome IP address to find its geographic location. If you notice this type of issue, contact your ISP because the ISP controls the route your request takes to Salesforce.

Contact Salesforce Support with Network Troubleshooting Results

If you cannot pinpoint any networking issues, send all the information you collected using the steps above to Salesforce Support, and Support will take a closer look at the issue. In addition to the traceroute and ping results, include login access, the steps to reproduce the slowness, the name of your ISP, and whether your ISP has provided any insight into the latency.

Ping and Traceroute Limitations on Hyperforce

Hyperforce uses Network Load Balancers (NLBs), which do not support pings and, by extension, tracert. On NLBs, all ICMP packets except Type 3 (Destination Unreachable) are considered unintended traffic and are not forwarded to any targets. For troubleshooting steps on Hyperforce, see Troubleshoot Network issues in Hyperforce with TCP Tracing.