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

Резервный канал интернета и непонятная работа routes

Доброго времени. 

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

RB3011, 6.43.2. 

2 канала интернета. Основной pptp (pptp-Aichyna1), резервный pppoe (pppoe-byfly). Оба без статических IP. 

Никаких сверхестественных наворотов нет.

Резервирование сделано через обычный netwatch пингованием адреса 8.8.4.4. И этот адрес в роутах прописан на основной канал pptp-Aichyna1.

Шлюз по-умолчанию прописан руками с разными дистанциями для разных каналов и отключён для резерва. Если 8.8.4.4 перестаёт пинговаться, активируется маршрут резерва, у которого вес больше (distance 1). 

down:

/ip route enable [find comment="BYFLY_ROUTE"]

up:

/ip route disable [find comment="BYFLY_ROUTE"]

Короче, всё просто как грабли. 

 

Но пару дней назад эти грабли вдруг дали сбой.  А именно - после активации резервного канала адрес 8.8.4.4 начинает пинговаться... через резервный канал! (как и все прочие маршруты, прописанные на другой интерфейс) И начинается мигалка с интервалом в 15 сек (netwatch то up, то down).

Раньше такого не было. Прошу не кидать тряпками, возможно где-то что-то упустил?

routes.png

Share this post


Link to post
Share on other sites

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

В первом случае шлюз будет Unreachable, маршрут до 8.8.4.4 не активен. Во втором случае Reachable - и маршрут до 8.8.4.4 будет активен.

Я такое резервирование никогда не делал, но по логике я бы пинг через основной канал до 8.8.4.4 прибил гвоздями. 

 

Попробуйте заблочить фаерволом пинг до гугла от роутера через резервный канал, должно сработать

Share this post


Link to post
Share on other sites
Только что, maxkst сказал:

Попробуйте заблочить фаерволом пинг до гугла от роутера через резервный канал, должно сработать

Уже когда писАл этот тред, появилась именно эта мысль.  Я не особо силён в настройках - если вам не сложно, подскажите, каким образом это сделать (в input?)

 

1 минуту назад, maxkst сказал:

В первом случае шлюз будет Unreachable, маршрут до 8.8.4.4 не активен

Именно в этом случае, соединение pptp лежит. Соотв. маршрут unreacheble. Микротик тогда его вообще не использует? 

Share this post


Link to post
Share on other sites

По правильному пинговать нужно шлюз каждого канала (а не какой-то посторонний узел в интернете), с заданием source-ip и уменьшением ttl.

Share this post


Link to post
Share on other sites
1 минуту назад, alibek сказал:

По правильному пинговать нужно шлюз каждого канала (а не какой-то посторонний узел в интернете), с заданием source-ip и уменьшением ttl

А если интернет упал за шлюзом?

Share this post


Link to post
Share on other sites
1 минуту назад, alibek сказал:

По правильному пинговать нужно шлюз каждого канала (а не какой-то посторонний узел в интернете), с заданием source-ip и уменьшением ttl.

По-правильному вариантов масса. Мне же нужно как можно проще. У меня в 100% случаев просто отваливается pptp интерфейс. Отсюда и пляшу.

Share this post


Link to post
Share on other sites
3 минуты назад, Parrot сказал:

Уже когда писАл этот тред, появилась именно эта мысль.  Я не особо силён в настройках - если вам не сложно, подскажите, каким образом это сделать (в input?)

Лучше output

 

Только что, alibek сказал:

А если узел на пинг не отвечает?

Какой?

Share this post


Link to post
Share on other sites
Только что, alibek сказал:

Проверяемый.

8.8.4.4? тогда надо бежать за противогазом, и в бункер, ибо третья мировая началась ))

Share this post


Link to post
Share on other sites
27 минут назад, maxkst сказал:

8.8.4.4? тогда надо бежать за противогазом, и в бункер, ибо третья мировая началась ))

Ну, учитывая последние тенденции обособления рунета, не факт. Хотя я из Беларуси.

 

Спасибо, отправил в drop всё, что пытается в output на 8.8.4.4 с резерва - пинги через резерв идти перестали. Значит и netwatch должен отрабатывать правильно. 

Share this post


Link to post
Share on other sites
12 минут назад, Parrot сказал:

отправил в drop всё, что пытается в output на 8.8.4.4 с резерва - пинги через резерв идти перестали

Прям все-все не обязательно, достаточно только ICMP по идее

Share this post


Link to post
Share on other sites
1 минуту назад, maxkst сказал:

Прям все-все не обязательно, достаточно только ICMP по идее

