High Availability Junos (подготовка JNCIS-ENT)

Рассмотрение 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.