Development discussion of WireGuard
 help / color / mirror / Atom feed
From: Edward Vielmetti <edward.vielmetti@gmail.com>
To: wireguard@lists.zx2c4.com
Subject: Re: how to diagnose lengthy ping times through a complex network stack
Date: Tue, 13 Nov 2018 14:24:02 -0500	[thread overview]
Message-ID: <CAPRZce1JNxoegq1ipopd1RMe47JRNXCYj9n+DsAzAA8Q-uZW4Q@mail.gmail.com> (raw)
In-Reply-To: <CAPRZce2R2W+WkXm26Jo2RTmTkyG=rO7tc2jFf0s7-4pxPESTqw@mail.gmail.com>


[-- Attachment #1.1: Type: text/plain, Size: 1895 bytes --]

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@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@gmail.com
>
>

-- 
Edward Vielmetti +1 734 330 2465
edward.vielmetti@gmail.com

[-- Attachment #1.2: Type: text/html, Size: 3321 bytes --]

[-- Attachment #2: Type: text/plain, Size: 148 bytes --]

_______________________________________________
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard

      reply	other threads:[~2018-11-13 19:25 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-11-10  4:56 Edward Vielmetti
2018-11-13 19:24 ` Edward Vielmetti [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAPRZce1JNxoegq1ipopd1RMe47JRNXCYj9n+DsAzAA8Q-uZW4Q@mail.gmail.com \
    --to=edward.vielmetti@gmail.com \
    --cc=wireguard@lists.zx2c4.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).