Mkrotik и vlan по быстрому.

Купили новый маленький роутер от Mikrotik — RB4011iGS+RM. Решили попробовать как он будет работать в маленькой сетке в качестве роутера (странно? Да? 🙂 ). У него есть 10G SFP+ интерфейс, подключенный непосредственно к процессору. Если включить FastPath, то по идее должен справляться.

SFP+ интерфейс естественно в trank. На всякий пожарный eth6, тоже в транк. Eth с 1-го по 5-й в 1-й vlan, в режиме access mode, что бы подключаться прямо в серверной к коммутаторам, если вдруг чего. Остальные не задействованы.

При обращении к Google с вопросом Mirotik+vlan вываливается куча страниц с описанием настройки vlan. Но, проблема в том, что они блин все устарели! В новых версиях router os все уже не так.

Как сейчас рулить vlan с возможностью маршрутизации? Теперь там все через bridge интерфейс.

В первую очередь добавляем сам мост:

> /interface bridge
/interface bridge> add name=core

Добавим к мосту порты, в которых будут бегать тегированные пакеты:

/interface bridge> port
/interface bridge port> add bridge=core interface=sfp-trunk
/interface bridge port> add bridge=core interface=ether6

Порты, работающие в access режиме:

/interface bridge port> add bridge=core interface=ether1
/interface bridge port> add bridge=core interface=ether2
/interface bridge port> add bridge=core interface=ether3
/interface bridge port> add bridge=core interface=ether4
/interface bridge port> add bridge=core interface=ether5

Там же, в разделе bridge есть возможность указывать какие vlan на каком интерфейсе и режим работы интерфейса.

/interface bridge port> /interface bridge vlan
/interface bridge vlan> add bridge=core tagged=sfp-trunk,ether6,core untagged=ether1,ether2,ether3,ether4,ether5 vlan-ids=1
/interface bridge vlan> add bridge=core tagged=sfp-trunk,ether6,core vlan-ids=1010,1011,1254

Итак, мы добавили vlan 1 к нужным нам интерфейсам и заодно определили режимы работы самих интерфейсов. Так же были определены другие vlan, которые будут приходить на mikrotik и в дальнейшем мы будем заниматься маршрутизацией между этими сетями.

На данном этапе пакеты Ethernet начнут бегать в своих vlan.

Пришло время заняться маршрутизацией.

Обязательно добавляйте интерфейс моста в параметре tagget при добавлении vlan в разделе bridge! Без этого у нас ничего не получиться на 3-м уровне 🙁

Для того, что бы маршрутизатор смог маршрутизировать 🙂 нам необходимо для каждого vlan создать свой интерфейс и задать им параметры ip.

Как обычно, интерфейсы создаём в разделе interface vlan (не bridge vlan!).

> /interface vlan
/interface vlan> add interface=core name=VLAN-1254 vlan-id=1254
/interface vlan> add interface=core name=VLAN-1010 vlan-id=1010
/interface vlan> add interface=core name=VLAN-1011 vlan-id=1011

Обратите внимание, что vlan-ы мы добавляем к bridge интерфейсу core. Не зря мы включали на этом интерфейсе режим работы tagged.

Осталось добавить ip адреса на интерфейсы:

> /ip address
/ip address> add address=192.168.1.1/24 interface=core network=192.168.1.0
/ip address> add address=192.168.10.1.24 interface=VLAN-1010 network=192.168.10.0
/ip address> add address=192.168.11.1/24 interface=VLAN-1011 network=192.168.11.0
/ip address> add address=192.168.254.1/24 interface=VLAN-1254 network=192.168.254.0

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

Вот и все.

Управление питанием web камеры при помощи mikrotik

На одном нашем объекте барахлят web камеры. Очень чувствительные к питанию. Постоянно приходиться их вкл/выкл. Каждый вкл/выкл стоит 1000 р. в обслуживающей организации (объект в другом городе). Да и время уходит, пока парни из саппорта приедут и дернут шнурок питания, строители могут пару самосвалов налево вывезти :).

Камеры без поддержки POE, но питание передаётся по ethernet кабелю. Стоит блок питания необходимой мощности, POE инжектор. На стороне камеры девайс, который из кабеля берет питание и дает его на камеру.

Изначально хотели брать питание с микротика, который там стоит, но когда нам согласовали камеры, выяснилось, что мощи микротика для них не хватает. Поэтому получилась вот такая хитрая фигня.

