From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.5 required=3.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,HTML_MESSAGE,MAILING_LIST_MULTI,SPF_PASS, URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 81761C43441 for ; Tue, 13 Nov 2018 19:25:02 +0000 (UTC) Received: from krantz.zx2c4.com (krantz.zx2c4.com [192.95.5.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id C7A20223C8 for ; Tue, 13 Nov 2018 19:25:01 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="paZFaHrP" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org C7A20223C8 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=wireguard-bounces@lists.zx2c4.com Received: from krantz.zx2c4.com (localhost [IPv6:::1]) by krantz.zx2c4.com (ZX2C4 Mail Server) with ESMTP id 26521a5b; Tue, 13 Nov 2018 19:19:28 +0000 (UTC) Received: from krantz.zx2c4.com (localhost [127.0.0.1]) by krantz.zx2c4.com (ZX2C4 Mail Server) with ESMTP id 2c662182 for ; Tue, 13 Nov 2018 19:19:27 +0000 (UTC) Received: from mail-it1-x12f.google.com (mail-it1-x12f.google.com [IPv6:2607:f8b0:4864:20::12f]) by krantz.zx2c4.com (ZX2C4 Mail Server) with ESMTP id 467814bf for ; Tue, 13 Nov 2018 19:19:26 +0000 (UTC) Received: by mail-it1-x12f.google.com with SMTP id m34-v6so20091601iti.1 for ; Tue, 13 Nov 2018 11:24:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=hBp/cs9GA4NaTXXe9JDW/7x/2SFQXyHm9QsAxWn9Mtg=; b=paZFaHrP0KMguX0ZJ37+xGTkfGpG/v4CKOfoyQpeYXbnIC2PyxHvip65xOS2mkxms1 AKraJwQA6MFDyANxIZcH9xGC5rTOPtxm66J7mcjezwZy+76+TqNWbmOUozvZ5xdYH13z rq6L3gnl99EaZ30G+04SoJp30doNV0nqj6rzgQk46+TtGTd4TmOUGH5pWlc+XTkUhprr sB5oiZV07/MJIqod6ZquReOqS82DpYwyhMoT4EnL4G96k5ulyEW1G2WOwOT88917pSB3 lwtOY9t10aMvlaMMQbOrHJfQY9O5Bgejrnw3ESZECYJVap7l5M8WOGDqYh86tRwBiWuf JlkQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=hBp/cs9GA4NaTXXe9JDW/7x/2SFQXyHm9QsAxWn9Mtg=; b=lG43Q917mi3Xg0VbEUVZaB7bco2gEKc1y9y9GIrWId4RI5HrTN9vq+3lkWGHTvloXs d6ZDG5HpGLAEXkXRfwEKB7dKq4cSyRc3H4ae5Ph8pk7NMvVQbhRvk36fYYuBYapLwdgV Jum+4rUvIrOgHc25d289HGmJkL4DrRnkNX7QHkkm+wBi9vWqvIuK3kzUm0VQwRBlY13z TkPVurKNcr8+qf1ZxKN8vgNTaSVehbUvZdSyT/SnF7SSarQs/wcEPYXDfZZgvHSrLW1d RxIj2hImgD0AYawjza4mJPeXC1xf/+h1rj3dmg9VU1D1pitp0fWLKEhZ2fqvOFfhuA/Z V2Hg== X-Gm-Message-State: AGRZ1gJDGyvw5+20Eyo+9YcQe0RAjhn95CMrXfAu0aFgIkTPfL1TduWP gY3mFZlijFBXUNuP2ykcUQM2NhH1325OQo6iXBzQCA== X-Google-Smtp-Source: AJdET5ekAehyC7oCcfpxK8gUgajdzRlGyEDqPL4Z8I/6jwlgSzTWZeB4aM0w4t50eojkaZ/LRyTHXfZOAckELDXq+Mw= X-Received: by 2002:a02:5953:: with SMTP id p80-v6mr6149641jab.111.1542137080898; Tue, 13 Nov 2018 11:24:40 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Edward Vielmetti Date: Tue, 13 Nov 2018 14:24:02 -0500 Message-ID: Subject: Re: how to diagnose lengthy ping times through a complex network stack To: wireguard@lists.zx2c4.com X-BeenThere: wireguard@lists.zx2c4.com X-Mailman-Version: 2.1.15 Precedence: list List-Id: Development discussion of WireGuard List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============5499651636074615190==" Errors-To: wireguard-bounces@lists.zx2c4.com Sender: "WireGuard" --===============5499651636074615190== Content-Type: multipart/alternative; boundary="000000000000e6eba9057a90c4a8" --000000000000e6eba9057a90c4a8 Content-Type: text/plain; charset="UTF-8" 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 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 --000000000000e6eba9057a90c4a8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Replying to my own=C2=A0email -

This la= tency problem I reported was not Wireguard's fault.
What happ= ened was that one of the floating IP addresses
that was assigned = to the VM was attached to an OpenStack
controller that had been p= rovisioned in the wrong data center.
Amazingly the whole setup di= d continue to work, but the
ping times reflected pessimal routing= , with the ping from=C2=A0
New Jersey to New Jersey going via Tok= yo.

No individual component was anywhere near as s= low as the
speed of light under the Pacific Ocean.

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

Ed

On Fri, Nov 9, 2018 at 11:56 PM Edward Vielmet= ti <edward.vielmetti@gmail= .com> wrote:
I have a network with several machines in it all running Wireguard.=C2=A0=

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 not= ice is slow network
performance through the Wireguard interface -= 200 ms round trip VPN ping
times to a machine in the same data c= enter, 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 d= on't claim to be an OpenStack expert, and I know there is some
considerable complexity hiding in its network stack that might not
<= div>be visible within the VM that I'm running.=C2=A0

I guess the question is, what's the best way to start to make se= nse of
network performance within Wireguard (and if anyone knows = the answer,
also within OpenStack?!).=C2=A0

<= div>thanks

Ed

-- <= br>
Edward Vielmetti=C2= =A0+1 = 734 330 2465



--
Edward Vielme= tti=C2=A0+1 734 330 2465

--000000000000e6eba9057a90c4a8-- --===============5499651636074615190== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard --===============5499651636074615190==--