Настройка bgp на маршрутизаторах микротик

Summary

The Border Gateway Protocol (BGP) allows setting up an interdomain dynamic routing system that automatically updates routing tables of devices running BGP in case of network topology changes.
MikroTik RouterOS supports BGP Version 4, as defined in RFC 4271
Standards and Technologies:

  • RFC 4271 Border Gateway Protocol 4
  • RFC 4456 BGP Route Reflection
  • RFC 5065 Autonomous System Confederations for BGP
  • RFC 1997 BGP Communities Attribute
  • RFC 2385 TCP MD5 Authentication for BGPv4
  • RFC 5492 Capabilities Advertisement with BGP-4
  • RFC 2918 Route Refresh Capability
  • RFC 4760 Multiprotocol Extensions for BGP-4
  • RFC 2545 Use of BGP-4 Multiprotocol Extensions for IPv6 Inter-Domain Routing
  • RFC 4893 BGP Support for Four-octet AS Number Space

Advertisements

Sub-menu:

Read only information about outgoing routing information currently advertised.

This information is calculated dynamically after ‘print’ command is issued. As a result, it may not correspond to the information that at the exact moment has been sent out. Especially if in case of slow connection, routing information prepared for output will spend long time in buffers. ‘advertisements print’ will show as things should be, not as they are!

Note: At the moment AS-PATH attribute for advertised routes is shown without prepends.

Property Description
aggregator (IP) Advertised AGGREGATOR attribute value
as-path (string) Advertised AS_PATH attribute value
atomic-aggregate (yes | no) Advertised ATOMIC_AGGREGATE attribute value
bgp-ext-communities ()
cluster-list (string) Advertised CLUSTER_LIST attribute value
communities ()
local-pref (integer) Advertised LOCAL_PREF attribute value
med (integer) Advertised MULTI_EXIT_DISC attribute value
nexthop (IP | IPv6) Advertised NEXT_HOP attribute value
origin (igp | egp | incomplete) Advertised ORIGIN attribute value
originator-id (IP) Advertised ORIGINATOR_ID attribute value
peer (string) Name of the peer this information is advertised to
prefix (IPv4 | IPv6 prefix) Advertised NLRI prefix

Траблшутинг

Когда файрвол не работает или работает не так, как подразумевалось при настройке, виноват админ. Магии не бывает

Первое, на что стоит обратить внимание при траблшутинге, — счетчики пакетов. Если счетчик не увеличивается, значит, трафик в него не попадает

А если трафик не попадает, значит, либо этого трафика просто нет, либо он был обработан стоящим выше правилом.

Счетчики

Ты же помнишь, что правила файрвола работают по принципу «кто первый встал — того и тапки»? Если пакет попал под действие правила, то дальше он уже не пойдет. Значит, нужно искать проблему выше. Просто копируем наше правило, action ставим accept (для траблшутинга не делай дроп — так при проверке можно сломать себе доступ или нарушить работу сети) и постепенно двигаем его наверх до первого увеличения счетчиков в этом правиле. Если через это правило уже проходил трафик, то счетчики будут ненулевые и можно пропустить нужные нам пакеты, — просто сбрось счетчики в этом правиле или во всех кнопками Reset Counters.

Reset Counters

или

Предположим, мы нашли правило, в которое попадает наш трафик, а попадать не должен. Нужно понять, почему так происходит. В этом нам поможет опция Log. Во вкладке Action ставим галочку Log (можно написать префикс для правила, чтобы было проще отлавливать его в логах) и смотрим логи, где написаны все характеристики пакетов, попадающих под правило. Среди характеристик: цепочка, входящий и исходящий интерфейсы, адреса и порты источника и получателя, протокол, флаги, размер пакета, действия NAT.

Лог

