Коммутация в Mikrotik — Bridge и Master-port
В RouterOS есть два способа коммутации портов.
Коммутация портов MikroTik через Switch (Master Port)
В этом случае коммутация производится через чип свитча, в обход центрального процессора маршрутизатора. Обычно в SOHO маршрутизаторах Mikrotik используется одна свитч-группа на 5 портов, если портов больше — две свитч-группы. В устройствах Cloud Router Switch чипы коммутации на больше портов и имеют больше возможностей, подробней на них мы останавливаться в этой статье не будем.
Настроить коммутацию можно в разделе General каждого порта, просто выбрав в пункте Master Port. Это главный порт, через который будет происходить коммутация. Коммутация позволяет достичь проводной скорости обмена данными между портами одной группы, как между портами в обычном Ethernet-коммутаторе. Основной (master) порт будет являться портом, через который RouterOS будет сообщаться со всеми остальными портами данной группы. Интерфейсы, для которых задан master-порт, становятся неактивны – не учитывается поступивший и отправленный трафик. Фактически, как будто мы объединили порты физическим, «тупым» коммутатором (свитчем). В роутерах Mikrotik применяются следующие чипы коммутации:
Возможности чипов коммутации:
| Возможности | Atheros 8316 | Atheros 8327 | Atheros 7240 | ICPlus 175D | Другие |
|---|---|---|---|---|---|
| Коммутация портов | да | да | да | да | да |
| Зеркалирование портов | да | да | да | да | нет |
| Таблица MAC-адресов | 2000 записей | 2000 записей | 2000 записей | нет | нет |
| Vlan-таблица | 4096 записей | 4096 записей | 16 записей | нет | нет |
| Таблица правил | 32 правила | 92 правила | нет | нет | нет |
* Порт ether1 на RB450G имеет особенность, которая позволяет ему быть исключённым/добавленным из/в коммутируемой(ую) группы(у) по умолчанию. По умолчанию порт ether1 будет включён в группу коммутации. Данная конфигурация может быть изменена с помощью команды
«/interface ethernet switch set switch1 switch-all-ports=no».
switch-all-ports=yes/no:
«yes» означает, что порт ether1 является портом коммутатора и поддерживает создание групп коммутации и все остальные расширенные возможности чипа Atheros8316, включая расширенную статистику (/interface ethernet print stats).
«no» означает, что порт ether1 не является частью коммутатора, что, фактически, делает его самостоятельным Ethernet-портом – это способ увеличения пропускной способности между ним и другими портами в режимах сетевого моста и маршрутизации, но в то же время исключает возможность коммутации на этом порту. Коммутация через Switch является самой быстрой и производительной в маршрутизаторе, в тоже время имеет наименьшее количество возможностей. При этом:
Итого, можно выделить несколько особенностей такого метода:
Коммутация в MikroTik через Bridge-interface
Порты объединяются не напрямую, а программно, используя ресурсы центрального процессора маршрутизатора. К портам могут быть применены фильтры брандмауэра. Такое объединение так-же влияет на прохождение пакетов по упрощенной схеме (Fastpath). Если взять в пример 2011-серию маршрутизаторов, то ether1-ether5 объеденены в switch1 (Atheros 8327) а ether6-ether10 в switch2 (Atheros 8227), вы можете использовать только Bridge для объединения их в одно целое. Особенность данного метода:
Коммутация позволяет достичь проводной скорости (wire speed) обмена данными между портами одной группы, как между портами в обычном Ethernet-коммутаторе.
Пока пакет не достиг cpu-порта, его обработка полностью осуществляется логикой коммутатора, не требуя какого-либо участия центрального процессора, и эта обработка происходит с проводной скоростью при любом размере кадра.
Пропала опция Master-port и поле Switch
Не пугайтесь, это нормально, если прошивка вашего роутера 6.41 и выше. Теперь вся информация, которая передается на втором уровне модели OSI, будет передаваться через Bridge. Использование swich-чипа (hw-offload) будет автоматически активировано автоматически в случае такой возможности. По умолчанию при добавлении любого интерфейса в Bridge у него будет активирована опция «Hardware Offload», которая будет передавать всю информацию 2-го уровня через switch-чип. Если эту опцию убрать, то обработка будет осуществляться силами операционной системы.
При обновлении на RouterOS 6.41 и выше с RouterOS версий 6.40.5 и ниже все настройки master-port будут автоматически перенесены в Bridge-интерфейс. Если произвести downgrade до версии, которая поддерживает master-port, то настройки не будут возвращены на место. Настоятельно рекомендуется сделать резервную копию до обновления.
До обновления до RouterOS 6.41:
/interface ethernet set [ find default-name=ether1 ] name=ether1-WAN1 set [ find default-name=ether5 ] name=ether5-LAN1-master set [ find default-name=ether2 ] master-port=ether5-LAN1-master name=ether2-LAN1 set [ find default-name=ether3 ] master-port=ether5-LAN1-master name=ether3-LAN1 set [ find default-name=ether4 ] master-port=ether5-LAN1-master name=ether4-LAN1 /ip address add address=10.10.10.1/24 interface=ether1-WAN1 network=10.10.10.0 add address=192.168.0.1/24 interface=ether5-LAN1-master network=192.168.0.0 /ip firewall nat add action=masquerade chain=srcnat out-interface=ether1-WAN1
После обновления на RouterOS 6.41 и старше:
/interface bridge add admin-mac=6C:3B:6B:4A:80:3D auto-mac=no comment=»created from master port» name=bridge1 protocol-mode=none /interface ethernet set [ find default-name=ether1 ] name=ether1-WAN1 set [ find default-name=ether2 ] name=ether2-LAN1 set [ find default-name=ether3 ] name=ether3-LAN1 set [ find default-name=ether4 ] name=ether4-LAN1 set [ find default-name=ether5 ] name=ether5-LAN1-master /interface bridge port add bridge=bridge1 interface=ether2-LAN1 add bridge=bridge1 interface=ether3-LAN1 add bridge=bridge1 interface=ether4-LAN1 add bridge=bridge1 interface=ether5-LAN1-master /ip neighbor discovery-settings set discover-interface-list=!dynamic /ip address add address=10.10.10.1/24 interface=ether1-WAN1 network=10.10.10.0 add address=192.168.0.1/24 interface=bridge1 network=192.168.0.0 /ip firewall nat add action=masquerade chain=srcnat out-interface=ether1-WAN1
Mikrotik с нуля. 04 Коммутация
Ранее уже обсуждалось, что RouterBOARD может в себя включать встроенный коммутатор.
В данной схеме устройство в себе объединяет два чипа коммутации: гигабитный и 100мбитный.
Любой порт данного устройства можно либо объединить в логически единый коммутатор, либо порт может работать отдельно, на 3-м уровне.
Нужно понимать что сам по себе чип коммутации способен коммутировать без участия процессора, при этом существуют разные чипы коммутации, которые могут быть включены в состав RouterBOARD.
https://wiki.mikrotik.com/wiki/Manual:Switch_Chip_Features
Выше приведена диаграмма RB2011, в составе которого входят два чипа: Atheros8327 (ether1-ether5+sfp1); Atheros8227 (ether6-ether10)
Возможности данных чипов приведена ниже:
hAP ac lite (RB952Ui-5ac2nD)
hAP ac lite имеет на борту чип Atheros8227 (ether1-ether5)
На уровне switch мы можем управлять элементами:
— switch
— port
— port-isolation
— host
— vlan
— rule
При этом при попытке создать rule, мы получим ошибку, поскольку данный switch не поддерживает rule.
Объединение портов
Здесь стоит упомянуть, что до версии 6.41 в коммутации было понятие master-port.
После версии 6.41 все объединения портов выполняются через bridge.
Поэтому не рекомендуется даунгрейдить на версию ниже 6.41
Далее весь материал будет применяться к версии 6.41 и старше.
Итак, принадлежность портов к тому или иному свитчу или чипу можно определить командами:
interface ethernet print
interface ethernet switch port print
Как видно, в данной модели RouterBOARD все порты «живут» на одном чипе switch1.
Например, hAP ac lite имеет на борту чип Atheros8227 (ether1-ether5). И при включении функции Bridge VLAN Filtering, Hardware Offload будет невозможна, т.к. данный чип не поддерживает эту функцию. Hardware Offload будет автоматически отключена и в обработке коммутации Bridge будет участвовать CPU.
Fast Path
Настройка Bridge
Как видно, мы добавили все три порта в Bridge. Теперь все IP адреса должны «жить» на интерфейсе Bridge.
DHCP также должен быть привязан к интерфейсу Bridge
interface bridge port print
Если добавить в созданный Bridge интерфейсы wifi:
interface bridge port print
Как видно, на интерфейсах wlan отсутствует Hardware Offload. Это из-за того, что интерфейсы wlan «не живут» на чипе switch
Mikrotik – bridge или Master-slave?
Раньше все необходимые порты для объединения в локальную сеть закидывал в бридж. Так вот – это не правильно.
Грубо говоря, лучше делать так – возьмём стандартную ситуацию, по типу домашнего роутера, на примере 951-2n – один интернет, 4 лан-клиента + WiFi. Первый порт понятно WAN, второй мы соединяем бриджем с WiFi, а остальные подключаем слейвами ко второму.
То есть должно получиться, что-то подобное –
“Коммутация позволяет достичь проводной скорости (wire speed) обмена данными между портами одной группы, как между портами в обычном Ethernet-коммутаторе”
“Пока пакет не достиг cpu-порта, его обработка полностью осуществляется логикой коммутатора, не требуя какого-либо участия центрального процессора, и эта обработка происходит с проводной скоростью при любом размере кадра.”
В общем, при включении в бридж, не задействуются возможности чипа коммутации. И начинаются проблемы по скорости (и ещё некоторые другие, из-за которых я и полез туда). Особо это заметно на 2011 серии (и думаю на всех более старших), при работе с гигабитными портами.
Про 2011 серию. В них установлено два чипа коммутации Atheros 8327 (ether1-ether5+sfp1) и Atheros8227 (ether6-ether10). Так что надо создавать 2 группы свитч-портов при помощи указания Master-port на интерфейсах. А уже мастер-порты объединить в бридж. Снизит нагрузку на CPU при проходе трафика между портами одной группы.
#mikrotik #routeos #bridge #disnetern
Bridge
Ethernet-like networks (Ethernet, Ethernet over IP, IEEE 802.11 in ap-bridge or bridge mode, WDS, VLAN) can be connected together using MAC bridges. The bridge feature allows the interconnection of hosts connected to separate LANs (using EoIP, geographically distributed networks can be bridged as well if any kind of IP network interconnection exists between them) as if they were attached to a single LAN. As bridges are transparent, they do not appear in the traceroute list, and no utility can make a distinction between a host working in one LAN and a host working in another LAN if these LANs are bridged (depending on the way the LANs are interconnected, latency and data rate between hosts may vary).
Bridge Interface Setup
To combine a number of networks into one bridge, a bridge interface should be created (later, all the desired interfaces should be set up as its ports). One MAC address from slave (secondary) ports will be assigned to the bridge interface, the MAC address will be chosen automatically, depending on «port-number», and it can change after a reboot. To avoid unwanted MAC address changes, it is recommended to disable «auto-mac», and to manually specify MAC by using «admin-mac».
Sub-menu: /interface bridge
When the last client on the bridge port unsubscribes to a multicast group and the bridge is acting as an active querier, the bridge will send group-specific IGMP/MLD query, to make sure that no other client is still subscribed. The setting changes the response time for these queries. In case no membership reports are received in a certain time period ( last-member-interval * last-member-query-count ), the multicast group is removed from the multicast database (MDB).
Maximum transmission unit, by default, the bridge will set MTU automatically and it will use the lowest MTU value of any associated bridge port. The default bridge MTU value without any bridge ports added is 1500. The MTU value can be set manually, but it cannot exceed the bridge L2MTU or the lowest bridge port L2MTU. If a new bridge port is added with L2MTU which is smaller than the actual-mtu of the bridge (set by the mtu property), then manually set value will be ignored and the bridge will act as if mtu=auto is set.
When adding VLAN interfaces on the bridge, and when VLAN is using higher MTU than default 1500, it is recommended to set manually the MTU of the bridge.
Multicast querier generates periodic IGMP/MLD general membership queries to which all IGMP/MLD capable devices respond with an IGMP/MLD membership report, usually a PIM (multicast) router or IGMP proxy generates these queries.
By using this property you can make an IGMP/MLD snooping enabled bridge to generate IGMP/MLD general membership queries. This property should be used whenever there is no active querier (PIM router or IGMP proxy) in a Layer2 network. Without a multicast querier in a Layer2 network, the Multicast Database (MDB) is not being updated, the learned entries will timeout and IGMP/MLD snooping will not function properly.
Only untagged IGMP/MLD general membership queries are generated, IGMP queries are sent with IPv4 0.0.0.0 source address, MLD queries are sent with IPv6 link-local address of the bridge interface. The bridge will not send queries if an external IGMP/MLD querier is detected (see the monitoring values igmp-querier and mld-querier ).
Example
To add and enable a bridge interface that will forward L2 packets:
Базовая конфигурация MikroTik (CLI) ( Создание простейшей конфигурации для обеспечения работы небольшого офиса с парой десятков пользователей. )
6 января 2015 (обновлено 26 января 2019)
Hard: «MikroTik RB/CCR».
OS: «RouterOS v6».
Задача: создать простейшую конфигурацию маршрутизатора «MikroTik» для обеспечения работы типового небольшого офиса с парой десятков пользователей и двумя-тремя серверами.
Прежде всего, если устройство только что поступило на полное реконфигурирование, есть смысл предварительно зачистить его настройки, и уже после этого приступать к дальнейшим действиям:
Аналогичного эффекта сброса настроек до заводских можно достигнуть следующей последовательностью действий:
Ознакомиться с текущей конфигурацией проще всего посредством команды экспортирования всего набора команд для воссоздания таковой:
Первичные настройки доступа.
Устанавливаем пароль для текущего пользователя «admin»:
Заводим дополнительного пользователя и выдаём ему полномочия суперпользователя:
Выключаем все сервисы управления устройством, кроме SSH, «winbox» и COM-порта:
Активируем повышенный уровень шифрования сеансов SSH и запрещаем транзитные подключения:
Настраиваем сетевое именование.
Задаём символическое сетевое имя (FQDN) устройству:
Задаём набор NS-серверов, к которым следует отправлять DNS-запросы (в примере Google и Yandex):
Разрешаем обслуживание маршрутизатором рекурсивных DNS-запросов от пользователей:
Устанавливаем точное системное время.
Наверняка изначально может потребоваться явно указать желаемый часовой пояс (пример для Новосибирска):
Задаём внешний источник данных для автоматической синхронизации времени:
Сразу по применению новых параметров даты и времени система попытается синхронизировать его с указанными time-серверами.
Позволяем маршрутизатору делиться сведениями о точном времени, активируя NTP-Server:
Об аппаратных чипах и логике коммутации.
Ранее (до «RouterOS v6.41») на большинстве «Mikrotik» в настройках по умолчанию была предустановлена схема из двух уровней коммутации: группа ethernet-интерфейсов собирается в «switch-group» (трафик которой обслуживается только в рамках подключения к физическому чипу коммутации, коих может быть несколько), а порты «switch-group» через произвольный «master-port» (таковым может быть назначен любой из портов группы) вводятся в мостовой виртуальный интерфейс «bridge», коммутирующий (уже на уровне центрального процессора) пакеты «switch-group», автономных ethernet-интерфейсов и беспроводного интерфейса, предоставляя им единое L2 адресное пространство.
Рекомендую сразу разделить по разным группам коммутации проводные и беспроводные интерфейсы (помним, что по умолчанию они сведены в «прозрачный мост») с тем, чтобы иметь возможность подключающихся беспроводных клиентов в любых комбинациях изолировать от работающих в проводной сети пользователей, а порты последней распределить в соответствии с назначением, функционально изолировав их в рамках аппаратных чипов.
Планируем распределение сетевых интерфейсов по задачам.
В дальнейшей настройке будем исходить из потребности в следующих сущностях:
Если устройство начального уровня, то в нём немного физических портов и может статься, что каждый из них будет задействован в своей задаче с индивидуальной сетевой IP-адресацией. Если ethernet-портов больше, чем задач, что часть из них можно свести в группы коммутации, получив в итоге картину вроде нижеследующей:
Конфигурируем локальные сетевые подключения.
Переименовываем сетевые интерфейсы для удобства восприятия их функциональной привязки, в соответствие с вышеприведённой схемой:
Создаём «мостовые интерфейсы», которые будут играть роль виртуальных коммутаторов:
Подключаем к виртуальным «мостовым интерфейсам» соответствующие сетевые физические интерфейсы:
Проверяем, получилось ли задуманное распределение интерфейсов:
Назначаем «мостовым интерфейсам» локальных сетей IP-адреса:
Результат наших действий по назначению IP-адресов:
Конфигурируем беспроводное сетевое подключение.
Создаём выделенный профиль, описывающий метод аутентификации пользователя в беспроводной сети:
Задаём параметры сети, обслуживаемой беспроводным интерфейсом, заодно привязав к нему заранее подготовленный профиль аутентификации:
Задаём IP-адрес беспроводному интерфейсу и включаем таковой:
Настраиваем автоматическую выдачу IP-адресов.
Запускаем DHCP-сервер для обслуживания клиентов локальной сети:
При необходимости фиксируем IP-адрес компьютера пользователя за его аппаратным MAC-адресом:
Запускаем DHCP-сервер для обслуживания клиентов беспроводной сети:
Удостоверяемся, что наши DHCP-серверы активны в заданной конфигурации:
А вот так можно просмотреть список выданных пользователям сетей IP-адресов:
Конфигурируем внешние сетевые подключения.
Задаём внешнему интерфейсу первого (основного) провайдера IP-адрес:
Объявляем маршрут «по умолчанию», отправляющий весь нераспределённый трафик в сеть первого провайдера «ISP1»:
Просматриваем получившуюся таблицу простейшей статической маршрутизации:
Настраиваем трансляцию запросов из локальной сети в интернет.
Так как внутри «MikroTik» живёт «Linux», управление сетевым трафиком и модификация пакетов реализовано через подсистему ядра «netfilter», только вместо обвязки «iptables» здесь оперируют сущностью «firewall».
Для упрощения дальнейшего конфигурирования отношений между подсетями составляем списки таковых:
Задаём правила NAPT/PAT (NAT Overload/Port Address Translation) трансляции локальных сетевых адресов пользователей во внешние, при обращении за сетевые интерфейсы провайдеров:
Проверяем, применились ли правила организации доступа в интернет:
.
1 ;;; NAPT/PAT via WAN1
chain=srcnat action=src-nat to-addresses=123.45.67.90 src-address-list=LIST_INET_USERS_IP out-interface=ether1-WAN1 log=no log-prefix=»»
2 ;;; NAPT/PAT via WAN2
chain=srcnat action=masquerade src-address-list=LIST_INET_USERS_IP out-interface=ether6-WAN2 log=no log-prefix=»»
Настраиваем трансляцию запросов из внешней сети к локальным ресурсам.
Наверняка потребуется обеспечить доступность внутреннего сервиса, спрятанного за «MikroTik», извне.
Добавляем правила DNAT (Destination NAT), разрешающие пропуск трафика снаружи к определённым сервисам и портам:
Более глубокую настройку защитного экрана, как такового рассмотрим в отдельной заметке.
Деактивируем ненужные в простом офисе функциональные модули:
Выключаем сервисы мониторинга (Ping) и управления (Telnet, Winbox), принимающие подключения с указанием MAC-адреса, если IP-адрес интерфейсу не выдан:
Выключаем сервис, предназначенный для приёма подключений с целью тестирования пропускной способности:
Явно выключаем сервисы проксирования клиентских запросов:
[ уже посетило: 6794 / +3 ] [ интересно! / нет ]
Поблагодарить автора 
( сделайте свой денежный вклад в хорошее настроение )
