how to diagnose lengthy ping times through a complex network stack

[Edward Vielmetti]

Replying to my own email -

This latency problem I reported was not Wireguard's fault.
What happened was that one of the floating IP addresses
that was assigned to the VM was attached to an OpenStack
controller that had been provisioned in the wrong data center.
Amazingly the whole setup did continue to work, but the
ping times reflected pessimal routing, with the ping from
New Jersey to New Jersey going via Tokyo.

No individual component was anywhere near as slow as the
speed of light under the Pacific Ocean.

Note to self: if you can't debug the problem within the virtual
machine, start to look at the physical machines that provide
the virtual machines, and make sure you know what (and where)
they are.

Ed

On Fri, Nov 9, 2018 at 11:56 PM Edward Vielmetti <edward.vielmetti at gmail.com>
wrote:

> I have a network with several machines in it all running Wireguard.
>
> The latest device I've added to this assemblage is a virtual machine
> provisioned under OpenStack. It has 4 ThunderX cores (2 Ghz armv8)
> subdivided off of 96-core machine. What I notice is slow network
> performance through the Wireguard interface - 200 ms round trip VPN ping
> times to a machine in the same data center, compared to 1 ms when
> I don't go through the VPN, and only 45 ms when I use a different
> machine in the same data center to an even slower Raspberry Pi 2 in my
> attic.
>
> I don't claim to be an OpenStack expert, and I know there is some
> considerable complexity hiding in its network stack that might not
> be visible within the VM that I'm running.
>
> I guess the question is, what's the best way to start to make sense of
> network performance within Wireguard (and if anyone knows the answer,
> also within OpenStack?!).
>
> thanks
>
> Ed
>
> --
> Edward Vielmetti +1 734 330 2465
> edward.vielmetti at gmail.com
>
>

-- 
Edward Vielmetti +1 734 330 2465
edward.vielmetti at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.zx2c4.com/pipermail/wireguard/attachments/20181113/84939f5a/attachment.html>