Внезапно потеряно подключение IPv6, в то же время состояние соседнего маршрутизатора IPv6 становится STALE. Как я могу этого избежать?

У меня есть виртуальная машина на хосте с мостовой сетью (следовательно, с собственным MAC-адресом). И хост, и виртуальная машина работают под управлением CentOS. Их сеть управляется простым /etc/sysconfig/сетевые скрипты/ifcfg-enpXsY файлы, содержащие статические IP-адреса. IPv4 работает нормально.

Я назначил виртуальной машине IPv6-адрес (у хоста он тоже есть), который правильно маршрутизируется в центре обработки данных. Однако в большинстве подключений используется IPv4 (пока нет записи DNS AAAA для машины, все еще тестируется IPv6).

Когда я загружаю виртуальную машину, она имеет полное подключение к IPv6. Однако, через некоторое время соединение IPv6 перестает работать (магия IPv6?). Я сузил проблему до данных соседа (ARP/NDISC cache):

IPv6 не работает, не удается пропинговать или подключиться по IPv6 входящим или исходящим образом, то я вижу:

# ip -6 сосед 
fe80::1 dev enp1s2 lladdr 0c:86:72:2e:04:28 маршрутизатор УСТАРЕВШИЙ

Исправление/обходной путь для обновления кеша:

# ip -6 соседний флеш dev enp1s2
# ip -6 сосед
(пусто, как и ожидалось)

затем пинг6 хост из виртуальной машины для заполнения кеша:

# ping6 2912:1375:23:9a6c::2
PING 2912:1375:23:9a6c::2(2912:1375:23:9a6c::2) 56 байт данных
64 байта из 2912:1375:23:9a6c::2: icmp_seq=1 ttl=64 время=2,35 мс
64 байта из 2912:1375:23:9a6c::2: icmp_seq=2 ttl=64 время=0,468 мс
^ С
# ip -6 сосед
fe80::1 dev enp1s2 lladdr 0c:86:72:2e:04:28 маршрутизатор ДОСТУПНО
2912:1375:23:9a6c::2 dev enp1s2 lladdr 08:21:4b:b7:f8:31 ЗАДЕРЖКА

Таблица соседей IPv6/ARP восстановлена ​​до действительности, и подключение работает то в одном, то в другом!

Итак, мои вопросы:

1. Почему кеш устаревает?
2. Что я могу сделать, чтобы этого избежать?
3. Почему/как команда выше это исправляет?

Конечно, я мог бы запустить эти команды в хрон работу (как часто?), но я полагаю, что это не может быть необходимо для работы IPv6 в целом?

PS: Я использовал скрипт для тестов: Стек IPv6 ломается примерно каждые 20 минут. Можно ли это объяснить RFC?

PPS: Конфигурация брандмауэра (сокращенный вывод, надеюсь, все соответствующие биты):

# ip6tables -nvL
Цепочка INPUT (политика DROP 0 пакетов, 0 байт)
 pkts bytes target prot opt ​​in out source target         
 9023 709K ПРИНЯТЬ icmpv6 !lo * ::/0 ::/0                
Цепочка OUTPUT (политика DROP 0 пакетов, 0 байт)
 pkts bytes target prot opt ​​in out source target         
 9360 785K ПРИНЯТЬ icmpv6 * !lo ::/0 ::/0                

Итак, ICMPv6 принимает входящие и исходящие данные на виртуальной машине. Нужно ли проверять фильтрацию на хосте?

В общем, Stale State — это хорошо, на самом деле это приемлемо, если у нас есть Stale State.

Давайте посмотрим на RFC 4861, раздел 5.1. :

  STALE Доступность соседнего узла больше неизвестна, но до тех пор, пока ему не будет отправлен трафик, не следует предпринимать никаких попыток проверить его доступность.

Сосед больше не известен как доступный (таймер истек, в последнее время нет трафика и т. д.), и достижимость будет «проверена» после того, как трафик снова будет отправлен соседу.

Таким образом, нет никаких проблем, если вы можете снова отправить трафик соседу.