Вопрос или проблема
В настоящее время я исследую странную сетевую проблему.
Рассмотрим следующее IPv6 Advertise Router (обратите внимание на сроки действия префикса, 5400 и 2700 секунд соответственно):
$ rdisc6 -1 wlan0
Запрос ff02::2 (ff02::2) на wlan0...
Предел перескоков : 64 ( 0x40)
Состояние настройки адреса : Да
Состояние другой настройки : Да
Мобильный домашний агент : Нет
Предпочтение маршрутизатора : среднее
Прокси обнаружения соседей : Нет
Время жизни маршрутизатора : 1800 (0x00000708) секунд
Время доступности : 3600000 (0x0036ee80) миллисекунд
Время повторной передачи : не указано (0x00000000)
Рекурсивный DNS-сервер : 2a02:####:####:####:f2af:85ff:fe11:70d
Время жизни DNS-сервера : 300 (0x0000012c) секунд
Префикс : 2a02:####:####:####::/64
На ссылке : Да
Автономная настройка адреса: Да
Время действия : 5400 (0x00001518) секунд
Время предпочтения : 2700 (0x00000a8c) секунд
Маршрут : 2a02:####:####:####::/62
Предпочтение маршрута : среднее
Время жизни маршрута : 5400 (0x00001518) секунд
Маршрут : ::/0
Предпочтение маршрута : среднее
Время жизни маршрута : 1800 (0x00000708) секунд
Исходный адрес канального уровня: ##:##:##:##:##:##
с fe80::f2af:85ff:fe11:70d
Я заметил, что сроки жизни, сообщаемые для одного конкретного адреса, иногда немного выше значений в рекламе маршрутизатора.
inet6 2a02:####:####:####:2f89:f9d2:504f:595d/64 (...)
valid_lft 5401sec preferred_lft 2701sec
(Этот вывод сделан вручную. Я не могу получить живую захватку прямо сейчас из-за проблемы с сетью, которую я в конечном итоге пытаюсь решить, но он является представительным для того, как сроки жизни могут быть на секунду больше значения RA.)
Почему это происходит?
В настоящее время я рассматриваю возможность того, что это может быть ошибка в сетевом стекле, используемом в Debian (12), потому что я также наблюдаю следующее:
Это реклама маршрутизатора с обоими сроками действия префикса, установленными на 0, и, насколько я понимаю, это не ошибка, а маршрутизатор намеренно пытается аннулировать этот префикс.
$ rdisc6 -1 wlan0
Запрос ff02::2 (ff02::2) на wlan0...
Предел перескоков : 64 ( 0x40)
Состояние настройки адреса : Да
Состояние другой настройки : Да
Мобильный домашний агент : Нет
Предпочтение маршрутизатора : среднее
Прокси обнаружения соседей : Нет
Время жизни маршрутизатора : 1800 (0x00000708) секунд
Время доступности : 3600000 (0x0036ee80) миллисекунд
Время повторной передачи : не указано (0x00000000)
Рекурсивный DNS-сервер : 2a02:####:####:####:f2af:85ff:fe11:70d
Время жизни DNS-сервера : 300 (0x0000012c) секунд
Префикс : 2a02:####:####:####::/64
На ссылке : Да
Автономная настройка адреса: Да
Время действия : 0 (0x00000000) секунд
Время предпочтения : 0 (0x00000000) секунд
Маршрут : ::/0
Предпочтение маршрута : среднее
Время жизни маршрута : 1800 (0x00000708) секунд
Исходный адрес канального уровня: ##:##:##:##:##:##
с fe80::f2af:85ff:fe11:70d
В этом случае preferred_lft, сообщаемое ip address, также изменяется на 1 секунду (в то время как valid_lft просто, кажется, нормально уменьшается от 5400 секунд в реальном времени). На практике, когда я часто использую ip address, preferred_lft периодически переключается между 1 и 0 секундами.
Кроме того, ip monitor выводит это каждые несколько секунд:
2: wlan0 inet6 2a02:####:####:####:2f89:f9d2:504f:595d/64 scope global dynamic noprefixroute
valid_lft 4916sec preferred_lft 1sec
2: wlan0 inet6 2a02:####:####:####:2f89:f9d2:504f:595d/64 scope global deprecated dynamic noprefixroute
valid_lft 4915sec preferred_lft 0sec
2: wlan0 inet6 2a02:####:####:####:2f89:f9d2:504f:595d/64 scope global dynamic noprefixroute
valid_lft 4913sec preferred_lft 1sec
2: wlan0 inet6 2a02:####:####:####:2f89:f9d2:504f:595d/64 scope global deprecated dynamic noprefixroute
valid_lft 4912sec preferred_lft 0sec
(и так далее)
Это также вызывает серьезный спам в /var/log/syslog:
2023-12-19T19:22:15.143458+01:00 ... avahi-daemon[458]: Регистрация новой записи адреса для 2a02:####:####:####:2f89:f9d2:504f:595d на wlan0.*.
2023-12-19T19:22:16.181261+01:00 ... avahi-daemon[458]: Отзыв записи адреса для 2a02:####:####:####:2f89:f9d2:504f:595d на wlan0.
2023-12-19T19:22:18.011506+01:00 ... avahi-daemon[458]: Регистрация новой записи адреса для 2a02:####:####:####:2f89:f9d2:504f:595d на wlan0.*.
2023-12-19T19:22:19.240632+01:00 ... avahi-daemon[458]: Отзыв записи адреса для 2a02:####:####:####:2f89:f9d2:504f:595d на wlan0.
(и так далее)
Это поведение определенно нежелательно. Произвольное добавление небольшого значения к предпочтительному сроку действия в рекламе маршрутизатора могло бы частично это объяснить.
Я смог наблюдать это на Debian 12 и Raspberry Pi OS.
Я не смог наблюдать это на Arch Linux и Lubuntu.
Тестировал на 3 разных устройствах.
Тем не менее, тесты могут быть не окончательными, потому что я не могу управлять своим маршрутизатором, и он не всегда отправляет одни и те же рекламы маршрутизатора, и у меня нет изолированной тестовой среды.
Это была ошибка в NetworkManager, и она была исправлена здесь.
Исправление доступно в NetworkManager 1.46.0.
Обновление до этой версии должно помочь.
Ответ или решение
Причина, по которой значения оставшихся сроков жизни (lifetimes), сообщаемые через команду ip address, могут быть на секунду выше, чем значения в полученных IPv6 Router Advertisement (RA), может быть вызвана особенностями реализации сетевого стека в операционных системах, а также возможными ошибками в программах, таких как NetworkManager.
В данном случае, наблюдаемые вами различия с увеличением на одну секунду могут быть связаны с неправильной интерпретацией или обработкой значений, полученных из RA. Когда устройство получает RA, оно использует значения для обновления своих записей о сроках жизни всех ассоциированных адресов. Однако, если в реализации присутствуют ошибки, такие как неправильное округление или неучет времени на уровне системы, это может привести к тому, что значения будут незначительно увеличены или не синхронизированы по времени.
Также стоит заметить, что в IPv6 есть механизм, называемый "обновлением срока жизни адреса". При каждом получении нового RA устройство может обновлять свои значения для оставшихся сроков жизни, что также может вызывать небольшие колебания из-за различий во времени выполнения этих действий и в моментах, когда происходит обновление данных.
Ваша проблема с ARP-записями, где preferred_lft периодически изменяется между 1 и 0, а также упомянутая вами ошибка с RA, где значения сроков жизни префикса установлены на 0, также подтверждают наличие багов в сетевом стеке, скорее всего, в компоненте NetworkManager. Для решения вашей проблемы стоит проверить версию NetworkManager на вашем устройстве. Согласно информации из исправления в репозитории GitLab, ошибка была исправлена в версии NetworkManager 1.46.0. Обновление до этой версии может решить вашу проблему с некорректными значениями оставшихся сроков жизни и излишним логированием в syslog.
Рекомендуется провести обновление до последней версии NetworkManager и протестировать поведение системы еще раз. Кроме того, если проблема сохраняется, можно рассмотреть возможность альтернативных реализаций сетевых стеков или систем, например, использование Arch Linux или Lubuntu, как вы упомянули. Это поможет определить, является ли проблема специфичной для вашей среды или для используемого вами программного обеспечения.