Любой удачный экспромт должен быть тщательно подготовлен. Поэтому, основная (по моему скромному мнению) ценность получения виртуального маршрутизатора (не только vESR) заключается в возможности запускать или отключать его в любых количествах «здесь и сейчас». Благодаря этому, можно:
Изучать какие-то новые сетевые технологии (применительно к Элтексу, может звучать странновато – но, к примеру, технология cluster не является типовой для маршрутизаторов других производителей);
Моделировать какие-то концептуальные варианты для систем, требующих заметного функционала на уровне сетевого оборудования (как правило, по управлению и перенаправлению потоков трафика);
Иметь дополнительные доводы в спорах с критически настроенными коллегами (точнее, у таких коллег уже не будет возражений типа «на Сиско-то все будет работать, а вендор Х точно это поддерживает?»);
Моделировать конкретные сценарии построения или модернизации сетевой инфраструктуры, в том числе с учетом каких-то технологических или функциональных ограничений сетевых устройств конкретного производителя;
По результатам моделирования, заблаговременно иметь версии файлов конфигураций (в том числе заранее обнаружить изменение синтаксиса команд – весьма актуально при работе с Элтексом), пригодные для внедрения на реальном оборудовании (может быть, с минимальной адаптацией);
В каких-то особых сценариях – даже замахнуться на применение в продуктивной среде.
Понятно, что для этого виртуальные маршрутизаторы нужно сначала запустить в какой-то среде, и хорошо бы иметь в этой среде дополнительные сервисы – например, Wireshark с возможностью захвата пакетов на конкретном соединении (очень полезно, особенно при начале работы с vESR). Этой цели служат симуляторы сетей, причем точно совместимых с vESR не менее 3 (EVE-NG, GNS3 и PNETLab). И именно подобные симуляторы дают возможность моделировать «здесь и сейчас», не тратя месяцы на ожидание аппаратного стенда или дни на создание виртуальной топологии (как на заре использование Cisco IOU). Поэтому также добавим пункт «0» - «Установка в симулятор GNS3» и связанные с этим тонкости и сложности.
0.0 Установка в симулятор GNS3
На самом деле, в документации на vESR 1.37 (а здесь будет рассматриваться именно он) явно описаны процедуры установки для следующих сред виртуализации и симуляторов: VirtualBox, VMware ESXi, QEMU/KVM, Proxmox, GNS3, EVE-NG, PNETLab и Xen. Для этого сам же производитель предоставляет файлы в различных форматах: .iso, .qcow2, .vdi и vmdk. В общем, с одной стороны, есть из чего выбрать.
С другой стороны, лично мой персональный выбор – GNS3. «Не является инвестиционной рекомендацией», как говорится. А «Почему?» - описано здесь. Кстати, ограничение из документации «версия GNS3 должна быть не ниже 2.2.53» избыточно – лично у меня версия 2.2.46, на которой все отлично работает.
Вне зависимости от среды виртуализации, при копировании настроек рекомендую пользоваться он-лайн документацией. Дело в том, что в случае с GNS3 для установки нужен шаблон устройства .gns3a, который описан в документации. Для EVE-NG понадобится файл .yml, который в документации также описан. В любом случае, набивать такие файлы руками «с нуля» никто в здравом уме не станет. Но при копирования из .pdf в моем случае случилась перестановка строк и потеря пары запятых – так что пришлось долго разбираться «почему не завелось».
Следующая засада (как минимум для GNS3) – устаревшая информация в файле шаблона (видимо, осталась от версии 1.34): заявленные размер и контрольная сумма не совпадают с фактическими параметрами файла .qcow2 версии 1.37. На практике, файл копируется на виртуалку и занимает место, но недоступен для использования.
Дабы избавить от уже пройденных мною граблей, привожу свой вариант шаблона (содержимое нужно сохранить в текстовом файле с расширением .gns3a и использовать при установке).
{ "appliance_id": "da593cf4-fdeb-4be4-9c1e-963263f9368f", "name": "vESR", "category": "router", "description": "virtual Eltex service router", "vendor_name": "Eltex", "vendor_url": "http://www.eltex-co.ru", "documentation_url": "https://docs.eltex-co.ru/pages/viewpage.action?pageId=52497571", "product_name": "vESR", "product_url": "https://eltex-co.ru/catalog/service_gateways/virtualnyy_servisnyy_marshrutizator_vesr/", "registry_version": 4, "status": "stable", "availability": "free-to-try", "maintainer": "Eltex", "maintainer_email": "", "usage": "Default credentials: admin/password\n\nUntil the standard password is changed, the device will not allow further configuration. To change the password, enter the command 'password <new password>', where the new password is the password that the user chooses and remembers.\n\nAfter changing the password, you need to accept the changes and save them with the command 'commit', and then additionally confirm your decision with the 'confirm' command.", "port_name_format": "Gi1/0/{port1}", "qemu": { "adapter_type": "e1000", "adapters": 8, "ram": 3072, "cpus": 1, "hda_disk_interface": "ide", "arch": "x86_64", "console_type": "telnet", "kvm": "require", "options": "-smp 1 -cpu host" }, "images": [ { "filename": "vesr-1.37.4-build2.qcow2", "version": "1.37.4-build2", "md5sum": "c1f16d15db275d188fbec3c1e13ebafc", "filesize": 293928960 } ], "versions": [ { "name": "1.37.4-build2", "images": { "hda_disk_image": "vesr-1.37.4-build2.qcow2" } } ] }
Помимо корректных значений размера и контрольной суммы, добавлен учет версий и еще пара параметров. Один из этих параметров - "options": "-smp 1 -cpu host" - оказался неожиданно важным. С ним стабильно удается запустить топологию, приведенную на рисунке ниже (23 vESR, загрузка с учетом протоколов OSPF и BGP), на виртуалке с параметрами 16 vCPU и 64GB RAM. Да, придется запускать частями по 4 устройства vESR – но совсем без этого параметра полностью запустить такую топологию не удалось ни разу.
И, забавное наблюдение: параметр cpu: 4 для EVE-NG и PNETLab намекает, что нужно выделять 4 vCPU – в 4 раза больше, чем для GNS3. Почему – не знаю. По ощущениям, на 1 vCPU в виртуальной среде GNS3, виртуальный ESR откликается чуть медленнее аппаратного ESR-30, но значительно бодрее аппаратного ESR-15.
0.1 Ограничения vESR «из коробки»
Основные ограничения vESR относятся к лицензионным требованиям (фактически – маркетинговым ограничениям, дабы не подрывать «коробочный» бизнес) и его виртуальной природе.
Без лицензии (демо-режим), vESR имеет следующие ограничения:
Два IPsec-туннеля;
Пропускная способность устройства 1 Мбит/c;
BGP RIB 1024;
OSPF RIB 1000;
RIP RIB 1000;
ISIS RIB 1000;
Отключена функция SLA.
Кроме того, в поставке идет комплект демо-лицензий, открывающий дополнительный функционал на устройстве и привязанный к серийному номеру VESR0000000. Данные лицензии пропадут при смене серийного номера:
WIFI-DEMO — лицензия с ограничением до 5 одновременно работающих точек доступа, с возможностью активации и отслеживания состояния SoftGRE-туннелей для работы WiFi-точек доступа.
BRAS-DEMO — лицензия с ограничением до 5 одновременно работающих абонентов, активирует функции авторизации/аутентификации/аккаунтинга пользователей, трафик которых маршрутизируется. Функциональность работает при наличии корректно настроенного RADIUS-сервера. ААА возможна по IP или MAC-адресу абонента.
IPS-DEMO — лицензия открывает доступ к командам настройки системы IDS/IPS с ограничением производительности (система IDS/IPS будет работать на одном ядре процессора).
На самом деле, пока единственным существенным лично для меня ограничением оказалось отсутствие SLA. При этом обнаружилась такая вот забавная вещь:
Для SLA в конфиге появляется явное уведомление об отключении (при вводе команд – никаких предупреждений или ограничений):
# no licence, inactive ip sla test 1 icmp-echo 1.1.1.1 source-ip 172.16.1.8 num-packets 1 exit
Для BGP в vrf, если задать максимальное число маршрутов больше 1024, то просто никаких полученных префиксов от BGP соседа (при том, что соседство устанавливается, а при вводе команд - никаких предупреждений или ограничений, как и комментариев в конфиге). Для числа маршрутов 1024 и меньше – все ОК.
# ip vrf TEST ip protocols bgp max-routes 2000 exit
А виртуальная природа vESR обусловила то, что «из коробки» у всех vESR одинаковый серийный номер и одинаковый системный MAC-адрес - VESR0000000 и A2:00:00:00:00:00 соответственно. При этом для работы L2 протоколов (например, LACP или LLDP) нужны уникальные системные MAC-адреса. В свою очередь, системный MAC-адрес определяется серийным номером – со сменой которого будут потеряны демо-лицензии на дополнительный функционал (WiFi, BRAS и IPS). В общем, «либо дудочка – либо кувшинчик». Тем не менее, после смены серийного номера, основной функционал полностью сохраняется в рамках лицензионных ограничений протоколов маршрутизации и отсутствия SLA.
1. Изучение новых технологий
Примерно год не доходили руки до «собрать кластер», поскольку:
по работе вроде как не требовалось, а
свободному времени всегда находилось более подходящее применение.
Плюс, с предыдущим доступным vESR (кажется, версии 1.18) общий язык найти не удалось (да и функционал у него показался сильно меньше, чем было описано в руководстве).
С этой точки зрения vESR версии 1.37 реально понравился. Тем более, производитель обещает идентичность функционала виртуальной и «материальной» версий (с точностью до лицензионных ограничений).
Для настройки кластера понадобилось сменить серийные номера, причем на всех узлах (для узлов с MAC-адресом A2:00:00:00:00:00 появляется уведомление о недоступности функционала кластера). Но в дальнейшем все настроилось строго по шагам из документации.
Как минимум в виртуальной среде, переключение на резервный узел кластера и обратно осуществлялось за 5-7 секунд (включая переустановление сеансов BGP). В целом, работа кластера оставила скорее положительное впечатление. Хотя определенно есть и пути для улучшения: снизить нижнюю границу интервала между пакетами VRRP (сейчас не менее 1 сек), функционал которого является основой работы кластера.
2, 3 и 4. Моделирование вариантов и споры с критически настроенными коллегами
Эти 3 пункта обычно тесно связаны, хотя и разнесены по времени:
либо сперва замысел и моделирование, потом споры и защита,
либо сперва замысел и споры, потом моделирование и защита
А причиной споров обычно являются сомнения в успехе вследствие каких-то ограничений, отсутствия функционала, несовместимости и т.п. И в отсутствии наглядной демонстрации (например, виртуального стенда), ситуация застревает на уровне «слово против слова» с подразумеваемой презумпцией виновности, что делает практически невозможным обойти аргумент «не верю» со стороны оппонентов.
В целом, функционал vESR оказался достаточно широким при моделировании решений для корпоративных сетей, поскольку поддержка Segment Routing или SRv6 не заявлены. Как уже упоминал, реально огорчило только отсутствие механизма SLA. Ну, и отсутствие виртуального коммутатора (пришлось использовать сисковские IOL L2).
Полнота и качество реализации заявленного функционала vESR приятно поразили: настроенное по мануалу, все работало как ожидалось. Как минимум, в рамках задач моделирования.
В части нейтрализации основного довода критиков – «не верю» – эффект также превзошел все ожидания: после 2 часов демонстрации и попыток в разных комбинациях обмануть протоколы маршрутизации и BFD (спойлер – они блестяще справились), критики сдались. До этого спорили больше месяца.
При взаимодействии со смежниками из ИБ изощренных издевательств над BGP не потребовалось: сама «православность» vESR сильно упростила получение их согласования.
5. Актуальные файлы конфигураций и изменение синтаксиса
С использованием vESR можно получить вполне качественные шаблоны файлов конфигураций с точностью до следующих показателей:
Обозначения портов (в ESR-15 все 6 портов – GigabitEthernet, тогда как у ESR-30 появляется пара TenGigabitEthernet, а у ESR-3200 – все 12 портов TwentyfiveGigabitEthernet.
Какие-то особенности работы и настроек именно аппаратных маршрутизаторов (например, настройка агрегации для портов 10 и 25 Гбит с подключением через DAC);
Специфичное для версии изменение синтаксиса команд.
Так уж получилось, что именно в версии 1.37 был изменен синтаксис в части настройки VRRP. На самом деле, синтаксис стал более логичным – но сам факт «изменения ради изменения» (без добавления каких-то «ништяков») слегка огорчил. И да, это изменение было сразу же обнаружено – когда при применении конфигурации «в старом стиле» посыпались сообщения об ошибках в командах.
Также (чуть позже) были обнаружены и вполне ценные фичи – например, именно с версии 1.37 маршрутизатор получил функционал сервера NTPv4. Также ZBF теперь можно отключить одной командой «ip firewall disable» в режиме глобальной конфигурации (и не нужно ее вводить для каждого интерфейса).
Вообще, полный список изменений можно найти в документе «ESR-Series_Release_notes_1.37». И именно в случае Элтекса рекомендуется хотя бы по диагонали первый пяток страниц просматривать.
А по ощущениям, применение vESR на ранних стадиях сильно упростило переход к «настоящим» маршрутизаторам.
6. Применение в продуктивной среде
Как бы это крамольно не прозвучало, но даже эту фантастическую (с учетом жестких ограничений демо-режима) опцию теоретически можно реализовать, используя vESR как Trigger Router в сценарии Remotely triggered black hole (RTBH).
Особой производительности там не потребуется, а лимит в 1000 блокированных адресов – это уровень очень крупного объекта. Тем более, что всегда рядом можно развернуть второй Trigger Router, третий и так далее (не забывая фильтровать маршруты, чтобы не превысить ограничения).
Заключение
В этой статье я поделился своим первым удачным опытом применения vESR (предыдущая попытка прошла менее продуктивно). Также описал возможные сценарии его применения, сложности при установке vESR в симуляторе GNS3 по инструкции производителя, и адаптированный файл шаблона .gns3a.
По моему личному ощущению, одним из фактором успеха в этой попытке явилось стремление производителя к поддержке разных сред виртуализации и предоставление «из коробки» файлов в нескольких форматах.
При освоении vESR 1.37 рекомендую первым делом отключать ZBF командой «ip firewall disable» в режиме глобальной конфигурации (потом всегда можно будет вернуть).
И да, официальный виртуальный коммутатор тоже не помешал бы.
