Description of problem: Running an IPv6 tunnel with Fedora 21 as the tunnel endpoint (sit) gives a severely crippled incoming download speed. Any clients it serves, because they serve as an IPv6 router, also suffer from this issue. Also, this issue seems to affect *only* incoming traffic, outgoing traffic seems to be unaffected. Version-Release number of selected component (if applicable): 3.17.4-301.fc21.x86_64 (the stock kernel), but the latest version as of this writing (3.19.2-201.fc21.x86_64) is also affected. Fedora 20's latest kernel as of this writing (3.18.9-100.fc20.x86_64) is also affected, its stock kernel (3.11.10-301.fc20.x86_64) is not affected. How reproducible: Always. Steps to reproduce: 1. Get an IPv6 tunnel with for example Hurricane Electric 2. Set up the tunnel, instructions for that are on their site, but basically: ip tunnel add he-ipv6 mode sit remote <PoP IP> local <local IP> ttl 255 ip link set he-ipv6 up ip addr add <IPv6 address> dev he-ipv6 ip route add ::/0 dev he-ipv6 3. Test download speed using wget from a known fast mirror Actual results: Severely crippled download speeds, jumping between 30KB/s to 120KB/s (KiloByte). Expected results: Speeds more up to par with what our upstream ISP offers, which should be anything higher, such as at least 5MB/s, up to 20MB/s (MegaByte) depending on the remote server connection. Additional info: These Fedora 21 and 20 routers are running under a fully updated Fedora 20 Xen host.
Proposed as a Blocker for 22-beta by Fedora user robbyke using the blocker tracking app because: I can't find a release criterion where this type of bug could fall under, but I'd still like to submit this as a blocker as this bug severely impacts network speed and affects all clients on networks where a Fedora machine is the tunnel endpoint and the router for those clients. F21 shipped with a kernel that has this issue and it is still not fixed in updates, and F22 looks to go towards the same route, hence this blocker proposal to prevent that from happening again.
This bug also affects F22 Beta RC1 (kernel 4.0.0-0.rc5.git4.1.fc22.x86_64).
This seems like something that should be fixed, but I'm not sure it's serious enough to be a Beta blocker.
Perhaps this is indeed more suited/feasible as a Final blocker. Feel free to change and push this back as a Final blocker, which I should probably have selected instead of leaving it set to Beta.
I don't think this is serious enough to be a blocker for any milestone. Certainly, it's important to fix, but "poor performance" is a very subjective term and difficult to write criteria for. Also, this isn't a regression; Fedora 21 is also experiencing this same bug (which makes it VERY difficult to justify blocking a later release from shipping). I'm opposed to slipping the release until it's fixed (the definition of a blocker). I'm also opposed to a freeze exception because any change to the kernel (particularly one that affects the network stack) has a VERY high risk of introducing blocker side-effects. Please try to fix this between the Beta and Final Freezes, or else as a post-release kernel update. -1 blocker, -1 FE.
-1 blocker
There are a myriad of issues that makes Fedora unsuitable as a router (trust me, I've tried). This is simply one of those issues that should be fixed, but isn't a blocker. Fedora does not advertise itself as a routing platform, so this isn't a criteria we measure. -1 Blocker.
Certainly seems to be a strong consensus against Beta blocker. Per #c4 instead of marking as RejectedBlocker I'll edit this to proposed Final blocker.
Discussed at today's blocker review meeting [1]. This bug was rejected as Final Blocker - there's no criteria violation here, and we think it's correct there's no criteria covering this area of functionality, it is too much of a niche concern to block the release. [1] http://meetbot.fedoraproject.org/fedora-blocker-review/2015-04-20/
*********** MASS BUG UPDATE ************** We apologize for the inconvenience. There is a large number of bugs to go through and several of them have gone stale. Due to this, we are doing a mass bug update across all of the Fedora 21 kernel bugs. Fedora 21 has now been rebased to 3.19.5-200.fc21. Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel. If you have moved on to Fedora 22, and are still experiencing this issue, please change the version to Fedora 22. If you experience different issues, please open a new bug report for those.
Maybe this can be closed? It seems to works perfectly here on Fedora 22: http://img2.ipv6-test.com/speedtest/result/2015/10/17/77a7ef30907f9388802ee3c9288ebc18.png
robby, is there still anything to fix here from your POV?
Hi, I have to mention that this Xen host is still on Fedora 20. In the meantime I have found the following workaround to work on the host: ethtool -K p7p2 gro off This server has 2 Intel NICs, p7p1 and p7p2 (this one is facing the Internet), doing that command on that NIC fixes it, there does not seem to be a need to repeat the command for p7p1. So it turned out this issue is caused by something on the host, once this command has been executed the virtual machines no longer suffer from this issue. Unfortunately I do not have another server with exact or similar hardware to install a newer Fedora on to test, so I cannot yet tell if this issue has been fixed in a newer Fedora kernel or not until this server is being upgraded.
Well, since we have a report that it's OK on F22, I'm gonna close it. If you update to a supported release and find there's still a problem, please re-open or file a new bug. Thanks! For the record, we strongly advise against running production systems on unmaintained Fedora release. F20 is certainly subject to known security issues at this point.