В статье будет рассмотрен способ подключения двух провайдеров к маршрутизатору микротик, использование 2-х провайдеров может быть двумя способами резервирование и балансировка. Резервирования каналов интернета, то есть в постоянной активности будет основной канал, а другой (резервный) будет запускаться в том случае, когда первый будет не активен, используется, если допустим 2-й оператор предоставляет интернет с ограниченным трафиком или через GSM модем. Балансировка, когда одновременно работает 2 провайдера.
Резервирование
Резервирование, когда работает только один провайдер, второй в это время выключен, если у первого происходит авария, интернет через него не доступен, то включается второй оператор, при доступности интернета через основной линк, второй отключается и снова весь трафик идет через основной канал.
Быстрый способ
Допустим, шлюзом первого провайдера ISP1 является ip 1.1.1.1 он же наш основной канал шлюз второго ISP2 ip 2.2.2.2 резервный провайдер.
Заходим В меню IP-Routes, и добавляем новое правило. Заполняем поля как на рисунке.
Аналогично настраиваем второго провайдера ISP2? Только метрику Distance ставим больше 1, например 10
Комплексный способ
Данный способ основывается на систематической проверке (раз в 1 минуту) доступности какого либо ресурса в интернете, например DNS гугла 8.8.8.8.. Схема такова: если пинг проходит, значит ISP1 канал активен и ISP2 может быть отключен, в противном случае включается второй, а 1-й должен быть выключен.
Аналогично, как и в первом случае добавляем маршруты, только без проверки шлюза и с равной метрикой 10. Обязательно добавляем комментарий, он нам пригодится позже.
Балансировка каналов
Настроим одновременную работу двух провайдеров, переходим снова в меню IP-routes и добавляем следующий маршрут по умолчанию.
./p%20pДавайте%20рассмотрим%20что%20же%20мы%20можем%20сделать:/p%20pСразу%20предупрежу:%20несмотря%20на%20то,%20что%20в%20этой%20статье%20буду%20все%20описывать%20для%20mikrotik,%20не%20буду%20касаться%20темы%20скриптов/p%20h2span%20id=)
Failover
У нас появился резервный канал, в который можно направить трафик при отказе основного. Но как сделать, чтобы mikrotik понял, что канал упал?
Простейшее резервирование каналов
Простейший failover можно настроить, используя приоритет маршрута (distance у mikrotik/cisco, metric в linux/windows), а так же механизм проверки доступности шлюза — check-gateway.
В приведенной ниже конфигурации весь интернет трафик по умолчанию ходит через 10.100.1.254 (ISP1). Но как только адрес 10.100.1.254 станет недоступным (а маршрут через него неактивным) — трафик пойдет через 10.200.1.254 (ISP2).
конфигурация: простейший failover
check-gateway=ping для mikrotik обрабатывается так:Периодически (каждые 10 секунд) шлюз проверяется отсылкой на него ICMP пакета (ping). Потерянным пакет считается, если он не вернулся в течении 10 секунд. После двух потерянных пакетов шлюз считается недоступным. После получения ответа от шлюза он становится доступным и счетчик потерянных пакетов сбрасывается.
Обеспечение failover с более глубоким анализом канала
В прошлом примере все замечательно, кроме ситуации, когда шлюз провайдера виден и пингуется, но интернета за ним нет. Нам бы это здорово помогло, если бы можно было принимать решение о жизнеспособности провайдера, пингуя не сам шлюз, а что-то за ним.
Я знаю два варианта решения этой инженерной задачи. Первый и самый распространенный — использовать скрипты, но так как в этой статье мы скрипты не трогаем, остановимся подробнее на втором. Он подразумевает не совсем корректное использование параметра scope, но поможет нам прощупать канал провайдера глубже, чем до шлюза.
Принцип прост:
Вместо традиционного указания default gateway=шлюз провайдера, мы скажем роутеру что default gateway это какой-то из всегда_доступных_узлов (например 8.8.8.8 или 8.8.4.4) и он в свою очередь доступен через шлюз провайдера.
конфигурация: failover с более глубоким анализом канала
Теперь разберем, что происходит чуть подробнее:
Хитрость в том, что шлюз провайдера не знает о том, что 8.8.8.8 или 8.8.4.4 — это роутер и направит трафик по обычному пути.
Наш mikrotik считает, что по умолчанию весь интернет трафик нужно отправлять на 8.8.8.8, который напрямую не виден, но через 10.100.1.254 доступен. А если пинг на 8.8.8.8 пропадает (напомню что путь к нему у нас жестко указан через шлюз от ISP1) то mikrotik начнет слать весь интернет трафик на 8.8.4.4, а точнее на рекурсивно определенный 10.200.1.254 (ISP2).
Но у меня пару раз возникала ситуация, когда интернет через шлюз провайдера работает, а вот конкретный узел или сеть нет. В таких случаях вышеописанный метод не очень-то помогает и для обеспечения бесперебойной работы мне приходилось проверять доступность узла уже с помощью скриптов. Кстати, если кто знает решение файловера на один внешний хост без применения скриптов и протоколов динамической маршрутизации — поделитесь рецептом.
Load Balancing
Теперь давайте рассмотрим другую схему:
В ней второй второй канал уже не резервный, а равноценный. Почему бы не использовать оба канала одновременно, повысив таким образом пропускную способность?
Начинаем настраивать Load Balancing
Первое правило Load Balancing — следить за соединениями: на пришедшее извне соединение отвечать с того же адреса, на который оно пришло. Для исходящих соединений — отправлять пакеты только через тот адрес, с которым установилось соединение.
Второе, что тоже важно понимать — нужно разделять понятия входящего и исходящего трафика. Дело в том, что для исходящего трафика роутер может решать, по какому пути он пойдет, а входящий трафик для него как «трафик Шредингера». Пока его нет, наш mikrotik не знает, через какой интерфейс он придет, а когда пришел — менять интерфейс уже поздно.
Третье — балансировка каналов не является резервированием. Это две отдельные функции.
Кстати почему при разделе трафика мы оперируем соединениями, а не пакетами?Почитайте, как работает TCP протокол. Если коротко — задача TCP протокола не только швырнуть пакетом в получателя, но и проконтролировать, как тот его принял. Делается это с помощью установки соединения, в рамках которого, собственно, и передаются пакеты данных — вместе со служебной информацией. Если оперировать пакетами и забыть про соединения, то возможны ситуации, когда удаленный хост, установив соединение с одним адресом, просто отбросит часть пакетов пришедшую со второго — «неправильного» адреса.
Готовимся принять «трафик Шредингера»
Итак, при любом варианте балансировки канала нам нужно сначала подготовиться к принятию входящего трафика и научить mikrotik отвечать на входящие соединения в тот же канал, из которого они пришли. С помощью маркировки соединений и последующей маркировки маршрутов для них мы, по сути, делаем несколько таблиц маршрутизации, отдельных для каждого внешнего адреса.
начальная конфигурация для load balancing с двумя внешними IP адресами
Таким образом mikrotik будет проводить каждый пакет помеченного соединения по соответствующей таблице маршрутизации и внешние адреса (10.100.1.1, 10.200.1.1) будут доступны извне без путаницы в каналах и маршрутах.
Делим исходящий трафик
Для распределения исходящего трафика по интерфейсам, нам всего-то нужно повесить соответствующую марку маршрута на соединение. Сложность в том, что нужно решить на какое соединение вешать метку ISP1, а на какое ISP2.
Существует несколько вариантов разделения соединений по группам:
1) Делим исходящий трафик, прикручивая марку намертво
Правила, балансирующие трафик мы можем прописать жестко:
Например мы хотим настроить важные для нас протоколы HTTP(80 port), HTTPS (443 port), POP (110 port), SMTP (25 port) через ISP1, а весь остальной трафик пустить через второго провайдера:
конфигурация с балансировкой канала по жестко прописанным правилам
2) Делим исходящий трафик, выбирая каждое Н-ое соединение
Можем делить соединения по-порядку. Первые налево, вторые — направо. Все просто.
конфигурация с балансировкой канала по Н-ному соединению:
3) Делим исходящий трафик, используя PCC (per connection classifier)
PCC подходит к дележу трафика чуть сложнее. Он разделяет трафик по группам, основываясь на данных TCP заголовка (src-address, dst-address, src-port, dst-port).
конфигурация с балансировкой канала по PPC:
Делим исходящий трафик, используя ECMP (equal cost multipath routing)
На мой взгляд самый простой и вкусный вариант разделения траффика:
конфигурация с балансировкой канала по ECMP
Mikrotik сам поделит трафик по шлюзам, используя round-robin алгоритм.
Кстати, в версии 6.Х RouterOS mikrotik поломал check-gateway в ECMP, так что использовать конструкцию
/ip route add gateway=10.100.1.254,10.200.1.254 check-gateway=ping можно и логично, но абсолютно бесполезно.
Для пометки неживых маршрутов в ECMP нужно создать дополнительные маршруты, которые используют каждый из gateway по-отдельности. С включенным check-gateway разумеется. Помечая маршрут неактивным, mikrotik делает это для всех.
И последнее немаловажное замечание про скорость каналов
Возьмем 2 неравнозначных канала, например, 100 мбит и 50 мбит. Сбалансируем их через Nth, PCC или ECMP. Какую суммарную пропускную способность получим?
На самом деле — где-то около 100 мбит (самый слабый канал Х раз).
Происходит это потому, что mikrotik понятия не имеет о пропускной способности каналов, он ее не измеряет. Он просто делит трафик на относительно равные группы.
Побороть этот нюанс можно правильно проектируя группы исходящего трафика, с учетом пропускной способности каналов.
Напримерв ECMP это можно сделать указав более скоростной шлюз несколько раз, тем самым повышая частоту его использования.
В PCC тоже можно сделать неравные группы:
Спасибо за внимание.
Удачи в настройках безотказных систем маршрутизации.
В последнее время ситуация, когда доступны несколько провайдеров не нова, MikroTik Router OS позволяет настроить доступ сразу по нескольким сетевым интерфейсам, а так же настроить балансировку нагрузки в зависимости от ограничений, которые выставляет провайдер.
Первым шагом настроим дополнительный интерфейс.
Инициализируем сам интерфейс.
[mkt@MikroTik] /interface> print
Flags: D — dynamic, X — disabled, R — running, S — slave
# NAME TYPE MTU
0 R ether1 ether 1500
1 R ether2 ether 1500
2 X ether3 ether 1500
[mkt@MikroTik] /interface> enable 2
[mkt@MikroTik] /interface> print
Flags: D — dynamic, X — disabled, R — running, S — slave
# NAME TYPE MTU
0 R ether1 ether 1500
1 R ether2 ether 1500
2 R ether3 ether 1500
Для удобства все же пора дать более понятные имена интерфейсам.
[mkt@MikroTik] /interface> set ether1 name=»ISP1″
[mkt@MikroTik] /interface> set ether2 name=»LOCAL»
[mkt@MikroTik] /interface> set ether3 name=»ISP2″
[mkt@MikroTik] /interface> print
Flags: D — dynamic, X — disabled, R — running, S — slave
# NAME TYPE MTU
0 R ISP1 ether 1500
1 R LOCAL ether 1500
2 R ISP2 ether 1500
Теперь назначим IP адрес новому интерфейсу.
[mkt@MikroTik] > ip address add address=192.168.222.100/24 interface=ISP2
[mkt@MikroTik] > ip address print
Flags: X — disabled, I — invalid, D — dynamic
# ADDRESS NETWORK BROADCAST INTERFACE
0 192.168.1.116/24 192.168.1.0 192.168.1.255 ISP1
1 192.168.0.1/24 192.168.0.0 192.168.0.255 LOCAL
2 192.168.222.100/24 192.168.222.0 192.168.222.255 ISP2
Настало время изменить маршрутизацию по умолчанию. Для начала допустим, что оба провайдера предоставляют одинаковую скорость доступа к сети Internet, значит настроим балансировку (это когда для исходящих соединений каналы чередуются), так что бы запросы распеределялись равномерно, т.е. 50/50. Прежде всего удалим старый шлюз по умолчанию.
[mkt@MikroTik] > ip route print
Flags: X — disabled, A — active, D — dynamic,
C — connect, S — static, r — rip, b — bgp, o — ospf, m — mme,
B — blackhole, U — unreachable, P — prohibit
# DST-ADDRESS PREF-SRC GATEWAY DISTANCE
0 A S 0.0.0.0/0 192.168.1.249 r. 1
1 ADC 192.168.0.0/24 192.168.0.1 LOCAL 0
2 ADC 192.168.1.0/24 192.168.1.116 ISP1 0
3 ADC 192.168.222.0/24 192.168.222.100 ISP2 0
[mkt@MikroTik] > ip route remove 0
[mkt@MikroTik] > ip route print
Flags: X — disabled, A — active, D — dynamic,
C — connect, S — static, r — rip, b — bgp, o — ospf, m — mme,
B — blackhole, U — unreachable, P — prohibit
# DST-ADDRESS PREF-SRC GATEWAY DISTANCE
0 ADC 192.168.0.0/24 192.168.0.1 LOCAL 0
1 ADC 192.168.1.0/24 192.168.1.116 ISP1 0
2 ADC 192.168.222.0/24 192.168.222.100 ISP2 0
И добавим новый, точнее новые.
[mkt@MikroTik] > ip route add dst-address=0.0.0.0/0
gateway=192.168.1.249,192.168.222.1
[mkt@MikroTik] > ip route print
Flags: X — disabled, A — active, D — dynamic,
C — connect, S — static, r — rip, b — bgp, o — ospf, m — mme,
B — blackhole, U — unreachable, P — prohibit
# DST-ADDRESS PREF-SRC GATEWAY DISTANCE
0 A S 0.0.0.0/0 192.168.1.249 r. 1
192.168.222.1 r.
1 ADC 192.168.0.0/24 192.168.0.1 LOCAL 0
2 ADC 192.168.1.0/24 192.168.1.116 ISP1 0
3 ADC 192.168.222.0/24 192.168.222.100 ISP2 0
Предположим, что у первого провайдера скорость доступа в два раза выше чем у второго, тогда 2/3 исходящих запросов надо направить на первого, а оставшиеся 1/3 на второго.
[mkt@MikroTik] > ip route add dst-address=0.0.0.0/0
gateway=192.168.1.249,192.168.1.249,192.168.222.1
[mkt@MikroTik] > ip route print
Flags: X — disabled, A — active, D — dynamic,
C — connect, S — static, r — rip, b — bgp, o — ospf, m — mme,
B — blackhole, U — unreachable, P — prohibit
# DST-ADDRESS PREF-SRC GATEWAY DISTANCE
0 A S 0.0.0.0/0 192.168.222.1 r. 1
192.168.1.249 r.
192.168.1.249 r.
1 ADC 192.168.0.0/24 192.168.0.1 LOCAL 0
2 ADC 192.168.1.0/24 192.168.1.116 ISP1 0
3 ADC 192.168.222.0/24 192.168.222.100 ISP2 0
Это простейший вариант настройки, при котором получаем выход в интернет с балансировкой нагрузки, но у такого подхода есть ряд недостатков, на пример не будет работать доступ через на NAT к локальному серверу (сервисы web, smtp, pop, которые были настроены ранее), но не такая большая проблема, но об этом в следующий раз.
После добавления в нашу тестовую конфигурацию второго провайдера появилась проблема ответа определенных сервисов по нужному каналу, если обращаться к ним из вне через NAT.
На пример веб сервер, выведенный через NAT на IP адрес первого провайдера получает запрос, а вот вероятность того, что ответ пойдет по нужному каналу уже не 100%. Какой же он после этого веб сервер?
Решить эту проблему нам поможет механизм маркировки пакетов.
Таблица MANGLE предназначена для операций по классификации и маркировке пакетов и соединений, а также модификации заголовков пакетов. В частности нас интересует цепочка PREROUTING, которая позволяет маркировать пакет до маршрутизации.
Попробуем разобраться с веб сервером.
Допустим у нас настроен NAT 80 порта с внешнего IP 192.168.1.116 (ISP1, первый провайдер) на 80 порт веб сервера в локальной сети и необходимо гарантировать, что все ответы, которые буду идти от веб сервера попадали на шлюз первого провайдера.
Вот правило для таблицы NAT.
[mkt@MikroTik] > ip firewall nat add chain=dstnat dst-address=192.168.1.116
protocol=tcp dst-port=80 action=dst-nat to-addresses=192.168.0.2 to-ports=80
comment=»NAT 80 port from ISP1 to local web server»
[mkt@MikroTik] > ip firewall nat print
Flags: X — disabled, I — invalid, D — dynamic
0 chain=srcnat action=masquerade out-interface=!LOCAL
1 ;;; NAT 80 port from ISP1 to local web server
chain=dstnat action=dst-nat to-addresses=192.168.0.2 to-ports=80
protocol=tcp dst-address=192.168.1.116 dst-port=80
Первым шагом создадим правило в таблице MANGLE.
[mkt@MikroTik] > ip firewall mangle add chain=prerouting src-address=192.168.0.2
protocol=tcp src-port=80 action=mark-routing new-routing-mark=to-isp1
[mkt@MikroTik] > ip firewall mangle print
Flags: X — disabled, I — invalid, D — dynamic
0 chain=prerouting action=add-src-to-address-list protocol=tcp
address-list=test_list address-list-timeout=0s dst-port=23
1 chain=prerouting action=mark-routing new-routing-mark=to-isp1
passthrough=yes protocol=tcp src-address=192.168.0.2 src-port=80
Пакеты с локального адреса 192.168.0.2 с 80 порта буду маркироваться как to-isp1.
Вторым шагом добавим правило в таблицу маршрутизации.
[mkt@MikroTik] > ip route add gateway=192.168.1.249 routing-mark=to-isp1
[mkt@MikroTik] > ip route print
Flags: X — disabled, A — active, D — dynamic,
C — connect, S — static, r — rip, b — bgp, o — ospf, m — mme,
B — blackhole, U — unreachable, P — prohibit
# DST-ADDRESS PREF-SRC GATEWAY DISTANCE
0 A S 0.0.0.0/0 192.168.1.249 r. 1
1 A S 0.0.0.0/0 192.168.1.249 r. 1
192.168.1.249 r.
192.168.222.1 r.
2 ADC 192.168.0.0/24 192.168.0.1 LOCAL 0
3 ADC 192.168.1.0/24 192.168.1.116 ISP1 0
4 ADC 192.168.222.0/24 192.168.222.100 ISP2 0
Все что приходит с маркером to-isp1 отправляется на шлюз первого провайдера.
Теперь усложним ситуацию, допустим второй провайдер предоставят на выгодных условиях большую локальную сеть по всему городу и через эту сеть объединены все 10 филиалов вашей фирмы. Все филиалы и офис пользуются тем же сайтом, но какой смысл ходить на него через первого провайдера, когда можно настроить доступ к нему практически локально.
В первую очередь добавляем правило в таблицу NAT, по которому все запросы, пришедшие на внешний IP адрес, который предоставляет 2-ой провайдер, на 80 порт будут переадресовываться на 80 порт локального веб сервера.
[mkt@MikroTik] > ip firewall nat add chain=dstnat dst-address=192.168.222.100
protocol=tcp dst-port=80 action=dst-nat to-addresses=192.168.0.2 to-ports=80
comment=»NAT 80 port from ISP2 to local web server»
[mkt@MikroTik] > ip firewall nat print
Flags: X — disabled, I — invalid, D — dynamic
0 chain=srcnat action=masquerade out-interface=!LOCAL
1 ;;; NAT 80 port from ISP1 to local web server
chain=dstnat action=dst-nat to-addresses=192.168.0.2 to-ports=80
protocol=tcp dst-address=192.168.1.116 dst-port=80
2 ;;; NAT 80 port from ISP2 to local web server
chain=dstnat action=dst-nat to-addresses=192.168.0.2 to-ports=80
protocol=tcp dst-address=192.168.222.100 dst-port=80
Следующим шагом добавим в таблицу MANGLE еще одно правило:
[mkt@MikroTik] > ip firewall mangle add chain=prerouting src-address=192.168.0.2
protocol=tcp src-port=80 dst-address=192.168.222.0/24 action=mark-routing
new-routing-mark=to-isp2
[mkt@MikroTik] > ip firewall mangle print
Flags: X — disabled, I — invalid, D — dynamic
0 chain=prerouting action=add-src-to-address-list protocol=tcp
address-list=test_list address-list-timeout=0s dst-port=23
1 chain=prerouting action=mark-routing new-routing-mark=to-isp2
passthrough=yes protocol=tcp src-address=192.168.0.2
dst-address=192.168.222.0/24 src-port=80
2 chain=prerouting action=mark-routing new-routing-mark=to-isp1
passthrough=yes protocol=tcp src-address=192.168.0.2 src-port=80
Пакеты с локального адреса 192.168.0.2 с 80 порта буду маркироваться как to-isp2 если они предназначены для подсети второго провайдера.
Ну и в заключении правило в таблице маршрутизации:
[mkt@MikroTik] > ip route add gateway=192.168.222.1 routing-mark=to-isp2
[mkt@MikroTik] > ip route print
Flags: X — disabled, A — active, D — dynamic,
C — connect, S — static, r — rip, b — bgp, o — ospf, m — mme,
B — blackhole, U — unreachable, P — prohibit
# DST-ADDRESS PREF-SRC GATEWAY DISTANCE
0 A S 0.0.0.0/0 192.168.1.249 r. 1
1 A S 0.0.0.0/0 192.168.222.1 r. 1
2 A S 0.0.0.0/0 192.168.1.249 r. 1
192.168.1.249 r.
192.168.222.1 r.
3 ADC 192.168.0.0/24 192.168.0.1 LOCAL 0
4 ADC 192.168.1.0/24 192.168.1.116 ISP1 0
5 ADC 192.168.222.0/24 192.168.222.100 ISP2 0
Теперь на запросы, пришедшие со стороны первого провайдера, ответ пойдет на шлюз первого провайдера, а на запросы со стороны второго провайдера и из подсети второго провайдера ответ пойдет на шлюз второго провайдера.
«>