По идее нужно вставить девайс, который по сигналу отрубает питание камеры и врубает его обратно. Реле, управляемые по Ethernet, стоят куеву тучу денег. Естественно мы их не купили.

Начали гуглить проблему и нашли записки доброго человека из lanmart: https://www.lanmart.ru/blogs/mikrotik-rb750up-remote-power-management-220v/

Он при помощи микротика с POE out управляет автомобильным реле, которое разрывает цепь 220 вольт. Вобщем наша тема!

Мы сделали точно так, но разрывали слаботочку 12 вольт. Реле поместили в корпус блока питания. Ethernet кабель маленько разрезали по середине. Все надрезы основательно изолировали. И вот итог:

На картинке второй конец кабеля воткнут в Mikrotik cAP. Свободный засовывали в управляющий микротик с POE out.

Автомобильное реле влезло в корпус блока питания. Но вот развести провода Ethernet места уже не хватило. Пришлось делать сопливую врезку:

Чуть крупнее.

Бомж комплект собран и работает.

Завтра соберем еще два таких «девайса» и поедем на объект ставить.

Mikrotik VPLS

Пытался построить VPLS на микротике (Cloud Hosted Router) в VirtualBox. Не получилось, есть подозрение, что Virtual Box малость неправильно эмулирует ethernet интерфейсы.

Собрал сетку на живых 450G устройствах. Все заработало на ура. L2 VPN фунциклирует как часы.

На выходных попробую в vmware повторить эксперимент.

MUM Москва

Вчера побывал на MUM в Москве.

Было (по заявлению Микротик) ~750 участников.

Узнал, что Mirotik сделал специальный образ для виртуальных машин Cloud Hosted Router, на который не надо покупать лицензию. Правда с вшитым ограничением скорости на интерфейсе. Для снятия ограничения лицензию таки придется покупать, но они обещают, что цена на нее будет меньше. Теперь крутить RouterOS в виртуалках будет проще.

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

Mikrotik — Wi-Fi bridge Ethernet — 100% CPU load

Микротик в прошивке 5.24 починил баг, связанный со 100% загрузкой процессора при объединении мостом Wi-Fi и Ethernet чипа.
Так что обновляемся.

Mikrotik и BeeLine

У моего старого домашнего провайдера начались проблемы. Причем эти проблемы приобрели регулярность. Решил попробовать домашний итернет от пчелайна.
Из-за особенностей организации сети пчелайна и фич микротика, подружить их между собой достаточно тяжело. Добрые люди написали толковый мануал, огромно спасибо им за это. Но, как обычно, в жизни не все так как в мануале 🙂 Учитывая, что старый провайдер пока от микротика не отключается, провод пчелайна был засунут в отключенный от общего свича интерфейс (ether5), появились маленькие тонкости.

1. Сначала подключитесь виндовым клиентом напрямую к сети  пчелок и запишите ip адреса DNS и VPN серверов пчелайна.

2. Почему то пчелайн DHCP сервер не отдает микротиковскому клиенту маршрут по умолчанию. Виндовому клиенту дает, микротику не дает. Поэтому приходится прописывать маршруты к сетям где находятся DNS и VPN серверам руками. Да и вообще, какой то странный их DHCP, выдал кучу всяких маршрутов, кроме вышеуказанных! Ну и по поводу его странности, см. следующий пункт.

3. Пчелайн редкосные бяки, их DHCP сервер выдает вот такой вот маршрут:
#      DST-ADDRESS  PREF-SRC  GATEWAY    DISTANCE
1 ADS  10.0.0.0/8             10.89.48.1 1
У моего старого провайдера внутренняя сеть тоже 10, но с маской /16. Т.е. старый провайдер честно дает маршрут на часть сети. Благо там pppoe подключение и можно не получать IP на интерфейс. Но пчелайн своим чудо маршрутом, просто заставил меня отказаться от использования внутренней сети старого провайдера. А там есть разные вкусности.

4. Вводить руками скрипт из мануала, занятие не для слабонервных. Поэтому, для тех кто пользуется winbox, привожу скрипты в нормальном виде.

