https://bugzilla.suse.com/show_bug.cgi?id=1175641 Bug ID: 1175641 Summary: All IPv6 packets are sent to router – even for neighbors in the LAN. Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Network Assignee: screening-team-bugs@suse.de Reporter: psikodad@gmx.de QA Contact: qa-bugs@suse.de Found By: --- Blocker: --- The default installation of tumbleweed (Leap 15.2 as well) is configured in a way that *all IPv6 packets* are sent to the router – even those packets which destination is inside the LAN. (Layer-2 destination is always the MAC address of the router.) This report is IPv6 specific. IPv4 isn't affected at all. System setup: - Fresh Tumbleweed 20180814 (with KDE) - NetworkManager (not wicked) Investigation: Here are some information of the system: # ip -6 route ::1 dev lo proto kernel metric 256 pref medium fd00::/64 via fe80::c225:6ff:fe08:eab8 dev enp0s3 proto ra metric 100 pref medium fe80::/64 dev enp0s3 proto kernel metric 100 pref medium The fe80::c225:… is the IPv6 address of the router. # sudo /sbin/sysctl net.ipv6.conf.enp0s3.accept_redirects net.ipv6.conf.enp0s3.accept_redirects = 0 Explanation: According to the "ip -6 route" output all IPv6 packets are leaving the computer from device enp0s3 and are sent to the router (via fe80::c225:…). I turned wireshark on in order to capture the packets I could see there is a packet from the router: It’s an ICMPv6 redirect (Code 137) which tells the sender (the tumbleweed installation) that he should not send the packets to the router because there is a better connection available. And tells him the MAC of the destination which should be used instead of the routers MAC. Thus, for further communication the packet should go direct the destination and not via the router. That *would* be OK. However, tumbleweed ignores the ICMPv6 redirect message because of "net.ipv6.conf.enp0s3.accept_redirects=0 and keeps sending everything to the router. *This ends in a huge performance regression and the router becomes the bottleneck of the network.* (Huge file transfers will be sent to the router and the router will forward it to the destination – which is in the same subnet!) Workarounds: 1. Do "sudo sysctl net.ipv6.conf.enp0s3.accept_redirects=1" The redirect instructions from the router are accepted. Performance will be great. This variation is used by the distribution Linux Mint 20 (Cinnamon) and Neon (KDE & NetworkManager). 2. Add an additional line in the route table (with a better metric than the one with the “via fe80::” line): # ip -6 route fd00::/64 dev enp0s3 proto ra metric 100 The packets are not sent to the router in first place and so, the performance will be great. This variation is used by the Distribution Ubuntu Server 20.04. 3. Modify the route table entry (=remove the “via fe80::…” string). # ip -6 route fd00::/64 dev enp0s3 proto kernel metric 256 expires 7140sec pref medium This variation is used by Tumbleweed when you switch from NetworkManager to wicked in yast (plus reboot). Performance will be great. Conclusion: NetworkManager is creating route table entries with fd00::/64 via fe80::c225:6ff:fe08:eab8 dev enp0s3 proto ra metric 100 pref medium and tumbleweed uses sysctl net.ipv6.conf.enp0s3.accept_redirects=0 This is a bad combination. (Fedora 32 had the same combination with the same bad results.) Proposal: Either # sudo sysctl net.ipv6.conf.enp0s3.accept_redirects=1 or # sudo ip route add fd00::/64 dev enp0s3 proto ra metric 90 pref medium (or both) would help to fix the issue. -- You are receiving this mail because: You are on the CC list for the bug.