Mikrotik neighbors не работает

Mikrotik Neighbors Discovery Protocol: Протокол обнаружения соседей в сети

В этой статье мы рассмотрим настройку протокола Mikrotik Neighbors Discovery Protocol (MNDP). С помощью этого протокола устройства фирмы Mikrotik могут обнаружить другие устройства, совместимые с MNDP, CDP (Cisco Discovery Protocol) или LLDP (Link Layer Discovery Protocol).

Освоить MikroTik вы можете с помощью онлайн-курса «Настройка оборудования MikroTik». В курсе изучаются все темы из официальной программы MTCNA. Автор – официальный тренер MikroTik. Материал подходит и тем, кто уже давно работает с оборудованием MikroTik, и тем, кто еще не держал его в руках. В состав входят 162 видеоурока, 45 лабораторных работ, вопросы для самопроверки и конспект.

Обнаружение происходит в одном широковещательном домене с интерфейсом, на котором работает протокол MNDP.

Часто системные администраторы пренебрегают данной настройкой, что очень зря. Давайте разберем почему.

Neighbors Discovery Mikrotik. Описание

Чтобы посмотреть, как по умолчанию настроен протокол, откроем Winbox:

• IP => Neighbors => Discovery Settings.

Как мы видим, по умолчанию протокол слушает все интерфейсы, кроме динамических.

Протокол MNDP может слушать следующие интерфейсы:

• All – Все интерфейсы;
• Dynamic – Динамические интерфейсы;
• Static – Статические интерфейсы;
• None – Не один интерфейс.

А также есть возможность добавлять свои списки интерфейсов. Как это сделать рассмотрим на примерах ниже.

Примеры обнаружения

Какую же информацию мы можем узнать о соседних устройствах? Откроем:

• IP => Neighbors.

Видно, что на порту ether1 обнаружено пять устройств провайдера, также устройство в локальной сети на порту ether5. Можем определить их IP-адреса, MAC-адреса, имя хоста (identity), платформу устройства, версию операционной системы и аппаратной платформы.

А также эту информацию можно получить из командной строки:

MNDP. Примеры настройки

Очень важный момент, для безопасности. Если мы включаем возможность обнаруживать другие устройства с помощью Mikrotik Neighbors Discovery Protocol, этим самым мы даем возможность обнаружить себя.

Не рекомендуется держать возможность обнаружить себя на внешних интерфейсах.

Отключить Mikrotik Neighbors Discovery на внешних интерфейсах

Чтобы отключить возможность обнаружить себя на внешних интерфейсах (например, для провайдера) по протоколу MNDP, при этом видеть устройства поддерживающих данную возможность во внутренней локальной сети, выполним следующие действия:

• Interface => Interface List => Lists => “+”.

Создадим новый интерфейс с такими параметрами:

• Name – произвольное имя для интерфейса;
• Include – какие интерфейсы по умолчанию в себя включает.

Далее вкладка Interface List. Добавим к созданному интерфейсу внешний порт (для моей конфигурации это ether1):

Следующим шагом откроем:

• IP => Neighbors => Discovery Settings.

В открывшемся окне выберем созданный интерфейс.

Обратите внимание, что перед Discovery стоит “!”. Это означает инверсия. Другими словами, мы слушаем все интерфейсы, кроме динамических и Ether1.

Отключить Mikrotik Neighbors Discovery Protocol полностью.

Для роутеров Mikrotik есть возможность полностью отключить MNDP. Это приемлемо, если присутствует только одно устройство Mikrotik и нет необходимости использовать обсуждаемый протокол.

Для этого перейдем:

• IP => Neighbors => Discovery Settings.

Выполним следующую настройку:

• Interface: none;
• OK.

Настройка MNDP Mikrotik закончена. Надеюсь, данная статья была вам полезна.

Освоить MikroTik вы можете с помощью онлайн-курса «Настройка оборудования MikroTik». В курсе изучаются все темы из официальной программы MTCNA. Автор – официальный тренер MikroTik. Материал подходит и тем, кто уже давно работает с оборудованием MikroTik, и тем, кто еще не держал его в руках. В состав входят 162 видеоурока, 45 лабораторных работ, вопросы для самопроверки и конспект.

Источник

Как MikroTik видит соседей. Обновление Neighbor discovery в RouterOS 6.38

Служба обнаружения соседних маршрутизаторов и совместимого оборудования в RouterOS присутствует давно. К сожалению, над схемой функционирования “Neighbor Discovery” товарищи админы задумываются редко. Там вроде как будто всё просто, но просто не настолько как кажется.

