Легенда — есть две площадки, связанных по 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. Условий также может быть несколько, это достаточно гибкий метод.
Всем спасибо, надеюсь, это сэкономит кому-то время.
Комментарии (10)
vertex4
13.02.2018 11:52И это всё? учитывая, что более подробная статья по этой теме на хабре уже есть…
1) Надо было рассмотреть не только icmp-ping. Есть ещё несколько типов
2) Надо было показать как настроить пробу, измеряющую jitter, что очень важно для ip-телефонии.
3) Для диагностики полезно использовать подробные данные из > show services rpm probe-results и > show services rpm history-results
PS: А в целом: чем больше статей по juniper'ам — тем лучше, если есть интересующие темы — могу написать статью
Yauheni1978
14.02.2018 11:44+1А почему бы не использовать такой функционал как bidirectional forward detection? Он трекает соседа и автоматом «выключает» статический маршрут через недоступного нейбора.
alk0v Автор
14.02.2018 11:44Да, похоже, тоже можно. Не знал о таком.
www.juniper.net/documentation/en_US/junos/topics/topic-map/policy-bfd-static-routes.html
Вот, похоже, для моей задачи решение.
set routing-options static route 0.0.0.0/0 qualified-next-hop 192.168.2.1
set routing-options static route 0.0.0.0/0 qualified-next-hop 172.16.1.1
set routing-options static route 0.0.0.0/0 bfd-liveness-detection minimum-interval 60
Night_Snake
15.02.2018 09:39bfd работает по специфичному udp-порту (раз) и требует ответной части (два). Далеко не всегда эти два условия выполнимы, когда вам нужно просто зарезервировать канал в интернет для офиса, например
iddqda
15.02.2018 10:33Спасибо за публикацию. Не то чтобы узнал что-то новое, но ваша статься натолкнула меня на написание своей статьи по схожей теме habrahabr.ru/post/349128
и в результате я наконец вышел из тени.
т.е. мои комментарии добавляются без премодерации. Ура! :)
alk0v Автор
15.02.2018 11:35Вообще, когда оба устройства под единым административным управлением, правильнее все-же поднять динамическую маршрутизацию, что я в итоге и сделал. В реальной инфраструктуре 3 точки через L2 соединены и там это еще удобнее оказалось, чем трекинг через RPM
BigDrive
Как быть с туннельными интерфейсами в этом случае, если у нас между точками поднят IPSec VPN. Два провайдера, два VPN.
alk0v Автор
С туннельными проще, там достаточно просто статических маршрутов с разной метрикой (чтобы сделать приоритет). Когда VPN-пир отвалится, интерфейс тоже перейдет в состояние down и маршрут сам удалится из таблицы маршрутизации.
vertex4
К слову, про это тоже редко пишут, RPM позволяет «положить» интерфейс, а не только манипулировать роутами.
А в варианте с VPN — проще перейти на динамическую маршрутизацию(ospf), если два провайдера с каждой стороны — это 4 туннеля в итоге. Преимущество такого подхода — проще настройка и все туннели уже активны, и не надо ждать их установления после переключения роута по rpm