Автоматическое переключение маршрута в Juniper SRX

  • Tutorial
Небольшая инструкция про то, как автоматизировать переключение сетевого маршрута в случае проблем с одним из линков. Дальше прошу под кат



Легенда — есть две площадки, связанных по 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. Условий также может быть несколько, это достаточно гибкий метод.

Всем спасибо, надеюсь, это сэкономит кому-то время.
Share post

Similar posts

AdBlock has stolen the banner, but banners are not teeth — they will be back

More
Ads

Comments 14

    0
    Как быть с туннельными интерфейсами в этом случае, если у нас между точками поднят IPSec VPN. Два провайдера, два VPN.
      0
      С туннельными проще, там достаточно просто статических маршрутов с разной метрикой (чтобы сделать приоритет). Когда VPN-пир отвалится, интерфейс тоже перейдет в состояние down и маршрут сам удалится из таблицы маршрутизации.
        0
        К слову, про это тоже редко пишут, RPM позволяет «положить» интерфейс, а не только манипулировать роутами.
        А в варианте с VPN — проще перейти на динамическую маршрутизацию(ospf), если два провайдера с каждой стороны — это 4 туннеля в итоге. Преимущество такого подхода — проще настройка и все туннели уже активны, и не надо ждать их установления после переключения роута по rpm
      +1
      И это всё? учитывая, что более подробная статья по этой теме на хабре уже есть
      1) Надо было рассмотреть не только icmp-ping. Есть ещё несколько типов
      2) Надо было показать как настроить пробу, измеряющую jitter, что очень важно для ip-телефонии.
      3) Для диагностики полезно использовать подробные данные из > show services rpm probe-results и > show services rpm history-results
      PS: А в целом: чем больше статей по juniper'ам — тем лучше, если есть интересующие темы — могу написать статью
        0
        Все :)
        +1
        А почему бы не использовать такой функционал как bidirectional forward detection? Он трекает соседа и автоматом «выключает» статический маршрут через недоступного нейбора.
          0
          Да, похоже, тоже можно. Не знал о таком.
          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
            0
            bfd работает по специфичному udp-порту (раз) и требует ответной части (два). Далеко не всегда эти два условия выполнимы, когда вам нужно просто зарезервировать канал в интернет для офиса, например
            0
            Спасибо за публикацию. Не то чтобы узнал что-то новое, но ваша статься натолкнула меня на написание своей статьи по схожей теме habrahabr.ru/post/349128

            и в результате я наконец вышел из тени.
            т.е. мои комментарии добавляются без премодерации. Ура! :)
              0
              Вообще, когда оба устройства под единым административным управлением, правильнее все-же поднять динамическую маршрутизацию, что я в итоге и сделал. В реальной инфраструктуре 3 точки через L2 соединены и там это еще удобнее оказалось, чем трекинг через RPM
                0
                Как и IP SLA, RPM решает вполне конкретные вещи, в т.ч. и мониторинг rtt/jitter внутри канала. не стоит мешать одно с другим
                  0
                  Не спорю, но у меня не было задачи мониторить RTT и Jitter
                0
                если 2 точки под одним административным управлением и надо только трекать доступность то удобнее использовать bfd
                  0
                  bfd не в состоянии оценить качество (jitter/rtt)

                Only users with full accounts can post comments. Log in, please.