Наглядной иллюстрацией служат неудачные попытки скрыть информацию о своём маршрутизаторе MikroTik, при этом получать инфу о маршрутизаторах соседей внутри broadcast-домена провайдера. Так сказать, подглядывать за соседями по провайдерскому свитчу. Обычно это выглядит как запрет фаерволом отправки широковещательных пакетов объявления службы discovery UDP 255.255.255.255:5678. Вбив запрещающее правило в конфиг фаервола, некоторые считают, что полностью скрыли свой маршрутизатор от видимости соседями. Но это не так.

Давайте разберемся, как работает Neighbor Discovery в MikroTik.
Neighbor Discovery в RouterOS до 6.38 содержит в себе два пути объявления и получения информации работающие на разных уровнях модели OSI: на уровне L4 работает транспорт UDP, на уровне L2 информацию принимает и передает протокол семейства MNDP/VDP/CDP. Полученная из обеих источников информация объединяется и отображается в списке обнаруженных соседей “/ip neighbors”. Вот так выглядит Neighbor Discovery в текущем релизе:

Таким образом, простым запретом отправки UDP-пакетов на порт 5678, информацию о маршрутизаторе скрыть невозможно. Нужно либо полностью отключать службу Neighbors на интерфейсе командой /ip neighbor discovery set ether1-gateway discover=no, либо фильтровать исходящий L2 трафик на предмет MNDP-пакетов с помощью bridge filters. Например, вот так:

Сейчас готовится к релизу новая версия RouterOS 6.38, и в ней наконец-то случилось то, о чём так долго говорили большевики просили админы многих стран. В 6.38 наконец-то добавлена хорошая плюшка в виде поддержки открытого протокола LLDP. Это еще немного расширяет возможности оборудования в части мониторигна состояния L2 соединения. Теперь в списке соседей можно будет видеть любое LLDP-совместимое оборудование, при условии, что на нем тоже включена поддержка объявления LLDP. Например, теперь мой тестовый маршрутизатор отлично «видит» соседний свитч HP v1905-24

Информации пока принимается и передается немного, но для мониторинга наличия/отсутствия видимости по L2 достаточно. Отмечу, что поддержка LLDP не заменила другие протоколы, а добавлена к списку поддерживаемых в MikroTik Discovery и начиная со 6.38 она будет выглядеть вот так:

В официальной WiKi MikroTik уже добавлены сведения об информации принимаемой и передаваемой RouterOS посредством LLDP.

RouterOS sends out:

Chassis subtype (MAC)

• Port subtype (interface name)
• TTL
• System name (system identity)
• Sys description ( RouterOS )
• All IP addresses on configured on the port

RouterOS accepts and processes:

• identity (LLDP_TYPE_SYS_NAME)
• interfaceName (depending on the priority, if one is empty checks the next: LLDP_TYPE_CHASSIS_ID, LLDP_TYPE_PORT_ID, LLDP_TYPE_PORT_DESC)
• ip4 (first entry of IPv4 LLDP_TYPE_MANAGEMENT_ADDR)
• ip6 (first entry of IPv6 LLDP_TYPE_MANAGEMENT_ADDR)
• TTL (LLDP_TYPE_TTL)
• MAC (Source — 6-11 byte)

Ну, что ж, ждём официального релиза и внимательно наблюдаем за тестовыми аппаратами – на то и статус у 6.38 пока еще «rc».

Источник

Mikrotik neighbors не работает

Бесплатный чек-лист
по настройке RouterOS
на 28 пунктов

Нет возможности подключиться по IP

Братцы, помогите, пожалуйста, советом. Микротик hAP AC. В Winbox перестал находиться по IP в разделе Neighbors. К микроту подключен еще один как ретранслятор, его видно и подключиться можно. На головное устройство нет, только по МАКу. Проблема, предположительно, возникла, когда был подключен ретранслятор. У головного ИП 88.1, у ретранслятора 88.2. DHCP-Server на 88.1. Не понимаю куда рыть..

По WWW тоже ноль. Но 88.1 из командной строки пингуется прекрасно.

1-е Правило WiFi — Везде где только можно откажитесь от WiFi!
2-е Правило WiFi -Устройство, которое пользователь не носит с собой постоянно, должно подключаться кабелем!!

Микротики есть разные: черные, белые, красные. Но все равно хочется над чем нибудь заморочится.

И в 22 и в 25 и 30 веке беспроводные технологии не будут превосходить проводные. И это не вера, это банальная физика. Воздух это очень плохой из существующих сред для прохождения сигнала, а условия города это вообще беда..
Я уже откровенно устал повторять, но, — тяните провода. Сверлите стены, отрывайте плитку, штробите стены, но прокладывайте провода.
Вот Вам для размышления: Почему современные дата-центры строят на проводах а не на WiFi? Почему в офисах протягивают целые лотки кабелей а не использую простую технологию WiFi? Потому что WiFi это сеть для беспроводных устройств (телефон, планшет, и в очень редких случаях ноуты, хотя на рабочем месте с ноутом обязан быть кабель ).

