High Availability: различия между версиями
Строка 71: | Строка 71: | ||
== Настройка == | == Настройка == | ||
R1# set chassis redundancy graceful-switchover | |||
Для синхронизации конфигов | Для синхронизации конфигов | ||
R1# set system commit synchronize | |||
== Просмотр == | == Просмотр == |
Версия 07:18, 14 октября 2016
Без включенных фич High Availibility
Когда есть 2 или более RE и падает master => PFE стартует заново и все железо и интерфейсы изучаются новым RE.
New RE restart rpd, so that all adjacencies are aware of the topological changes.
Graceful restart (GR)
Позволяет маршрутизатору информировать своих соседей (helper router) о предстоящей перезагрузке или перезагрузки процесса rpd.
Перезагружающийся маршрутизатор (restarting router) запрашивает у соседей определенное время на перезагрузку, после которой они заново станут соседями.
О процессе перезагрузке будет знать не вся сеть, а только непосредственные соседи (соседство различных протоколов падать не будет).
Во время перерыва на control plane, трафик может передаваться через forwarding plane.
Применимо к протоколам: OSPF, ISIS, RIP, BGP, RSVP, LDP, MSDP, PIM.
Каждому RE можно задать ip управления (interface fxp0).
Требования:
- и restarting роутер и helper роутер должны поддерживать GR (на Junos для helper роутера функция активна по умолчанию).
- роутер должен уметь передавать трафик через себя во время процесса перезагрузки (у Junos это по архитектуре есть, проблема может возникнуть только при соседстве с другими вендорами).
Настройка
# show routing-options graceful-restart { <------------------------- включается глоально restart-duration 300; <--------------- max время, в теч которого маршрутизатор находится в GR }
# show protocols bgp graceful-restart { <------------------------- можно задать для конкретного протокола restart-time 300; stale-routes-time 300; <---------------- max время, в теч которого хранятся старые маршруты } group external { export bgp; neighbor 192.168.0.40 { peer-as 200; graceful-restart { <------------------- можно применить для более специфичного уровня иерархии disable;
Просмотр
Мониторинг только внутри протоколов:
# show protocols ospf traceoptions { file ospf_wtf; flag graceful-restart;
# show log ospf_wtf
# show bgp neighbor 192.168.0.40 [Options]
Graceful RE switchover
Когда включен GRES, RE синхронизируют конфигурации и обмениваются keepalive через internal link.
Если один из RE падает (не приходят keepalive 2 сек), то процесс передачи пакетов через PFE продолжает работать.
Graceful RE Switchover сохраняет инфо об интерфейсах, о ядре, но не инфо, содержащуюся в control plane.
Новому RE придется заново устанавливать соседства для разных протоколов и запускать rpd процесс.
Когда рухнет один из RE, PFE разрывает связь со старым RE и устанавливает с новым, с которым обмениваются сообщениями в дальнейшем.
PFE не ребутается и продолжает слать трафик, основываясь на существующей forwarding table.
Настройка
R1# set chassis redundancy graceful-switchover
Для синхронизации конфигов
R1# set system commit synchronize
Просмотр
> show chassis routing-engine
> show system switchover
Принудительно сделать switchover
user@R1> request chassis routing-engine master ?
acquire Attempt to become master Routing Engine
release Request that other Routing Engine become master
switch Toggle mastership between Routing Engines
Nonstop Active Routing (NSR)
Используется только с кол-вом RE > 1.
Также как и graceful RE switchover, NSR хранит информацию об интерфейсах и ядре, но плюс к этому - хранит информацию о маршрутизации на backup RE =>
=> не нуждается в helper router => используется на тех сетях, где роутерами не поддерживается GR => заменяет полностью GR
Для протоколов, которые не поддерживаются NSR, после процессе переключения на новый RE, процесс восстановления работы протоколов происходит по стандартному алгоритму.
Для работы NSR обязательно включить graceful RE switchover, синхронизировать конфиги.
После включения NSR, backup начинает собирать маршрутную информацию с master.
Просмотр
Для переключения из master в backup
{master} user@R1-re0> request routing-engine login other-routing-engine --- JUNOS 10.1R1.8 built 2010-02-12 18:31:54 UTC {backup} user@R1-re1>
Мониторинг работы также осущ-ся в каждом протоколе отдельно (для traceoptions можно задать флаг: nsr-synchronization)
Bidirectional Forwarding Detection (BFD)
Быстрее, чем обычные протоколы определяет (+ статическая маршуртизация), что сервис упал (менее секунды). Хосты устанавливают сессию и обмениваются hello. Если перестали приходить hello, то BFD оповещает систему, что возникла проблема связности между хостами.
В настройках вы определяете минимальное значение для передачи и поучения helloна роутерах. Если значения не совпадают, то BFD использует наибольшее значение (adaptive-mode). Это поведение по умолчанию можно выключить: no-adaptation
Значение кол-ва пропущенных hello можно менять (multiplier)
Настройка
ospf { area 0.0.0.0 { interface fe-0/0/0.0 { bfd-liveness-detection { minimum-interval 300; } }
bgp { bfd-liveness-detection { minimum-receive-interval 300; } group external { export bgp; bfd-liveness-detection { transmit-interval { minimum-interval 300; } }
Просмотр
show bfd session
Virtual Router Redundancy Protocol (VRRP)
Особенности роутеров:
Master - выполняет ф-ию ARP
Backup - их может быть несколько
Для обмена информацией между собой (о приоритете и состоянии мастера) роутеры запихивают обновления в ip-пакеты и шлют на ip 224.0.0.18 раз в 1 сек (по умолчанию).
Можно задать другой интервал для обмена обновлений (1-255). Или с помощью fast-interval (100–999 milliseconds). TTL = 255
Мак-адрес для virtual-router: 00-00-5E-00-01-VRID [virt router ID]
Приоритет по умолчанию: 100
Выигрывает: больший приоритет
Сотосяния:
Initialization - выборы мастера
Master - мастер отправляет всем сообщения о своем состоянии
Backup - backup роутер мониторит состояние master роутера
Transit - короткий момент, когда master сдох, а backup еще не стал master'ом.
Настройка
> show configuration interfaces ae5.398 vlan-id 398; family inet address 77.94.165.185/29 { vrrp-group 1 { <---------------------------------------------- в рамках одного маршрутизатора не должно существовать несколько групп с одинаковым ID virtual-address 77.94.165.187; priority 10; <----------------------------------------------- приоритет advertise-interval 10; <----------------------------------- интервал отправки сообщений внутри группы accept-data; <------------------------------------------- позволяет отвечать на icmp-пакеты authentication-type md5; <------------------------------ md5, simple pass, none authentication-key "$9$"; ## SECRET-DATA no-preempt; <-------------------------------------------- backup не перехватывает роль master (In situations where the VIP address is not owned by any of the participating VRRP routers within a specific VRRP group)
vrrp-inheret-from - ????????
Просмотр
show vrrp summary Interface State Group VR state VR Mode Type Address ae5.398 up 1 backup Active lcl 77.94.165.185 vip 77.94.165.187
Unified in-service software upgrade (ISSU)
Позволяет обновиться без перерыва на control plane и с минимальным перерывом на forwarding plane.
Обязательно должно быть 2 RE.
Должны быть включены: GRES, NSR.
На обоих RE должны быть одинаковые версии прошивки.