Небольшая инструкция про то, как автоматизировать переключение сетевого маршрута в случае проблем с одним из линков. Дальше прошу под кат
Легенда — есть две площадки, связанных по L2 транспорту через двух разных провайдеров. Нужно обеспечить связность между сетями через ISP1 (первичный маршрут). В случае проблем с ISP1 автоматически переключиться на ISP2.
Устройства — Juniper SRX.
Для простейшей реализация этой задачи достаточно на FW1 прописать статический маршрут в сеть 192.168.2.0 через 10.0.0.2 c меньшей метрикой и через 10.0.0.6 с большей. На FW2 наоборот. Но работать этот метод будет только при падении интерфейса в сторону одного из провайдеров, что на практике бывает очень редко, поэтому нужно контролировать состояние канала другим способом.
Для этого в Juniper есть сервис RPM (Real-Time Performance Monitoring). Вот о его использовании в этом сценарии я и хочу рассказать.
На FW1 у нас есть обычная статическая запись (на FW2 зеркальная через 10.0.0.1):
В таблице маршрутизации видим эту запись:
Настраиваем сервис RPM для контроля первичного соединения. Отправляем пинг на адрес 10.0.0.2 по 10 штук на тест с интервалом 5 сек (probe-interval 5). Интервал между тестами тоже 5 сек, т.е. у нас фактически идет непрерывный пинг каждые 5 сек. Если в течение теста мы потеряли 5 пингов подряд, тест считается проваленным.
Настраиваем реакцию на тест. В случае, если тест провален, добавляем маршрут через ISP2
Проверяем:
На FW2 надо настроить зеркальную конфигурацию:
Можно тестировать, отключаем один из интерфейсов (vlan из транка в сторону FW), чтобы физически линк остался живым. Теряем около 6 пингов из LAN1 в LAN2, примерно через 30 сек. видим на FW1 следующее:
В таблице маршрутизации видим новую запись:
При восстановлении соединения через ISP1 тест снова переходит в состояние PASS и убирает запись из таблицы маршрутизации.
Обращаю внимание, что конфигурация должна быть зеркальной для обоих устройств.
Если статических маршрутов несколько, их можно добавлять новыми строками then. Условий также может быть несколько, это достаточно гибкий метод.
Всем спасибо, надеюсь, это сэкономит кому-то время.
Легенда — есть две площадки, связанных по L2 транспорту через двух разных провайдеров. Нужно обеспечить связность между сетями через ISP1 (первичный маршрут). В случае проблем с ISP1 автоматически переключиться на ISP2.
Устройства — Juniper SRX.
Для простейшей реализация этой задачи достаточно на FW1 прописать статический маршрут в сеть 192.168.2.0 через 10.0.0.2 c меньшей метрикой и через 10.0.0.6 с большей. На FW2 наоборот. Но работать этот метод будет только при падении интерфейса в сторону одного из провайдеров, что на практике бывает очень редко, поэтому нужно контролировать состояние канала другим способом.
Для этого в Juniper есть сервис RPM (Real-Time Performance Monitoring). Вот о его использовании в этом сценарии я и хочу рассказать.
На 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-interval 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 и убирает запись из таблицы маршрутизации.
Обращаю внимание, что конфигурация должна быть зеркальной для обоих устройств.
Если статических маршрутов несколько, их можно добавлять новыми строками then. Условий также может быть несколько, это достаточно гибкий метод.
Всем спасибо, надеюсь, это сэкономит кому-то время.
