Russian Users MikroTik | Форум пользователей MikroTik

Привет.
Есть такой теоретически практический вопрос.
Мы имеем центральный маршрутизатор Mikrotik на который приходит два провайдера.
Настроена маркировка (mangle) трафика с нужных портов.
Что то типо: Настроены маршруты по умолчанию и доп маршруты маркированного трафика через router rules.
По такой конфигурации будет задействовано два канала одновременно (то есть два провайдера).
Правильно ли я понимаю что при падении одного провайдера трафик пойдет через второго провайдера автоматически (но скорость упадет на ширину канала упавшего провайдера)? И в этом случае нет необходимости переключать что то через Netwatch (отключать маршруты, менять distance и тд)

Нет неправильно. Микротик упорно будет засылать трафик в ту таблицу маршрутизации в которую вы ему сказали за исключением случая если линк отвалится. В этом случае таблица с упавшим линком как бы перестанет существовать и по логике микротик трафик уйдет в main если микротику не объяснить что так делать ненадо

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

У меня Rules в Route настроены с пометкой lookup-only-in-table, следовательно трафик не попадет в main. Он будет попадать только в ту таблицу на которую настроен маркированный трафик.
Тоесть на провайдера1 в одну запись, а на провайдера 2 в другую.
Или я не так понимаю lookup-only-in-table?

Правильно понимаете. Но в этом случае вы получите потери равные 50% Даже если у вас линк отвалился

В общем я обычно делаю схему резервирование по внешнему хосту + отключение/включение агрегации (если 2 канала) или перенастройка схемы агрегации (если 3 и более каналов)

В случае с двумя каналу ну тупо тушите маршрут в main и полностью тушите механизм агрегации, в этом случае микротик начнет засылать все в головной маршрут. Если канал поднялся то в обратном порядке

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

По поводу "50%".
Если у меня два провайдера по 5мб. То клиент. Внутри сети получит скорость в ~10мб.
При недоступности интернета (именно интернета, а не потому что дефллтный шлюз одного из провайдеров упал, он доступен).
То пакеты соединения 50/50 разделяться между провайдерами? И если один провайдер не будет доступен то получим скорость в 5мб.
Но при схеме active/standby, все идёт через одного провайдера, когда падает основной то скриптом переключаем на второго. Но в изначально в работе мы имеем скорость одного провайдера (тоесть 5мб) и при переключении также 5мб получаем от другого.
Поэтому и вопрос если есть балансировка 50/50 (если я правильно понимаю Per Connection) то зачем скрипт для переключений? Если один провайдер просто не будет доступен, да скорость упадет, да не будет создаваться новых подключений через упавшего провайдера.

Вы внимательно посмотрите как формируются соединения и поймете (особенно хорошо видно на торентах)

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

Например. Идете на ютуб, он открылся а ролик не грузится, а другой ролик вдруг грузится и т.п.

Спасибо за разъяснения.
Тогда получается сне нужно скриптом мониторить доступность каналов и если один из них падает то тогда я вырубаю правило в Mangle которое Per Connection ( тем самым убираю балансировку соединений), оставляю обычную маркеровку на интерфейс и отрубаю маршрут на упавшего провайдера.
И получаю после работы скрипта схему с одним провайдером. Когда все соединения маркируются через работающего провайдера.
И когда упавший провайдер поднялся (буду скриптом мониторить) то возвращаю все обратно.

ага, только отключаете оба правила в манагл ))) И это был только первый камень на тернистом пути агрегации