BGP Multihoming на Cisco 1841: два провайдера без downtime при переключении

Несколько месяцев назад крупный клиент поставил задачу, которую раньше мы решали статической маршрутизацией и молитвой: истинное резервирование двух интернет-провайдеров без ручного вмешательства при переключении. Клиент - производственная компания с распределёнными площадками, онлайн-доступ к ERP-системе. Час простоя стоит деньги, не абстрактные.

До этого момента типичная схема у таких клиентов выглядела так: основной канал через ISP-A, резервный через ISP-B, два дефолтных маршрута с разным метриком, скрипт на cron, который пингует 8.8.8.8 и при потере меняет routing table. Это работает. Грубо, но работает - пока не начнёшь разбираться в деталях. Переключение занимает от 30 секунд до нескольких минут в зависимости от интервала cron. Входящий трафик при этом не переключается никак - для внешнего мира адрес клиента принадлежит ISP-A, и если ISP-A лежит, входящие соединения просто падают. Клиент, у которого партнёры подключаются к его ERP извне, это ощущает.

Решение - BGP Multihoming. Получить собственный AS-номер, анонсировать свой IP-префикс через двух провайдеров одновременно. Интернет знает два пути до клиента, и при падении одного переходит на второй по механизмам BGP без всяких cron-скриптов.

Что потребовалось для старта

Раньше это был разговор для крупных компаний: нужен PI-адресный блок (/24 минимум для нормальной маршрутизируемости), AS-номер в RIPE, два провайдера с готовностью поднять BGP-сессию. Всё это реально и для среднего бизнеса, если знать, как оформить. Клиент получил AS-номер и /24-блок через RIPE - процедура небыстрая, около месяца, но однократная.

Оба ISP согласились на BGP-пиринг без экзотических требований. Один уже работал с клиентом, второго подключили параллельно именно под эту задачу.

На оборудовании решили не раздувать бюджет. Cisco 1841 с IOS 12.4 - это не флагман, но BGP он тянет без проблем при нашем объёме маршрутов. Два WAN-порта, нормальная таблица маршрутизации, команды bgp neighbour - всё есть.

Конфигурация BGP на 1841

Схема простая: роутер устанавливает две eBGP-сессии, с ISP-A и ISP-B. От каждого получает дефолтный маршрут (или полную таблицу, но это нам не нужно - взяли только default). В обратную сторону анонсирует /24-блок клиента через обоих провайдеров.

Ключевые параметры, которые пришлось выставить руками:

• Таймеры BGP. По умолчанию keepalive 60 секунд, hold time 180. При падении сессии детект занимает до трёх минут. Выставили keepalive 10 / hold 30 - компромисс между нагрузкой на CPU и скоростью обнаружения. Оба ISP согласились на такие таймеры на своей стороне.

• Local preference. Один провайдер основной, второй резервный. Через local-preference задаём предпочтение: исходящий трафик в нормальном режиме идёт через ISP-A. При падении - автоматически через ISP-B.

• Prefix-list на анонс. Роутер анонсирует строго свой /24 и ничего лишнего. Фильтр на обе сессии, чтобы случайно не стать транзитным узлом для чужого трафика.

• BFD не использовали - на IOS 12.4 для 1841 поддержка ограничена, и оба ISP не были готовы к BFD на своей стороне. Поэтому скорость детекта определяется только BGP-таймерами.

Что показало тестирование

Тестировали переключение тремя способами: shutdown WAN-интерфейса на роутере, отключение кабеля физически, и просьба к ISP-A временно прибить BGP-сессию на своей стороне.

При shutdown интерфейса BGP-сессия падает мгновенно, роутер убирает маршруты ISP-A и переключается на ISP-B. Время - секунды, субъективно незаметно.

При физическом отключении кабеля интерфейс падает тоже быстро, картина схожая.

При «тихом» падении сессии (ISP имитировал недоступность без явного down на интерфейсе) роутер обнаружил проблему за hold time - то есть за 30 секунд. Переключение после этого - мгновенное. Итого клиент видел прерывание около 30-35 секунд, что несравнимо лучше предыдущей схемы на cron.

Входящий трафик переключился корректно - внешние BGP-маршрутизаторы убрали маршрут через ISP-A и начали направлять пакеты через ISP-B. Это и есть принципиальное отличие от старой схемы со статикой: не только исходящий, но и входящий трафик резервируется.

Что не идеально

Честно: 30 секунд при hold time 30 - это не sub-second failover. Если бы ISP поддерживали BFD, можно было бы уйти в диапазон 1-3 секунды. Но ISP не поддерживают, а агрессивно уменьшать BGP-таймеры ниже 10/30 на 1841 мы не рискнули - CPU-нагрузка от keepalive-обмена на слабом железе начинает складываться.

Для этого клиента 30 секунд - приемлемо. Для кого-то нет. Если нужно быстрее - либо железо с поддержкой BFD, либо другой подход.

Второй момент - сложность. Конфиг BGP длиннее и требует понимания. Администратор, который раньше правил два ip route в конфиге, теперь имеет дело с BGP-атрибутами, prefix-list, route-map. Это нормально, но нужно учитывать при передаче сопровождения.

Итог

Задача решена: два канала, истинное резервирование входящего и исходящего трафика, автоматическое переключение без скриптов. Клиент получил то, что просил, на обычном офисном роутере без экзотического оборудования.

Это часть того, чем мы занимаемся в рамках сопровождения инфраструктуры: не только поддерживать то, что есть, но и перестраивать схемы, когда старое перестаёт соответствовать требованиям. Иногда правильное решение - не ещё один скрипт поверх старой схемы, а другая архитектура.