Перейти к содержимому
Калькуляторы

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. Не знаю почему, мне так в соседней теме сказали.

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

Изменено пользователем Margulis

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Вы в своей конфигурации использовали 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) не нужно.

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Ну, что ж... Если нет других предложений, идём по пути, предложенному уважаемым 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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

Нет.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

А кто такой BFD?

Изменено пользователем Margulis

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 смайлов.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.