From: Stephen Hemminger <stephen@networkplumber.org>
To: netdev@vger.kernel.org
Subject: Fw: [Bug 218412] New: Low throughput in WireGuard VPN
Date: Tue, 23 Jan 2024 08:54:22 -0800 [thread overview]
Message-ID: <20240123085422.1061aca6@hermes.local> (raw)
Begin forwarded message:
Date: Tue, 23 Jan 2024 15:07:14 +0000
From: bugzilla-daemon@kernel.org
To: stephen@networkplumber.org
Subject: [Bug 218412] New: Low throughput in WireGuard VPN
https://bugzilla.kernel.org/show_bug.cgi?id=218412
Bug ID: 218412
Summary: Low throughput in WireGuard VPN
Product: Networking
Version: 2.5
Hardware: Intel
OS: Linux
Status: NEW
Severity: normal
Priority: P3
Component: Other
Assignee: stephen@networkplumber.org
Reporter: wads31566@gmail.com
Regression: No
Created attachment 305758
--> https://bugzilla.kernel.org/attachment.cgi?id=305758&action=edit
kernel config
Issue: iperf3 shows low throughput using WireGuard VPN
Host hardware: Intel(R) Xeon(R) Gold 6226R (64 cores), 700GB RAM.
VM configurations: OpenWRT latest stable release, 2 cores from Intel(R) Xeon(R)
Gold 6226R, 128MB RAM.
Network config: Two physical host (same hardware on both, configs in
attachment) connected via Ethernet switch. On host A (IP ends with 33.101)I run
few VMs via libvirt, every VM is endpoint of one of VPN tunnels. On host B (IP
ends with 33.102) I run VPN server, 1 interface with many VPN endpoint peers.
Throughput between A & B is 10Gb/s, the same between VMs and host B (non-VPN
connection).
Detail description: I run different test configurations, for better
understanding I attached all configs and simple network graph.
Test 1: I run "iperf3 -s" on host B and run one iperf3 client on VM using as
address destination VPN server IP address "iperf3 -c 10.10.10.56 -b 0 -t 0".
Result: about 3Gb/s.
Test 2: I run two iperf3 servers with different ports "iperf3 -s -p *port
number*" on host B and two iperf3 clients on VM using as address destination
VPN server IP address, but for every client is different port "iperf3 -c
10.10.10.56 -b 0 -t 0 -p *port number*". Result: summary throughput about 3Gb/s
and about 1.5Gb/s
Other tests: Same as Test 2, but with 3,4 and 5 clients. Result: summary
throughput about 3Gb/s and throughput for every client is evenly dividing by
clients' amount.
On B host I use kernel version 6.8.0-1rc compiled from scratch by myself
(kernel config is also attached), on host A is usual Debian 12. Before updating
kernel on host B there also was Debian 12 and here's Debian bug report link for
the same config: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1060912
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are the assignee for the bug.
reply other threads:[~2024-01-23 16:54 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=20240123085422.1061aca6@hermes.local \
--to=stephen@networkplumber.org \
--cc=netdev@vger.kernel.org \
/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