Я унаследовал поддержку удаленного сайта, который содержит 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. Какие инструменты доступны на коммутаторах доступа для отслеживания порта-нарушителя?
Ответы:
Вы можете попытаться заблокировать кадры, используя MAC ACL на интерфейсах и / или на vlans на коммутаторах доступа. Применяя блоки выборочно и проверяя, исчезают ли сообщения об ошибках на 4500 или нет, вы можете определить источник трафика.
Перемещение кабелей вокруг, чтобы увидеть, может ли порт, упомянутый в сообщении об ошибке на 4500, также помочь, но может оказаться сложным в производственной среде.
источник
Обычно, когда я видел это, он исходит из плохо сконфигурированной виртуальной машины (часто размещенной на пользовательском компьютере). В зависимости от ситуации и среды, их может быть трудно отследить (многие из них видели в университете в зданиях департамента CS и ECE, которые перемещались и приходили / уходили, как это делали студенты).
У вас уже есть пара отличных ответов, но другой вариант, который вы можете использовать, - это добавить следующую конфигурацию в нисходящие коммутаторы (37xx, 36xx, 29xx):
Это будет отбрасывать любой трафик с этим MAC, а не пересылать его, и, поскольку это должно быть сделано аппаратно (за исключением любых функций / проблем, которые приводят к выполнению поиска MAC в программном обеспечении), это не должно оказывать негативного влияния на производительность.
источник
Мне кажется, что эта ошибка не влияет на производительность сети, так как вы обнаружили сообщения журнала самостоятельно, а не наводнены жалобами пользователей. Это заставляет меня подозревать, что проблема заключается в некотором подключенном, но частично настроенном или неправильно настроенном программном обеспечении или службе, которая в данный момент не используется.
Ваш лучший способ может заключаться в том, чтобы позволить этой спящей собаке лгать до тех пор, пока некоторые пользователи не сообщат о проблеме. В качестве альтернативы, если у вас есть свободное время, вы можете запустить сеансы SPAN, как предложено @Daniel Dib, и внимательно следить за выходом, пока не определите подозрительный порт или устройство.
источник