Comments
Огромное спасибо! Как раз взял домой 951-ый микротик для организации резервирования 2-ух проводных ISP и балансировки нагрузки!
ECMP штука простая, вот только таблица роутинга обнуляется каждые 10 минут. Как следствие — соединение может пойти через другого провайдера, что из-за использования nat'а приведёт к обрыву соединения.
PPC надёжнее.
Ну вроде бы по делу написано, но уж больно как то на уровне начальных уроков. Обычно такие проблемы возникают у совсем новичков. Хотя как часть книги «настраиваем микротик за 24 часа» очень даже круто. Так сказать сухо и по делу без лишней информации.
Урра! наконец-то вышла хорошая статья на эту тему. Добавить даже сразу особо нечего.
придумал, что добавить: накидайте больше тегов и фраз в конце текста, наподобие: «баласерофка тырнета» или «атказаусточивасть на некротике». Чтобы легче потом в поиске находилось кому понадобится.
это шутка, пишите грамотно
Спасибо.
А добавить есть что.
Например если оба провайдера не используют статику или Point-to-Point соединения, а дают нам динамическую адресацию по DHCP, причем меняя и адреса default gateway.
тогда невозможно напрямую прописать маркировки трафика.

Вариант решения у меня есть, оттестирую что он работает и выложу небольшой апдейт.
о! у меня второй ISP пчелайн с их забористым L2TP…
Жду с нетерпением!
а у пчелайна в чем забористость L2TP?
вроде L2TP — Point-to-Point и сам туннель можно в качестве роута указывать.
или там Dual Access (то что в старых прошивках Длинка называют Russian PPTP/L2TP)?
в смысле сначала DHCP с роутом на 0.0.0.0/0 а не только свои сети, и поверх уже L2TP туннель.
кстати пока добавлю куда копать, если провайдер раздает DHCP — 1) при настройке DHCP client в микротик можно задать distance.
2) в подразделе routing (динамическая маршрутизация) у микротика есть filter. С его помощью можно на все маршруты приходящие по DHCP автоматом метить.
Получилось придумать оптимальный вариант для DHCP-выдаваемых адресов у обоих ISP?
Пока единственное, что нашлось — скриптом обновлять каждый раз.

