GetNet

Достаточно часто в малом бизнесе картина выглядит так: никакого резервирования нет вообще. Один провайдер. VPN подключается к внешнему IP-адресу. Сервер стоит в офисе. Коммутация — без резервирования. Примерное время простоя при аварии — около суток.

Даже такой набор мер сокращает время простоя примерно до полудня — пока доехали, пока разобрались, пока расчехлили резервный маршрутизатор.

Механизмы делятся на два класса: active/backup, когда всегда работает один оператор, и схемы с двумя постоянно активными подключениями.

При одном маршрутизаторе доступны следующие варианты:

ECMP и его спецэффекты

ECMP — это схема active/active. Если прямого стыка с операторами связи нет, в полный рост встают проблемы с NAT: на части сервисов периодически меняются внешние IP-адреса. Балансировку между двумя внешними каналами следует применять с большой осторожностью: стоит протестировать, как ведёт себя IP-телефония, банковские приложения и прочие чувствительные сервисы. Для торрентов схема великолепна, но в корпоративной сети это вряд ли актуальный сценарий.

Не стоит делать минимальную скорость на резерве. Показательный случай из практики: у клиента корректный BGP-стык, всё как положено. Падает основной оператор — потери около 60 %. Выясняется, что на основном канале полтора гигабита, а на резервном — 50 мегабит, «потому что экономим». Два часа ушло на звонки оператору, чтобы расширить резервный линк.

При двух операторах гораздо гибче не ECMP, а policy routing. Да, его не любят и считают костылём, но он позволяет гораздо более гранулярно управлять тем, какой трафик в какого оператора уходит.

Идеальные условия

По возможности стоит требовать статические IP-адреса без DHCP и без VPN-клиентов от операторов связи: это лишний оверхед. При DHCP или статическом адресе железка показывает производительность, близкую к заявленной в даташите; VPN-клиент от оператора даёт падение производительности примерно вдвое.

При нормально настроенном policy routing корректно работают пробросы портов — их придётся продублировать, если есть публикация сервисов. Дополнительный маршрутизатор от оператора в филиалах лучше переводить в режим моста либо избегать вовсе.

Простейшая схема — VRRP плюс два канала в разных маршрутизаторах. Активность провайдера проверяется, при отказе VRRP на соответствующем узле выключается, мастер переходит на соседа. Базово всё работает из коробки, без сложных схем с policy routing.

Для балансировки схема заметно усложняется: ECMP, policy routing, передача трафика между маршрутизаторами, вопросы connection tracking и stateful firewall, обработка invalid-пакетов (raw-таблица, notrack и т. д.). Те же вопросы возникают и при BGP на двух маршрутизаторах: при полноценном stateful firewall придётся разрешать пакеты, возвращающиеся не на основной маршрутизатор.

Если сервисы опубликованы на адресах оператора, при его падении они станут недоступны. Входящий трафик резервируется через DNS. При серьёзном дисбалансе каналов (например, гигабит и 50 мегабит) внесение нескольких A-записей даст негативный эффект: DNS работает по round-robin, и каждый второй клиент попадёт на канал, где скорости не хватит. Выход — скрипты, обращающиеся к API DNS-провайдера и вносящие изменения при падении основного оператора. Схема стандартная, и российские DNS-операторы — Яндекс, RU-CENTER и другие — её вполне поддерживают.

Если нужен трафик между VLAN на максимальной скорости, от VRRP приходится отказываться сразу — это частый кейс. Взамен используется проверка доступности соседа плюс скрипт включения IP-адресов. Нюанс IPv4 — локальные ARP-таблицы клиентов: они какое-то время остаются необновлёнными, и время сходимости зависит от каждого клиента. Классический симптом: после возврата основного канала трафик по-прежнему идёт через резервный маршрутизатор, потому что в ARP-таблице клиента остался его MAC-адрес. Решается отправкой gratuitous ARP через генератор трафика; готовые скрипты, которые сами вытаскивают MAC-адреса из интерфейсов, уже существуют.

Если трафик приходит на резервный маршрутизатор со вторым каналом снаружи, простейший способ довести его до локальной сети — source NAT в её сторону, без policy routing. Если требуется видеть исходные внешние адреса, придётся строить policy routing между своими же маршрутизаторами, рассматривая второй маршрутизатор как внешний канал.

Схема, которую операторы связи любят, поскольку она позволяет продать больше. Тем не менее она даёт лучшую работу сети при отказах. VRRP-интерфейсы можно поставить как в сторону операторов, так и вниз, в сторону абонентов. В сторону оператора для безопасности имеет смысл настроить аутентификацию VRRP-группы, чтобы VRRP-пакеты не передавались между маршрутизаторами в сети оператора и схема «не светилась». У оператора потребуется взять минимум сеть /29. Для схем active/active на каждом маршрутизаторе понадобится policy routing — сложнее и трудозатратнее, но результат интереснее.

Для сохранения аппаратной маршрутизации (старшие маршрутизаторы, часть коммутаторов в роли маршрутизаторов) от VRRP отказываются. Взамен появляется возможность использовать аппаратную маршрутизацию в том числе в сторону оператора, причём вместе с NAT: аппаратный FastTrack позволяет сохранить stateful firewall и NAT. Из минусов — интерфейсы операторов придётся добавить в общий мост, настроить соответствующие VLAN и обезопасить L2 со стороны оператора (BPDU Guard, edge-порты и прочее). Взамен — производительность, близкая к скорости интерфейса.

