2016-10-29 13:32 GMT+08:00 Selva Nair <selva.n...@gmail.com>: > Hi Hongyi, > > On Fri, Oct 28, 2016 at 10:55 PM, Hongyi Zhao <hongyi.z...@gmail.com> wrote: >> >> >> I tried it as follows: >> >> $ ping -c 10 -I eth0 8.8.8.8 >> PING 8.8.8.8 (8.8.8.8) from 192.168.0.2 eth0: 56(84) bytes of data. >> 64 bytes from 8.8.8.8: icmp_seq=1 ttl=53 time=128 ms >> 64 bytes from 8.8.8.8: icmp_seq=2 ttl=53 time=124 ms >> 64 bytes from 8.8.8.8: icmp_seq=3 ttl=53 time=124 ms >> 64 bytes from 8.8.8.8: icmp_seq=4 ttl=53 time=124 ms >> 64 bytes from 8.8.8.8: icmp_seq=5 ttl=53 time=127 ms >> 64 bytes from 8.8.8.8: icmp_seq=6 ttl=53 time=133 ms >> 64 bytes from 8.8.8.8: icmp_seq=7 ttl=53 time=122 ms >> 64 bytes from 8.8.8.8: icmp_seq=8 ttl=53 time=125 ms >> 64 bytes from 8.8.8.8: icmp_seq=9 ttl=53 time=131 ms >> 64 bytes from 8.8.8.8: icmp_seq=10 ttl=53 time=123 ms >> >> --- 8.8.8.8 ping statistics --- >> 10 packets transmitted, 10 received, 0% packet loss, time 9011ms >> rtt min/avg/max/mdev = 122.963/126.756/133.225/3.199 ms >> >> $ ping -c 10 -I tun104 8.8.8.8 >> PING 8.8.8.8 (8.8.8.8) from 10.211.1.49 tun104: 56(84) bytes of data. >> 64 bytes from 8.8.8.8: icmp_seq=1 ttl=56 time=209 ms >> 64 bytes from 8.8.8.8: icmp_seq=2 ttl=56 time=206 ms >> 64 bytes from 8.8.8.8: icmp_seq=3 ttl=56 time=435 ms >> 64 bytes from 8.8.8.8: icmp_seq=4 ttl=56 time=351 ms >> 64 bytes from 8.8.8.8: icmp_seq=5 ttl=56 time=202 ms >> 64 bytes from 8.8.8.8: icmp_seq=6 ttl=56 time=203 ms >> 64 bytes from 8.8.8.8: icmp_seq=7 ttl=56 time=206 ms >> 64 bytes from 8.8.8.8: icmp_seq=8 ttl=56 time=210 ms >> 64 bytes from 8.8.8.8: icmp_seq=9 ttl=56 time=204 ms >> 64 bytes from 8.8.8.8: icmp_seq=10 ttl=56 time=208 ms >> >> --- 8.8.8.8 ping statistics --- >> 10 packets transmitted, 10 received, 0% packet loss, time 9008ms >> rtt min/avg/max/mdev = 202.260/243.852/435.330/77.155 ms > > > > This is not a proper comparison of the latency overhead due to the tunnel, > assuming that's what you are trying to measure. Because of anycast, in one > case you are pinging a google dns server geographically close to you > (through eth0), while through the tunnel you reach one close to the vpn > server.
Thanks for your notes. > > Instead, ping the vpn server's public address (through eth0) I tried and in most cases this method will fail to respond. > and compare > that with pinging the tunnel's remote endpoint As Gert has told me, the "topology net30" is used in the server side; hence it's impossible to ping the tunnel's remote endpoint. > or gateway. The vpn_gateway is 10.211.254.254, I've used this as the probe for a period of time. The command used by me is something as follows: ping -I tunxx 10.211.254.254 But just as you have said below, I really not use the --redirect-gateway option, instead, the --route-nopull is used by me. The reason is that I keep several vpn connections to different vpn servers at the same time in order to do the ecmp-based load balance among them. This issue is the above ping command will fail till the multi-path routing table for the ecmp been added. Regards > No -I eth0 or -I > tunxx needed for this as the former will automatically go through eth0 (in > clear) and the latter through the tun interface (encrypted), based on routes > set up when you use --redirect-gateway (which I guess you do use). Will work > only if the server responds to pings, though. > > My experience is that the the tunnel adds an insignificant amount to the > latency. Here are two examples of such a ping statistics. Both are measured > under no or minimal load. > > 1. Client and server ~1000 kms away, but with an decent link between them > > ping server_public ip: rtt min/avg/max/mdev = 16.116/16.298/16.512/0.198 ms > ping vpn_gateway: rtt min/avg/max/mdev = 16.805/16.920/17.024/0.061 > ms: > > 2. Client and server in same city but over domestic DSL/cable, so RTT is > larger: > > ping server_public_ip: rtt min/avg/max/mdev = 43.040/43.252/43.453/0.232 ms > ping vpn_gateway: rtt min/avg/max/mdev = 42.902/43.216/43.485/0.330 ms > (I cheated here as this server does not respond to ping. So another machine > on > the same LAN as the server was pinged instead of the server's public ip). > > Selva -- Hongyi Zhao <hongyi.z...@gmail.com> Xinjiang Technical Institute of Physics and Chemistry Chinese Academy of Sciences GnuPG DSA: 0xD108493 ------------------------------------------------------------------------------ The Command Line: Reinvented for Modern Developers Did the resurgence of CLI tooling catch you by surprise? Reconnect with the command line and become more productive. Learn the new .NET and ASP.NET CLI. Get your free copy! http://sdm.link/telerik _______________________________________________ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
