This blog will help you to determine if your SAP Cloud for Customer experience is affected by high latency and where, but first let’s get some concepts:
The last mile or last kilometer is a colloquial phrase widely used in telecommunications to refer to the final leg of the networks that deliver telecommunication services to retail end_users (customers). More specifically, the last mile refers to the portion of the telecommunications network chain that physically reaches the end_user’s premises.
Latency is how long it takes for the data to travel between its source and destination, measured in milliseconds.
One of the ways to optimize network performance is to minimize latency across the entire network. Packets travel across networks at a speed slightly slower than the speed of light. A rough estimate of the speed packets travel would be about 100,000 miles per second. Although the speed is still very fast, a packet that has to travel to the other side of the Earth and back would have at least 250 ms of latency (before you calculate latency introduced by routers)
Network Route using Traceroute
For SAP Cloud customers, is possible to validate routing of the last mile, using the command “tracert”. This identifies the route that is used to connect to the Akamai server and with this helps to understand if the network packages are traveling to other regions or countries which could be adding overhead and might require a closer look by the network administrators or ISP. For example:
- Use the tracert command to get the IP for each of the hoops or routers involved in the routing
The format of each line is as follows:
Hop RTT1 RTT2 RTT3 Domain Name [IP Address]
- Hop: Whenever a packet is passed between a router, this is referred to as a “hop.” For example, in the output above, we can see that it takes 10 hops to reach akamaitechnologies.com servers from my current location.
- RTT1, RTT2, RTT3 (Latency): This is the round-trip time that it takes for a packet to get to a hop and back to your computer (in milliseconds). This is often referred to as latency, and is the same number you see when using ping. Traceroute sends three packets to each hop and displays each time, so you have some idea of how consistent (or inconsistent) the latency is. If you see a * in some columns, you didn’t receive a response – which could indicate packet loss.
- Domain Name [IP Address]: The domain name, if available, can often help you to see the location of a router. If this isn’t available, only the IP address of the router is displayed.
RTT or Latency
|1||56, 14, 1||192.168.1.1|
|2||2, 3, 2||First external IP|
|3||3, 2, 3||126.96.36.199|
|4||4, 4, 3||188.8.131.52|
|5||125, 8, 8||184.108.40.206|
|6||11, 9, 12||220.127.116.11|
|7||51, 34, 10||18.104.22.168|
|8||11, 15, 16||22.214.171.124|
|9||10, 111, 8||126.96.36.199|
|10||10, 9, 10||188.8.131.52|
Latency rule of thumb:
For Cloud for Customer the following latency guidelines have been established:
- Under 100 ms if the tenant datacenter is in the same continent
- Under 250 ms should be the total latency from end user to C4C
Troubleshooting network issues due to bad routing
|Hop||RTT or Latency||IP||Geolocation|
|1||56, 14, 1||192.168.1.1||Private|
|2||2, 3, 2||First external IP||*|
|3||3, 2, 3||184.108.40.206||Houston|
|4||4, 4, 3||220.127.116.11||Washington|
|5||125, 8, 8||18.104.22.168||Dallas|
|6||11, 9, 12||22.214.171.124||Dallas|
|7||51, 34, 10||126.96.36.199||
|8||11, 15, 16||188.8.131.52||Dallas|
|9||10, 111, 8||184.108.40.206||Dallas|
|10||10, 9, 10||220.127.116.11||Cambridge|
It is important to mention that different tools use different geo database and results could be different due to outdated database, it is recommended to get geo location information from different sources.
With the geolocation information, you can determine the location of each one of the IP’s and determine the route a user is taking to connect to C4C.
RTT or Latency
|1||1, 2, 1||192.168.1.1||Private|
|2||2, 3, 6||10.0.0.1||Private|
|3||* , * , *||Unknown|
|4||20, 18, 14||18.104.22.168||Houston|
|5||14, 11, 15||22.214.171.124||Houston|
|6||27, 17, 16||126.96.36.199||Houston|
|7||26, 36, 22||188.8.131.52||Dallas|
|8||23, 21, 21||184.108.40.206||Stemmons|
|9||18, 25, 22||220.127.116.11||Chicago|
|10||22, 27, 26||18.104.22.168||Cambridge|
A bad routing can create a lot of latency and sequentially a slow behavior of C4C.
In this example, a customer located in Spain connects via VPN to the Australian office and tries to connect to their application located in Germany. As you can see the customer’s request goes around the world (Melbourne, Sidney, California, New York, Hamburg, Frankfurt) to connect to a datacenter in Rot, Germany generating a lot of latency and negatively affecting the user experience
Using TCP Traceroute to detect routing issue
Because the traditional traceroute uses either UDP or ICMP ECHO packets with TTL (Time to Live) increments of one, there will be times where the hop information will be blocked by a firewall or any other security policy making it impossible to completely trace the path to the destination.
Tcptraceroute helps us to solve this problem by routing its packets using TCP. By sending out TCP SYN packets instead of UDP or ICMP ECHO packets, tcptraceroute is able to bypass the most common firewall filters.
Linux and OSX:
tcptraceroute is included by default in most Unix based distributions. On OSX you will need to install it via homebrew (http://brew.sh/) by running the following command
brew install tcptraceroute
tcptraceroute hostname port
sudo tcptraceroute www.sap.com 443
Windows does not include a way to run TCP traceroute. Luckily someone was kind enough to write a version that works with Windows. In order to run tracetcp on Windows you will need to have the WinPcap library installed. You can find download links below the screenshot.