Comments 45
Отличная статья, спасибо.
Добро пожаловать на Хабр.
Добро пожаловать на Хабр.
Огромное спасибо! Как раз взял домой 951-ый микротик для организации резервирования 2-ух проводных ISP и балансировки нагрузки!
ECMP штука простая, вот только таблица роутинга обнуляется каждые 10 минут. Как следствие — соединение может пойти через другого провайдера, что из-за использования nat'а приведёт к обрыву соединения.
PPC надёжнее.
PPC надёжнее.
Ну вроде бы по делу написано, но уж больно как то на уровне начальных уроков. Обычно такие проблемы возникают у совсем новичков. Хотя как часть книги «настраиваем микротик за 24 часа» очень даже круто. Так сказать сухо и по делу без лишней информации.
Урра! наконец-то вышла хорошая статья на эту тему. Добавить даже сразу особо нечего.
придумал, что добавить: накидайте больше тегов и фраз в конце текста, наподобие: «баласерофка тырнета» или «атказаусточивасть на некротике». Чтобы легче потом в поиске находилось кому понадобится.
это шутка, пишите грамотно
это шутка, пишите грамотно
Спасибо.
А добавить есть что.
Например если оба провайдера не используют статику или Point-to-Point соединения, а дают нам динамическую адресацию по DHCP, причем меняя и адреса default gateway.
тогда невозможно напрямую прописать маркировки трафика.
Вариант решения у меня есть, оттестирую что он работает и выложу небольшой апдейт.
А добавить есть что.
Например если оба провайдера не используют статику или 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 туннель.
вроде 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 автоматом метить.
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
То есть я имею на микротике 2 локальные сети вида: 10.0.2.1, 10.0.33.1
Хотелось бы почитать про разграничение каналов и сетей, то есть:
В микроик подключается 1 провод или оптика, с пулом на несколько адресов, теперь надо 1IP пустить в одну сеть, 2IP пустить в другую сеть и так далее… И было бы интересно про сквозное подключение почитать, когда 2IP не микроиком обслуживается, а пропускается дальше (как свитч).
Выше описанная ситуация была, когда провайдер дал оптику и надо было настроить выше описанным методом.
P.S.
Провайдер давал просто адреса, не vlan
В микроик подключается 1 провод или оптика, с пулом на несколько адресов, теперь надо 1IP пустить в одну сеть, 2IP пустить в другую сеть и так далее… И было бы интересно про сквозное подключение почитать, когда 2IP не микроиком обслуживается, а пропускается дальше (как свитч).
Выше описанная ситуация была, когда провайдер дал оптику и надо было настроить выше описанным методом.
P.S.
Провайдер давал просто адреса, не vlan
> это какой-то из всегда_доступных_узлов (например 8.8.8.8 или 8.8.4.4)
На всякий случай уточню, что эти сервера всегда работают, но _не_всегда_ доступны. Так что пинг на них может и пропасть, просто потому, что они — anycast.
В общем, либо пингу на такие точки верить с оглядкой (обобщать несколько замеров, брать не только гугловские ДНС, но и Яндексовские — всяко поближе будет).
На всякий случай уточню, что эти сервера всегда работают, но _не_всегда_ доступны. Так что пинг на них может и пропасть, просто потому, что они — 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)
Причина проста: всем узлам задаётся таблица маршрутизации, в которой указан только 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 — должно работать полностью.
Кроме того, если немного скорректировать балансировку с ECMP — вместо роутинг марка mixed использовать «дефолтный» main — должно работать полностью.
Интересно получается с манглами: если нет дефолтного маршрута то схема не работает.
то есть для работающей схемы нужен дефолтный маршрут + два маршрута с метками.
P.S. Это я про доступность роутера из-вне по разным интерфейсам.
то есть для работающей схемы нужен дефолтный маршрут + два маршрута с метками.
P.S. Это я про доступность роутера из-вне по разным интерфейсам.
А ведь и правда не работает балансировка исходящего траффика от самого микротика.
Господа, может кто нибудь нашел способ? Поделитесь!
Мне надо распределить по нескольким каналам несколько туннелей. Попробовал и EMCP, и PCC, счетчики растут но траффик бежит упорно через один интерфейс. Хотя если рассматривать таблицу прохождения пакетов iptables, то mangle output должен был поменять ему маршрут, далее route recheck.
Господа, может кто нибудь нашел способ? Поделитесь!
Мне надо распределить по нескольким каналам несколько туннелей. Попробовал и EMCP, и PCC, счетчики растут но траффик бежит упорно через один интерфейс. Хотя если рассматривать таблицу прохождения пакетов iptables, то mangle output должен был поменять ему маршрут, далее route recheck.
Спасибо!
Настроил failover с двумя провайдерами. А как быть с их DNS? Как сделать, что бы для каждого провайдера использовался «его» DNS?
И ещё, если не сложно: следующим этапом планирую прикручивать OpenVPN-туннель. Внешний IP даёт только основной провайдера, его доступность >95%. Потеря туннеля при работе через резерв не беспокоит. Но не возникнет ли проблем с доступом в подсеть за туннелем, из-за предложенных «хитростей» в роутах?
Настроил failover с двумя провайдерами. А как быть с их DNS? Как сделать, что бы для каждого провайдера использовался «его» DNS?
И ещё, если не сложно: следующим этапом планирую прикручивать OpenVPN-туннель. Внешний IP даёт только основной провайдера, его доступность >95%. Потеря туннеля при работе через резерв не беспокоит. Но не возникнет ли проблем с доступом в подсеть за туннелем, из-за предложенных «хитростей» в роутах?
А как насчет использования DNS того же Гугла?
8.8.8.8 да 8.8.4.4
8.8.8.8 да 8.8.4.4
Попробуйте на самом роутере поднять роль DNS-сервера, а в качестве источников для него укажите все DNS-серверы обоих провайдеров. Это костыль, но работать будет. Для внутренних абонентов укажите DNS-сервер, который на роутере.
Второй вариант — статические маршруты.
Второй вариант — статические маршруты.
До костыля с единым списком «всех DNS» я дотумкал самостоятельно, и как раз, понимая, что «это костыль» — хотел найти другое решение. Про «статические маршруты» — пока не осознал… Имеете ввиду прописать отдельно для LAN-WAN1 и LAN-WAN2?
Кстати, а не честнее ли будет сделать failover на скриптах? Не нашёл сравнения преимуществ/недостатков этих двух решений.
Кстати, а не честнее ли будет сделать 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
Файловер на скриптах — это попытка использования только одного провайдера в один момент времени. В случае полноценного использования двух каналов одновременно(а в случае падения одного из каналов использовать резервный) требуется подобное решение, которое описано в статье.
Мне правда описанное в статье нравиться немного по другому делать, но этот способ тоже вполне жизнеспособен.
В коде это выглядит примерно так(по памяти):
/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. Я правильно понимаю, что «оповещение» один фиг скриптами будет?
Моя задача — как раз организация резервного канала, т.к. нет никакого смысла складывать «100мбит» основного и «2мбит» резервного. Кроме того, мне нравится идея оповещения (e-mail, SMS или ещё как) о падении «основного» — так у меня раньше жил mwan3 под OpenWRT. Я правильно понимаю, что «оповещение» один фиг скриптами будет?
Маркировать СОЕДИНЕНИЯ в цепочке 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
/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), а не к самому роутеру (WinBox или SSH, например).
Sign up to leave a comment.
Mikrotik. Failover. Load Balancing