Ich verwende Debian 8 auf einem virtuellen Server. Nach der Installation von Docker und der Aktivierung von IPv6 ist mir etwas Merkwürdiges aufgefallen. Ich weiß nicht, ob Docker damit etwas zu tun hat, aber mir ist dieses Problem erst nach der Installation aufgefallen.
Meine Standardroute ist so konfiguriert, dass sie nach ca. 1800 Sekunden abläuft. Nach diesem Timeout verschwindet sie tatsächlich. Dann verliere ich (offensichtlich) die IPv6-Konnektivität.
root@wopr:~# ip -6 route
xxxx:yyyy:zzz:xxxx::/64 dev eth0 proto kernel metric 256
fe80::/64 dev eth0 proto kernel metric 256
fe80::/64 dev br-5c1ce68ea951 proto kernel metric 256
fe80::/64 dev br-61f6bbfdbe87 proto kernel metric 256
[a lot more routed for my docker containers]
default via fe80::1 dev eth0 proto ra metric 1024 expires 1259sec hoplimit 64
Warum ist der Router so konfiguriert, dass er nach 1800 s abläuft? Wo kann ich das konfigurieren?
[Bearbeiten 14.05.2016 16:08]
Das manuelle Hinzufügen einer Standardroute scheint problemlos zu funktionieren. Sie bleibt dort, wo sie ist. Aber ich brauche eine Route, die nach dem Booten nicht abläuft.
[Bearbeiten 14.05.2016 16:13]
Die Maschine läuft auf einem KVM-Host, der von netcup.de gehostet wird. Sie verwendet den Virtio-Treiber, wie von meinem Provider empfohlen.
root@wopr:~# cat /etc/network/interfaces
auto lo
iface lo inet loopback
iface lo inet6 loopback
auto eth0
iface eth0 inet dhcp
iface eth0 inet6 static
address xxxx:yyyy:zzz:xxxx::1
netmask 64
gateway fe80::1
virt-what sagt:
root@wopr:~# virt-what
kvm
[Bearbeiten 14.05.2016 15:34]
Es sieht so aus, als hätte ich übersehen, dass es net.ipv6.conf.default.autoconfauf 1 gesetzt war. Jetzt habe ich eine Datei in /etc/sysctl.d hinzugefügt, um dies beim Booten zu unterdrücken:
root@wopr:~# cat /etc/sysctl.d/ipv6.conf
net.ipv6.conf.default.accept_ra=0
net.ipv6.conf.default.autoconf=0
net.ipv6.conf.all.accept_ra=0
net.ipv6.conf.all.autoconf=0
net.ipv6.conf.eth0.accept_ra=0
net.ipv6.conf.eth0.autoconf=0
Antwort1
Offenbar habe ich übersehen, dass net.ipv6.conf.default.autoconf auf 1 gesetzt war. Das Hinzufügen einer Datei in /etc/sysctl.d, um dies beim Booten zu unterdrücken, hat das Problem für mich gelöst:
root@wopr:~# cat /etc/sysctl.d/ipv6.conf
net.ipv6.conf.default.accept_ra=0
net.ipv6.conf.default.autoconf=0
net.ipv6.conf.all.accept_ra=0
net.ipv6.conf.all.autoconf=0
net.ipv6.conf.eth0.accept_ra=0
net.ipv6.conf.eth0.autoconf=0
Jetzt bekomme ich eine Standardroute, die beim Booten nicht abläuft. Problem gelöst. Danke, dass du mich in die richtige Richtung gelenkt hast, Sander.
Antwort2
1800 Sekunden klingt nach einem Standard-Timeout für eine Router-Anzeige.
Meine erste Vermutung wäre, dass es im Netzwerk einen Cisco-Router gibt, der mit ipv6 nd ra suppressder Schnittstelle konfiguriert ist. In diesem Modus sendet der Router eine RA, wenn ein Host eine mit einer RS anfordert, aktualisiert sie aber nicht regelmäßig. Ein Host sendet eine RS, wenn er die Schnittstelle hochfährt, was erklären würde, warum er nach dem Booten eine Standardroute erhält.
Diese Einstellung ist eine seltsame, nutzlose Cisco-Einstellung. Ein Router sollte entweder auf Anfrage + regelmäßig (die Standardeinstellung bei Cisco) oder überhaupt nicht ( ipv6 nd ra suppress all) RAs senden. Die Halbwegs-Einstellung ipv6 nd ra suppressverursacht ein solches seltsames Verhalten und sollte nicht verwendet werden.
Antwort3
Tatsächlich ist die markierte Antwort falsch. Das Problem besteht darin, dass Docker die Weiterleitung an Schnittstellen ermöglicht und der Linux-Kernel dadurch RAs an dieser bestimmten Schnittstelle ignoriert, siehe:https://www.mattb.net.nz/blog/2011/05/12/linux-ignores-ipv6-router-advertisements-when-forwarding-is-enabled/
Die richtige Lösung in diesem Fall besteht also accept_radarin , Folgendes einzustellen 2:
# cat /etc/sysctl.d/ipv6.conf
net.ipv6.conf.default.accept_ra=2
net.ipv6.conf.all.accept_ra=2
net.ipv6.conf.eth0.accept_ra=2
anstatt die Routenerkennung vollständig zu deaktivieren.