Случаи пропадания канала связи можно разделить на 2 вида:
1) Пропадание физического соединения.
2) Отсутствие связи при наличии физического соединения.
В первом случае, достаточно прописать qualified-next-hop в настройках статической маршрутизации, как выглядит такая настройка, см. ниже.
Для второго случая удобно использовать rpm и ip-monitoring. Есть 2 интерфейса, которые подключены и настроены на 2-х разных провайдеров.
Настройки интерфейсов ge-1/0/1 и ge-1/0/2 выглядят примерно вот так:
ge-1/0/1 { unit 0 { description ISP1; family inet { address 1.1.1.2/30; } } ge-1/0/2 { unit 0 { description ISP2; family inet { address 2.2.2.2/30; } }
Настройки маршрутизации будут следующими:
static { route 0.0.0.0/0 { next-hop 1.1.1.1; qualified-next-hop 2.2.2.1 { metric 7; } } }
ISP1 — это основной канал, ISP2 — резервный (все IP-шники вымышленные, любые сходства считайте случайными).
Переходим к настройке rpm, она разбивается на 2 этапа:
1) Настройка мониторинга удаленных хостов (rpm);
2) Настройка переключения маршрутов, в случае отсутствия ответа от удаленного хоста (ip-monitoring).
Итак, настраиваем rpm-мониторинг:
[edit] root@srx# edit services [edit services] root@srx# set rpm probe [PROBENAME] test [TESTNAME] probe-type icmp-ping target address 8.8.8.8 [edit services] root@srx# set rpm probe [PROBENAME] test [TESTNAME] probe-count 5 probe-interval 2 test-interval 10 thresholds successive-loss 5 total-loss 5 [edit services] root@srx# set rpm probe [PROBENAME] test [TESTNAME] destination-interface ge-1/0/1 next-hop 1.1.1.1
Здесь мы создали в качестве rpm-пробы пинг публичного DNS-сервера Google (8.8.8.8) через интерфейс основного провайдера ISP1.
Теперь переходим ко второму этапу — настройке ip-monitoring:
[edit services] root@srx# set ip-monitoring policy [POLICYNAME] match rpm-probe [PROBENAME] [edit services] root@srx# set ip-monitoring policy [POLICYNAME] then preferred-route route 0.0.0.0/0 next-hop 2.2.2.1
Если адрес который указан в пробе выше не пингуется, т.е., проба, как бы, сработала, то выполняется действие, описанное в нашем policy, а именно: мы переходим на альтернативный маршрут, через шлюз резервного провайдера ISP2.
PROFIT!
Добрый день! Спасибо вам большое за выложенную информацию.
Единственное, как я понял пример настройки переключения на резервный канал приведен для версии Junos старше 11й. А как она настраивается на 10й версии? Просто например «set ip-monitoring policy [POLICYNAME] then preferred-route route 0.0.0.0/0 next-hop 2.2.2.1» такой ветки в 10й версии нет.
Заранее спасибо!
Здравствуйте, Александр. Функционал ip monitoring появился с версии JunOS 11.3, по этому и нет на 10 такой ветки.
Здравствуйте Александр! А как сделать, чтобы при появлении основного канала произошло автоматическое переключение на основной канал с резервного?
Здравствуйте, хоть я и не Александр, возьмусь Вам ответить:
В первом случае переключение произойдет, когда появится физический линк и таблица маршрутизации перестроится на основной маршрут.
Во втором случае rpm продолжает работать, даже после переключения на резервный канал, т.е. после того как удаленный хост начнет пинговаться через основной интерфейс, маршруты автоматом перестроятся обратно. Таким образом как только причины отсутствия основного канала устранены и он вернулся в строй, маршруты должны перестроиться на него автоматически в любом случае.
Спасибо за разъяснения. А как такое же сделать на MX серии, там нет в настройках ip-monitoring/
Простите, с MX-ами напрямую не сталкивался, точно не скажу, возможно там нет такого функционала.
Полезная статья, только как прописать не статику (1.1.1.1) как в примере, а РРРоЕ (их 2 от разных провайдеров)?
В «бою» тестировать не приходилось, но думаю схема сильно не будет отличаться. Мне это видится примерно следующим образом:
1) при настройке PPPoE мы создадим некие интерфейсы для ISP1 pp0.0 и для ISP2 pp0.1, например.
2) Далее в таблице маршрутизации пропишем маршруты на ISP1 и на ISP2
route 0.0.0.0/0 {
next-hop pp0.0;
qualified-next-hop pp0.1 {
metric 7;
}
}
3) Ну и на конец в настройке IP monitoring, так же как в статье, просто меняем 1.1.1.1 на pp0.0 и 2.2.2.1 на pp0.1
Думаю как то так.
Спасибо за статью. Полезная информация. Подскажите, плиз, будет ли такая схема работать на кластере из двух SRX240H, если нужно настроить для 1-го ISP интерфейс на 1-м шлюзе, а для 2-го ISP на 2-м шлюзе?
Боюсь нет, поскольку HA-cluster работает в режиме active-standby, такая схема не сработает. Варианты следующие:
1) Попросить операторов предоставить 2 линка, что бы можно было подключить каждого оператора в каждую ноду.
2) Раздвоить операторские линки самостоятельно, с помощью собственного коммутатора(ов)
Приношу извинения за поздний ответ.