我已無計可施，因此非常感謝您的幫助。
我有一個 IPv6 主機 (Linux 4.15.1-gentoo SMP x86_64)，它隨機停止傳送鄰居通告。執行 tcpdump 顯示大量鄰居請求請求，並且對這些請求的反應幾乎為零。有時，主機仍會發送 NA，但只有在數十個被忽略的 NS 請求之後才會發送。顯然，這完全破壞了 IPv6 連線。
我不知道它是否相關，但 IPv6 是在橋接器上配置的（幾個 lxc 容器也在該橋上運行）。該橋是典型的 brctl 橋，STP 關閉。
IPv6 是靜態設定的（主機和網關）。
ndsend手動用未經請求的鄰居廣告（例如使用來自）淹沒網路vzctl可以稍微緩解問題，但這顯然不是解決方案。
更奇怪的是，透過 procfs ( ) 在介面上停用和重新啟用 ipv6/proc/sys/net/ipv6/conf/br0/disable_ipv6並重新配置它（ip -6 addr add等）暫時「修復」了問題。但一兩天後它會再發生。
為了完整起見，主機上運行著一個 nftables 防火牆，但它明確允許所有 icmpv6 流量（通過ip6 nexthdr ipv6-icmp accept任何地方）。當問題出現時停用防火牆不會改變任何事情。
那麼，問題是：我該怎麼做才能找出根本問題？
更新：對我來說，這個問題在幾次核心更新後就消失了，但有報告稱在更高版本的核心上也存在類似問題，特別是在大型路由表和/或大量鄰居的情況下。據報道，其中一個可能的罪魁禍首是核心中 ipv6 路由/鄰居快取大小的小限制。如果您遇到類似的問題，請嘗試將net.ipv6.route.max_sizesysctl 參數提高到相對較大的值（例如1048576），例如透過執行sysctl -w net.ipv6.route.max_size=1048576和/或編輯/etc/sysctl.conf.您可能還希望籌集資金net.ipv6.route.gc_thresh以避免過度頻繁地運行垃圾收集器。另外，檢查net.ipv6.neigh.default.gc_thresh1、
net.ipv6.neigh.default.gc_thresh2以及
net.ipv6.neigh.default.gc_thresh3鄰居快取中是否有特別多的記錄。看https://www.kernel.org/doc/Documentation/networking/ip-sysctl.txt所有這些選項的作用。
答案1
我剛剛發現 Linux VLAN 感知網橋中的multicast_snooping 有一個錯誤。它不會觸及路由器通告，但即使打開了multicast_flooding，它也會阻止鄰居發現。所發生的情況是，在系統啟動時，它將執行“爸爸”操作，並且該“爸爸”將保留在多播轉發資料庫中。但 200 或 300 秒後就會過期。此後，任何鄰居發現多播封包都將被丟棄到該連接埠。這只會發生在鄰居發現中，而不是路由器通告中。您可以透過執行以下操作來見證它：
bridge mdb show
如果它顯示條目，則表示multicast_snooping 已開啟。您可能/將會遇到該錯誤。就我而言，我設置的大約 80% 的系統僅開始阻止鄰居發現多播。任何其他多播都會被淹沒或正確偵聽。
目前的解決方案是關閉multicast_snooping：
echo 0 > /sys/net/devicename/bridge/multicast_snooping
當我有時間時，我會進行測試設定。這個bug已經困擾了我兩年了，在緊急維修期間我終於有時間完全掌握了這個問題。
答案2
我在使用 4.16.2-gentoo 核心時遇到了同樣的問題。但就我而言，它與核心完全無關。
該盒子充當 ipv6 VPN 網關並且具有穩定的連接。即使它背後的子網路路由器也完全正常，只是路由子網路本身不斷失去連線。
TL;博士;
防火牆是我案件的罪魁禍首。 ipv6過濾器設定過濾了我的子網路路由器的鄰居請求。
透過啟用登入發現了這一點/etc/firewalld/firewalld.conf
LogDenied=all
這導致日誌行如下（MAC 和 SRC 被縮短和混淆）：
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
我剛剛禁用了 ipv6 rpfilter，直到我能夠找出發生這種情況的原因。設定非常簡單，對我來說一切看起來都很好，但也許這是介面成為 vlan 的問題...