Відстеження недійсної мак-адреси джерела

Я успадкував підтримку віддаленого сайту, який містить Cisco 4500 і підключений до ~ 2-х десятків комутаторів доступу Cisco - насамперед 2960-х з парою 3750-х та 3560-х. Не всі комутатори доступу безпосередньо підключені до пристрою 4500 - є кілька ромашкових ланцюжків комутаторів, що, очевидно, було зроблено внаслідок недостатнього підключення кабелів. Нещодавно я помітив серверні повідомлення на 4500, які вказують, що кадри були отримані з недійсною mac-адресою джерела:

*Sep 10 09:29:48.609: %C4K_L2MAN-6-INVALIDSOURCEADDRESSPACKET: (Suppressed 102563 times)Packet received with invalid source MAC address (00:00:00:00:00:00) on port Te5/1 in vlan 1460

Пристрій, підключений до Te5 / 1, є комутатором доступу (Cisco 3750). Він у свою чергу підключений до 6 інших комутаторів доступу. Після трохи гуглінгу з'являється 4500 - єдина платформа cisco, яка реєструє недійсні мак-адреси джерела. З мого читання, інші платформи (2960, 3750 тощо), схоже, пересилають кадри уздовж, але не записують їх як недійсні, а також не додають запис до таблиці адрес mac. Я підозрюю, що першопричиною недійсних мак-адрес може бути несправний нік, помилка програмного забезпечення або, можливо, неправильно налаштований сервер vmware. Які інструменти доступні на комутаторах доступу для відстеження порушника?

cisco switch layer2

— Користувач123456
джерело

Видаливши свою посаду, не зрозумів, що їх взагалі не бачили. Якщо комутатор не поставить їх у CAM, то, мабуть, найкраще запустити сеанс SPAN на комутаторах, але навіть тоді було б складно знайти вихідний порт. Іншим варіантом може бути відключення невідомого одноадресного вікна та перевірка, чи щось порушиться Я дивуюсь, що спілкування працює, хоча. Якщо хост із цим MAC надсилає щось поза його підмережею, GW доведеться ARP, щоб побачити MAC хоста та інкапсулювати кадр, чи GW має якісь дивні відображення ARP?

— Даніель Діб

Відповідно до supportforums.cisco.com/docs/DOC-36000 ці кадри повинні бути скинуті в HW, так що принаймні це не повинно впливати на роботу комутаторів.

— Даніель Діб

Так, за цим посиланням: "Зверніть увагу, що пакети з недійсною MAC-адресою все одно будуть скинуті, всі інші комутатори Cisco Catalyst мовчки скидають ці пакети в HW, 4k платформа явно генерує повідомлення журналу, коли спостерігається така подія." ... але я знаю, що це насправді не може бути так, оскільки 4500 скаржиться на кадри, які надходять на Te5 / 1, це порт, підключений до 3750. Це означатиме, що 3750 пересилає кадри з недійсним source mac, незважаючи на те, що говорить DOC-36000.

— Користувач123456

Розділіть і перемагайте!

— generalnetworkerror

Чи допомогла вам якась відповідь? якщо так, то слід прийняти відповідь, щоб питання не з’являлося вічно, шукаючи відповідь. Крім того, ви можете надати та прийняти власну відповідь.

— Рон Моупін

Відповіді:

Ви можете спробувати, чи можна кадри блокувати за допомогою MAC ACL на інтерфейсах та / або vlans на комутаторах доступу. Застосовуючи блоки вибірково і перевіряючи, чи зникають повідомлення про помилки на 4500 чи ні, ви можете повернутися до джерела трафіку.

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

— Гербен
джерело

Як правило, коли я це бачив, він походить від погано налаштованої VM (часто розміщеної на користувальницькій машині). Залежно від ситуації та навколишнього середовища їх складно відстежити (побачили багато цього в університеті в будівлях відділу CS та ECE, які переїжджали та приїжджали / їхали, як це робили студенти).

У вас вже є кілька чудових відповідей, але ще один варіант, який ви можете скористатися, - це додати наступний конфігурацію до комутаторів нижче (37xx, 36xx, 29xx):

   mac address-table static 0000.0000.0000 vlan <VLAN ID> drop

Це знизить будь-який трафік із цим MAC, а не переадресує його, і оскільки це потрібно робити апаратно (забороняючи будь-які функції / проблеми, які викликають пошук MAC у програмному забезпеченні), це не повинно негативно впливати на продуктивність.

— YLearn
джерело

Дякую за цю пропозицію. Це запобіжить переправленню кадрів через магістралі на інші комутатори, що є великим виграшем. Чи існує спосіб за допомогою команд реєстрації або налагодження відстежувати кадри, що випадають з порту, виходячи з цієї конфігурації?

— Користувач123456

@fcorrao, на жаль, не з цією конфігурацією. Вам доведеться спробувати зробити те, що запропонував Гербен, і використовувати MAC ACL або пропозицію Дейва щодо захоплення трафіку з портів. Але я вважаю, що тільки неправильно налаштований пристрій зазнає негативного впливу, тому або вони дадуть йому знати, або навіть не помітять себе.

— YLearn

Мені здається, що ця помилка не впливає на продуктивність мережі, оскільки ви виявили повідомлення журналу самостійно, а не переповнювались скаргами користувачів. Це змушує мене підозрювати, що проблема пов’язана з деяким підключеним, але частково налаштованим або неправильно налаштованим програмним забезпеченням або послугою, яка наразі не використовується.

Ваш найкращий курс може бути, щоб цей сплячий пес лежав до тих пір, поки деякі користувачі не повідомить про проблему. Крім того, якщо у вас є час на запас, ви можете запустити сеанси SPAN, як запропонував @Daniel Dib, і дати ретельну ретельну перевірку, поки не визначите підозрілий порт або пристрій.

— Дейв в Огайо
джерело