А по теме.. Отрубите репетир по питанию и после перезагрузи основного роутера попробуйте подключится.

1-е Правило WiFi — Везде где только можно откажитесь от WiFi!
2-е Правило WiFi -Устройство, которое пользователь не носит с собой постоянно, должно подключаться кабелем!!

Микротики есть разные: черные, белые, красные. Но все равно хочется над чем нибудь заморочится.

Я сам за провода. И на стадии ремонта заложил везде кабель, но в одном месте я ошибся. Точнее не предвидел, что у модулей управления теплым полом (а работают они только по Wi-Fi) не дотянется сигнал до роутера. Поэтому был вынужден для них поставить ретранслятор. Скорость и надёжность канала меня в этом случае не волнует. Данных передаётся минимум.

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

Искал по сети похожую проблему, на одном из форумов находил подобную ситуацию. Решения там не было, было указано что это какой-то баг, но у каждого бага должен быть номер или RFC на исправление. Я такой инфы не нашел и проблема достаточно старая, в одной из прошивок уже бы ее исправили, Change list обычно читаю.

Аналогичная проблема уже со мной происходила на другом роутере микротик. Тоже перестал определяться по IP, но при этом работал как надо, но через какое-то время он начал чудить, не определяться по всем портам, только по Wi-Fi, стали отваливаться клиенты и т.д. и в итоге перестал работать LTE интерфейс (роутер использовался на даче). Я сбрасывал настройки, но проблему это не решало. Вероятно, аппаратная проблема, саму коробку еще не вскрывал. Думаю его перезалить сначала, чтобы исключить проблему с ПО, а потом полезем «искать вздутые кондёры» и отвалившуюся пайку) Но это так. Последний абзац — мысли в слух)

Если найдётся время посмотреть конфиг, ребят, буду благодарен.

1) не было чтобы по IP как-то пропадал роутер.
(если не перехимичать только по не знаю или по плану )

2) и глюков таких я что-то в ChangeLoge не встречал, нет, ошибки есть в Винбоксе,
но обычно не так форма, поле отображается, что-то нельзя до-настроить или кнопка не
выводиться, но это не критические баги.

3) часть конфига Вы убрали (странно, сами порешали, сами убрали). Обычно оставляют всё,
а замазывают лишь адресацию.

4) в конфиге есть слово » defconf» — как я вижу это, это значит использовали заводской конфиг,
и уже поверх его делали свои настройки = и как итог и практика — 80% глюков Вы поймаете.
Что видимо и произошло.
4.1) мастер-порта давно нет, и хоть и понимаю что это отголоски, но надо всё же убрать/переименовать
4.2) адрес роутеру (локальный) надо задавать на бридже (на котором и работает DHCP, а не на порту).

5) Не используйте (очень советую) заводские адреса (192.168.88.ххх) и сеть эту. Мало что она у микротиков,
так ещё и ряд производителей камер и ряд другого оборудования так их использует.

6) зачем на роутере Вам IGMP ? (мультикаст передаёте)?

7) опять же по вифи — зачем на 5ггц включать все бэнды? Только хуже делаете!
7.1) а зачем WPA включаете? Сейчас уже WPA2 не самый надёжный, а Вы старый протокол
используете, опять же, зачем?
8) RFC — это общий набор правил и стандартов и описания сервисов и их параметры.
НО не список багов и ошибок.
9) хочу напомнить, что Винбокс по IP видит в рамках сети L2-уровня. Репитер может
частично ограничивать/блокировать такой трафик?!

Итог:
Конфиг переусложнён, «грязный» и имеет баги.
Совет (если нужен): слить весь конфиг в текстовик.
Руками очистить роутер, и по-блочно/по абзацу часть данных
перенести, а часть проще мышкой в ручном режиме за 10-20 минут
вбить/создать.
И прежде чем делать, подумать что и как именно нужно на роутере,
чтобы опять не усложнять. И сделать правильно и сразу.

P.S.
Всё выше изложенное личное мнение, возможно оно немного суровое,
но меня настораживают такие конфиги, если приводить аллегорию:
то всё равно что уметь делать борщ, но не суметь пожарить яичницу.
Так и тут, с этим конфигом.

Критику люблю, ценю и дорожу ей 🙂

Давайте по пунктам:

