High Availability: различия между версиями
м |
|||
(не показана 21 промежуточная версия этого же участника) | |||
Строка 1: | Строка 1: | ||
{{#description2:Работы Junos без HA. Graceful restart (GR). Graceful RE switchover (GRES). Nonstop Active Routing (NSR). Bidirectional Forwarding Detection (BFD). Link Aggregation Control Protocol (LACP). Virtual Router Redundancy Protocol (VRRP). Unified in-service software upgrade (ISSU). Информация для подготовки к экзаменам Juniper.}} | |||
= Без включенных фич High Availibility = | = Без включенных фич High Availibility = | ||
Когда есть 2 или более RE и падает master => PFE стартует заново и все железо и интерфейсы изучаются новым RE. | Когда есть 2 или более RE и падает master => PFE стартует заново и все железо и интерфейсы изучаются новым RE. | ||
Новый RE запускает rpd, поэтому все соседствующие устройства детектят изменение топологии и заново производят вычисление кратчайших путей и активных маршрутов. | |||
То есть без включения дополнительных фич, сходимость на сети происходит крайне медленно! | |||
= Graceful restart (GR) = | = Graceful restart (GR) = | ||
Позволяет маршрутизатору информировать своих соседей (helper router) о предстоящей перезагрузке или перезагрузки процесса rpd. | Позволяет маршрутизатору информировать своих соседей (helper router) о предстоящей перезагрузке или перезагрузки процесса rpd. | ||
Перезагружающийся маршрутизатор (restarting router) запрашивает у соседей определенное время на перезагрузку, после которой они заново станут соседями. | Перезагружающийся маршрутизатор (restarting router) запрашивает у соседей определенное время на перезагрузку, после которой они заново станут соседями. | ||
О процессе перезагрузке будет знать не вся сеть, а только непосредственные соседи (соседство | О процессе перезагрузке будет знать не вся сеть, а только непосредственные соседи (соседство по протоколам падать не будет). | ||
Во время перерыва на control plane, трафик | Во время перерыва на control plane, трафик будет передаваться через forwarding plane. | ||
Применимо к протоколам: OSPF, ISIS, RIP, BGP, RSVP, LDP, MSDP, PIM. | Применимо к протоколам: OSPF, ISIS, RIP, BGP, RSVP, LDP, MSDP, PIM. | ||
Строка 21: | Строка 23: | ||
* и restarting роутер и helper роутер должны поддерживать GR (на Junos для helper роутера функция активна по умолчанию). | * и restarting роутер и helper роутер должны поддерживать GR (на Junos для helper роутера функция активна по умолчанию). | ||
* роутер должен уметь передавать трафик через себя во время процесса перезагрузки (у Junos это по архитектуре есть, проблема может возникнуть только при соседстве с другими вендорами). | * роутер должен уметь передавать трафик через себя во время процесса перезагрузки (у Junos это по архитектуре есть, проблема может возникнуть только при соседстве с другими вендорами). | ||
== Настройка == | == Настройка == | ||
# show routing-options | # show routing-options | ||
graceful-restart { <------------------------- включается глоально | graceful-restart { <------------------------- включается глоально | ||
Строка 32: | Строка 32: | ||
# show protocols bgp | # show protocols bgp | ||
graceful-restart { | graceful-restart { | ||
restart-time 300; | restart-time 300; | ||
stale-routes-time 300; <---------------- max время, в теч которого хранятся старые маршруты | stale-routes-time 300; <---------------- max время, в теч которого хранятся старые маршруты | ||
Строка 44: | Строка 44: | ||
== Просмотр == | == Просмотр == | ||
Мониторинг только внутри протоколов: | Мониторинг только внутри протоколов: | ||
Строка 51: | Строка 50: | ||
file ospf_wtf; | file ospf_wtf; | ||
flag graceful-restart; | flag graceful-restart; | ||
# show log ospf_wtf | # show log ospf_wtf | ||
# show bgp neighbor 192.168.0.40 [Options] | # show bgp neighbor 192.168.0.40 [Options] | ||
= Graceful RE switchover = | = Graceful RE switchover (GRES) = | ||
Когда включен GRES, RE синхронизируют конфигурации и обмениваются keepalive через internal link. | Когда включен GRES, RE синхронизируют конфигурации и обмениваются keepalive через internal link. | ||
Если один из RE падает (не приходят keepalive 2 сек), то | Если один из RE падает (не приходят keepalive 2 сек), то передача пакетов через PFE продолжается. | ||
Graceful RE Switchover сохраняет инфо об интерфейсах, о ядре, но не инфо, содержащуюся в control plane. | Graceful RE Switchover сохраняет инфо об интерфейсах, о ядре, но не инфо, содержащуюся в control plane. | ||
Строка 65: | Строка 62: | ||
Новому RE придется заново устанавливать соседства для разных протоколов и запускать rpd процесс. | Новому RE придется заново устанавливать соседства для разных протоколов и запускать rpd процесс. | ||
Когда рухнет | Когда рухнет одна из RE, PFE разрывает связь со старым RE и устанавливает с новым, с которым обмениваются сообщениями в дальнейшем. | ||
PFE не ребутается и продолжает слать трафик, основываясь на существующей forwarding table. | PFE (packet forwarding engine) не ребутается и продолжает слать трафик, основываясь на существующей forwarding table. | ||
Чтобы сохранить работоспособность не только форвардинга, но и роутинга во время switchover, GRES должен использоваться совместно с NSR и Grasefull restart protocols extentions. | |||
Switchover происходит в том случае, если: | |||
*RE kernel перестает работать | |||
*hardware failure на RE | |||
*принудительно руками | |||
'''Приложения, поддерживающие GRES:''' LACP, MPLS LSPs (transit only), Multicast, VPLS, DHCP relay, l2circuits, и другие... | |||
== Настройка == | == Настройка == | ||
set chassis redundancy graceful-switchover | |||
Для синхронизации конфигов | Для синхронизации конфигов | ||
set system commit synchronize | |||
Только что вставленная backup RE синхронизирует свой конфиг с конфигом master RE. | |||
Только при включенном GRES можно скопировать JunOS с master на backup RE. | |||
== Просмотр == | == Просмотр == | ||
show chassis routing-engine | |||
show system switchover || используется только на backup RE, поэтому сначала нужно перейти на backup: ''request routing-engine login backup'' | |||
==Принудительно сделать switchover== | |||
R1> request chassis routing-engine master ? | |||
acquire Attempt to become master Routing Engine </code> | acquire Attempt to become master Routing Engine </code> | ||
release Request that other Routing Engine become master | release Request that other Routing Engine become master | ||
Строка 96: | Строка 101: | ||
Также как и graceful RE switchover, NSR хранит информацию об интерфейсах и ядре, но плюс к этому - хранит информацию о маршрутизации на backup RE => | Также как и graceful RE switchover, NSR хранит информацию об интерфейсах и ядре, но плюс к этому - хранит информацию о маршрутизации на backup RE => | ||
=> не нуждается в helper router => используется на тех сетях, где роутерами не поддерживается GR => заменяет | => не нуждается в helper router => используется на тех сетях, где роутерами не поддерживается GR => полностью заменяет GR. | ||
Для протоколов, которые не поддерживаются NSR, после | Для протоколов, которые не поддерживаются NSR, после процесса переключения на новый RE, процесс восстановления работы протоколов происходит по стандартному алгоритму. | ||
Для работы NSR обязательно включить | Для работы NSR обязательно включить Graceful RE Switchover, синхронизировать конфиги. | ||
После включения NSR, backup начинает собирать маршрутную информацию с master. | После включения NSR, backup начинает собирать маршрутную информацию с master. | ||
Строка 108: | Строка 113: | ||
Для переключения из master в backup | Для переключения из master в backup | ||
{master} | '''{master}''' | ||
user@R1-re0> request routing-engine login other-routing-engine | user@R1-re0> request routing-engine login other-routing-engine | ||
--- JUNOS 10.1R1.8 built 2010-02-12 18:31:54 UTC | --- JUNOS 10.1R1.8 built 2010-02-12 18:31:54 UTC | ||
{backup} | '''{backup}''' | ||
user@R1-re1> | user@R1-re1> | ||
Мониторинг работы также осущ-ся | Мониторинг работы также осущ-ся для каждого протокола отдельно (для traceoptions можно задать флаг: nsr-synchronization) | ||
= Bidirectional Forwarding Detection (BFD) = | = Bidirectional Forwarding Detection (BFD) = | ||
Обнаружение падения соседства намного быстрее, чем у обычных протоколов (и статической маршуртизации) - менее секунды. | |||
Хосты устанавливают сессию и обмениваются hello. | Хосты устанавливают сессию и обмениваются hello. | ||
В настройках | Если перестали приходить hello, то BFD дает знать протоколу, что пропала связность между хостами. | ||
В настройках определяем минимальное значение для передачи и поучения hello на роутерах. | |||
Если значения не совпадают, то BFD использует наибольшее значение (adaptive-mode). | Если значения не совпадают, то BFD использует наибольшее значение (adaptive-mode). | ||
Это поведение по умолчанию можно выключить: no-adaptation | Это поведение по умолчанию можно выключить: no-adaptation. | ||
Значение кол-ва пропущенных hello можно менять (multiplier) | Значение кол-ва пропущенных hello можно менять (multiplier). | ||
== Настройка == | == Настройка == | ||
Строка 136: | Строка 140: | ||
interface fe-0/0/0.0 { | interface fe-0/0/0.0 { | ||
bfd-liveness-detection { | bfd-liveness-detection { | ||
minimum-interval 300; | minimum-interval 300;}} | ||
bgp { | bgp { | ||
bfd-liveness-detection { | bfd-liveness-detection { | ||
minimum-receive-interval 300; | minimum-receive-interval 300;} | ||
group external { | group external { | ||
export bgp; | export bgp; | ||
bfd-liveness-detection { | bfd-liveness-detection { | ||
transmit-interval { | transmit-interval { | ||
minimum-interval 300 | minimum-interval 300:}} | ||
== Просмотр == | == Просмотр == | ||
show bfd session | |||
= Link Aggregation Control Protocol (LACP) = | |||
*Автоматическое добавление и удаление отдельных линков в ae. (глобально, но не в JunOS) | |||
*Мониторинг линка с целью проверки, что он с обоих концов включен в ae. | |||
Когда собрана ae и включен lacp, локальная и удаленная сторона начинает обмениваться PDU, которые содержат в себе инфо о состоянии линка. | |||
Настраивается либо active-active, либо active-passive. Одна из сторон обязательно должна отправлять PDU, то есть быть active. | |||
==Link protection== | |||
Link-protection: позволяет приоритезировать прохождение трафика по конкретному линку. Eggress трафик (транзитный или локально сгенерированный) будет проходить только через назначенный primary линк. | |||
Имеет смысл при объединении от 2х линков в ae. | |||
Если нужно задействовать большее кол-вол линков - собираем subgroups. | |||
Мы можем добавить линки в разные subgroups, в рамках одной ae - primary и secondary. По линкам из primary subgroup будет идти трафик, пока не возникнет проблем с линком из primary subgroup. Как только, так сразу трафик перестраивается на secondary subgroup. | |||
Трафик бегает пол инкам с высшим приоритетом. При добавлении нового линка с высшим приоритетом, или восстановления старого линка с высшим приоритетом, трафик сразу переходит на него. Чтобы избежать такого состояния, настраиваем: ''non-revertive''. | |||
Если настраиваем link-protection, настройки у линков с обеих сторон должны быть обязательно одинаковыми! | |||
Можно делать настройку как глобально, так и локально для конкретной ae. | |||
===Config=== | |||
* Глобально | |||
[edit chassis aggregated-devices ethernet] | |||
+ lacp { | |||
+ link-protection { | |||
+ non-revertive; | |||
*2 линка в ae: | |||
[edit interfaces ge-0/0/2 gigether-options 802.3ad] | |||
+ lacp { | |||
+ port-priority 33333; | |||
[edit interfaces ae0 aggregated-ether-options lacp] | |||
+ link-protection { | |||
+ non-revertive; | |||
*>2 линков в ae: | |||
[edit interfaces ae0 aggregated-ether-options] | |||
+ link-protection-sub-group | |||
+ subgroup-primary primary | |||
+ subgroup-backup backup | |||
[edit interfaces ge-0/0/2 ether-options 802.3ad] | |||
+ link-protection-sub-group group-name | |||
[edit interfaces ge-0/0/3 ether-options 802.3ad] | |||
+ link-protection-sub-group group-name | |||
[edit interfaces ge-0/0/4 ether-options 802.3ad] | |||
+ link-protection-sub-group group-name | |||
и включаем link-protection на каком-нибудь уровне: LAG/LACP/AE. | |||
[edit interfaces ae0 aggregated-ether-options lacp] | |||
+ link-protection | |||
==Link-speed== | |||
Когда указываем в настройках ae link-speed, все линки, входящие в ae должны соответствовать этой настройке. | |||
Начиная с 14.2 версии, можно объединять в ae линки разных скоростей: | |||
[edit interfaces ae33] | |||
+ aggregated-ether-options { | |||
+ link-speed mixed; | |||
Минимальное кол-во линков можно задавать, но по дефолту хотя бы один линк соберется в ae. | |||
[edit interfaces ae0 aggregated-ether-options] | |||
+ minimum-links 4; | |||
Если число линков указываем, то ae0 соберется, только если как минимум это число линков будет у статусе ''collecting distributing''. | |||
= Virtual Router Redundancy Protocol (VRRP) = | |||
Особенности роутеров: | |||
*'''Master''' - выполняет ф-ию | |||
*'''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 - мастер отправляет остальным не master роутерам сообщения о своем состоянии | |||
*Backup - backup роутер мониторит состояние master роутера | |||
*Transit - короткий момент, когда master сдох, а backup еще не стал master'ом. | |||
== Настройка == | == Настройка == | ||
> show configuration interfaces ae5.398 | > show configuration interfaces ae5.398 | ||
vlan-id 398; | vlan-id 398; | ||
Строка 204: | Строка 255: | ||
VRRP routers within a specific VRRP group) | VRRP routers within a specific VRRP group) | ||
'''preempt/no-preempt''' - если падал vrrp интерфейс с большим приоритетом, и потом вернулся в работу - может выставить параметр не переключать master обратно на него. Либо интерфейс может себе вернуть роль мастера по истечению hold-timer. На практике сработал только когда интерфейс физически падал. | |||
vrrp-inheret-from - | '''vrrp-inheret-from''' - создан для удобства создания интерфейсов в одинаковыми параметрами. Все настройки интерфейса, который указан в качестве vrrp-inheret-from - наследуются. | ||
== Просмотр == | == Просмотр == | ||
show vrrp summary | show vrrp summary | ||
Interface State Group VR state VR Mode Type Address | Interface State Group VR state VR Mode Type Address | ||
ae5.398 up 1 backup Active lcl 77.94.165.185 | ae5.398 up 1 backup Active lcl 77.94.165.185 | ||
vip 77.94.165.187 | vip 77.94.165.187 | ||
==Track interface/route== | |||
У vrrp есть возможность следить за состоянием маршрута или интерфейса, или за кол-вом трафика на интерфейсе. И в зависимости от состояния - уменьшать приоритет. По сути пригодно, когде vrrp сделан на PE-роутер и через этот vrrp работает клиент. В таком случае, например, при "потере" uplink линков, роутер перестал быть master, и клиент слал бы трафик на другой роутер. | |||
> show configuration interfaces ge-0/0/4 | |||
unit 300 { | |||
family inet { | |||
address 172.30.1.2/24 { | |||
vrrp-group 101 { | |||
track { | |||
interface ge-0/0/2.204 { | |||
priority-cost 10; | |||
interface ge-0/0/3.228 { | |||
priority-cost 10; | |||
= Unified in-service software upgrade (ISSU) = | = Unified in-service software upgrade (ISSU) = | ||
Строка 224: | Строка 287: | ||
На обоих RE должны быть одинаковые версии прошивки. | На обоих RE должны быть одинаковые версии прошивки. | ||
=Дополнительная информация= | |||
*[[Static, Aggregate, Generate route]] | |||
*[[OSPF]] | |||
*[[BGP]] | |||
*[[IS-IS]] |
Текущая версия на 18:12, 15 июля 2021
Без включенных фич High Availibility
Когда есть 2 или более RE и падает master => PFE стартует заново и все железо и интерфейсы изучаются новым RE.
Новый RE запускает rpd, поэтому все соседствующие устройства детектят изменение топологии и заново производят вычисление кратчайших путей и активных маршрутов.
То есть без включения дополнительных фич, сходимость на сети происходит крайне медленно!
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)
Когда включен GRES, RE синхронизируют конфигурации и обмениваются keepalive через internal link.
Если один из RE падает (не приходят keepalive 2 сек), то передача пакетов через PFE продолжается.
Graceful RE Switchover сохраняет инфо об интерфейсах, о ядре, но не инфо, содержащуюся в control plane.
Новому RE придется заново устанавливать соседства для разных протоколов и запускать rpd процесс.
Когда рухнет одна из RE, PFE разрывает связь со старым RE и устанавливает с новым, с которым обмениваются сообщениями в дальнейшем.
PFE (packet forwarding engine) не ребутается и продолжает слать трафик, основываясь на существующей forwarding table.
Чтобы сохранить работоспособность не только форвардинга, но и роутинга во время switchover, GRES должен использоваться совместно с NSR и Grasefull restart protocols extentions.
Switchover происходит в том случае, если:
- RE kernel перестает работать
- hardware failure на RE
- принудительно руками
Приложения, поддерживающие GRES: LACP, MPLS LSPs (transit only), Multicast, VPLS, DHCP relay, l2circuits, и другие...
Настройка
set chassis redundancy graceful-switchover
Для синхронизации конфигов
set system commit synchronize
Только что вставленная backup RE синхронизирует свой конфиг с конфигом master RE.
Только при включенном GRES можно скопировать JunOS с master на backup RE.
Просмотр
show chassis routing-engine show system switchover || используется только на backup RE, поэтому сначала нужно перейти на backup: request routing-engine login backup
Принудительно сделать switchover
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
Link Aggregation Control Protocol (LACP)
- Автоматическое добавление и удаление отдельных линков в ae. (глобально, но не в JunOS)
- Мониторинг линка с целью проверки, что он с обоих концов включен в ae.
Когда собрана ae и включен lacp, локальная и удаленная сторона начинает обмениваться PDU, которые содержат в себе инфо о состоянии линка. Настраивается либо active-active, либо active-passive. Одна из сторон обязательно должна отправлять PDU, то есть быть active.
Link protection
Link-protection: позволяет приоритезировать прохождение трафика по конкретному линку. Eggress трафик (транзитный или локально сгенерированный) будет проходить только через назначенный primary линк.
Имеет смысл при объединении от 2х линков в ae.
Если нужно задействовать большее кол-вол линков - собираем subgroups.
Мы можем добавить линки в разные subgroups, в рамках одной ae - primary и secondary. По линкам из primary subgroup будет идти трафик, пока не возникнет проблем с линком из primary subgroup. Как только, так сразу трафик перестраивается на secondary subgroup.
Трафик бегает пол инкам с высшим приоритетом. При добавлении нового линка с высшим приоритетом, или восстановления старого линка с высшим приоритетом, трафик сразу переходит на него. Чтобы избежать такого состояния, настраиваем: non-revertive.
Если настраиваем link-protection, настройки у линков с обеих сторон должны быть обязательно одинаковыми!
Можно делать настройку как глобально, так и локально для конкретной ae.
Config
- Глобально
[edit chassis aggregated-devices ethernet] + lacp { + link-protection { + non-revertive;
- 2 линка в ae:
[edit interfaces ge-0/0/2 gigether-options 802.3ad] + lacp { + port-priority 33333; [edit interfaces ae0 aggregated-ether-options lacp] + link-protection { + non-revertive;
- >2 линков в ae:
[edit interfaces ae0 aggregated-ether-options] + link-protection-sub-group + subgroup-primary primary + subgroup-backup backup [edit interfaces ge-0/0/2 ether-options 802.3ad] + link-protection-sub-group group-name [edit interfaces ge-0/0/3 ether-options 802.3ad] + link-protection-sub-group group-name [edit interfaces ge-0/0/4 ether-options 802.3ad] + link-protection-sub-group group-name и включаем link-protection на каком-нибудь уровне: LAG/LACP/AE. [edit interfaces ae0 aggregated-ether-options lacp] + link-protection
Link-speed
Когда указываем в настройках ae link-speed, все линки, входящие в ae должны соответствовать этой настройке.
Начиная с 14.2 версии, можно объединять в ae линки разных скоростей:
[edit interfaces ae33] + aggregated-ether-options { + link-speed mixed;
Минимальное кол-во линков можно задавать, но по дефолту хотя бы один линк соберется в ae.
[edit interfaces ae0 aggregated-ether-options] + minimum-links 4;
Если число линков указываем, то ae0 соберется, только если как минимум это число линков будет у статусе collecting distributing.
Virtual Router Redundancy Protocol (VRRP)
Особенности роутеров:
- Master - выполняет ф-ию
- 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 - мастер отправляет остальным не 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)
preempt/no-preempt - если падал vrrp интерфейс с большим приоритетом, и потом вернулся в работу - может выставить параметр не переключать master обратно на него. Либо интерфейс может себе вернуть роль мастера по истечению hold-timer. На практике сработал только когда интерфейс физически падал.
vrrp-inheret-from - создан для удобства создания интерфейсов в одинаковыми параметрами. Все настройки интерфейса, который указан в качестве 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
Track interface/route
У vrrp есть возможность следить за состоянием маршрута или интерфейса, или за кол-вом трафика на интерфейсе. И в зависимости от состояния - уменьшать приоритет. По сути пригодно, когде vrrp сделан на PE-роутер и через этот vrrp работает клиент. В таком случае, например, при "потере" uplink линков, роутер перестал быть master, и клиент слал бы трафик на другой роутер.
> show configuration interfaces ge-0/0/4 unit 300 { family inet { address 172.30.1.2/24 { vrrp-group 101 { track { interface ge-0/0/2.204 { priority-cost 10; interface ge-0/0/3.228 { priority-cost 10;
Unified in-service software upgrade (ISSU)
Позволяет обновиться без перерыва на control plane и с минимальным перерывом на forwarding plane.
Обязательно должно быть 2 RE.
Должны быть включены: GRES, NSR.
На обоих RE должны быть одинаковые версии прошивки.