Отслеживание неверного исходного MAC-адреса

Я унаследовал поддержку удаленного сайта, который содержит 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 другим коммутаторам доступа. После небольшого поиска в Google, кажется, 4500 - единственная платформа cisco, которая регистрирует неверные MAC-адреса источника. Насколько я понимаю, другие платформы (2960, 3750 и т. Д.), Кажется, направляют кадры вперед, но не регистрируют их как недействительные и не добавляют запись в таблицу адресов Mac. Я подозреваю, что основной причиной неправильных исходных MAC-адресов может быть неисправный ник, программная ошибка или, возможно, неправильно настроенный сервер VMware. Какие инструменты доступны на коммутаторах доступа для отслеживания порта-нарушителя?

cisco switch layer2

— User123456
источник

Удалил мой пост, не понял, что их вообще не было видно. Если коммутатор не поместит их в 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 пересылает кадры с недействительными Исходный Mac, несмотря на то, что говорит DOC-36000.

— 11.09.13

Разделяй и властвуй!

— generalnetworkerror

Вам помог какой-нибудь ответ? Если это так, вы должны принять ответ, чтобы вопрос не появлялся вечно, ища ответ. Кроме того, вы можете предоставить и принять свой собственный ответ.

— Рон Мопин

Ответы:

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

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

— Gerben
источник

Обычно, когда я видел это, он исходит из плохо сконфигурированной виртуальной машины (часто размещенной на пользовательском компьютере). В зависимости от ситуации и среды, их может быть трудно отследить (многие из них видели в университете в зданиях департамента CS и ECE, которые перемещались и приходили / уходили, как это делали студенты).

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

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

Это будет отбрасывать любой трафик с этим MAC, а не пересылать его, и, поскольку это должно быть сделано аппаратно (за исключением любых функций / проблем, которые приводят к выполнению поиска MAC в программном обеспечении), это не должно оказывать негативного влияния на производительность.

— YLearn
источник

Спасибо за это предложение. Это предотвратит пересылку кадров через соединительные линии другим коммутаторам, что является большой победой. Есть ли способ через команды ведения журнала или отладки наблюдать кадры сброса порта на основе этой конфигурации?

— 13.09.13

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

— YLearn

Мне кажется, что эта ошибка не влияет на производительность сети, так как вы обнаружили сообщения журнала самостоятельно, а не наводнены жалобами пользователей. Это заставляет меня подозревать, что проблема заключается в некотором подключенном, но частично настроенном или неправильно настроенном программном обеспечении или службе, которая в данный момент не используется.

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

— Дэйв в Огайо
источник