RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1282169 - tunneling ipv6 subnets over ipv4 is unusably slow
Summary: tunneling ipv6 subnets over ipv4 is unusably slow
Keywords:
Status: CLOSED WORKSFORME
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: kernel
Version: 7.3
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: rc
: ---
Assignee: Sabrina Dubroca
QA Contact: xmu
URL:
Whiteboard:
Depends On:
Blocks: 1296180 1394638 1469551
TreeView+ depends on / blocked
 
Reported: 2015-11-15 09:29 UTC by Paul Wouters
Modified: 2020-01-09 23:38 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-09-19 09:21:13 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Paul Wouters 2015-11-15 09:29:48 UTC
When using ipv6 in ipv4 for a net-to-net connection, performance downgrades severely (from like 100mbps to 200kbps)

This is with libreswan using a leftsubnet= and rightsubnet= that is ipv6 and connaddrfamily=ipv6. The eft= and right= are ipv4 addresses.

A host to host ipv6 connection between the same hosts is not affected.

Playing with mtu or crypto parameters did not seem to make a difference.

Comment 2 Herbert Xu 2015-11-26 04:51:30 UTC
Paul, can you see if the patch in #1257952 helps? Thanks!

Comment 3 Tuomo Soini 2015-12-08 22:10:38 UTC
I did some testing over 10Mbit internet link.

Speed with ipv4 native ipsec, 1.11MB/s, that's about link speed (10Mbit)
Speed with ipv6 native ipsec, 1.08MB/s, again very near to link speed
Speed with ipv6 in ipv4 ipsec, 128KB/s, about same as without patch.

Testing method was nothing fancy, just rsync over ssh big file. Transfer was started from scratch for each test so it should show quite realistic result.

Tests were done with 3.10.0-327.3.1.el7 + xfrm ipv6 gro fix patch, IPsec tunnels were created with libreswan 3.16rc2 and aes_gcm256-null was used.

Comment 4 Marcelo Ricardo Leitner 2019-07-03 15:10:41 UTC
Mass-moving bugs RHEL <= 7.6.0 to 7.7.0.
As we are past RFE deadline for 7.7.0 and we should have no new features on 7.8.0, please evaluate if it's still wanted on RHEL7 and contact PM for exception. You may also move it to RHEL8 if that's wanted. Thanks!

Comment 5 Sabrina Dubroca 2019-07-17 11:16:02 UTC
I can't reproduce that on -957. It's possible this got fixed. Tunnel mode is slower than transport mode, but seems perfectly usable:

Tunnel ipv6 over ipv4: 1947.74Mbps
Tunnel ipv4 over ipv4: 1949.94Mbps
Transport ipv4:        2688.19Mbps

Is this still an issue for you? If not, I will close this bug.


Note You need to log in before you can comment on or make changes to this bug.