Если даже в самом верху в правиле не будут увеличиваться счетчики, убирай правила из условия по одному. Начинай с интерфейсов — админы часто путаются в своих представлениях о том, откуда или куда должен идти трафик (например, при коннекте к провайдеру через PPPoE или в туннелях между филиалами или сложном роутинге). Счетчики пошли? Включаем лог и смотрим интерфейсы и другие параметры.

Чтобы упростить траблшутинг, можно использовать функцию комментирования. Если из-за комментов окно становится слишком большим и это мешает смотреть на правила, воспользуйся инлайновыми комментариями (Inline Comments). Так комменты встанут с правилом в одну строку и в окно будет умещаться больше правил.

Inline Comments

Также рекомендую распределять правила по порядку, следуя какой-то определенной логике. И старайся ее поддерживать на всех роутерах.

Simple queue vs Queue Tree

В Mikrotik присутствуют 2 типа очередей:

  • Simple Queues — простой тип очередей.
  • Queue Tree — очереди из иерархических деревьев с правилами.

Отличий у этих очередей много. Показываю наиболее значимые в виде таблицы. Автор этой таблицы — Дмитрий Скоромнов. По крайней мере я ее увидел у него.

Разница между Simple queue и Queue Tree
Опция Simple Queue Queue Tree
Порядок правил играет роль не играет роль
Маркировка трафика возможна обязательная
Время действия правила возможно не возможно
График загрузки есть нет

В целом, настройка Simple Queues более простая и очевидная, в то время как Queue Tree позволяют строить более сложные конфигурации QOS с обязательным использованием маркировки в Mangle. В случае же с Simple Queues в простых ситуациях достаточно будет информации об адресах источника и получателя. Маркировать ничего не придется.

Что же выбрать для настройки QOS — Simple queue или Queue Tree? Я советую начать с простых очередей. Если ваша задача не решается с их помощью, переходите на иерархические деревья правил с маркировкой. И еще нужно понимать, что Simple queue это частный случай Queue Tree, поэтому при использовании обоих типов очередей нужно внимательно смотреть на то, чтобы правила не пересекались в разных очередях.

Перенаправление портов Mikrotik

Все настройки по прокидыванию портов делаются в разделе IP -> Firewall -> Nat. Ниже опишу все параметры и на примере пробросим RDP 3389 на сервер или компьютер.

Стрелочками показано в какой раздел заходить, нажимаем + и создадим новое правило NAT. Итак:

  • Chain – здесь выбираем что будем заменять в ip пакете (то есть адрес отправителя или получателя). Для нашего примера с RDP выбираем dstnat.
  • Src. Address – можем указать тут конкретный ip с которого нужно осуществлять проброс порта (то есть если здесь указать 2.45.34.77, то при работающем правиле проброс будет работать только при подключении с этого адреса). Нам этого не надо поэтому оставляем пустым.
  • Dst. Address – здесь указываем белый ip нашего роутера к которому будет подключаться по RDP а он в свою очередь будет натить на сервер. (Здесь имеет смыслю указывать ip если у вас несколько белых адресов на интерфейсе.) В нашем случае оставляем пустым.
  • Protocol – выбираем какой протокол будем пробрасывать (RDP работает по TCP протоколу и порту 3389). Очевидно, выбираем
  • Src. Port – Порт с которого будет подключения. Оставляем пустым, для нашего примера он не нужен.
  • Dst. Port – вот здесь указываем 3389 как писалось выше.
  • Any. Port – бываю случае порты src и dst одинаковые его можно вписать сюда, или когда нужно пробросить все TCP. (оставляем пустым)
  • In. Interface – входящий интерфейс микротика, указываем тот на котором висит белый ip. У меня этот. 
  • Out. Interface – исходящий интерфейс, тут можно указать тот который смотрит в вашу локальную сеть а можно и ничего не указывать, тогда mikrotik сам выберет его по адресу подсети.
  • In. Interface list – тут указывается интерфейс лист. То есть, если у вас 2 и более каналов в интернет, их можно все объединить в interface list и указать тут. Тогда не надо будет для каждого провайдера делать правило проброса RDP.
  • Out. Interface List – тоже самое что и 10 пункт только исходящий.

