Debian / IPv6: Die Standardroute läuft nach 1800 Sekunden ab und verliert die Konnektivität

Ich verwende Debian 8 auf einem vServer. Nach der Installation von Docker und der Aktivierung von IPv6 habe ich etwas Seltsames festgestellt. Ich weiß nicht, ob Docker etwas damit zu tun hat. Ich habe dieses Problem nur nach der Installation bemerkt.

Meine Standardroute ist so konfiguriert, dass sie nach ca. 1800 Sekunden. Nach dieser Zeit verschwindet ich tatsächlich. Dies ist, wenn ich (offensichtlich) die IPv6-Konnektivität verliere.

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 2016-05-14 16:08]

Das manuelle Hinzufügen einer Standardroute scheint einwandfrei zu funktionieren. Es bleibt stehen. Aber ich muss nach dem Booten eine nicht ablaufende Route haben.

[Bearbeiten 2016-05-14 16:13]

Der Computer wird auf einem von netcup.de gehosteten KVM-Host ausgeführt. Es wird der virtio-Treiber verwendet, wie von meinem Anbieter 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-was sagt:

root@wopr:~# virt-what
kvm

[edit 2016-05-14 15:34] Es sieht so aus, als hätte ich verpasst, dass dies net.ipv6.conf.default.autoconfauf 1 gesetzt wurde. 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

Es sieht so aus, als hätte ich verpasst, dass net.ipv6.conf.default.autoconf auf 1 gesetzt wurde. Das Hinzufügen einer Datei in /etc/sysctl.d, um dies beim Booten zu unterdrücken, löste das Problem für mich:

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.

1800 Sekunden klingen wie ein Standardzeitlimit für eine Router-Ankündigung.

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, diese jedoch nicht regelmäßig aktualisiert. Ein Host sendet beim Aufrufen der Schnittstelle eine RS, was erklären würde, warum er nach dem Start eine Standardroute erhält.

Diese Einstellung ist eine seltsame, nutzlose Cisco-Einstellung. Ein Router sollte entweder RAs senden, wenn er regelmäßig gefragt wird (Standardeinstellung bei Cisco), oder überhaupt nicht ( ipv6 nd ra suppress all). Die Einstellung auf halber Strecke ipv6 nd ra suppressverursacht ein derart seltsames Verhalten und sollte nicht verwendet werden.

Eigentlich ist die markierte Antwort falsch. Das Problem ist, dass Docker die Weiterleitung auf Schnittstellen aktiviert und der Linux-Kernel RAs auf dieser bestimmten Schnittstelle ignoriert (siehe: https://www.mattb.net.nz/blog/2011/05/12/linux-ignores) -ipv6-Router-Werbung-wenn-Weiterleitung-aktiviert ist /

So ist die richtige Lösung in diesem Fall Satz accept_razu 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.