Default route failover

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

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

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

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

не надо так

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

А что, в 2018 уже даже пинг сломали?

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

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

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

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

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

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

Cast pascal. Расскажи, как у нас было сделано, а то я подзабыл.

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

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

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

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

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

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

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

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

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

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

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

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

Как насчет ip neigh show dev eth0 | grep «REACHABLE»?

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

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

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

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

Ага.

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

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

А что за узлы были?

Произвольные, гарантированно рабочие.

временные маршруты?

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

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

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

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