Прежде всего, попробуем разобраться в причинах отсутствия стекируемых маршрутизаторов как явления. И призовем на помощь ИИ в виде YandexGPT – не реклама или хейт (вообще ничего не имею против Яндекса и пользуюсь их Навигатором), «но истина дороже».
Далее, настроим кластер на виртуальном (программном) стенде.
И, наконец, попробуем найти реальные рамки и границы применения кластерной технологии на маршрутизаторах ESR.
Я спросил у Яндекса
И так, первый вопрос: «чем друг от друга отличаются сетевые коммутатор, маршрутизатор и межсетевой экран?». Возможно, причина на поверхности.
Ответ YandexGPT:
«Сетевой коммутатор (свитч) — это устройство, которое соединяет несколько устройств в локальную сеть и позволяет им обмениваться данными. Коммутатор анализирует входящие сигналы и направляет их только на те порты, где находятся устройства, которым они предназначены. Основная задача коммутатора — обеспечение связи между устройствами в пределах одной сети.
Маршрутизатор — это устройство, которое пересылает пакеты данных между различными сегментами сети на основе правил и таблиц маршрутизации. Маршрутизатор определяет наилучший путь для передачи данных от отправителя к получателю, анализируя сетевые адреса и используя таблицы маршрутизации. Маршрутизаторы часто используются для соединения локальных сетей с интернетом.
Межсетевой экран (файрвол) — это система или программное обеспечение, которое контролирует и фильтрует трафик между сетями. Межсетевой экран может разрешать или запрещать трафик на основе различных критериев, таких как IP-адреса, порты, протоколы и т. д. Основная задача межсетевого экрана — защита сети от несанкционированного доступа, вирусов, троянов, червей и других угроз.
Таким образом, коммутатор обеспечивает связь между устройствами в сети, маршрутизатор определяет путь для передачи данных между сетями, а межсетевой экран защищает сеть от внешних угроз.»
Понятнее не стало. Наверное, «каков вопрос – таков и ответ».
Попробуем зайти с другой стороны. Второй вопрос: «почему не стекируют маршрутизаторы?»
Ответ YandexGPT:
«Маршрутизаторы не всегда стекируют (объединяют несколько устройств в одно для увеличения производительности или объёма памяти) по нескольким причинам:
1. Архитектура и функции. Маршрутизаторы предназначены для пересылки пакетов данных между различными сегментами сети на основе правил и таблиц маршрутизации. Их основная задача — определение наилучшего пути для передачи данных. В отличие от коммутаторов, которые работают на канальном уровне и обеспечивают связь между устройствами в пределах одной сети, маршрутизаторы работают на сетевом уровне. Их функции и архитектура могут не предусматривать возможность стекирования.
2. Сложность реализации. Стекирование может потребовать дополнительных аппаратных и программных решений, что может увеличить стоимость и сложность устройства. Производители могут предпочесть сосредоточиться на других функциях и возможностях, которые более востребованы на рынке.
3. Совместимость и стандарты. Различные производители могут использовать разные протоколы и стандарты для стекирования. Это может затруднить совместимость между устройствами разных производителей и ограничить возможность стекирования в некоторых сетях.
4. Потребности рынка. В некоторых случаях потребности рынка могут не требовать стекирования маршрутизаторов. Например, в небольших или средних сетях может быть достаточно одного или нескольких маршрутизаторов для удовлетворения потребностей. В таких случаях производители могут не видеть необходимости в разработке и производстве стекируемых маршрутизаторов.
5. Специализация. Некоторые маршрутизаторы могут быть специализированными для определённых задач, например, для работы в определённых протоколах или для определённых типов сетей. В таких случаях стекирование может быть нецелесообразным или невозможным из-за различий в архитектуре и функциях.»
В принципе, после стекирования «для увеличения производительности или объёма памяти» можно больше вопросов не задавать. Да и стекирование устройств от разных производителей похоже на неудачную шутку.
Однако, для полноты картины, спросим напоследок: «Почему стоит использовать кластер ESR от Элтекс».
Ответ YandexGPT:
«Кластер ESR от компании «Элтекс» может быть полезен по следующим причинам:
1. Высокая надёжность и отказоустойчивость. Кластер ESR обеспечивает непрерывную работу сети за счёт распределения нагрузки между узлами и автоматического переключения на резервный узел в случае отказа основного. Это минимизирует простои и потери данных.
2. Масштабируемость. Кластер ESR позволяет легко масштабировать производительность и объём хранения данных путём добавления новых узлов. Это обеспечивает гибкость и адаптивность системы к растущим требованиям бизнеса.
3. Централизованное управление. Управление кластером ESR осуществляется через единый интерфейс, что упрощает настройку, мониторинг и обслуживание системы. Это снижает нагрузку на IT-персонал и повышает эффективность работы.
4. Интеграция с существующими системами. Кластер ESR может быть интегрирован с различными сетевыми устройствами и приложениями, что позволяет использовать его в составе комплексной сетевой инфраструктуры.
5. Безопасность. Кластер ESR обеспечивает защиту данных и сети благодаря встроенным функциям безопасности, таким как межсетевой экран, антивирусная защита и системы обнаружения вторжений.
6. Оптимизация трафика. Кластер ESR может оптимизировать трафик в сети, распределяя нагрузку между узлами и обеспечивая балансировку нагрузки. Это повышает производительность сети и улучшает качество обслуживания пользователей.
7. Поддержка различных протоколов. Кластер ESR поддерживает различные сетевые протоколы, что обеспечивает совместимость с различными устройствами и приложениями.
8. Экономическая эффективность. Использование кластера ESR может снизить общие затраты на IT-инфраструктуру за счёт оптимизации ресурсов, уменьшения простоев и повышения эффективности работы сети.
9. Техническая поддержка. Компания «Элтекс» предоставляет техническую поддержку и обслуживание кластера ESR, что обеспечивает надёжную работу системы и оперативное решение возникающих проблем.
10. Репутация производителя. «Элтекс» зарекомендовала себя как надёжный производитель сетевого оборудования, что может служить дополнительным аргументом в пользу выбора их продукции.»
Откровенно спорные моменты (ОК, не все) выделил подчеркиванием. Эта спорность станет особенно понятной после выполнения процедур настроек. А приведенные выше результаты общения с ИИ подтверждают расхожее мнение, что ИИ очень часто галлюцинируют. А иногда – даже бредят. И еще нескоро полностью заменят сетевых специалистов.
И так, кластер на ESR – для чего?
Для получения ответа можно ввести в CLI команду «show high-availability state»
И проанализировать подзаголовки результата:
· AP Tunnels
· DHCP option 82 table
· DHCP server
· crypto-sync
· Firewall sessions and NAT translations
Видно, что защищаются туннели к точкам доступа, шифрование, DHCP, Firewall sessions и NAT translations. С одной стороны, вполне логично. С другой стороны, YandexGPT не угадал вообще ничего.
Что приятно, почти весь упоминаемый функционал вполне подробно описан в документации вендора. Исходя из опыта работы с документацией Элтекс, она достаточно полна и точна по части описания реализации. Правда, не всегда исчерпывающе объясняет замысел разработчиков, что поначалу порождает некоторое недоумение по поводу подходов и способов. И, как следствие, является причиной досадных ошибок при освоении новых тем.
И да, функционал кластера на ESR не требует дополнительных лицензий.
Собственно, эта статья будет посвящена основам настройки кластера на ESR, поскольку разобравшись с этими основами и далее работая по документации, можно запросто настроить весь требуемый функционал. Главное – правильно собрать саму основу (собственно кластер), поверх которого уже настраиваются остальные сервисы и протоколы.
Для большей наглядности, будем настраивать не просто «кластер ради команд show», а соберем простейшую схему из 4 маршрутизаторов, 2 из которых будут «конечными точками», а 2 – промежуточным кластером. При этом между всеми функциональными узлами такой сети настроим BGP+BFD. Такой эксперимент даст представление о временах переключения и причинах этих значений. Ну и позволит определить технологическую нишу этого решения.
Все маршрутизаторы – vESR 1.37.4. При этом интерфейсы Gi 1/0/1 на устройствах R0 и R1 будут использованы как кластерный интерфейс (при желании, можно несколько интерфейсов собрать в отказоустойчивый бандл – явно описано в документации, но в нашем случае необязательно). Интерфейсы же Gi 1/0/2 на всех устройствах будут использоваться для передачи данных.
Собственно, настройка
Настройка выполняется в 3 шага (ОК, в 4). Определенным плюсом является то, что устройства виртуальные. Поэтому такой параметр, как серийный номер, может быть задан произвольно (а этот параметр, в свою очередь, после перезагрузки предсказуемо и повторяемо определит System MAC). Поэтому приведенные ниже конфигурации можно просто применять на соответствующих устройствах. И так, по шагам:
Шаг 0 – Задать новый пароль для пользователя admin
Стандартное требование при первом запуске маршрутизатора ESR (в том числе, виртуального). Описано в документации.
Шаг 1 — Настройка серийного номера и Cluster Unit на устройствах кластера – R0 и R1
И то, и другое требует перезагрузки для активации, поэтому удобно настраивать разом.
vesr# set unit id 1Unit ID will be 1 after rebootvesr# set serial-number VESR0000001WARNING!!! Changes of serial number will be applied after system rebootvesr# commitConfiguration has been successfully applied and saved to flash. Commit timer started, changes will be reverted in 600 seconds.vesr# confirmConfiguration has been confirmed. Commit timer canceled.vesr# reload systemy
Примечание: для каждого vESR установлен serial-number по-умолчанию VESR0000000. Но с таким значением устройство не позволит настроить кластер, поэтому изменить номер придется для каждого vESR, входящего в кластер.
Для устройства R1 список команд будет следующий:
set unit id 2set serial-number VESR0000002commitconfirmreload system(и ввести букву “y”)
После перезагрузки необходимо убедиться в правильности промежуточного результата. Вообще, в случае с кластером успех каждого последующего шага напрямую зависит от правильности результатов шага предыдущего. Поэтому не пренебрегайте проверками и выполняйте настройки максимально полно и точно.
И так, на каждом устройстве R0 и R1 выполняем следующие команды:
show system | in MAC
show interfaces status
Ожидаемые результаты для R0
vesr# sh system | in MAC
System MAC address: A2:00:00:00:10:00
vesr# sh interfaces status
Interface Admin Link MTU MAC address Last change Mode
State State (d,h:m:s)
——————— ———- —— —— —————— ————- ————
gi1/0/1 Up Up 1500 0c:fb:de:a3:00:00 00,00:16:02 routerport
gi1/0/2 Up Up 1500 0c:fb:de:a3:00:01 00,00:16:02 routerport
gi1/0/3 Up Down 1500 0c:fb:de:a3:00:02 00,00:16:10 routerport
gi1/0/4 Up Down 1500 0c:fb:de:a3:00:03 00,00:16:10 routerport
gi1/0/5 Up Down 1500 0c:fb:de:a3:00:04 00,00:16:10 routerport
gi1/0/6 Up Down 1500 0c:fb:de:a3:00:05 00,00:16:10 routerport
gi1/0/7 Up Down 1500 0c:fb:de:a3:00:06 00,00:16:10 routerport
gi1/0/8 Up Down 1500 0c:fb:de:a3:00:07 00,00:16:10 routerport
Ожидаемые результаты для R1
vesr# show system | in MAC
System MAC address: A2:00:00:00:20:00
vesr# show interfaces status
Interface Admin Link MTU MAC address Last change Mode
State State (d,h:m:s)
——————— ———- —— —— —————— ————- ————
gi2/0/1 Up Up 1500 0c:6a:61:d7:00:00 00,00:13:55 routerport
gi2/0/2 Up Up 1500 0c:6a:61:d7:00:01 00,00:13:55 routerport
gi2/0/3 Up Down 1500 0c:6a:61:d7:00:02 00,00:14:04 routerport
gi2/0/4 Up Down 1500 0c:6a:61:d7:00:03 00,00:14:04 routerport
gi2/0/5 Up Down 1500 0c:6a:61:d7:00:04 00,00:14:04 routerport
gi2/0/6 Up Down 1500 0c:6a:61:d7:00:05 00,00:14:04 routerport
gi2/0/7 Up Down 1500 0c:6a:61:d7:00:06 00,00:14:04 routerport
gi2/0/8 Up Down 1500 0c:6a:61:d7:00:07 00,00:14:04 routerport
Здесь главное:
-
System MAC address: A2:00:00:00:10:00 для R0
-
System MAC address: A2:00:00:00:20:00 для R1
-
Интерфейсы Gi для R0 начинаются на 1
-
Интерфейсы Gi для R1 начинаются на 2
Шаг 2 — Настраиваем кластер (пока без сервисов и протоколов маршрутизации)
Здесь единая конфигурация, применяется на каждом устройстве:
Единая конфигурация настройки кластера
ip firewall disable
cluster
cluster-interface bridge 1
unit 1
mac-address a2:00:00:00:10:00
exit
unit 2
mac-address a2:00:00:00:20:00
exit
enable
exit
hostname R0 unit 1
hostname R1 unit 2
bridge 1
vlan 1
ip address 192.168.1.111/24 unit 1
ip address 192.168.1.112/24 unit 2
vrrp 1
ip address 192.168.1.1/24
priority 254 unit 1
priority 253 unit 2
group 1
enable
exit
enable
exit
interface gigabitethernet 1/0/1
mode switchport
switchport access vlan 1
exit
interface gigabitethernet 2/0/1
mode switchport
switchport access vlan 1
exit
system prompt ‘(Cluster: %s% | Unit: %u% | State: %r% | VRRP id 1: %v1%)|%h%’
Первым делом – отключаем встроенный firewall (примеры настроек с включенным firewall есть в документации).
Далее – настройка кластера. В качестве кластерного интерфейса используется bridge 1, и пока только bridge интерфейсы могут быть кластерными интерфейсами. Указание МАС-адреса – возможно, мера предосторожности (если несколько устройств окажутся с одинаковым идентификатором UNIT). По умолчанию, последующие настройки должны выполняться на активном узле и далее транслироваться на standby-узел (эту настройка менять не будем).
Из важного хочется обратить внимание, что в настройках vrrp указаны максимально допустимые значения приоритета. Это удобно в случае выхода из строя одного из узлов (аппаратных) кластера. Тогда новому узлу можно присвоить следующее (по убыванию) значение приоритета, чтобы избежать дополнительных переключений с неизбежным простоем (см. раздел «Вот теперь мы попингуем»).
Интерфейсы gigabitethernet 1/0/1 и 2/0/1 – «физические» интерфейсы, соединяющие узлы кластера. С помощью wireshark можно посмотреть пакеты, передаваемые через них. Утверждается, что сейчас все изменения в конфигурациях передаются в открытом виде (в том числе пароли учетных записей).
Нижняя строчка в конфигурации является быстрым и очень полезным индикатором состояния кластера без необходимости ввода диагностических команд. Последовательно отображается следующая информация:
-
статус полной синхронизации кластера (Yes/No),
-
номер юнита администрируемого устройства (1-4),
-
роль устройства в кластере (Active/ Standby),
-
статус кластерного VRRP (Master/ Backup),
-
и последний параметр – хостнейм устройства
Ожидаемые состояния таковы:
(Cluster: Yes | Unit: 1 | State: Active | VRRP id 1: Master)|R0#
(Cluster: Yes | Unit: 2 | State: Standby | VRRP id 1: Backup)|R1#
ИМХО, самым важным параметром является первый. Если он не в «Yes» — значит, что-то неладно. Иногда помогает дополнительная команда commit на активном устройстве кластера.
К недостаткам этого промпта можно отнести его большую длину (но можно сократить указатели, либо оставить только переменные — которые с символами процентов).
Полезные диагностические команды:
show cluster status
show cluster sync status
Результаты диагностики
(Cluster: Yes | Unit: 2 | State: Standby | VRRP id 1: Backup)|R1# sh cluster status
Unit Hostname Role MAC address State IP address
—- ——————— ———- —————— ————— —————
1 R0 Active a2:00:00:00:10:00 Joined 192.168.1.111
2* R1 Standby a2:00:00:00:20:00 Joined 192.168.1.112
(Cluster: Yes | Unit: 2 | State: Standby | VRRP id 1: Backup)|R1# sh cluster sync status
System part Synced
———————- ——
candidate-config Yes
running-config Yes
SW version Yes
licence Yes
licence (After reboot) Yes
date Yes
Шаг 3 — Настраиваем интерфейсы (данные) и маршрутизацию
Нужно настроить:
-
Конечные точки (R2 и R3) для обмена маршрутной информацией и тестового трафика
-
Узлы кластера (R0 и R1) для обмена маршрутной информацией с конечными точками и передачи тестового трафика
Логическая схема с адресами, инкапсуляцией и BGP AS приведена на рисунке.
В целом, на схеме приведена вся необходимая информация. При этом:
-
номер саб-интерфейса уже определяет инкапсуляцию (т.е., саб-интерфейсы .2 и .3 будут использовать VLAN соответственно 2 и 3), такова специфика ESR
-
4-й октет в рамках диапазонов будет .1 для кластера и .2 и .3 для R2 и R3 соответственно
-
для R2 и R3 настроим интерфейсы Loopback 1 c соответствующими адресами и будем анонсировать через BGP
в качестве L2 устройства можно использовать встроенный хаб GNS3 (и тогда настраивать вообще ничего не надо – он пропускает все пакеты с любой инкапсуляцией) либо IOL (добавляем VLAN 2,3 и все порты настраиваем как транки). Поскольку хаб подводил при подготовке к лабе, использовал IOL.
Настройки R2
hostname R2
route-map PASS
rule 10
exit
exit
router bgp 65002
neighbor 10.0.2.1
remote-as 65000
update-source 10.0.2.2
fall-over bfd
address-family ipv4 unicast
route-map PASS out
enable
exit
enable
exit
address-family ipv4 unicast
network 2.2.2.2/32
exit
enable
exit
interface gigabitethernet 1/0/2.2
ip address 10.0.2.2/24
ip bfd min-rx-interval 800
ip bfd min-tx-interval 800
ip bfd multiplier 3
exit
interface loopback 1
ip address 2.2.2.2/32
exit
ip firewall disable
Примечание: одной особенностью реализации eBGP на ESR является необходимость явного разрешения анонса префиксов через route-map. В нашем случае, используем route-map PASS, которая ничего не запрещает. Входящие же BGP анонсы принимаются без ограничений.
В сущности, можно было бы использовать iBGP, но тогда понадобились бы route-reflector-client и next-hop-self all.
Настройки R3
hostname R3
route-map PASS
rule 10
exit
exit
router bgp 65003
neighbor 10.0.3.1
remote-as 65000
update-source 10.0.3.3
fall-over bfd
address-family ipv4 unicast
route-map PASS out
enable
exit
enable
exit
address-family ipv4 unicast
network 3.3.3.3/32
exit
enable
exit
interface gigabitethernet 1/0/2.3
ip address 10.0.3.3/24
ip bfd min-rx-interval 800
ip bfd min-tx-interval 800
ip bfd multiplier 3
exit
interface loopback 1
ip address 3.3.3.3/32
exit
ip firewall disable
Для кластера приводятся именно сервисные настройки с учетом того, что кластер, хостнеймы и ip firewall disable были настроены на шаге 2. Применяются на активном узле (это важно), после чего автоматически реплицируются на соседний узел.
Настройки кластера
route-map PASS
rule 10
exit
exit
router bgp 65000
neighbor 10.0.2.2
remote-as 65002
update-source 10.0.2.1
fall-over bfd
address-family ipv4 unicast
route-map PASS out
enable
exit
enable
exit
neighbor 10.0.3.3
remote-as 65003
update-source 10.0.3.1
fall-over bfd
address-family ipv4 unicast
route-map PASS out
enable
exit
enable
exit
enable
exit
interface gigabitethernet 1/0/2.2
ip address 192.168.2.1/24
vrrp 2
ip address 10.0.2.1/24
group 1
enable
exit
ip bfd min-rx-interval 800
ip bfd min-tx-interval 800
ip bfd multiplier 3
exit
interface gigabitethernet 1/0/2.3
ip address 192.168.3.1/24
vrrp 3
ip address 10.0.3.1/24
group 1
enable
exit
ip bfd min-rx-interval 800
ip bfd min-tx-interval 800
ip bfd multiplier 3
exit
interface gigabitethernet 2/0/2.2
ip address 192.168.2.2/24
vrrp 2
ip address 10.0.2.1/24
group 1
enable
exit
ip bfd min-rx-interval 800
ip bfd min-tx-interval 800
ip bfd multiplier 3
exit
interface gigabitethernet 2/0/2.3
ip address 192.168.3.2/24
vrrp 3
ip address 10.0.3.1/24
group 1
enable
exit
ip bfd min-rx-interval 800
ip bfd min-tx-interval 800
ip bfd multiplier 3
exit
Как видно, кластер в основном использует технологию VRRP, синхронизируя роль устройства на всех интерфейсах через механизм vrrp group. Благодаря этому, абсолютно весь входящий трафик приходит только на одно устройство. Т.е. режим работы – «активный-пассивный». Так что здесь YandexGPT скорее польстил – но тоже не угадал.
На МЭ режим «активный-активный» обычно поддерживается через контексты, полностью независимые в рамках одного устройства. В документации Eltex про реализацию контекстов пока ничего не написано, так что на режим «активный-активный» можно не рассчитывать.
Обращаю внимание на еще одну особенность ESR: VRRP адрес необязательно должен находиться в том же диапазоне, что и адреса интерфейсов. На самом деле, это не какое-то открытие – в документации вендора приведены именно такие настройки адресов в кластерной конфигурации. В общем, если адресов в нужном диапазоне ну совсем нет (например, /30), а резервирование нужно – у Элтекса есть решение. Главное – чтобы длина маски у VRRP адреса не была /32 (тогда не заведется).
Ну и прямое отличие от настройки «классических» маршрутизаторов: обычно маршрутизатор не дает настроить на паре интерфейсов IP-адреса из одной подсети. Здесь же – без проблем.
Полезная диагностика (куда же без нее)
(Cluster: Yes | Unit: 1 | State: Active | VRRP id 1: Master)|R0# sh vrrp
Unit 1* ‘R0’
————
VRID Virtual IP Priority Preemption State Inherit Group ID
—- ——————————— ——— ———- —— ——- ———
1 192.168.1.1/24 150 Enabled Master — 1
2 10.0.2.1/24 100 Enabled Master — 1
3 10.0.3.1/24 100 Enabled Master — 1
Unit 2 ‘R1’
————
VRID Virtual IP Priority Preemption State Inherit Group ID
—- ——————————— ——— ———- —— ——- ———
1 192.168.1.1/24 100 Enabled Backup — 1
2 10.0.2.1/24 100 Enabled Backup — 1
3 10.0.3.1/24 100 Enabled Backup — 1
(Cluster: Yes | Unit: 1 | State: Active | VRRP id 1: Master)|R0#
(Cluster: Yes | Unit: 1 | State: Active | VRRP id 1: Master)|R0# sh bfd nei
Neighbor Discriminator State Interface
————————————— ————- ——— —————-
10.0.3.3 2499551714 Up vrrp 3
10.0.2.2 1609432860 Up vrrp 2
(Cluster: Yes | Unit: 1 | State: Active | VRRP id 1: Master)|R0#
(Cluster: Yes | Unit: 1 | State: Active | VRRP id 1: Master)|R0# sh bgp ipv4 uni
Status codes: u — unicast, b — broadcast, m — multicast, a — anycast
* — valid, > — best
Origin codes: i — IGP, e — EGP, ? — incomplete
Network Next Hop Metric LocPrf Weight Path
*> u 3.3.3.3/32 10.0.3.3 — 100 0 65003 i
*> u 2.2.2.2/32 10.0.2.2 — 100 0 65002 i
(Cluster: Yes | Unit: 1 | State: Active | VRRP id 1: Master)|R0#
Вот теперь мы попингуем
Перед проверкой рекомендуется перезагрузить узлы кластера.
Почему-то сразу после настройки времена переключения могут доходить до 15-20 секунд, а после перезагрузки все переходит к более приемлемым и стабильным значениям.
Далее можно просто попинговать, деактивируя и активируя порт Gi1/0/2 на устройстве R0 (удобно делать встроенными средствами GNS3). Получилось следующее:
R2# ping 3.3.3.3 sou ip 2.2.2.2 pack 100
PING 3.3.3.3 (3.3.3.3) from 2.2.2.2 : 56 bytes of data.
!!!!........!!!!!!!!!!!........!!!!!!!!!!!!!!........!!!!!!!!!!!........!!!!!!!!!!!!........!!!!!!!!
Поскольку маршрутизаторы ESR четко выдерживают секундные интервалы между пакетами ICMP, времена недоступности можно оценить по числу точек. Видно, что как в случае переключения на резервный узел, так и при возвращении на основной, время недоступности составляет примерно 8 секунд.
Много это или мало? И чем это вообще вызвано?
Можно предположить, что на время переключения влияют как минимум 4 технологии:
-
VRRP – это вообще основная технология, на которой строятся кластера Eltex ESR. Предположу, что именно переход интерфейса резервного узла в состояние VRRP Master является сигналом для кластера, что «что-то пошло не так». Здесь типичное время между VRRP пакетами 1 сек, и я не нашел в документации возможности тюнинга этого значения (в отличии от Huawei, где это значение может быть даже 100 мс).
-
Собственно кластер – нужно корректно отработать инфу о сбоях, изменить состояние кластерного VRRP, и через vrrp group распространить на все VRRP-пары интерфейсов
-
BFD – нужно не только обнаружить пропадание связности, но и установить новый BFD сеанс с кластерного адреса
-
BGP – после смены активного устройства нужно переустановить BGP сеансы с соседями, причем только после переключения VRRP и установления сеансов BFD
И, поскольку они срабатывают последовательно друг за другом, 8 секунд кажутся вполне объяснимыми.
Для поставщиков телекоммуникационных услуг 8 секунд должно быть очень медленно – там, если верить легендам, «золотым стандартом» считается переключение за 50 мс. Впрочем, на магистральных устройствах Eltex семейства МЕ технология кластер и не реализована (как минимум, сейчас).
С другой стороны, в случае стека вообще происходит перезагрузка устройств, что не меньше 30 секунд. Так что на этом фоне 8 секунд кажутся очень даже приемлемой величиной. Опять же, это показатели для виртуального ESR – вполне вероятно, что для «железного» устройства это время можно снизить (например, поставить минимальный интервал для пакетов BFD в 300 мс – на виртуальном стенде делать этого не стал).
Справедливости ради
… как минимум на vESR обнаружил одну странную особенность: если помимо кластеров еще и VRF настроить, причем внутри VRF запускать BGP+BFD, ловил такую ситуацию: не устанавливалась сессия BGP. Анализ в wireshark показал, что после пакетов SYN и SYN,ACK прилетает RESET. При более внимательном изучении обнаружил отсутствие BFD (спасибо фильтрам). Причем ситуация могла длиться часами после включения/перезагрузки, могла возникать при переключении с активного узла на резервный и т.п. И если планируется демонстрация решения – то это полный провал.
Причина реально оказалась в отсутствии BFD, вследствие чего BGP включал «режим паники», немедленно «сбрасывал» сеанс и начинал искать альтернативные маршруты. Отсюда и RESET.
«Разбудить» BFD удавалось следующим образом:
-
Определяем (например, через wireshark), с каких узлов нет BFD
-
Командой sh bfd nei на таком узле определяем, с каким соседом отсутствует связность BFD
-
Далее, выполняем команду sh bfd nei Х.Х.Х.Х (IP адрес этого соседа). Она выполняется с заметной задержкой, но после этого BFD появляется.
Во время демонстрации можно артистично сделать вид, что вы показываете аудитории текущие значения BFD на примере конкретного соседа, хотя по-факту – спасаете свое маленькое шоу.
Понятно, что практического смысла создавать VRF на vESR нет, ибо ничто не мешает просто запустить нужное число экземпляров. А этот глюк проявлялся только в сочетании VRF и кластера; в кластере без VRF или на VRF без кластера проблем с BFD не возникало.
Немного анализа и выводов
Кластер на Eltex ESR – не очень известная фича, и даже YandexGPT почти нигде не угадал.
Но я смотрел в сторону кластера не совсем из праздного интереса. Одно из замечаний к некоторому решению было «а почему так много сессий BGP нужно настраивать»? Понятно, что при работе маршрутизаторов в режиме «активный-активный», каждый линк должен использоваться и как-то контролироваться – поэтому на них настраивалась стандартная связка BGP+BFD (поскольку часто линки идут через коммутаторы, не все сбои удастся обнаруживать по пропаданию «несущей»).
Использование кластерной технологии должно было явно снизить примерно вдвое число активных узлов. И, поскольку число связей пропорционально n(n-1)/2, ожидалось снижение числа связей примерно в 4 раза (на самом деле, даже чуть больше). С пропорциональным снижением числа сеансов BGP.
Дополнительные плюсы: поддержка stateful сервисов (см. в начале статьи), плюс возможность резервирования оборудования без расширения диапазонов адресов на стыках (или перенумерации).
В сущности, на этом весь позитив заканчивается: чем больше устройств в кластере, тем больше у них физических портов, которые надо приземлять в порты коммутаторов (ибо везде используется VRRP). При этом все устройства в кластере (кроме активного) будут в состоянии пассивных наблюдателей, поэтому роста производительности и распределения трафика по нескольким устройствам не произойдет – ибо VRRP.
Таким образом, с учетом кратно большего времени переключения по сравнению с работой маршрутизаторов в традиционном режиме, в текущем виде кластер может применяться либо от лени (снизить объем настроек протоколов, пропорциональных числу стыков), либо от безысходности (резервирование stateful сервисов или при нехватке IP-адресов на стыках). В общем, это достаточно нишевое решение – тем не менее, решающее нужные задачи.
С другой стороны, даже при всех ограничениях, наличие функционала кластера на ESR – несомненный плюс, ибо нередко именно дополнительная степень свободы при выборе или внедрении варианта решения отделяет заслуженный успех от обидной неудачи.
ссылка на оригинал статьи https://habr.com/ru/articles/1049422/