Остальные пункты с 12 по 16 вам сейчас не нужны, они используются для более сложных схем, таких как маркировка трафика и отправка его в конкретную таблицу маршрутизации и тд.

Теперь переходим на вкладку Action на которой мы скажем роутеру что делать с полученным пакетом и куда его отправлять.

Здесь настраиваем так:

  • Action – действие которое mikrotik должен произвести, выбираем dst-nat, так как нам надо запрос приходящий на белый ip с портом 3389 перенаправить на адрес из серой сети.
  • Галочка Log будет писать все nat трансляции в лог файл – этого делать не стоит.
  • Log Prefix – будет добавлять в лог в начало строки произвольные символы которые тут напишете.
  • To Addresses – люда вписываем ip сервера (серый) на который нужно настроить перенаправление портов на mikrotik.
  • To Ports – ну и TCP порт на который пересылать.

Вот так просто настраивается проброс портов на mikrotik, дальше приведу еще несколько примеров для различных сервисов.

Настройка Simple queue в Mikrotik

Давайте потихоньку переходить к практике. Но перед этим необходимо проверить важную деталь. Для того, чтобы в Mikrotik работали очереди, необходимо обязательно отключить . Для начала настроим равномерное распределение трафика между клиентами. Их у меня будет два:

  • 192.168.88.195 — ubuntu18.
  • 192.168.88.196 — centos7.
  • 10.20.1.23 — сервер в «интернете», к которому будем подключаться и проверять скорость соединения.

Адрес Микротика — 192.168.88.1. Измерять скорость буду с помощью программы iperf. Канал в интернет — 100 Мбит/c. Для начала посмотрим, как будет распределяться канал между клиентами без настройки qos. Для этого просто запускаю iperf на обоих клиентах с разницей в 10 секунд.

Я сначала запустил проверку скорости на ubuntu18, а через 10 секунд на centos7. Видно, что ubuntu сначала качала на полной скорости 100 Мбит/c, а потом, при запуске параллельного теста на centos, снизила скорость на треть. По факту получилось, что кто раньше запустил тест, тот и забрал себе больше канала. Средняя скорость загрузки разных клиентов отличается — 51.9 Mbits/sec у того, кто начал позже, против 79.4 Mbits/sec. Если бы тут работал какой-нибудь торрент клиент, он бы забрал большую часть канала себе.

А теперь сделаем так, чтобы скорость между клиентами распределялась равномерно. Для этого идем в очереди и создаем simple queue.

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

Работает четкое равномерное деление скорости интернет канала. В настройке Target у меня указан bridge, в который объединены все интерфейсы локальной сети. Там можно указать адрес или подсеть, например 192.168.88.0/24. Все зависит от того, что конкретно вы хотите сделать и между кем и кем поделить поровну интернет. Если у вас выход из этой локальной сети есть не только в интернет, но и в другие подсети, то укажите в Dst свой wan интерфейс, иначе скорость будет резаться всегда для всех адресов назначения.

Разберу основные параметры, которые есть в simple queue. Напомню, что все это можно посмотреть в .

Target Как я уже сказал, источник, к которому будет применено queue правило. Можно указать интерфейс или ip адрес.
Dst (destination) Интерфейс или адрес, куда будет направлен поток с ограничением по queue. Обычно какой-то внешний адрес.
Max Limit Максимально разрешенная скорость upload/download для данной очереди.
Burst Limit Максимально разрешенная скорость upload/download для включенного режима Burst.
Burst Threshold Граница средней скорости, превышение которой выключает режим burst.
Burst Time Интервал времени, в течении которого выполняется оценка средней скорости передачи данных (average-rate), которая используется для управления режимом burst.
Packet Marks Здесь выбираются промаркированные пакеты, если используется маркировка.
Limit At Скорость, которая выделяется очереди гарантированно.
Priority Приоритет для потоков данной очереди. 1 — максимальный приоритет, 8 — самый низкий.
Queue Type Выбор типа очереди, перечисленной в Queue Types.
Parent Очередь, являющейся родителем по отношению к текущей.

