Comments 14
Как быть с туннельными интерфейсами в этом случае, если у нас между точками поднят IPSec VPN. Два провайдера, два VPN.
С туннельными проще, там достаточно просто статических маршрутов с разной метрикой (чтобы сделать приоритет). Когда VPN-пир отвалится, интерфейс тоже перейдет в состояние down и маршрут сам удалится из таблицы маршрутизации.
К слову, про это тоже редко пишут, RPM позволяет «положить» интерфейс, а не только манипулировать роутами.
А в варианте с VPN — проще перейти на динамическую маршрутизацию(ospf), если два провайдера с каждой стороны — это 4 туннеля в итоге. Преимущество такого подхода — проще настройка и все туннели уже активны, и не надо ждать их установления после переключения роута по rpm
А в варианте с VPN — проще перейти на динамическую маршрутизацию(ospf), если два провайдера с каждой стороны — это 4 туннеля в итоге. Преимущество такого подхода — проще настройка и все туннели уже активны, и не надо ждать их установления после переключения роута по rpm
И это всё? учитывая, что более подробная статья по этой теме на хабре уже есть…
1) Надо было рассмотреть не только icmp-ping. Есть ещё несколько типов
2) Надо было показать как настроить пробу, измеряющую jitter, что очень важно для ip-телефонии.
3) Для диагностики полезно использовать подробные данные из > show services rpm probe-results и > show services rpm history-results
PS: А в целом: чем больше статей по juniper'ам — тем лучше, если есть интересующие темы — могу написать статью
1) Надо было рассмотреть не только icmp-ping. Есть ещё несколько типов
2) Надо было показать как настроить пробу, измеряющую jitter, что очень важно для ip-телефонии.
3) Для диагностики полезно использовать подробные данные из > show services rpm probe-results и > show services rpm history-results
PS: А в целом: чем больше статей по juniper'ам — тем лучше, если есть интересующие темы — могу написать статью
А почему бы не использовать такой функционал как bidirectional forward detection? Он трекает соседа и автоматом «выключает» статический маршрут через недоступного нейбора.
Да, похоже, тоже можно. Не знал о таком.
www.juniper.net/documentation/en_US/junos/topics/topic-map/policy-bfd-static-routes.html
Вот, похоже, для моей задачи решение.
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
bfd работает по специфичному udp-порту (раз) и требует ответной части (два). Далеко не всегда эти два условия выполнимы, когда вам нужно просто зарезервировать канал в интернет для офиса, например
Спасибо за публикацию. Не то чтобы узнал что-то новое, но ваша статься натолкнула меня на написание своей статьи по схожей теме habrahabr.ru/post/349128
и в результате я наконец вышел из тени.
т.е. мои комментарии добавляются без премодерации. Ура! :)
и в результате я наконец вышел из тени.
т.е. мои комментарии добавляются без премодерации. Ура! :)
Вообще, когда оба устройства под единым административным управлением, правильнее все-же поднять динамическую маршрутизацию, что я в итоге и сделал. В реальной инфраструктуре 3 точки через L2 соединены и там это еще удобнее оказалось, чем трекинг через RPM
если 2 точки под одним административным управлением и надо только трекать доступность то удобнее использовать bfd
Sign up to leave a comment.
Автоматическое переключение маршрута в Juniper SRX