Рассмотрение GR, GRES, NSR, BFD
Graceful Restart (GR) - возможность выполнить перезагрузку демона маршрутизации (rpd) без перестроения топологии. Простыми словами: если для протоколов (OSPF, IS-IS, BGP, RIP, RSVP, LDP, MSDP, PIM) включен функционал GR, то при перезагрузки роутинг демона мы не потеряем соседство с маршрутизатором и не будет пересчитывать топологию.
Как включается данный функционал для каждого отдельного протокола:
https://www.juniper.net/techpubs/en_US/junos15.1/topics/task/configuration/graceful-restart-for-routing-protocols-configuring.html
GR helper - режим включенный по умолчанию на устройствах. Это тот самый сосед, который ничего не расскажет про перезагрузку процесса другим в сети.
GR’s restarting router mode - не включен по умолчанию. Это и есть та самая возможность перезагрузки процессов без информация остальных.
Условия для выполнения GR:
- сетевая топология стабильна
- соседи настроены для взаимодействия
- не один из соседей не находится в состоянии GR
- grace период не просрочен
GR helper можно отключить глобально.
Болея специфическая конфигурация - предпочтительна.
Как пример:
Можно отключить GR глобально, но включить для BGP.
Можно включить GR глобально, но отключить для OSPF.
Graceful RE Switchover - возможность включить поддержку смены ролей RE (master RE/backup RE) без простоя трафика. Естественной такой функционал будет работать, если у нас установлено 2 RE и GRES предусмотрен спецификацией конкретной модели оборудования.
В случае падения master RE без активированого GRES - PFE перезагружается, все физические интерфейсы переопределяются новой RE. Перезагружается rpd, теряются все соседства и идет перестроение топологии.
В случае падения master RE с активированной функцией GRES - PFE и интерфейсы не перезагружаются, перезагружается только процесс rpd. Чтоб RPD не перезагружался GRES настройку надо комбинировать с NSR или GR.
Алгоритм работы:
1. RE0 находится в состоянии мастер, RE1 находится в состоянии резервной
2. Когда GRES активирован - конфигурация и служебная информация синхронизированы между RE, они обмениваются keepalive пакетами
3. Если резервная RE на протяжении 2-х секунд не получает keepalive от мастер RE, они считает себя главной
4. PFE переподключается с RE0 на RE1
5. Новая мастер RE и PFE синхронизируются, если надо RE отправляет state update сообщения к PFE
show chassis routing-engine - проверка состояний и ролей
Конфигурация при разных RE:
groups {
re0 {
system {
host-name spice-re0;
}
interfaces {
fxp0 {
unit 0 {
family inet {
address 192.168.69.155/21;
}
}
}
}
}
re1 {
system {
host-name spice-re1;
}
interfaces {
fxp0 {
unit 0 {
family inet {
address 192.168.70.72/21;
}
}
}
}
}
global;
}
apply-groups [ re0 re1 ];
Эта конфигурация позволяет задать разные Hostname и разные MNG IP для разных RE.
Чтоб синхронизировать конфигурация между разными RE необходимо сохранять конфигурацию через commit synchronize, либо задать автоматический коммит в конфигурации:
{master}[edit system]
user@R1-re0# set commit synchronize
Не забываем, что поменять отношения master/backup можно и в ручном режиме, например чтоб вытащить RE и тд. - request chassis routing-engine master switch
Когда GRES активирован появляется баннер - master или backup в CLI.
Nonstop Active Routing - функционал для оборудования с резервированием по RE который позволяет при синхронизировать rdp данные между двумя RE. Такая возможность нам дает практически идеальную смену master RE и backup RE отношений.
Использовать одновременно NSR и GR нельзя.
Процесс RPD запускается на backup RE.
При изменении mastership ролей пиры подключенные к данному устройство об этом ничего не узнают.
NSR проверятся через команду: show task replication
BFD - Bidirectional Forwarding Detection
Большинство протоколов уже имеют встроенные функции по обнаружению ошибок на каналах логических, так и физических. Например, определение что OSPF сосед стал недостижим с интервалами по умолчанию может занят до 40 секунд! Это критично!
Решением такой проблемы стает протокол BFD - Bidirectional Forwarding Detection, своеобразная надстройка над протоколом маршрутизации, которая позволяет с помощью keepalive пакетов определять живучесть соседа. Такой процесс может занимать меньше секунды.
Можно установить transmit и receive интрвалы отдельно или сразу вместе. Не рекомендуется ставить интервал меньше 300 мс, высока вероятность ложных срабатываний. Логика работы такая: если 3 BDF hello не пришло - значит соединение помечено как не успешное.
Периодические пакеты в некоторых моделях Junos называются - periodic packet management (PPM) в BFD. По умолчанию они включены в Junos.
Проверка: show bfd session
VRRP - Virtual Router Redundancy Protocol, протокол резервирование основного шлюза. На нескольких устройствах настраивается функционал VRRP, одно из устройство выступает основным шлюзом остальные резервные для сегмента сети. Протокол стандартизирован - RFC 2338.
Аналог протокола VRRP у Cisco называется - Hot Standby Router Protocol (HSRP).
VRRP Router - маршрутизатор на котором запущен протокол (это может быть как Master, так и Backup маршрутизатор).
Master Router - маршрутизатор принимающий пакеты от сегмента сети и отвечающий на arp запросы.
Backup Router - маршрутизатор который отслеживает состояние Master и готов принять на себя трафик в случае сбоя Master. Таких маршрутизаторов может быть несколько.
Virtual Router - виртуальный IP адрес, который является шлюзом по умолчанию для сегмента сети обычно называемого VIP. VR имеет идентификатор который состоит из virtual router identifier (VRID) и virtual IP (VIP) address.
VRRP v2 использует common advertisement packet для взаимодействия между VRRP маршрутизаторами. Такие пакеты ходят по мультикаст адресу 224.0.0.18 и имеют TTL 255.
Временной интервал пересылки таких пакетов - 1 секунда, по умолчанию. Данный интервал можно править руками в пределах 1 - 255 секунд. Также, можно установить fast-interval и настроить время пересылки в пределах от 100-999 мс.
При пересылке служебных пакетов и при ответе клиенту arp используется виртуальный MAC адрес, формат которого: 00-00-5E-00-01-VRID.
Выбор VRRP Master Router происходит по приоритету, который может быть от 1-255. Чем выше значение - тем выше приоритет. По умолчанию всем маршрутизаторам устанавливается значение в 100, кроме маршрутизатора который имеет VIP адрес.
По умолчанию VIP не отвечает на ICMP, чтоб включит возможность отвечать необходимо добавить accept-date в конфигурацию VRRP.