Теперь некоторые комментарии к перечисленным параметрам.

Трафик с более высоким приоритетом будет иметь преимущество в достижении скорости, указанной в max-limit

Отсюда следствие — очень важно корректно указывать и следить за max-limit. Обычно его указывают на 5% ниже реальной скорости канала

Сумма параметров max-limit дочерних очередей может превышать лимит родительской очереди, но не может быть меньше limit-at. Приоритет работает только для дочерних очередей, не родительских. Очереди c наивысшим приоритетом будут иметь максимальный шанс на достижение указанного в них max-limit.
С помощью Dst удобно управлять очередями в случае использования нескольких каналов wan. Достаточно указывать их интерфейсы в правилах очередей.
Приоритизировать можно только исходящий трафик! Не все это понимают и пытаются настраивать приоритеты для входящего.
Параметр limit at используется, чтобы гарантировать очереди заданную скорость, если это возможно. При этом он имеет преимущество перед приоритетом. То есть с его помощью можно гарантировать какую-то полосу пропускания трафику с низким приоритетом. Если данный канал не используется полностью, то он доступен другим очередям.

В целом, настройка simple queue в Микротике не представляет какой-то особой сложности и интуитивно понятна. Исключение только параметр Burst. Рассмотрим его отдельно.

Режим Local-forwarding

Отдельно рассмотрю настройку local-forwarding. Если он активирован, то всем трафиком клиентов точки доступа управляет сама точка, не контроллер. И большинство настроек datapath не используются, так как до контроллера трафик не доходит. Если этот параметр не установлен, то весь трафик на wifi интерфейсах точек инкапсулируется и отправляется по сети на контроллер. Он виден на его виртуальных интерфейсах. Управляется (firewall, qos и т.д.) в зависимости от настроек.

Обработка трафика на точке более распространенный и простой вариант. В этом случае нагрузка на каналы связи с контроллерами и на сам контроллер минимальна. Так же отключать local-forwarding не рекомендуется, если клиенты wifi сети ходят на какие-то локальные ресурсы, а контроллер у вас совершенно в другом сегменте сети, возможно удаленном с не очень толстым каналом связи. Пускать на него весь трафик клиентов бессмысленно. Это увеличит отклик и забьет канал связи с контроллером. Например, сотрудник пришел в офис и работает за ноутбуком по wifi. При этом активно использует сетевой диск. Вам нет смысла этот трафик гонять на контроллер.

Другой вариант, когда у вас все клиенты wifi сети это обычные пользователи интернета, например, гостевой сети. Никакого локального трафика у них нет. Да еще и сам контроллер находится рядом со шлюзом в интернет. Тогда можно их всех пропускать через Capsman и удобно управлять всем трафиком.

Приоритет HTTP трафика для максимально быстрого серфинга

Давайте теперь к нашим правилам добавим еще одно — приоритет http трафика. Благодаря этому, серфинг интернета будет всегда комфортным, даже если весь канал занят чем-нибудь другим. Причем мы сделаем так, чтобы http трафик не смог занять весь канал, так как с максимальным приоритетом это будет сделать не сложно. Особенно, если качать что-то объемное. Для этого мы его ограничим через max-limit и кратковременно ускорим через burst, чтобы серфить было комфортно.

Начнем настройку приоритета для http трафика. Для этого его надо промаркировать. Идем в IP -> Firewall -> Mangle и добавляем 2 правила маркировки.

То же самое делаем для https трафика, просто указав порт 443. Вот оба правила.