1. Не исключаю, скорее думаю в этом направлении.
2. Критичные недочеты встречаются, чаще всего уязвимости их стараются устранить, об этом часто пишут в новостях. Но я за этим не слежу, я SOHO-потребитель без нужного объема знаний. Увы.
3. См. последнюю часть пункта 2, я не всегда понимаю риск, поэтому стараюсь избежать любых.
4. Да, за основание был взять дефолтный конфиг. Да, скорее всего в этом проблема. Но готов ли я пройти еще раз путь настройки «от и до». Не знаю. Для опытных людей это не проблема, а для меня первое знакомство с Микротик закончилась 4мя днями чтения форумов и т.д. Но я трудностей не испугался и в итоге все что мне было нужно — заработало. Поэтому какие-либо изменения конфигурации произвожу с особой осторожностью. Собственно, с момента покупки и до возникновения необходимости поднять VPN я к нему практически не прикасался. Этим Микротик мне отплатил за мою настырность. Если можно так выразиться.
4.1 Да, настройка производилась тогда, когда еще были slave и master, мне не мешает.
4.2 Вот тут хотелось бы остановиться по подробнее. Видите ли как. Оператор мне раздаёт помимо интернета еще и IPTV, уже не помню в чем была проблема, ТВ не работало и никак не получалось его настроить. Толи забивался Wi-Fi мультикастом, толи еще что-то. Много прошло времени. Помню, что для меня решением оказалось сделать еще один бридж, добавить в него порт (у меня он за номером 4), воткнуть в него кабель от IPTV-приставки и все получилось прекрасно. Если я правильно понял вышло что-то вроде свича перед WAN чисто теоретически). Поменял с порта на бридж. Теперь тут перфект.
5. Принял на вооружение. В дальнейшем буду следовать Вашему совету.
6. См. п. 4.2. Настройка была на тот момент, когда настраивалось IPTV. Нужна ли она мне сейчас при наличии специального бриджа, я не знаю.
7. Тоже принял. Но дома есть устройство, которое понимает 5Ghz, но не работает на AC (ASUS ME302C). Попробовал оставить только AC band, устройство видит сеть, но не может подключиться. Изменил на N/AC. Теперь пока так.
7.1 Вот тут Вы точно правы. Это я не досмотрел. Знаю, что WPA это утопия, но что у меня была активна, не видел. Изменил.
8. Тут я могу спорить долго, т.к. работаю на крупном предприятии я сам выпускаю RFC чуть ли не еженедельно. Request for change — это служебная записка, не более. И то, что она содержит описание стандартов не делает её существование только для этой задачи. Она может содержать описание действий по изменению существующего ПО, разработку нового, описание стандартов существующего, откат доработок т.е. даунгрейд и т.д.
9. ПК, которым пытаюсь найти Микротик по IP напрямую включен в роутер. Репитера на пути нет. Но находится именно репитер. А головное устройство нет.

Спасибо большое за Ваш развернутый ответ. Для меня он оказался крайне полезным.
P.S. Петропавловск-Камчатский? Серьезно? Очень круто

1) по части адреса на бридже. Вы смешали настройку отдельного сервиса и мой совет.
Сам совет: если порт находиться в бридже, порт уже не самостоятельный, он подчичённый (slave)
и адрес должен быть установлен/или/перенесён с порта на бридж. БРИДЖ может и работает
также как обычный Интерфейс. Поэтому при создании локального бриджа, и помещение туда
портов, адрес локальный ставиться только на Бридже.
Было тут пару тем, как только адрес делали на бридже, глюки,зависания уходили.

На счёт IPTV — стандартная практика у Ростелекома и прочих: создаём отдельный (второй) бридж,
запихиваем туда порт1 и порт4(где приставка) и всё, всё начинает работать. Адрес тут не нужен,
формально сделали хаб виртуальный. Единственно надо знать: при такой схеме, рррое интерфейс
уже не может работать на порту1 и надо в настройках рррое его переместить на работу на бридже IPTV
(а почему не может рррое работать на порту, который входит в составе бриджа, читаем пункт 1).

И ещё почитайте, что такой Hardware Offload (HW).

2) на счёт устройства Асус которая якобы работает на 5, но на 5 не может подключиться, не мучьте его
и себя, если устройство не может подключиться, пусть сидит на N протоколе но на 2.4, и стабильнее
и лучше. Хочу донести Вам, как SOHO пользователю, что вифи на 5ггц — это протокол создан больше
для ближней работы, в рамках 2-5 метрах, он легко подавляется помехами, стенами, зато соседи
не мешают друг другу. Поэтому надо это понимать и делать правильно, если у меня устройство
работает на 5ггц, оно подключиться при идеально-хороших условиях, нет, будет работать на 2.4,
а скорости — если нужны мегабиты и гигабиты = это уже провода.

3) На заводском конфиге на порту1 стоит запрет обнаружения. Поэтому правильный совет (не знаю
почему читая форумы Вы этого не видели, но мы советуем это почти каждый раз) — это
очищение роутера, НЕ использовать пре-заводской конфиг, НЕ использовать мастер-настроек.
И руками, с нуля делать. У Вас есть конфиг, конфиг можно разобрать на части/абзацы,
и плавно руками через консоль импортировать.
Думаю на чистом роутере, убрав лишнее или уже не нужное = и ряд проблем Ваши сразу решаться.

Источник