мастер порт mikrotik что это

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

Источник

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-port

В RouterOS есть два способа коммутации портов.

Коммутация портов MikroTik через Switch (Master Port)

В этом случае коммутация производится через чип свитча, в обход центрального процессора маршрутизатора. Обычно в SOHO маршрутизаторах Mikrotik используется одна свитч-группа на 5 портов, если портов больше — две свитч-группы. В устройствах Cloud Router Switch чипы коммутации на больше портов и имеют больше возможностей, подробней на них мы останавливаться в этой статье не будем.
Настроить коммутацию можно в разделе General каждого порта, просто выбрав в пункте Master Port. Это главный порт, через который будет происходить коммутация. Коммутация позволяет достичь проводной скорости обмена данными между портами одной группы, как между портами в обычном Ethernet-коммутаторе. Основной (master) порт будет являться портом, через который RouterOS будет сообщаться со всеми остальными портами данной группы. Интерфейсы, для которых задан master-порт, становятся неактивны – не учитывается поступивший и отправленный трафик. Фактически, как будто мы объединили порты физическим, «тупым» коммутатором (свитчем). В роутерах Mikrotik применяются следующие чипы коммутации:

Возможности чипов коммутации:

* Порт 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 (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-адрес интерфейсу не выдан:

Выключаем сервис, предназначенный для приёма подключений с целью тестирования пропускной способности:

Явно выключаем сервисы проксирования клиентских запросов:

[ уже посетило: 6443 / +3 ] [ интересно! / нет ]

Поблагодарить автора ( сделайте свой денежный вклад в хорошее настроение )

Источник

Mikrotik: VLAN с использованием чипа коммутации

Вступление

Итак, вокруг множество статей, где с VLAN работаю на CPU (объявляют VLAN на интерфейсе и помещают его в Bridge). Такая связка имеет право на жизнь, но в её работе мы расходуем ресурс CPU, который может быть очень ценным. Два разных устройства представляют различные механизмы настройки для чипа коммутации, так как они сильно разные в техническом плане.

Реализовывать будем некоторые примеры из официальной Wiki:

Port Based VLAN

Поясним картинку: На порт ether2 приходят тегированные пакеты (порт транковый), а с портов ether6-ether8 уходят растегированные пакеты (порты доступа — клиентские порты).
Я буду брать конфигурацию с реально работающего устройства, поэтому полного соответствия с картинкой не будет.

RB951Ui-2HnD

Конфигурация: На ether1 приходят тегированные пакеты (VID: 4,5,6,10, 603), с портов ether2-ether4 уходят раздетые VID:10, с ether5 уходит раздетый VID:5, VID:603 сейчас не используется, а особый порт switch1-cpu принимает любые пакеты.

Вначале, создадим группу коммутации, для этого, во всех интерфейсах выставим мастер порт (по умолчанию ether2-master), тем самым мы отдадим эти порты в управление коммутатору.

Аналогично для всех остальных. Не затягивая, на мастер порт (так мы получим доступ к этому VLAN из CPU, по сути мы связываем его с switch1-cpu) подвесим нужные нам VLAN:

Далее зададим политику обработки пакетов на портах (номер VLAN по умолчанию), что отбросить, что раздеть, а где и шарфик повязать:

О параметрах можно почитать в Wiki в разделе Vlan-таблица.

Далее, мы создадим таблицу VLAN, по которой чип будет работать с тегами:

Вот и все, теперь VLAN обслуживаются на чипе коммутации, к сожалению, у RB951Ui-2HnD его возможности не очень большие, к примеру он не сможет сделать гибридный порт, тут придется строить лес из костылей на bridge.

CRS125-24G-1S-2HnD

Тут чип коммутации совсем другой, и умеет больше, приступим:

Конфигурация: На ether24 приходят тегированные пакеты (VID: 4,5,6,7,16), с портов ether1-ether23 уходят раздетые VID:16 и одетые VLAN:7 (будет для второго примера), а особый порт switch1-cpu принимает любые пакеты.

Вначале, создадим группу коммутации, для этого, во всех интерфейсах выставим мастер порт (по умолчанию ether2-master), тем самым мы отдадим эти порты в управление коммутатору.

Аналогично для всех остальных. На мастер порт подвесим нужные нам VLAN:

Далее, мы создадим таблицу VLAN, по которой чип будет работать с тегами:

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

Зададим порты, на которых соответсвующий VLAN будет одетым при выходе:

Теперь, на каких портах, выходящий VLAN надо раздеть:

Дословно это описывается так: если VID: 16, порт с 1 по 23, установить новый VID:0 (раздеть).

Теперь, на каких портах, входящий пакет надо одеть в VLAN:

Дословно это описывается так: если VID: 0 (пакет раздетый), порт с 1 по 23, установить новый VID:16 (одеть).

Example 2 (Trunk and Hybrid ports)

Тут мы рассмотрим только CRS125-24G-1S-2HnD, к сожалению, RB951Ui-2HnD такое на чипе коммутации уже не умеет.

Итак, возьмем полностью конфу из предыдущего примера, и добавим такое правило:

Источник