/ip firewall mangle
add action=mark-packet chain=forward comment=HTTP new-packet-mark=HTTP passthrough=yes port=80 protocol=tcp
add action=mark-packet chain=forward comment=HTTPS new-packet-mark=HTTP passthrough=yes port=443 protocol=tcp

Теперь идем добавлять новую очередь с более высоким приоритетом для веб трафика.

add burst-limit=50M/50M burst-threshold=15M/15M burst-time=16s/16s limit-at=10M/10M max-limit=20M/20M name=http_hi_Priority packet-marks=HTTP parent=wan1 priority=6/6 target=""

В итоге имеем следующий набор правил:

Не забываем про порядок правил в простых очередях. Он имеет значение, в отличие от queue tree.

Теперь проверяем, насколько заметно и корректно в итоге работает приоритизация http трафика. Я, как обычно, запущу iperf на двух других машинах в сети и параллельно с этим запущу веб серфинг на еще одном компьютере. Вот какая картина будет в списке очередей.

Если посмотреть статистику очереди с приоритетом http трафика, то там будет такая картинка.

Напоминаю, что при этом канал в интернет забит полностью другим трафиком, но из-за более высокого приоритета, www трафик бегает с заданными лимитами на ширину канала.

Я заметил небольшую особенность, причину которой не понял. Во время теста на ip 195, что на картинке справа, четко действует лимит в 10М, оставляя указанную полосу, даже если канал забивает более приоритетный трафик с сервера 196 слева. Но когда я запускают тест http трафика, он работает на максимальной скорости, но при этом у ip 195 полоса увеличивается примерно на 3-4М и становится в районе 13-14M, что выше указанного limit-at для этой очереди. Я сначала думал, что это просто погрешность какая-то, но эффект стабильно воспроизводится. Как только заканчивается http тест, скорость четко опускается до лимита в 10M. С чем это связано, я не понял.

Надеюсь, общая идея понятна. По такому принципу можно маркировать любой трафик и встраивать в дерево очередей на основе маркировки.

Как подключиться к Mikrotik через Winbox

Итак, утилиту мы скачали. Теперь рассмотрим варианты подключения к Mikrotik через Winbox. Тут проявляется еще одна очень полезная фишка микротиков. Если ты находишься с ним в одном широковещательном домене, то можно подключиться напрямую, используя mac адрес. Поясню для тех, кто не очень разбирается в теории сетей, о чем тут идет речь.

Расскажу по-простому. Единый широковещательный домен это как-будто вы подключены к микротику через общий свитч. Ваше соединение с ним осуществляется на канальном, втором уровне модели OSI. То есть вам не нужно ничего знать про ip адреса друг друга. Вы можете найти друг друга широковещательным запросом, а свитч вас соединит.

Такая возможность часто спасает, когда вы ошиблись в каких-то настройках ip адреса, или на фаерволе случайно закрыли себе доступ. Вы можете обойти ошибки на уровне ip, подключившись напрямую по mac адресу. Выглядит это следующим образом:

С помощью широковещательного запроса winbox обнаружил все доступные устройства Mikrotik в своем сегменте сети и получил возможность подключиться напрямую по mac адресу. Сразу скажу, что такое соединение менее стабильно, чем по ip. Вытекает это из особенностей протоколов подключения.

При подключении по IP адресу с помощью протокола TCP, осуществляется проверка целостности пакетов и подтверждение их доставки. При подключении по MAC этого не происходит, поэтому подключение менее стабильно. Это объясняет, почему во время подключения по mac часто происходит обрыв соединения и отключение от устройства. В общем случае лучше подключаться по ip адресу.

Когда мне приходилось удаленно настраивать Микротики, я всегда старался оставить себе возможность подключиться к устройству напрямую по mac. Понятно, что это не всегда получится и не всегда спасет, если ты по ошибке отключишь интернет. Но если была возможность подстраховаться, я ее использовал.

