Ich bin mit meinem Latein am Ende und bin für jede Hilfe dankbar.
Ich habe einen IPv6-Host (Linux 4.15.1-gentoo SMP x86_64), der zufällig aufhört, Neighbor Advertisements zu senden. Beim Ausführen von tcpdump werden viele Neighbor Solicitation-Anfragen angezeigt, aber fast keine Reaktion auf diese Anfragen. Gelegentlich sendet der Host immer noch NA, aber erst nach ein paar Dutzend ignorierten NS-Anfragen. Dies unterbricht offensichtlich die IPv6-Konnektivität vollständig.
Ich weiß nicht, ob es relevant ist, aber IPv6 ist auf einer Bridge-Schnittstelle konfiguriert (ein paar lxc-Container laufen auch auf dieser Bridge). Die Bridge ist eine typische brctl-Bridge mit deaktiviertem STP.
IPv6 ist statisch konfiguriert (sowohl Host als auch Gateway).
Das manuelle Überfluten des Netzwerks mit unerwünschten Nachbaranzeigen (beispielsweise mithilfe ndsendvon „from vzctl“) kann das Problem ein wenig lindern, ist aber offensichtlich keine Lösung.
Noch seltsamer ist, dass das Deaktivieren und erneute Aktivieren von IPv6 auf der Schnittstelle über procfs ( /proc/sys/net/ipv6/conf/br0/disable_ipv6) und die Neukonfiguration ( ip -6 addr add, usw.) das Problem vorübergehend „behebt“. Nach ein oder zwei Tagen tritt es jedoch erneut auf.
Der Vollständigkeit halber sei erwähnt, dass auf dem Host eine nftables-Firewall ausgeführt wird, die jedoch ausdrücklich sämtlichen ICMPv6-Verkehr (überall ip6 nexthdr ipv6-icmp accept) zulässt. Das Deaktivieren der Firewall, wenn das Problem auftritt, ändert nichts.
Hier ist also die Frage: Was kann ich tun, um das zugrunde liegende Problem zu ermitteln?
AKTUALISIEREN: Bei mir verschwand das Problem nach einigen Kernel-Updates, aber es gibt Berichte über ähnliche Probleme bei späteren Kernel-Versionen, insbesondere bei großen Routing-Tabellen und/oder einer großen Anzahl von Nachbarn. Berichten zufolge ist ein möglicher Schuldiger hier die geringe Beschränkung der IPv6-Routen-/Nachbarcachegröße im Kernel. Wenn Sie ähnliche Probleme haben, versuchen Sie, den net.ipv6.route.max_sizeSysctl-Parameter auf einen relativ großen Wert (z. B. 1048576) zu erhöhen, beispielsweise durch Ausführen sysctl -w net.ipv6.route.max_size=1048576und/oder Bearbeiten von /etc/sysctl.conf. Sie werden wahrscheinlich auch erhöhen wollen, net.ipv6.route.gc_threshum zu vermeiden, dass der Garbage Collector zu oft ausgeführt wird. Überprüfen Sie auch net.ipv6.neigh.default.gc_thresh1,
net.ipv6.neigh.default.gc_thresh2und
net.ipv6.neigh.default.gc_thresh3wenn Sie besonders viele Datensätze im Nachbarcache haben. Siehehttps://www.kernel.org/doc/Documentation/networking/ip-sysctl.txtfür den Zweck all dieser Optionen.
Antwort1
Ich habe gerade entdeckt, dass es einen Fehler beim Multicast_Snooping in Linux-VLAN-fähigen Bridges gibt. Router-Werbung wird dadurch nicht beeinflusst, aber Neighbor Discovery wird blockiert, selbst wenn Multicast_Flooding eingeschaltet ist. Beim Booten eines Systems wird Dad ausgeführt und Dad bleibt in der Multicast-Weiterleitungsdatenbank. Aber das läuft nach 200 oder 300 Sekunden ab. Danach wird jedes Neighbor Discovery-Multicast-Paket an diesen Port gesendet. Dies geschieht nur bei Neighbor Discovery, nicht bei Router-Werbung. Sie können dies beobachten, indem Sie Folgendes tun:
bridge mdb show
Wenn Ihnen Einträge angezeigt werden, ist Multicast_Snooping aktiviert. Und Sie könnten/werden den Fehler erleben. In meinem Fall haben etwa 80 % der Systeme, die ich eingerichtet habe, begonnen, nur Neighbor Discovery Multicast zu blockieren. Alle anderen Multicasts werden überflutet oder richtig überwacht.
Die Lösung besteht derzeit darin, Multicast_Snooping auszuschalten:
echo 0 > /sys/net/devicename/bridge/multicast_snooping
Wenn ich Zeit habe, werde ich einen Testaufbau machen. Dieser Virus plagt mich jetzt schon seit 2 Jahren, und während der Notfallwartung hatte ich endlich die Zeit, das Problem vollständig zu erfassen.
Antwort2
Ich hatte dasselbe Problem mit einem 4.16.2-Gentoo-Kernel. Aber in meinem Fall stellte sich heraus, dass es überhaupt nichts mit dem Kernel zu tun hatte.
Die betreffende Box diente als IPv6-VPN-Gateway und hatte eine stabile Verbindung. Sogar der Subnetz-Router dahinter war einwandfrei, nur das geroutete Subnetz selbst verlor ständig die Verbindung.
Kurz zusammengefasst:
Firewallwar in meinem Fall der Übeltäter. Das IPv6rpfilterDie Einstellung filterte die Nachbaranfragen meines Subnetz-Routers.
Finden Sie es heraus, indem Sie die Anmeldung aktivieren/etc/firewalld/firewalld.conf
LogDenied=all
was zu Loglines wie diesen führte (MAC und SRC gekürzt und verschleiert):
kernel: rpfilter_DROP: IN=enp6s0.100 OUT= MAC=XX:…:XX SRC=fe80:…:beaf DST=ff02:0000:0000:0000:0000:0001:ff00:0001 LEN=72 TC=0 HOPLIMIT=255 FLOWLBL=0 PROTO=ICMPv6 TYPE=135 CODE=0
Ich habe einfach den IPv6-RP-Filter deaktiviert, bis ich herausfinden kann, warum das passiert. Die Einrichtung ist ziemlich einfach und für mich sieht alles gut aus, aber vielleicht liegt es daran, dass die Schnittstelle ein VLAN ist ...