☰

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

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

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

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

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

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

# ip -6 neighbour 
fe80::1 dev enp1s2 lladdr 0c:86:72:2e:04:28 router STALE

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

# ip -6 neighbour flush dev enp1s2
# ip -6 neighbour
(empty, as expected)

Затем ping6хост из виртуальной машины заполняет кэш:

# ping6 2912:1375:23:9a6c::2
PING 2912:1375:23:9a6c::2(2912:1375:23:9a6c::2) 56 data bytes
64 bytes from 2912:1375:23:9a6c::2: icmp_seq=1 ttl=64 time=2.35 ms
64 bytes from 2912:1375:23:9a6c::2: icmp_seq=2 ttl=64 time=0.468 ms
^C
# ip -6 neighbour
fe80::1 dev enp1s2 lladdr 0c:86:72:2e:04:28 router REACHABLE
2912:1375:23:9a6c::2 dev enp1s2 lladdr 08:21:4b:b7:f8:31 DELAY

Таблица IPv6 neighbor/ARP восстановлена ​​и связь работает нормально!

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

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

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

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

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

# ip6tables -nvL
Chain INPUT (policy DROP 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         
 9023  709K ACCEPT     icmpv6    !lo    *       ::/0                 ::/0                
Chain OUTPUT (policy DROP 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         
 9360  785K ACCEPT     icmpv6    *      !lo     ::/0                 ::/0

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

решение1

В целом, застойное состояние — это хорошо, на самом деле вполне приемлемо, что у нас есть застойное состояние.

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

  STALE       The neighbor is no longer known to be reachable but until traffic is sent to the neighbor, no attempt should be made to verify its reachability.

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

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

Связанный контент