В общем случае для подключения по winbox достаточно убедиться в том, что включена соответствующая служба. Проверить это можно в разделе IP -> Services.

Если здесь отключить службу winbox, подключение через эту утилиту будет невозможно.

CRS3xx series features

Features Description
Forwarding
  • Full non-blocking wirespeed switching
  • Up to 16k MAC entries in Host table
  • Forwarding Database works based on SVL or IVL
  • Port Isolation
  • Jumbo frame support — 10218 bytes
Spanning Tree Protocol
Link Aggregation
  • Supports 802.3ad LACP groups
  • Supports static link aggregation groups
  • Up to 16 link aggregation groups
  • Up to 8 member ports per a group
  • Hardware automatic failover and load balancing
Multicast Forwarding
  • IGMP Snooping support
  • Unknown Multicast Filtering
Mirroring
VLAN
  • Fully compatible with IEEE802.1Q
  • Port based VLAN
  • Up to 250 VLAN entries (limited by SwOS)
  • VLAN filtering
Security
  • Port Lock
  • Broadcast Storm Control
  • DHCP & PPPoE Snooping
Quality of Service (QoS)
Access Control List
  • Ingress ACL tables
  • Up to 32 ACL rules (limited by SwOS)
  • Classification based on ports, L2, L3, L4 protocol header fields
  • ACL actions include filtering, forwarding and modifying of the protocol header fields

Area

Sub-menu:

Description

OSPF allows collections of routers to be grouped together. Such a group is called an area. Each area runs a separate copy of the basic link-state routing algorithm. This means that each area has its own link-state database and corresponding shortest path tree.

The structure of an area is invisible from other areas. This isolation of knowledge makes the protocol more scalable if multiple areas are used; routing table calculation takes less CPU resources and routing traffic is reduced.

However, multi-area setups create additional complexity. It is not recommended separate areas with fewer than 50 routers. The maximum number of routers in one area is mostly dependent on CPU power you have for routing table calculation.

Properties

Property Description
area-id(IP address; Default:0.0.0.0)
default-cost(integer; Default:1) specifies the cost for the default route originated by this stub area ABR. Applicable only for stub areas on ABRs (applied on type-3 default routes).
inject-summary-lsas(yes | no; Default:yes) specifies whether to flood summary LSAs in this stub area. Applicable only for stub areas on ABRs
name(string; Default: ) the name of the area
translator-role(translate-always | translate-candidate | translate-never; Default:translate-candidate) Parameter indicates which ABR will be used as translator from type7 to type5. Applicable only if area type is NSSA
  • translate-always — router will be always used as translator
  • translate-never — router will never be used as translator
  • translate-candidate — ospf ellects one of candidate routers to be a translator
type(default | nssa | stub; Default:default) area type

Status

will show additional read-only properties

Property Description
interfaces(integer;) count of interfaces assigned to this area
active-interfaces(integer;) count of interfaces in operating state assigned to this area
neighbors(integer;) count of OSPF neighbors in this area
adjacent-neighbors(integer;) count of adjacent OSPF neighbors in this area

Когда нужно применять статическую маршрутизацию в MikroTik

Любая корпоративная сеть, как правило состоит из многоуровневой коммутации как на уровне самого роутера, так и во внешних сервисах. В качестве примера будет сформирован список случаев, когда актуально обратиться к настройке статического маршрута(route) на маршрутизаторе(роутере) MikroTik:

  • При добавлении статического адреса на какой-либо интерфейс. Это может быть как интернет соединение(ppoe, dhcp client, static address), так и обычная локальная настройка интерфейса в MikroTik.
  • Для обмена данным связки L2TP\PPTP VPN сервера и узлами, которые находятся ЗА VPN клиентом. Эта частая связка, когда в качестве VPN клиента выступает не конечный узел, а установлен маршрутизатор(роутер), за которым может быть множество узлов(при объединении двух офисов).
  • При использовании нескольких провайдеров и создании различных правил по балансировки нагрузке или автопереключению(резервированию) интернета.
  • Когда нужно разделить узлы локальной сети на группы, каждая их которых будет использовать разные правила для выхода в интернет.
  • Индивидуальные случаи, когда нужно задать предопределенное правило движение трафика для узла, которое не создаётся автоматически.

