Сегодня в логах маршрутизатора MikroTik заметил необычную последовательность предупреждений об ARP-конфликтах, ранее ничего подобного не было. Что это может значить?
Valentin Barbolin, Не помог. Мог бы понять, если бы ошибка возникла с одним конкретным MAC - можно было бы грешить на то, что конкретное устройство пытается получить уже занятый IP-адрес. Меня же смущает то, что конфликт возник у пяти разных MAC в короткий промежуток времени
MeredithMcGlynn, Такое бывает когда люди статикой себе забивают адреса, если у тебя конфлик значит надо найти в IP/ARP два одинаковых IP (отсортируй колонку IP) и посмотреть на их МАК, по этим МАК опредедить ПК и посмотреть у кого адрес забит статикой.
Valentin Barbolin, Думал об этом, но есть два "но"
1) Сеть очень маленькая - на постоянной основе работа ведётся с 12-15 ПК, в большинстве своём, пользователями, которые знают разве что как открыть Word и почту. Вряд ли кто-то из них смог бы пролезть в настройки интерфейсов и для чего-то изменить свой IP, к тому же, вряд ли сразу пять юзеров решили бы этим заняться в течение 30 секунд;
2) IP/ARP смотрел, ничего подозрительного не увидел. Те MAC, о которых Микротик выдавал конфликты, по итогу спокойно присвоили себе те же адреса, что и в логах выше
Valentin Barbolin, От Apple - разве что несколько телефонов пользователей, логично, подключающихся к сети по Wi-Fi (в "Wireless Clients" этих IP и MAC нет). Все стационарные станции и ноутбуки от иных производителей.
Что ещё необычно - я эти MAC-адреса вижу впервые. В сети такого размера MAC постоянных юзеров помню почти наизусть, но те, что на скриншотах, к ним не относятся
Оказалось, MAC и IP с первого скриншота принадлежат пяти серверам из лабораторного стенда, это объясняет, почему их данные не мелькали ранее в логах МикроТик - устройства постоянно в сети и работают 24/7. Всё ещё остаётся неясным, из-за чего возникли конфликты в логах и почему возникли именно сейчас - на них задана статика, к оборудованию в последнее время никто не прикасался, новых юзеров в сети не появлялось. Но приятно, что хотя бы на работе оборудования это никак не сказалось и нет угрозы безопасности.
Благодарю за уделенное время.
MAC и IP с первого скриншота принадлежат пяти серверам из лабораторного стенда,
И все они под управлением Windows? Тогда посмотрите по логам назад - когда именно началась эта ерунда...
Намекну - Windows, даже настроенный на статический адрес, тем не менее умудряется без проблем работать с принтерами через APIPA-адрес. А порой и не только с принтерами.
Akina, Akina, Да, лабораторные сервера на Windows. Смущает то, что последнюю неделю ежедневно просматривал логи маршрутизатора, т.к. боролся с настройкой Wi-Fi, который постоянно отваливался у некоторых юзеров. И как минимум на протяжении этой недели сообщений о конфликтах ARP на MikroTik не было.
Попробую посмотреть сами сервера и продолжу мониторить логи маршрутизатора. Может, что-то обнаружится.
MeredithMcGlynn, у меня был случай, сеть условно 192.168.0.0/24, шлюз .1 на оборудовании провайдера, DHCP-сервер 192.168.0.2 на собственном оборудовании организации. Мигнуло питание, оборудование провайдера ожило позже собственного, и IP .1 был DHCP-сервером выдан какому-то из компов. Причём интернет даже слега работал для тех устройств, которые получали правильный ARP шлюза :) Я тогда разбирался как в том устройстве ограничить диапазон выдаваемых IP, чтобы такое не повторилось.
Так что сценарий выдачи уже занятых IP вполне возможен. Например, если на момент выдачи с точки зрения DHCP-сервера занятый IP не был виден. Или если DHCP-сервер криво написан и не проверяет это нормально...
shurshur, зачем ограничивать диапазон, если этот статический адрес можно "выдать" в настройках DHCP-сервера.
я обычно прописываю в этот мак-адрес машины со статическим адресом. все получается красиво и логично.
pfg21, тоже вариант. Просто это работает, когда точно знаешь занятые IP и лучше с мак-адресом сразу. А когда хочется забронировать "вот эти не брать", то лучше как раз указать какие брать можно.
судя по всему появились глючные устройства которые заняли такой же ip что и другие (бывает при подключении wifi) + судя по пулу адресов - он потихоньку заканчивается, не могло ли возникнуть ситуации что какому то устройству не хватило ip?
попробуйте понизить время которое ip привязан к маку в настройках dhcp