Jump to content
Калькуляторы

SRX210. Как автоматически переводить трафик на другого провайдера?

Дано:

Есть Juniper SRX210. Есть выход на двух провайдеров: ISP-1 и ISP-2. Первый подключен через ADSL-роутер, адрес ADSL-роутера 192.168.72.76 и включен он в Джунипер в порт

Logical interface fe-0/0/6.0

Destination: 192.168.72/24, Local: 192.168.72.1, Broadcast: 192.168.72.255

Второй провайдер включен в порт

Logical interface fe-0/0/2.0

Destination: 2.2.2.16/28, Local: 2.2.2.17, Broadcast: 2.2.2.31

В локальную сеть Джунипер смотрит интерфейсом

Logical interface vlan.0

Destination: 192.168.20/24, Local: 192.168.20.5, Broadcast: 192.168.20.255

Для сети 192.168.20/24 (назовём её N-1) создан специальный routing-instance и она отдельно от всех выводится в Интернет через ISP-1:

set routing-instances specialroute instance-type forwarding

set routing-instances specialroute routing-options static route 0.0.0.0/0 next-hop 192.168.72.76

 

set routing-options rib-groups 192.168.20 import-rib [ inet.0 specialroute.inet.0 ]

set routing-options interface-routes rib-group inet 192.168.20

 

set firewall filter filter-for-192.168.20 term match from address 192.168.20.0/24

set firewall filter filter-for-192.168.20 term match then routing-instance specialroute

set firewall filter filter-for-192.168.20 term default then accept

set interfaces vlan unit 0 family inet filter input filter-for-192.168.20

Что требуется:

При пропадании Интернета на канале ISP-1 автоматически переводить трафик из сети N-1 на ISP-2.

Пробовал делать по науке, то есть так, как написано тут. Очень сложно, муторно, незапоминательно и, в общем, ни фига не получилось. Но оно и понятно, что не получилось: именно потому что муторно и сложно, непонятно, шаг влево-вправо - почти стопроцентная ошибка. Но самое главное: как выяснилось, Джунипер не будет запускать пинг через routing-instance. Не знаю почему, мне так в соседней теме сказали.

Поэтому вопрос: можно эту задачу решить как-то проще и изящнее?

Edited by Margulis

Share this post


Link to post
Share on other sites

Вы в своей конфигурации использовали routing-instance type forwarding. Этот instance действительно лучше всего подходит для policy-routing, но у него собственных интерфейсов. Т.е. у него просто нет ни одного IP-адреса с которого он может послать пакет.

Попробуйте использовать instance-type vrf или instance-type virtual-router. С ними обязательно нужно ассоциировать собственные интерфейсы (в Вашем случае это будет интерфейс к ISP-1). При этом вам придется позаботится о том, чтобы пакеты, принятые через этот интерфейс и адресованные в локальную сеть, попали в 'основной' instance. Что-то типа такого: set routing-instance <name> routing-options static route 192.168.20/24 next-table inet.0. При этом перекладывать интерфейсные маршруты из GRT в instance (set routing-options interface-routes rib-group inet 192.168.20) не нужно.

Как 'проще и изящнее' решить основную задачу я не знаю.

Share this post


Link to post
Share on other sites

А что в вашем случае есть пропадание интернета? при падении некст хопа можно дописать qualified next hop например, и поставить метрику повыше. Один упадет другой поднимется, только смотрите что бы маршрутизация до другого next hop была.

Ну это так навскидку.

 

Если пропадание интернета не подразумевает падение next hop то надо подумать. )))

Share this post


Link to post
Share on other sites

Если пропадание интернета не подразумевает падение next hop то надо подумать. )))

А вот то-то и оно, что next-hop - это ADSL-роутер, и в общем-то не факт, что событие "упал Инет" ограничивается выключением роутера. Я бы даже сказал, что как раз скорее всего роутер-то в сети останется, а упадёт линк с провайдером. Как я понимаю, в этом случае у Джунипера не будет оснований использовать второй дефолтный маршрут, если его указать. Поэтому, кажется, логичнее использовать пинг-тест. Но это решение выглядит тяжеловатым...

Share this post


Link to post
Share on other sites

Ну, что ж... Если нет других предложений, идём по пути, предложенному уважаемым nnm:

Попробуйте использовать instance-type vrf или instance-type virtual-router.

Итак, я вижу следующую последовательность своих действий:

1) Создать виртуальный роутер:

set routing-instances VirtRouter-1 instance-type virtual-router

2) Привязываем к нему интерфейс, через который Джунипер смотрит на первого провайдера:

set routing-instances VirtRouter-1 interface fe-0/0/6.0

Сразу же у меня вопрос: а надо к нему привязывать интерфейс, который смотрит в локалку?

Share this post


Link to post
Share on other sites

Сразу же у меня вопрос: а надо к нему привязывать интерфейс, который смотрит в локалку?

 

Нет.

Share this post


Link to post
Share on other sites

Создать какой нибудь костыль, который будет делать этот несчастный пинг тест ) случае пропадания он заходит на железку и меняет маршрут. Пинговать должен через срх как обычный клиент с адресом подсети. Наверное это должно сработать. Ну уж а где взять костыль и как его реализовать, смотрите сами как удобнее. но как то это все геморройно.

ну еще можно попробовать поднять BFD например между вами и провайдером, и тогда next-hop точно должен отвалиться, насколько я понимаю данную технологию, в случае пропадения линка между модемом и провайдером или еще каких либо подобных выкрутасов.

Share this post


Link to post
Share on other sites

Создать какой нибудь костыль, который будет делать этот несчастный пинг тест ... но как то это все геморройно.

Костыль описан тут. Действительно, Вы верно заметили, геморройно. Но и этот костыль работать не будет, потому что сама выбранная мной технология не позволяет использовать пинг. То есть, никакой костыль в рамках этой технологии не сработает. Разве что какой-нибудь другой костыль приладить где-то на компе в локалке, пусть он пингует и если что - как-то переконфигурит Джунипера... Геморроя от этого меньше не становится. )) Похоже, придётся переезжать на virtual-router.

ну еще можно попробовать поднять BFD например между вами и провайдером

А кто такой BFD?

Edited by Margulis

Share this post


Link to post
Share on other sites

BFD - bidirectional forwarding detection , специальный такой протокол который служит для проверки линка. тупо между двумя соседними адресами отсылаются hello туда суда. в случае не ответа маршрут считается ... потерянным.

 

 set routing-options static route 0.0.0.0/0 bfd-liveness-detection  

 

что то типа того в SRX.

Share this post


Link to post
Share on other sites

Можно побить SRX на 3 виртуальных роутера. Два смотрят на провайдеров (I1, I2), а третий (I3) логическими интерфейсами подключается к первым двум.

На I2 прописываем дефолтный маршрут на провайдера. На I1 прописываем /32 маршрут через провайдера на I2.

Поднимаем между ними gre туннелльчег. На туннельчеге bgp. От I2 отдаем default. На I1 меняем next-hop для этого маршрута на next-hop провайдера.

А далее отдаем этот default с I1 и I2 по ospf на I3.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this