LINUX.ORG.RU
ФорумAdmin

Default route failover

 ,


0

1

На шлюзе есть два cту маршрута по-умолчанию от двух разных провайдеров.

Нужен автоматический FAILOVER(второй маршрут работает только когда не работает первый) маршрута по-умолчанию. Причем отказ маршрута должен определятся по доступности шлюза провайдера, а не ya.ru или <что там еще пишут>

Сейчас меняются руками, через ip route replace default ...

Не взлетело:

  • Протоколы маршрутизации. Надо договариваться с провайдерами. Если ли есть варианты, что бы не договариваться, то я обеими руками за.
  • Два маршрута с разными метриками и изменение настроек ядра. Это работает, но проблема в том, что только пока линк становиться неактивным. Если линк активен, но связи нет, то переключения не будет.
  • Скрипт с ping. Шел 2018 год.

Какие есть еще варианты?

Скрипт с ping. Шел 2018 год

Справедливости ради - почитай как работает тот же track/IP SLA в Cisco. По факту там тот же аналог скрипта с ping/wget/whatever.

Учитывая что тебе надо проверять доступность шлюза провайдера подобный скрипт будет тривиальным.

Pinkbyte ★★★★★ ()

отказ маршрута должен определятся по доступности шлюза провайдера

не надо так

BOOBLIK ★★ ()

отказ маршрута должен определятся по доступности шлюза провайдера. Это не совсем правильно потому что могут быт ситуации когда шлюз провайдера доступен а интернет не работает

rootmaster ()
Ответ на: комментарий от rootmaster

или бывают случаи, когда половина интернета нормально открывается, пока другая недоступна.

Deleted ()

Ну да, нету у нас dead gateway detection, в отличии от оффтопика.

Вариант с ospf не рассматривается ?

vel ★★★★★ ()

Скрипт с ping. Шел 2018 год.

Скрипт это нормально, скрипт это хорошо! Не нравится скрипт, договаривайся с провайдером.

vasya_pupkin ★★★★★ ()

Исходя из описания задачи и пропустить первый пункт, то:

Скрипт с ping. Шел 2018 год.

Оно. Но как писали выше, не только шлюз прова, но и еще несколько предполагаемо постоянно рабочих. По итогу, если все не отвечают считаем что канал лег.

ЗЫ Не в тему, просто навеяло соседним топиком. В домашних вариантах со всякими pppoe, l2tp &etc проще, у них по статистике если рушиться, так только своя сеть, можно ориентироваться на интерфейс.

anc ★★★★★ ()
Ответ на: комментарий от vel

Ну да, нету у нас dead gateway detection, в отличии от оффтопика.

Который емнип ориентирован на tcp (могу ошибаться). Но в теории вроде можно же такое самому накалякать. Правда с Вашим опытом виднее как такое накалякать, может я и фигню написал :)

anc ★★★★★ ()
Ответ на: комментарий от rootmaster

Это не совсем правильно потому что могут быт ситуации когда шлюз провайдера доступен а интернет не работает

Я бы даже сказал, что в большинстве случаев (95%) отказа каналов шлюз провайдера как раз остается живым :)

stave ★★★★★ ()

То, что ты хочешь, называется BFD. Вот только наверняка его нет на твоем роутере-он-стик.

stave ★★★★★ ()
Ответ на: комментарий от anc

не, идея проста как грабли.

Если не удается получить мас-адрес шлюза (нет ответа на arp 3 секунды) , то маршрут отмечается как временно неактивный и его не учитывают при поиске маршрута до появления адреса.

Для мелких систем, где 2.5 маршрута, такая вещь реализуется просто, а вот если это какой-нибудь роутер c 100к маршрутами, то реализация будет совсем не дешевая, там более, что на BR используются протоколы маршрутизации, который делают DGD ненужной фичей.

vel ★★★★★ ()
Ответ на: комментарий от thesis

Имеется в виду, что возможно придумали что-то более правильное

greek_31 ★★ ()
Ответ на: комментарий от rootmaster

В моем конкретном случае такого, к счастью, не бывает

greek_31 ★★ ()
Ответ на: комментарий от greek_31

это уже скрипт, а ты то хочешь без них...

vel ★★★★★ ()
Ответ на: комментарий от DELIRIUM

Простейший скрипт на bash, который периодически мониторил узлы за шлюзами через временные маршруты и выставлял актуальные исходя из результата проверок

pascal ★★★ ()
Последнее исправление: pascal (всего исправлений: 1)
Ответ на: комментарий от greek_31

Ну у нас было как:

прописывался мультихоп маршрут в 0.0.0.0 через двух провайдеров (типа балансировка 50/50). Далее для узла, который пинговался, выставлялся временный маршрут через конкретного провайдера, проверялся ответ, потом этот маршрут удалялся и прописывался новый через другово провайдера - проверялся ответ. Если ответа нет, то маршрут в 0.0.0.0 выпиливался до последующего восстановления. Все это дело молотило в цикле.

pascal ★★★ ()
Ответ на: комментарий от greek_31

Для OSPF, как я понимаю, надо с провайдерами общаться?
Это, конечно самый лучший вариант, но боюсь не взлетит

Не взлетит. Просто административно никто не даст OSPF, так как получится полная жопа в ситуации, когда две разных автономки имеют связь через левую чужую арию. Вот BGP можно попробовать приспособить. И, даже, с приватной AS.

AS ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.