Краткая инструкция, как автоматизировать переключение сетевого маршрута при проблемах с одним из звеньев.
Дальше спрашиваю под катом 
Легенда — есть два сайта, соединенные транспортом L2 через двух разных провайдеров.
Необходимо обеспечить связь между сетями через ISP1 (основной маршрут).
В случае проблем с ISP1 автоматически переключайтесь на ISP2. Устройства - Juniper SRX. Для простейшей реализации этой задачи достаточно прописать на FW1 статический маршрут в сеть 192.168.2.0 через 10.0.0.2 с меньшей метрикой и через 10.0.0.6 с более высокой.
В FW2 все наоборот. Но этот метод сработает только в случае сбоя интерфейса в сторону одного из провайдеров, что на практике случается очень редко, поэтому контролировать состояние канала нужно другим способом.
У Juniper есть для этого сервис RPM (мониторинг производительности в реальном времени) .
Вот что я хочу рассказать о его использовании в данном сценарии.
На FW1 у нас есть обычная статическая запись (на FW2 она зеркалируется через 10.0.0.1):
В таблице маршрутизации видим такую запись:set routing-options static route 192.168.2.0/24 next-hop 10.0.0.2
show route 192.168.2.0/24
192.168.2.0/24 *[Static/5] 1d 07:20:14
> to 10.0.0.2 via reth1.1
Настраиваем службу RPM для управления основным соединением.
Отправляем пинги на адрес 10.0.0.2 по 10 штук на тест с интервалом 5 секунд (probe-интервал 5).
Интервал между тестами тоже 5 секунд, т.е.
у нас фактически непрерывный пинг каждые 5 секунд. Если в ходе теста мы теряем 5 пингов подряд, тест считается проваленным.
set services rpm probe SLA_LAN2 test CHECK_PRIMARY_FW2 target address 10.0.0.2
set services rpm probe SLA_LAN2 test CHECK_PRIMARY_FW2 probe-count 10
set services rpm probe SLA_LAN2 test CHECK_PRIMARY_FW2 probe-interval 5
set services rpm probe SLA_LAN2 test CHECK_PRIMARY_FW2 test-interval 5
set services rpm probe SLA_LAN2 test CHECK_PRIMARY_FW2 thresholds successive-loss 5
Настройка реакции на тест. Если тест не пройден, добавьте маршрут через ISP2. set services ip-monitoring policy LAN2_FAILOVER match rpm-probe SLA_LAN2
set services ip-monitoring policy LAN2_FAILOVER then preferred-route route 192.168.2.0/24 next-hop 10.0.0.6
Мы проверяем: show services ip-monitoring status
Policy - LAN2_FAILOVER (Status: PASS)
RPM Probes:
Probe name Test Name Address Status
------------------ --------------- ---------- ---------
SLA_LAN2 CHECK_PRIMARY_FW2 10.0.0.2 PASS
Route-Action:
route-instance route next-hop state
----------------- ----------------- ---------------- -------------
inet.0 192.168.2.0/24 10.0.0.6 NOT-APPLIED
На FW2 вам необходимо настроить конфигурацию зеркала: set services rpm probe SLA_LAN1 test CHECK_PRIMARY_FW1 target address 10.0.0.1
set services rpm probe SLA_LAN1 test CHECK_PRIMARY_FW1 probe-count 10
set services rpm probe SLA_LAN1 test CHECK_PRIMARY_FW1 probe-interval 5
set services rpm probe SLA_LAN1 test CHECK_PRIMARY_FW1 test-interval 5
set services rpm probe SLA_LAN1 test CHECK_PRIMARY_FW1 thresholds successive-loss 5
set services ip-monitoring policy LAN1_FAILOVER match rpm-probe SLA_LAN1
set services ip-monitoring policy LAN1_FAILOVER then preferred-route route 192.168.1.0/24 next-hop 10.0.0.5
Вы можете проверить это, отключив один из интерфейсов (vlan от транка к FW), чтобы канал оставался физически активным.
Мы теряем около 6 пингов от LAN1 к LAN2 примерно через 30 секунд. На FW1 мы видим следующее: show services ip-monitoring status
Policy - LAN2_FAILOVER (Status: FAIL)
RPM Probes:
Probe name Test Name Address Status
------------------ --------------- ---------- ---------
SLA_LAN2 CHECK_PRIMARY_FW2 10.0.0.2 FAIL
Route-Action:
route-instance route next-hop state
----------------- ----------------- ---------------- -------------
inet.0 192.168.2.0/24 10.0.0.6 APPLIED
Видим новую запись в таблице маршрутизации: 192.168.2.0/24 *[Static/1] 00:01:24, metric2 0
> to 10.0.0.6 via reth1.2
[Static/5] 1d 07:30:26
> to 10.0.0.2 via reth1.1
Когда соединение через ISP1 восстанавливается, тест возвращается в состояние PASS и удаляет запись из таблицы маршрутизации.
Обратите внимание, что конфигурация должна быть зеркальной для обоих устройств.
Если статических маршрутов несколько, их можно дополнить новыми строками.
Также может быть несколько условий; это довольно гибкий метод. Спасибо всем, надеюсь, это сэкономит кому-то время.
Теги: #Сетевые технологии #Системное администрирование #juniper #juniper #route Failover
-
Я Меняю Свой Стек С Понедельника
19 Oct, 24 -
Разработка Архитектуры Для Чайников. Часть 3
19 Oct, 24 -
Таблицы Данных В Адаптивном Дизайне
19 Oct, 24
