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 >>> >
signature.asc
Description: OpenPGP digital signature
