Thanks again Noel.
I have executed `traceroute -T --mtu <destination>` and `mtr -rw
<destination>` on machines at both locations.
I did not do further investigation on the MSS yet since I have this
strange packet loss.
Based on the route, I assume this happens at the hub which is in between
the two routers?
Could this be the root cause I need to further investigate?
Kind regards
Martin
traceroute -T --mtu pi-frankfurt
traceroute to pi-frankfurt (192.168.2.135), 30 hops max, 60 byte packets
1 router-freiburg (192.168.1.1) 0.263 ms 0.179 ms 0.172 ms
2 * * *
3 router-frankfurt (192.168.2.1) 41.762 ms 41.182 ms 36.716 ms
4 pi-frankfurt (192.168.2.135) 36.693 ms 43.629 ms 37.051 ms
traceroute -T --mtu pi-freiburg
traceroute to pi-freiburg (192.168.1.130), 30 hops max, 60 byte packets
1 router-frankfurt (192.168.2.1) 0.489 ms 0.381 ms 0.287 ms
2 * * *
3 router-freiburg (192.168.1.1) 38.368 ms 47.673 ms 35.441 ms
4 pi-freiburg (192.168.1.130) 39.456 ms 54.566 ms 36.117 ms
mtr -rw pi-frankfurt
Start: 2017-12-27T22:57:40+0100
HOST: workstation Loss% Snt Last Avg Best Wrst StDev
1.|-- router-freiburg 0.0% 10 0.2 0.2 0.2 0.3 0.0
2.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
3.|-- router-frankfurt 0.0% 10 33.3 35.5 32.5 42.0 2.7
4.|-- pi-frankfurt 0.0% 10 33.5 34.4 32.7 36.7 1.5
On 27.12.2017 21:08, Noel Kuntze wrote:
Hi,
You can test the convergence speed using `traceroute -T --mtu <destination>`,
but that only gives you the MTU. You need to manually discover the MSS
using `traceroute -T -O mss=<mss> <destination>`.
The best way to check if the problem continues is to just run tcpdump/wireshark
and check for ICMP Fragmenation needed packets and TCP errors or timeouts.
Kind regards
Noel
On 27.12.2017 17:12, Martin Sand wrote:
Thanks Noel. Sorry, I had to travel to the other location (350 km).
I adapted the iptable rules. It improved, but I have the impression it only
improved a bit.
Is there a way to measure MTU discovery time?
Kind regards
Martin
On 14.12.2017 13:51, Noel Kuntze wrote:
Hi,
VPN internal http requests to a web server of another spoke take some time
until the page is rendered.
I assume this is due to the latency.
Nah. It's extremely more likely that the path MTU discovery takes some time
(maybe due to some missing/wrong firewall rules on some host(s) in your network
topology).
Try lowering the MTU and MSS of the tunneled traffic[1].
Kind regards
Noel
[1]
https://wiki.strongswan.org/projects/strongswan/wiki/ForwardingAndSplitTunneling#MTUMSS-issues
On 14.12.2017 13:41, Martin Sand wrote:
Hi all
I have a Hub and Spoke setup. Connections are working perfectly fine.
Throughput is almost reaching the maximum rate of the upload channel speed, 10
MBit/s.
Unfortunately the latency is not fulfilling my objectives. I have an average
ping time of 39 ms (see below) when pinging clients on other spokes.
VPN internal http requests to a web server of another spoke take some time
until the page is rendered.
I assume this is due to the latency.
Is there any chance to improve the latency? Or is the latency perfectly good?
Best regards
Martin
Hub internet address
64 bytes from vpn.example.com (217.122.5.6): icmp_seq=1 ttl=57 time=15.2 ms
Internal address of Hub
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
64 bytes from 192.168.1.1: icmp_seq=1 ttl=62 time=40.4 ms
Client on another spoke
PING 192.168.1.130 (192.168.1.130) 56(84) bytes of data.
64 bytes from 192.168.1.130: icmp_seq=1 ttl=61 time=108 ms
64 bytes from 192.168.1.130: icmp_seq=2 ttl=61 time=41.8 ms
64 bytes from 192.168.1.130: icmp_seq=3 ttl=61 time=38.0 ms
64 bytes from 192.168.1.130: icmp_seq=4 ttl=61 time=35.2 ms
64 bytes from 192.168.1.130: icmp_seq=5 ttl=61 time=36.4 ms
64 bytes from 192.168.1.130: icmp_seq=6 ttl=61 time=39.1 ms
64 bytes from 192.168.1.130: icmp_seq=7 ttl=61 time=38.1 ms
64 bytes from 192.168.1.130: icmp_seq=8 ttl=61 time=41.6 ms
64 bytes from 192.168.1.130: icmp_seq=9 ttl=61 time=36.0 ms
64 bytes from 192.168.1.130: icmp_seq=10 ttl=61 time=36.7 ms
--- 192.168.1.130 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 9013ms
rtt min/avg/max/mdev = 35.295/45.159/108.281/21.146 ms