corbina-l2tp_refresh
:local interface «BeeLine-l2tp»
:local vpnserver «tp.internet.beeline.ru»
:log debug message=»Hard resolv script run»
/ip dns cache flush
:local «current-ip» [:resolve $vpnserver]
:local «old-ip» [/interface l2tp-client get [/interface l2tp-client find name=»$interface»] connect-to]
:if ($»current-ip» != $»old-ip») do= {
:log info «VPN Server changed IP address from $»old-ip» to $»current-ip»»
/interface l2tp-client set [/interface l2tp-client find name=»$interface»] connect-to=$»current-ip»
}

corbina-l2tp_soft_refresh
:local interface «BeeLine-l2tp»
:local vpnserver «tp.internet.beeline.ru»
#:log debug message=»Soft resolv script run»
:if ([/interface l2tp-client get $interface running] = false) do={
 :log info message=»VPN down. Refreshing»
 /ip dns cache flush
 :local «current-ip» [:resolve $vpnserver]
 :local «old-ip» [/interface l2tp-client get [/interface l2tp-client find name=»$interface»] connect-to]
 :if ($»current-ip» != $»old-ip») do= {
 :log info «VPN Server changed IP address from $»old-ip» to $»current-ip»»
 /interface l2tp-client set [/interface l2tp-client find name=»$interface»] connect-to=$»current-ip»
 }
}

Разумеется вместо BeeLine-l2tp вы подставите свое имя l2tp интерфейса.

З.Ы. Очень понравились возможности микротика в части управления чипа свича! Для начала сформировал два интерфейса в отдельный свитч (смотрите параметр Master Port на интерфейсе). В один воткнул шнур от пчелок, в другой шнур идущий на кухню. Таким образом смог подключить ноут на прямую в сеть пчелок. Записал все необходимые параметры, вернул интерфейс в старый свич. Если бы этой возможности не было, пришлось бы на табуретке сидеть в коридоре 🙂

Ай да mikrotik, а да сукин сын.

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

Итак: есть как бы роутер на микротик, у него два интерфейса:

  1. eth1 192.168.0.100
  2. eth2 192.168.1.100

Маршрут по умолчанию через eth1 на другой роутер.
И микротик и роутер двумя интерфейсами подключены к обеим сетям: 192.168.0.0/24 и 192.168.1.0/24
Причем у микротика eth2 — это было временное подключение, только на стадии первичной конфигурации, так как рабочая станция с которой он первоначально конфигурился была в сети 1.0.

А теперь вопрос: если на микротике из интерфейса eth2 вытащить шнурок, сможете ли вы с машины, находящейся в сети 192.168.1.0/24 попасть на 192.168.0.100?
Или немного другой вариант вопроса: можете ли вы, находясь на микротике попасть в сетку 192.168.1.0/24 согласно его маршрута по умолчанию?

Ответ простой — нет!

Как оказалось, у RouterOS есть забавная фишка. У нее маршруты к сетям, подключенным к интерфейсу, при отключении линка из таблицы маршрутизации автоматически не удаляются! О как! В Linux удаляются (кстати все маршруты проходящие через этот интерфейс), в Windows удаляются, а в RouterOS нет!

И вот, три дня я нем мог понять, почему с упорством маньяка RouterOS пытается отсылать пакеты в интерфейс, на котором нет линка?

Слава богу служба поддержки Микротика работает отлично и они меня просветлили (именно просветлили, прямо таки карму почистили).

Для того, что бы интерфейс начал работать в привычном, например для меня, режиме. Нужно добавить небольшой фильтр.

[admin@MikroTik] > /routing filter print
Flags: X — disabled
 0   chain=connected-in prefix=192.168.1.0/24 scope=200 invert-match=no
     action=reject set-bgp-prepend-path=»»

Принцип работы этого фильтра: если есть лик, значение scope=10, если линк down — то scope=200.

Немного поработав с mikrotik девайсами я догадываюсь почему у них так устроено 🙂 но все равно — это было очень неожиданно.

Небольшой апдейт. Достаточно удалить ip адрес из списка и маршрут будет удален. Но если его не удалить руками, то да — пишем фильтр.

Mikrotik 1100AHx2

Однако он меня напрягает. Отказывается нормально поднимать bonding 🙁 Хотя то же RouterOS на Х86 девайсе с bonding работает нормально.
Залили на него 6.0rc1, так в режиме бондинга вобще все сетевые интерфейсы отрубаются. Вернуть девайс в рабочий режим можно только путем разборки корпуса и и замыкания жесточайшего reset на плате 🙁
Оставили девайс в покое до среды. То ли мы че то не так, то ли они как то не очень.