Я понимаю :). Но 8.8.4.4 у меня как DNS не используется.

Share this post


Link to post
Share on other sites
17 минут назад, Parrot сказал:

Значит и netwatch должен отрабатывать правильно. 

Есть возможность проверить на практике?

 

18 минут назад, Parrot сказал:

Ну, учитывая последние тенденции обособления рунета, не факт. Хотя я из Беларуси.

Не думал, что все так плохо. Я из Канады

Share this post


Link to post
Share on other sites

@Parrot 

Если для проверки ничего кроме простого пинга хоста не нужно, очень просто делается на рекурсивных маршрутах.

Смотрите (ваш адрес взял для шлюза)

add distance=1 dst-address=8.8.4.4/32 gateway=10.128.0.0 scope=10
add check-gateway=ping distance=1 gateway=8.8.4.4

Первый маршрут на проверочный хост, обязательно шлюзом IP адрес должен быть, не интерфейс. И scope=10.

Второй маршрут основной дефолт - через первый - с проверкой пингом хоста.

 

Третий маршрут резерв дефолт сами добавьте через второго провайдера, как он есть у вас, но с distance больше 1. Он должен быть enable, т.е. НЕ отключен.

И это все, скрипты, netwatch не нужны !

 

Как работает

- как только проверочный хост становится не доступным (проверяется пингом) ИЛИ падает интерфейс,

дефолт маршрут сразу становится неактивным. И тут же становится активным резервный маршрут, который до этого был неактивным (синим)

- когда проверочный хост становится доступным - доступным именно через основного провайдера - основной дефолт становится активным, а резерв опять неактивным (синим)

 

 

Edited by McSea

Share this post


Link to post
Share on other sites

@McSea да но с нетвотчем с манглами оутпутами роутингами оно как то прямее. Тем более гугл очень не любит быть дефолт гейтом... может и забанить и несекурно это.

P.s. сарказм. Как хоть вас угораздило додуматся до этого садомазо с нетворчем?

Share this post


Link to post
Share on other sites
1 час назад, user71 сказал:

@McSea да но с нетвотчем с манглами оутпутами роутингами оно как то прямее. Тем более гугл очень не любит быть дефолт гейтом... может и забанить и несекурно это.

P.s. сарказм. Как хоть вас угораздило додуматся до этого садомазо с нетворчем?

Надеюсь сарказм относился к утверждению что гугл не любит быть дефолтом и про несекурность?

Share this post


Link to post
Share on other sites

Да. Но я неуверен. Вдруг действительно ходит. Если у вас не ходит возможно гугл неоригинальный. Это же эникаст. 

Edited by user71

Share this post


Link to post
Share on other sites

Что ходит, о чем вы вообще? Трафик через гугл ходит если его указать гейтом?

Edited by VolanD666

Share this post


Link to post
Share on other sites

@user71 

Ознакомьтесь, все уже придумано до нас -- https://wiki.mikrotik.com/wiki/Advanced_Routing_Failover_without_Scripting

 

Через проверяемый хост трафик конечно же не ходит, он там нужен только для проверки доступности. 

Вместо гугла там может что угодно стоять, хоть провайдерский гейт, хоть свой же хост на другой площадке,

хоть любой из 6-ти адресов Яндекс.DNS

Edited by McSea

Share this post


Link to post
Share on other sites

Самое хорошее это 2 L2TP туннеля поднять до некого узла в ДЦ, и по ним передавать интернет. Если один провайдер перестанет работать, то и туннель отвалится, делов то.

Share this post


Link to post
Share on other sites
8 часов назад, Saab95 сказал:

Самое хорошее это 2 L2TP туннеля поднять до некого узла в ДЦ, и по ним передавать интернет. Если один провайдер перестанет работать, то и туннель отвалится, делов то.

Ну обычно между провадерами пиринг, так что не сработает такая схема.

Edited by VolanD666

Share this post


Link to post
Share on other sites

Если туннель не отвалится, то и работать продолжит, есть резерв, разве не так?

Share this post


Link to post
Share on other sites

Если проверочный ДЦ у другого провайдера, то трафик между вашим провайдером и ДЦ может ходить через пиринг. Если речь о ДЦ у вашего провайдера, то это вообще бессмысленно т.к. не защищает от проблем у провайдера.

Share this post


Link to post
Share on other sites
В 25.06.2019 в 22:12, Saab95 сказал:

2 L2TP туннеля поднять до некого узла в ДЦ, и по ним передавать интернет.

И поиметь проблемы с MTU.

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