Мы поможем настроить: маршрутизатор(роутер), точку доступа или коммутатор.

Заказать

Как настроить “static routing” в MikroTik

Будет рассмотрена запись статического маршрута, с детальным описанием рабочих параметров.

Настройка находится IP→Routes

Dst. Address – конечный адресат, популярные значения

  • 0.0.0.0/0 – интернет;
  • 192.168.0.0/24 – подсеть;
  • 192.168.0.50 – конечный узёл;

Gateway – шлюз, которому будет отправлен пакет.

Check Gateway – проверка доступности шлюза:

  • arp – по наличию записи в таблице ARP;
  • ping – посредством отправки icmp запросов.

Этот пункт позволяет произвести точное определение не доступности шлюза и является рекомендованным, при использовании автоматического переключения линии интернета.

Type – маршруты, которые не указывают nexthop для пакетов, но вместо этого выполняют некоторые другие действия с пакетами, имеют тип, отличный от обычного unicast(одноадресного). Маршрут blackhole(черная дыра) молча отбрасывает пакеты, в то время как маршруты, unreachable(недоступные) и prohibit(запрещающие), отправляют сообщение ICMP Destination Unreachable (код 1 и 13 соответственно) на адрес источника пакета.

Distance – определение приоритета заданного маршрута. Чем ниже число, те выше приоритет.

Scope\Target Scope – параметры рекурсивной маршрутизации, состоящей из этапов:

  • Маршрут ищет интерфейс для отправки пакета исходя из своего значения scope и всех записей в таблице main с меньшими или равными значениями target scope
  • Из найденных интерфейсов выбирается тот, через который можно отправить пакет указанному шлюзу
  • Интерфейс найденной connected записи выбирается для отправки пакета на шлюз

Больше информации по использованию параметров ааа можно найти в соответствующем руководстве “Manual:Using scope and target-scope attributes →”

Routing Mark – направлять пакеты из заданной таблицы маршрутизации. Как правило этот параметр или пустой или заполняется промаркерованнымb маршрутами из раздела Mangle.

Pref. Source – задается IP адрес, от которого будет отправлен пакет. Этот параметр актуален, когда на интерфейсе несколько IP адресов.

Примеры статических маршрутов в MikroTik

Применяется для использования разных линий интернета для разных узлов. К примеру в сети расположено два сервера, использующие внешние порты 80 и 443.

Для работы правила нужно промаркировать трафик(раздел Mangle) и указать его в параметре Routing Mark.

Применяется, когда нужно изменить некоторые параметры в автоматическом добавлении маршрута(Add default route)

В качестве параметра переключателя между провайдера используется параметр Distance. Трафик в этом случае направляется в тот маршрут, значение Distance которого МЕНЬШЕ,

Осуществляется через почередное указание шлюзов провайдера. Параметром Gateway можно задавать не только последовательность, но и управлять количественной частью. К примеру, если вам нужно чтобы к провайдеру со шлюзом 11.11.11.11 уходило в 2 раза больше трафика(или там канал в 2 раза быстрее) достаточно этот шлюз указать два раза.

В качестве шлюза указывается IP адрес VPN клиента. Использование таких маршрутов в MikroTik популярно, когда в качестве L2TP или PPTP VPN клиента выступает роутер, со своей подсетью.

Если у вас есть профессиональный интерес в расширении данной статьи – заполните форму запроса.

Оцените статью
Рейтинг автора
5
Материал подготовил
Андрей Измаилов
Наш эксперт
Написано статей
116
Добавить комментарий