Mikrotik + IPTV + IGMP + WiFi

Ух, ну и задачка была. Вроде ничего сложного, пропустить IPTV через mikrotik по wifi на комп. Перевернул кучу мануалов, не помогает. Но все равно добил вопрос до конца. Ладно, давайте по порядку.

Ставим пакет multicast.

По умолчанию он у меня не стоял.

Включаем igmp-proxy.

/routing igmp-proxy print              
              quick-leave: yes
           query-interval: 1m
  query-response-interval: 10s

/routing igmp-proxy interface print detail
Flags: X — disabled, I — inactive, D — dynamic, U — upstream
0 U interface=ether1-gateway threshold=1 alternative-subnets=0.0.0.0/0 upstream=yes
1 interface=bridge-local threshold=1 alternative-subnets=»» upstream=no

На что следует обратить внимание?

  1. На alternative-subnets=0.0.0.0/0. Эта фишка позволяет ловить трафик с сетей к которым у вас нет обратного роутинга.
  2. interface=ether1-gateway — это тот интерфейс на который к вам будет приходить мультикаст трафик. Например у моего провайдера (Искрателеком) он приходит на локальный ethernet интерфейс, а не на pppoe интерфейс.
  3. quick-leave=yes. Позволяет быстро переключаться между каналами.

Разрешаем в фаерволе igmp и udp

Это нужно делать на цепочке input того интерфейса, который подключен к провайдеру и являющемся upstream.

И самое главное

Во всех мануалах на этом заканчивается настройка и все вроде должно работать. Но! если у вас Wi-Fi то по нему приходит маленький пушной зверек. Мультикаст пакеты начинаю тупо валить ваш беспроводной интерфейс! Упс.
В Инете рекомендуют дропать мультикаст трафик на Wi-Fi (при этом никакого ТВ там не будет) или выкинуть микротик и купить супер дупер девайсы 🙂
На самом деле проблема решается просто, очень просто.

Тадаааамммм!!!! Фанфары!!!

Включаем multicast-helper=full
Этот маленький пунктик заставляет ваш микротик отправлять мультикаст пакеты по индивидуальным MAC-ам тех девайсов, которые зарегистрированы  на Wi-Fi.

Все, вы можете смотреть ТВ на девайсе, подключенном к микротику по Wi-Fi.

З.Ы. Проверено на Искрателеком.

Апдейт раз. Пункт multicast-helper доступен в окне настройки wifi интерфейса после нажатия кнопки advanced. Ну или явно в командной строке после set.

Апдейт два. Не рекомендуется быстро переключать каналы. Особенность igmp proxy заключается в том, что при переключении на новый канал, старый трафик некоторое время продолжает транслироваться. Переключив быстро 4-5 каналов, вы превысите пропускную способность wifi канала и начнутся дикие тормоза. Конечно через минуту трансляция ненужных каналов отвалится и все станет нормально. Но все же…

DUDE контроль картриджей HP Printers

Начал щупать программку сетевого монитора Dude. Что сказать? Прикольно, удобно, управляет девайсами mikrotik на прямую, на шару, работает 🙂

Возникла задача контролировать картриджи в принтерах HP. Получилось.

1. Создал функцию:
Имя: HPCartrige
Описание: Выдает % использования картриджа
Код: oid(«1.3.6.1.2.1.43.11.1.1.9.1.1») * 100 / oid(«1.3.6.1.2.1.43.11.1.1.8.1.1»)

2. Создал пробу:
Имя: HP pages
Тип: Functions
Агент: по умолчанию
Доступно: if(oid(«1.3.6.1.2.1.43.11.1.1.8.1.1″)>2000,1,-1)
Ошибка: if(HPCartrige()<95,»»,»Картридж смени!»)
Значение: HPCartrige()
Единица измерения: %

3. Подключил пробу к принтерам HP.

Сразу скажу, что контролируется только черный картридж у лазерных принтеров HP. С цветными и струйниками не разбирался. Подозреваю, что на каждый цветной картридж надо свою пробу делать.

Апдейт. Конечно приятно самому докопаться до проблемы,  но… таки надо читать мануалы и спец форумы. Оказывается — все уже придумано 🙂 тыц вот тут.