Позор за эту статью! Эта статья не подходит по хабрахабр, потому что показана обычная дефолтная настройка, плюс на хабре уже по 10 раз описывалось, в деталях. И настройка резервного канала делается через distance плюс скрипт.
Через дистанс уже хлебнул проблем, провайдера прекосило шлюз пингуется а за ним мира нет, здрасте приехали. А благодаря статье я открыл для себя новый инструмент. И вообще если для Вас подобная настройка это тривиал, то для человека впервые взявшего микротик могут быть некоторые вещи не очевидны, наличие подобной статьи порой заменяет огромную вики да ещё и время экономит.
Верно, но мы хотим подчеркнуть особый момент настройки МикроТик — работу с двумя провайдерами. Будем публиковать развитие этой темы — следите за публикациями.
А напишите пожалуйста о том, как сделать правильно раскидывание трафика по двум аплинкам, а именно:
* простая round-robin балансировка;
* балансировка с возможностью установки некого трешхолда (чтобы весь трафик бегал через основной интерфейс, но когда поток достигает битрейта в 70% пропускной способности аплинка — задействовать второй);
* как сделать балансировку с использованием mark-connection и QoS (queue) одновременно;
Ну и естественно, хочется увидеть реализацию этого с возможностью завернуть принудительно определенный трафик в нужный аплинк, и в случае пропадания алпинка сделать так, чтобы все продолжило работать (хоть и с потерей имеющихся коннектов) :)
Я делал то же самое, только настраивал еще распаралеливание коннектов — через ip firewall => mangle помечал роутинги и распределял по двум провайдерам. В итоге у меня в торрентах удваивалась скорость закачки. Ну и так же через netwatch скрипт прозрачно переключал провайдеры и высылал смс-уведомление если кто-то упал. Более того, у меня два провайдера из одной двойной розетки в коридоре объединялись в одну витуху и разъединялись около микротика :) Могу подробно расписать как это делается, если интересно )
Распаривать кабель и обратно — про это можно не писать ;)
А вот про распределение через маркроуты — напишите, т.к. если это не классический микротиковский PCC, и на самом деле скорость удваивается — то будет интересно. В итоге у вас получается что вы (для торрентов) держите два соединения с одним и тем же пиром, но через разных провайдеров? Или все-таки на одного пира одно соединение?
P.S. Вот этим и прекрасен микротик — его операционка многогранна (порезанный, но линукс) — никогда не знаешь что еще оказывается можно реализовать из хотелок!
А не проще завести два route до адреса 0.0.0.0/0, с разными distance? Там же есть опция check-gateway.
Единственное когда не поможет — когда поломка Где-то на магистрали провайдера…
Да ребят, согласен, добавлю правило в управление трафиком чтобы запретить ping 8.8.4.4 через isp_2. Спасибо за комментарии. Посмотрел в готовой конфигурации есть.
У вас один раз переключится роутинг на резервный интерфейс с запрещенным пингом и больше никогда не переключится назад.
1) вы весь траффик завернули через интерфейс с запрещенным пингом
2) вы никак не проверяете доступность хоста через первый интерфейс
На самом деле бросайте дурное! Netwatch крайне нестабильная вещь для переключения между провайдерами. Race condition словить на раз-два! Я делал немного иначе (задача была похожая), когда шлюзом у меня был первый внешний (!) IP адрес, а маршрут на него был через первого же провайдера, и когда доступность нарушалась, то переключалось на второго — сразу же, встроенными средствами. А второй провайдер был с меньшей дистанцией и тут же подхватывал трафик. Как только первый провайдер оживал, переключалось назад. Это схема резервирования в одну сторону, хорошо подходит для ассиметричных каналов (резерв это что-то вроде ADSL), неидеальна, зато весьма стабильна.
Пример такого маршрута (только то, про что я написал, у меня много еще разных маршрутов, включая маркированные для корректного распознавания входящих соединений):
Кусок конфига, двойные кавычки должны быть обычными, не фигурными!
add check-gateway=ping comment=«mts remote route via ether01-gateway, used the second address» distance=1 dst-address=87.252.243.193/32 gateway=192.168.0.10 scope=10 target-scope=30
add comment=«mts dns» distance=2 dst-address=87.252.243.193/32 type=unreachable
add check-gateway=ping comment=«mts ip gateway» distance=3 gateway=87.252.243.193 scope=10 target-scope=30
add check-gateway=arp comment=«byfly pppoe gateway» distance=4 gateway=pppoe-byfly
Т.е. в примере выше есть маршрут на DNS (тестируемый IP, опытным путем выяснил что он перестает работать при падении интернета, но работоспособности самой сети) провайдера с дистанцией 1, есть fallback с дистанцией 2 (чтобы сработать если не работает первый) и есть маршрут по-умолчанию, на шлюз в виде DNS. Если работает первый вариант — есть интернет, если второй (unreachable) — его нет и в дело вступает второй маршрут по-умолчанию с дистанцией 4. Отмечу что вместо 192.168.0.10 может быть просто интерфейс, все зависит от вашей конфигурации сети и вашего провайдера.
+ заменить jpg на png.
Лучше использовать routing-mark geektimes.ru/post/186284
Таким образом вы получите постоянно работающие WAN и можете настраивать логику деления их между собой, оба интерфейса будут доступны из мира одновременно. В вашем же варианте, если работает первый канал, то на второй канал не пробиться.
В вашем случае Вам не надо 3 порта включать в бридж LAN — этим Вы только ограничиваете скорость передачи, поскольку коммутация будет идти через CPU.
Уберите их из бриджа, для eth4 и eth5 укажите мастер-портом порт eth3, и его уже включайте в бридж LAN. В этот же бридж включайте и wifi, если Вы его на бордере используете.
Если бы не wifi (который иначе никак с eth-портом в единую группу не объединить), то можно было бы IP вешать на eth3, и вообще не городить бридж, а wifi, конечно, выключить. Если же wifi нужен, то вешаем IP на бридж.
Да, не забываем отключить лишние пакеты (в System -> Pakages) — почти наверняка MPLS Вам не нужно, и Routing также не нужен (IP -> Routes от него не зависит). Заодно не забываем нажать кнопку Check for Updates в этом же окне с пакетами. Нажали, далее жмем Update and Reboot, дожидаемся перезагрузки, заходим еще раз, затем идем в System -> Routerboard, и там, если текущая и доступная версии firmware отличаются, также жмем Upgrade, а потом выбираем руками System -> Reboot.
Основная проблема микротика это невозможность его использовать в более менее нормальном энтерпрайзе с двумя провайдерами с белыми ип, ибо он не умеет натить сразу с двух внешних интерфейсов внутрь сети.
Или я не прав? Всем нагом бились и официальным форумом, сделать никто у себя не смог…
Не очень понял в чем проблема. Два провайдера, через них пяток VPN, все нормально натится в любую сторону. Опишите свою задачу поподробнее, пока звучит как нечто, имеющее чуть менее, чем очевидное решение.
#Роутим в соответствии с маркерами
/ip route
add distance=1 gateway=77.37.236.1 routing-mark=rout_Main
add distance=1 gateway=79.165.208.1 routing-mark=rout_Reserve
Все в точности как у вас и у меня и проброс портов сразу с двух белых ип не работает, бился пол года, у вас работает одновременно проброс с двух белых ип куда-нибудь внутрь? Так то по белым ип сам микротик доступен и у меня.
nag обсуждение
Задача то элементарная, согласен, но не работает это на микротике не у меня одного, на linux руками это сделать не проблема, а на микротике так и не смог победить…
Значит что-то не так с самим роутером (встречаются такие «странные» экземпляры). У меня несколько таких конфигураций в работе — никогда не сталкивался с описанными проблемами, всё работает как часы.
Было бы весьма полезно увидеть то же самое в виде консольных команд. Не все настраивают MikroTik из винды, и не все любят протыкивать менюшки и диалоговые окна, глядя на скриншоты.
Плюсую. В статье описаны ужасные сложности, а в Гиге всё просто до удивления.
Сам пару дней назад настроил два соединения с разными настройками в несколько кликов никогда перед этим такого не делав.
Немного оффтопа: недавно был в шоке от того, что у Акадо в Москве на некоторых тарифах с NAT запрещены запросы на сторонние DNS-сервера.
Просто микротик это устройство уровнем выше обычных, пускай даже модных и глянцевых (и местами с интересными аппаратными модулями), но мыльниц. И да, некоторые вещи делаются неочевидно, но это не сложно, как и не сложна таблица умножения для того, кто понимает ее суть.
P.S. Нет, я не гуру микротика и не сетевик, но после того как разобрался в основах, теперь многое видится в ином свете.
Софт. Плюс, как вы должны знать, чипсет накладывает ограничения, но не является гарантом результата. От обвязки зависит получится ли приблизиться к границам возможностей или нет.
UP: Если кто не в курсе, Mikrotik начинал с разработки софта (ROS), и только позже начал еще и выпуск железа со встроенной ROS, так что можно (и так много кто делает) его использовать на x86 железках.
Да но он не умеет из коробки pptp сервер, eoip туннели ) и всякие другие вкусности, которые очень хорошо используются в малом и среднем бизнесе. Да и работает он стабильно.
На 750G живет: c 7 вланов, 7 бриджей, на него подключаются 5 pptp клиентов с eoip туннелями. При всем этом он натит порядка 270 (выданные ip за сутки) клиентов (корп сеть + вайфай свободный). И при всем этом, жрет 10-12% cpu и то из-за того, что видеокамеры фуллХД потока находятся в другом влане(временное решение пока идет ремонт) и через него постоянно роутится этот трафик.
И все это при том, что стоит оба девайса одинаково, могу сказать, что ваш выигрывает только в простоте настройки простых вещей из веб интерфейса, + антеннами для вайфая. И я не уверен что ZyXEL потянет столько клиентов )
PPTP сервер умеет уже несколько лет (NDMS 2, компонент VPN Server), очень скоро подтянется IPsec в разных видах.
EoIP кстати реализовать элементарно — было бы желание, только запросов от клиентов нет.
Автор, а вы не забыли про то что с включенным Connection Tracking текущие установленные соединения так и останутся висеть на первом провайдере (ведь он не упал, это вы маршруты перекинули для новых соединений)? И хорошо было бы еще и перезапустить CT путем отключение, выжидания и включения снова.
Вообще, я такой велосипед не первый раз вижу, сам намучался с различными вариантами, но ожидал от статьи глубокого анализа, а не очередной копипасты очевидных вещей…
Да все верно пишешь. Тут приведен лишь пример как это можно реализовать, при дальнейшем развитии инфраструктуры сети необходимо править конфиг, а возможно даже переделывать сам алгоритм. К примеру как описано выше можно для всего этого дела использовать скрипт, но тут встаёт вопрос а потянет ли железо микротика, либо придётся ставить что то другое.
Еще раз напишу, а то вы видимо не заметили.
По приведённому в статье примеру микротик переключится на резервный канал и больше никогда самостоятельно не переключится назад.
Решение в корне неверное и не рабочее.
Каждый раз читаю и приходит мысль: а что, Peplink, f5, Juniper WX/WXC уже не торт? Или так хочется в гамаке этим заниматься, вместо чтобы поставить в 30 мин настроить и забыть? И ещё скажите, что у этого «тика» 2 power supply есть… Блин, извините…
описанное в статье настраивается за означенные 30 минут. Однако со временем конфигурация может стать сложнее например контора разделилась на 2 подсети, появился третий провайдер, понадобилась балансировка и тд, в случае с с микротиком настройки добавляются легко и непринужденно прям в описанный конфиг в случае с некоторыми нат машинками где все придумано за нас можно наткнуться на полную замену железки по той причине что производитель упростил настройку и не продумал нетривиальные конфигурации. уже не раз сталкивался с ситуацией когда у клиента дорогущий роутер который может настроить уборщица, но который не умеет элементарных вещей вроде поднять ещё 1 впн кроме как до провайдера или сделать гостевую сетку в другом диапазоне адресов.
кстати да этот микротик умеет питаться по пое и от родного блока одновременно, отключение одного из питаний даже не приводит к перезагрузке, и да для того чтобы заменить блок питания если врог он нагнулся ненадо пол города объезжать в стандартный разьем можно воткнуть всечто угодно от 9 до 30 вольт
Согласен полностью. Про балансировку это уже отдельная история т.к. протоколы которые требуют постоянного подключения будут работать только на одном канале 50 на 50 сделать не получиться.
недавно делал, суть примерно следующая: за натом сервак на сервак сыпятся запросы запросы с 2 разных провайдеров, метим сессию, на основе этих меток метим роуты и пакеты, с какого провайдера установили с нами соединение в шлюз того все пакеты с этого соединения и насыпаются, с трафиком инициаторы которого в интарсети, конечно так не получится, для них шлюзы по умолчанию с дистанциями.
Пусть выглядит как самореклама, но
все проблемы тут давно решены, работает пол года идеально.
Единственное, чтобы адаптировать под свой случай — нужно разобраться по-честному.
Мы не говорим, что представляем единственно возможный вариант объединения двух провайдеров в одной сети. Мы показываем, как это можно сделать на оборудовании MikroTik, Безусловно, благодарны за добавление и расширение материала новыми примерами.
Организация локальной сети с одновременным подключением к двум интернет-провайдерам при помощи маршрутизатора MikroTik