[Parrot]

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

Скорее всего вопрос заезжен до блеска, но судя по отсутствию 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).

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

[maxkst]

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

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

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

 

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

[Parrot]

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

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

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

 

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

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

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

[alibek]

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

[maxkst]

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

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

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

[alibek]

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

[Parrot]

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

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

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

[maxkst]

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

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

Лучше output

 

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

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

Какой?

[alibek]

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

[maxkst]

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

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

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

[Parrot]

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

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

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

 

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

[maxkst]

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

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

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

[Parrot]

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

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

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

[maxkst]

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

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

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

 

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

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

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

[McSea]

@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 не нужны !

 

Как работает

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

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

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

 

 

Изменено 24 июня, 2019 пользователем McSea

[user71]

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

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

[VolanD666]

1 час назад, user71 сказал:

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

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

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

[user71]

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

Изменено 25 июня, 2019 пользователем user71

[VolanD666]

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

Изменено 25 июня, 2019 пользователем VolanD666

[McSea]

@user71 

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

 

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

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

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

Изменено 25 июня, 2019 пользователем McSea

[Saab95]

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

[VolanD666]

8 часов назад, Saab95 сказал:

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

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

Изменено 26 июня, 2019 пользователем VolanD666

[Saab95]

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

[VolanD666]

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

[jffulcrum]

В 25.06.2019 в 22:12, Saab95 сказал:

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

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