Примерно таким.
:global newgw [/ip dhcp-client get [find interface="ether1-gateway" ] gateway ]
:global activegw [/ip route get [/ip route find comment="Ether1-Wan"] gateway ]
:if ($newgw != $activegw) do={
/ip route set [find comment="Ether1-Wan"] gateway=$newgw
/ip route set [find comment="Ether1-Wan routing gateway"] gateway=$newgw
}
:global newgw [/ip dhcp-client get [find interface="ether2-gateway" ] gateway ]
:global activegw [/ip route get [/ip route find comment="Ether2-Wan"] gateway ]
:if ($newgw != $activegw) do={
/ip route set [find comment="Ether2-Wan"] gateway=$newgw
/ip route set [find comment="Ether2-Wan routing gateway"] gateway=$newgw
}
В первой части статьи ставился вопрос: как обнаружить отсутствие соединения с Интернетом? Автор предлагал пинговать DNS Googl`а — IP 8.8.8.8. Замечу, что есть встроенное средство — /System/Watchdog, которое может перезагрузить роутер и отправить оповещение на e-mail. Для целей резервирования канала это не подходит, а для подключений через одного провайдера по одной линии — помогает в случае проблем с соединением.
Подскажите, а как «домешать» в вашу схему еще одну локальную подсеть?
То есть я имею на микротике 2 локальные сети вида: 10.0.2.1, 10.0.33.1
Для начала добавить их в маскарадинг (нат)
/ip firewall nat add src-address=10.0.2.0/24 action=masquerade chain=srcnat
/ip firewall nat add src-address=10.0.33.0/24 action=masquerade chain=srcnat

а потом разобраться с метками — в некоторых используются адреса локальной сети.
Ну еси я правильно понял, то еще надо для моих адресов локальной сети продублироать это правило:
/ip firewall mangle add src-address=10.1.1.0/24 action=mark-routing chain=prerouting new-routing-mark=mixed — при этом заменить 10.1.1.0 на свое
Хотелось бы почитать про разграничение каналов и сетей, то есть:
В микроик подключается 1 провод или оптика, с пулом на несколько адресов, теперь надо 1IP пустить в одну сеть, 2IP пустить в другую сеть и так далее… И было бы интересно про сквозное подключение почитать, когда 2IP не микроиком обслуживается, а пропускается дальше (как свитч).

Выше описанная ситуация была, когда провайдер дал оптику и надо было настроить выше описанным методом.

P.S.
Провайдер давал просто адреса, не vlan
Так в этой ситуации микротик уже не выступает роутером. Объединить порты в bridge и настроить IP провайдера на хостах.
Тут уже не будет балансировки и файловера на уровне IP. Если ее строить — то на канальном.
> это какой-то из всегда_доступных_узлов (например 8.8.8.8 или 8.8.4.4)

На всякий случай уточню, что эти сервера всегда работают, но _не_всегда_ доступны. Так что пинг на них может и пропасть, просто потому, что они — anycast.

В общем, либо пингу на такие точки верить с оглядкой (обобщать несколько замеров, брать не только гугловские ДНС, но и Яндексовские — всяко поближе будет).
О! Крутая статья. Так получилось, что наткнулся на не только сейчас. Спасибо мил человек за труды. Как вспомню как мне эта тема с маркировками в микро тике сложно давалась аж вздрагиваю. Был бы тогда под рукой такой мануал все прошло бы легче.
Данная схема не работает, если нужна связь между узлами в локальной подсети или подсетях.
Причина проста: всем узлам задаётся таблица маршрутизации, в которой указан только 0.0.0.0/0 поэтому любые узлы мы ищем в интернетах, и, как ни странно, не находим.
А вот если нам нужна маршрутизация внутри локальной сети — мы должны в каждое правило рядом с src-adress=172.16.0.0/22 добавить dst-adress=!172.16.0.0/22 (ip взяты «к примеру»), тогда при поиске узлов с локальным адресом mangle правило применено не будет, и будет назначена дефолтная main-таблица. (HINT! не забываем, что мы можем использовать не -adress а -adress-list — так имеем возможность гибкой настройки)
Кроме того, сам микротик для исходящих от него самого пакетов и соединений полностью игнорирует routing-mark'и в input и output цепочках, указанные в mangle таблице, и всегда использует таблицу маршрутизации main, отсюда вытекает то, что:
1) показанный здесь фильтр входящих на микротик соединений и отсылки их на тот же ISP не работает — микротик принимает соединение на интерфейс ISP, и пытается отослать его туда же, но сталкивается с тем, что no route to host
2) сам микротик не может ничего получить из интернетов, т.к. мы лешаем его дефолт гейта
Поправить это у меня пока не получилось (вернее получилось, задав дефолт гейт одного из ISP с метрикой 100, другого с метрикой 90 — но это костыль — так мы не имеем возможности отсылать входящие соединения туда, откуда они пришли, а только на интерфейс с меньшим значением метрики в таблице main)
т.е. по этой схеме совсем нельзя сделать доступ до самого роутера извне?
очень печально, но всеже спасибо за очень подробный разбор полетов, действительно доходит аж до головы.
С небольшими корректировками возможно. Но через одного ISP, прописав в основную таблицу маршрутизации дефолт гейт через этого ISP с бОльшей метрикой, чем прочие маршруты, дабы использовался последним.
Кроме того, если немного скорректировать балансировку с ECMP — вместо роутинг марка mixed использовать «дефолтный» main — должно работать полностью.
Интересно получается с манглами: если нет дефолтного маршрута то схема не работает.
то есть для работающей схемы нужен дефолтный маршрут + два маршрута с метками.
P.S. Это я про доступность роутера из-вне по разным интерфейсам.
А ведь и правда не работает балансировка исходящего траффика от самого микротика.
Господа, может кто нибудь нашел способ? Поделитесь!
Мне надо распределить по нескольким каналам несколько туннелей. Попробовал и EMCP, и PCC, счетчики растут но траффик бежит упорно через один интерфейс. Хотя если рассматривать таблицу прохождения пакетов iptables, то mangle output должен был поменять ему маршрут, далее route recheck.
Похоже я сам тупой, проблема судя по всему в алгоритме хеширования, я использую в качестве туннелей l2tp, а они и порт источник и порт назначения используют 1701, поэтому для алгоритма все одно..
Спасибо!
Настроил failover с двумя провайдерами. А как быть с их DNS? Как сделать, что бы для каждого провайдера использовался «его» DNS?
И ещё, если не сложно: следующим этапом планирую прикручивать OpenVPN-туннель. Внешний IP даёт только основной провайдера, его доступность >95%. Потеря туннеля при работе через резерв не беспокоит. Но не возникнет ли проблем с доступом в подсеть за туннелем, из-за предложенных «хитростей» в роутах?
А как на счёт того, что не все провайдеры с этим соглашаются ;)?
Попробуйте на самом роутере поднять роль DNS-сервера, а в качестве источников для него укажите все DNS-серверы обоих провайдеров. Это костыль, но работать будет. Для внутренних абонентов укажите DNS-сервер, который на роутере.
Второй вариант — статические маршруты.
До костыля с единым списком «всех DNS» я дотумкал самостоятельно, и как раз, понимая, что «это костыль» — хотел найти другое решение. Про «статические маршруты» — пока не осознал… Имеете ввиду прописать отдельно для LAN-WAN1 и LAN-WAN2?
Кстати, а не честнее ли будет сделать failover на скриптах? Не нашёл сравнения преимуществ/недостатков этих двух решений.
статические маршруты — вы прописываете, что маршрут к конкретному IP должен идти только через шлюз первого провайдера, а к другому IP через другого провайдера.
В коде это выглядит примерно так(по памяти):
/ip route add dst-address=8.8.8.8 gateway=2.2.2.2
/ip route add dst-address=8.8.4.4 gateway=1.1.1.1

Файловер на скриптах — это попытка использования только одного провайдера в один момент времени. В случае полноценного использования двух каналов одновременно(а в случае падения одного из каналов использовать резервный) требуется подобное решение, которое описано в статье.
Мне правда описанное в статье нравиться немного по другому делать, но этот способ тоже вполне жизнеспособен.
Мысль со статикой уловил — спасибо.
Моя задача — как раз организация резервного канала, т.к. нет никакого смысла складывать «100мбит» основного и «2мбит» резервного. Кроме того, мне нравится идея оповещения (e-mail, SMS или ещё как) о падении «основного» — так у меня раньше жил mwan3 под OpenWRT. Я правильно понимаю, что «оповещение» один фиг скриптами будет?
Оповещение — самая простая задача, которую можно организовать в любом случае.

Лично у меня оповещения работают через нетвоч, который дёргает скрипты.
AntiHelper:
у меня оповещения работают через нетвоч, который дёргает скрипты

Так и я про то, что без скриптов оповещения не сделать. Может тогда имеет смысл всё на скриптах?
Маркировать СОЕДИНЕНИЯ в цепочке INPUT совершенно бесполезно.
/ip firewall mangle add action=mark-connection chain=input in-interface=ISP1 new-connection-mark=cin_ISP1
/ip firewall mangle add action=mark-connection chain=input in-interface=ISP2 new-connection-mark=cin_ISP2
происходит это потому что цепочка input идёт уже после маршрутизации, а значит первый прилетевший пакет уже прошел маршрутизацию и открыл соединение без марки, и всё что происходит дальше в этом соединении так же не будет маркироваться.
Можете проверить сами, открыть Connection list и поссмотреть какая марка навешиваеться на соединения.
Правильно будет вот так:
/ip firewall mangle add action=mark-connection chain=prerouting in-interface=ISP1 new-connection-mark=cin_ISP1
passthrough=no
Справедливости ради, маркировать соединение можно в любой момент, и с этого момента все последующие пакеты данного соединения будут иметь соответствующую метку соединения. Например, так делают, чтобы отмаркировать «тяжёлые» соединения, после прохождения по ним определённого объёма данных: connection-bytes=1000000-0

Надо проверить в новой прошивке, в прошивках ниже 6.39 все именно так как я написал.

Возможно, вы пытаетесь объяснить не то, что написали. Потому что в прошивках примерно выше v2.x всё так, как написал я.

По вашему тексту можно предположить, что вы можете иметь в виду соединения из Интернета к внутренним адресам (через DST-NAT), а не к самому роутеру (WinBox или SSH, например).

Так и есть. Из интернета к внутренним адресам через dst-nat и к интернету от внутренних через masqarade. На сам микрот у меня два правила: input accept мой локальный ip и input drop all

Так эти соединения никакого отношения к цепочке input не имеют, они проходят через forward. Поэтому ошибочно говорить, что в input маркировать бесполезно. Просто в input маркируются другие соединения.

Only those users with full accounts are able to leave comments. Log in, please.