Таймер VRRP обнаруживает потерю Active, но не задаёт полный срок восстановления сервиса
Фотография конкретного исполнения не приложена.
Обещание переключения «за три advertisement intervals» упускает часть расчёта и последующих действий. Для приёмки нужно отдельно измерять обнаружение и возвращение полезной передачи. Протокольный timer не равен готовому SLA приложения.
RFC 9568 задаёт Active_Down_Interval как три Active_Adver_Interval плюс Skew_Time. Skew зависит от priority. Условный пример при интервале 1 секунда и priority 100 даёт skew 156/256 секунды и общий расчёт около 3,609 секунды для указанного случая.
Это расчёт таймера с переводом единиц, а не результат испытания маршрутизатора. После выбора роли остаются packet scheduling, L2 learning, routing и приложение. Отдельный graceful shutdown с priority 0 также имеет другую предусмотренную реакцию, чем тихая потеря advertisements.
В приёмке фиксируют реальный interval, priority, момент последнего advertisement и восстановление трафика. Проверяют нужный тип отказа. Отчёт должен показывать обе границы. Само совпадение расчётного timer с конфигурацией не подтверждает, что конечный запрос завершится за тот же срок.
Основание — VRRPv3 RFC9568 April2024 and selected BFD base, single/multihop, application, micro and seamless RFCs, разделы RFC9568 6.1 Skew_Time and Active_Down_Interval; timer units. Сохранён текст публичной справочной публикации; конкретная реализация может поддерживать только часть возможностей. Основание — указанные RFC: VRRPv3 рассматривается по RFC 9568 от апреля 2024 года, заменившему RFC 5798; BFD — в явно указанном scope. Реальная поддержка, timers, hardware и маршруты не проверялись. Переключения, faults, пакеты и настройки рабочей сети не выполнялись.
Запросы отправляются на наш e-mail из вашей почтовой программы.