Главный инструмент — снова DNS. VPN должен подключаться по имени; несколько записей в глобальном DNS прекрасно работают как с классическими, так и с вендорскими решениями.

В OpenVPN можно указать несколько серверов, которые перебираются по round-robin. Известны реализации, доработавшие этот механизм через SRV-записи: клиент получает весь пул VPN-серверов и знает, куда подключаться в конкретный момент. Из бесплатных вариантов под Windows — CMAK: специализированный пакет, позволяющий собрать VPN-подключение с несколькими серверами и перебором по round-robin.

При серьёзном дисбалансе каналов без скриптов через API DNS-провайдера не обойтись.

По большому счёту удалённый офис — такой же клиент remote access. Если допустима вероятность того, что VPN просто оборвётся и переподключится в момент проблемы у основного оператора, достаточно классической схемы с DNS и несколькими A-записями.
Более сложный вариант:

Частая операторская схема — кольцо коммутаторов: гирлянда, замкнутая ещё одним линком снизу. Резервирование обеспечивается протоколами семейства STP. Экономически выгодно, но коммутация часто неоптимальна, а в STP нужно разобраться на 100 %: расставить приоритеты на корневом мосте и желательно на линках, чтобы топология собиралась предсказуемо. Диагностировать и управлять этим сложно. Главный минус: пропускная способность всей коммутации фактически сводится к скорости одного верхнего линка, и современные коммутаторы отдают лишь малую часть своих возможностей.

Классическая двух-трёхуровневая модель никуда не делась, и Collapsed Core великолепно себя показывает. При небольшом трафике «запад — восток» между пользовательскими VLAN их можно дотащить прямо до маршрутизатора. На старших маршрутизаторах включается аппаратная маршрутизация, скорости достигают 10 Гбит/с и более. Управление доступом и межсетевым экранированием удобно, поскольку всё концентрируется на верхнем маршрутизаторе. STP при этом сохраняется — он поддерживает резервные линки и обеспечивает отказоустойчивость. На клиентских портах включаются edge-режим (аналог fast forward), BPDU Guard и прочие защиты. Межкоммутаторные линки в 2026 году разумно строить на десяти гигабитах.

Если дефицита скорости между коммутаторами нет, лишние приключения не нужны. MSTP сложнее сам по себе: нужно разделять два и более дерева, продумывать балансировку VLAN между ними. Сложнее и с совместимостью: если проблемы совместимости встречаются даже в RSTP, то в MSTP их гарантированно больше, несмотря на обратную совместимость. При отказе от моновендорной схемы и при импортозамещении стоит готовиться к сюрпризам.

MLAG — технология любопытная, но способна неожиданно «отстрелить» трафик: встречаются потери в 50 % на одном из верхних линков. Прежде чем внедрять, её нужно очень чётко оттестировать: подёргать провода между MLAG-парой, поотключать и повозвращать питание разными способами, посмотреть, всё ли отработает корректно. И, разумеется, придётся внимательно читать changelog прошивок.

Если трафика между коммутаторами доступа становится много или в офисе появляется серверная ферма, а маршрутизатор такой объём уже не вывозит (в том числе просто по количеству и ёмкости интерфейсов — чип мощный, но физически порты не помещаются), маршрутизацию приходится опускать на уровень ниже: на ядро или ещё ниже.

Рассматриваются только решения с аппаратной маршрутизацией. VLAN терминируются на агрегации или на ядре. Отказ шлюза решается скриптами с Netwatch и оповещением ARP. MLAG и VRRP с аппаратной маршрутизацией несовместимы.

Для самых сильных инженеров есть вариант опустить L3 прямо до коммутатора доступа и терминировать VLAN на нём. Поддержки IP unnumbered в этом случае нет, поэтому сети придётся дробить на мелкие сегменты средствами VLSM — по небольшому сегменту на каждый коммутатор доступа. Бонус: между коммутаторами можно собирать ECMP-пары, использовать динамическую маршрутизацию — OSPF или BGP — и получить суммирование скорости без характерных для MLAG рисков. По сути, это подход IP-фабрики. Из нюансов — DHCP relay на L3-коммутаторах и общий рост стека технологий: чем больше трафика, тем больше придётся освоить.

Если сервер не утилизирует один интерфейс целиком, не стоит выдумывать себе приключения. Раскладка хешей, MLAG и подобные механизмы зачастую провоцируют аварии, а не отказоустойчивость. Классическая история: «зарезервировались так, что в итоге упали» — настроили сложную схему, она обрушилась, и полдня ушло на выяснение причин.

При разрастании инфраструктуры складывается базовая сводная схема: резервирование серверов, резервирование клиентов на уровне «отказал один коммутатор — пользователи на других продолжают работать», плюс ЗИП на пользовательские устройства. Если отдельный пользователь генерирует выручку сопоставимо с сервером, его есть смысл резервировать двумя линками. Но это уже вопрос денег и того, что проект может себе позволить.