👍

Закинуть сетевому админу, он должен быть... админище, у него голова большая, пусть думает. Чего не знает - нагуглит, с людьми поговорит, с асушниками, наденет каску и сходит на объект с ноутом. Недельку другую не поспит, потом выдаст вердикт "потому, что гладиолус" :)

И не говори! От админов уже неделю не могу добиться ответа почему стек коммутаторов периодически в падает в транс и ведет себя как хаб и на разных VLAN это с разной периодичностью проявляется. Первым делом подумали, что ARP-спуфингом кто балуется. Но в ARP таблицевсе в порядке. Ребут не помогает, обновление прошивки не помогает. Вот и гадают админы на кофейной гуще. :(

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

Еще была раньше тема слабой хеш функции в асиках, но это тогда проявлялось бы всегда. Хотя теоретически могло везти с самими макмми, что коллизий не было

FDB соответвует реально существующим устройствам, в ней мусора не наблюдается. Да и 400 MAC на стек из 5 коммутаторов не предельные значения.

Нафлудить можно столько, сколько нужно, но раз вы не наблюдаете этого факта, то отпадает. Надо внимательно смотреть и раскрыть вопрос "ведет себя как хаб", т.к. тут может быть масса ньюансов. А именно - масштабы этого поведения. Это проявляется для всех портов в влан-е, для любого трафика или как-то более узко. Мне сдается, что более узко. Недавно разбирался с такой проблемой, мол виден на совешренно "левом" порту чужой трафик. Причина банальна - nlb кластер и фокусы с несуществующим мак-ом. Там механизм, когда в арп ответе фигурирует мак, которого реально нет ни на каких интерфейсах нигде, свич ему обучиться не может и получаем широковещание, когда на этот мак посылается трафик, так добиваются получения трафика на все ноды сразу. Лечится приколоченными записями в фдб. Могут быть подобные моменты. Важна инвентаризация всех мак-ов и контроль за ними, я бы начал с этого. Все ли они валидные, в смысле реально принадлежат известным и лигитимным устройствам. Причем, такую штуку, имхо, надо иметь всегда на сети и собирать стату непрерывно. Дальше уже думать.

Еще бывает в схемах отказоустойчивых, где дублируется оборудование, но при этом в силу косяка трафик идет ассиметрично

Радиус сервер развернуть и авторизацию по mac.

т.е., допустим, обучился по входящему трафику один свич, условное полуядро, а исходящий уходит по другому маршруту и другой свич мака не знает, получается флуд по портам. Но у вас стек, ему это не свойственно, вот когда на базе hsrp + stp - там бывает

VRRP присутствует, да. Погляжу еще раз дампы трафика, спасибо за подсказку.

Тогда вангую, что что-то с этим

Смотрим на трафик, который нам кажется странным и типа мы его видеть не должны, как мы понимаем работу свича. Берем мак-и и разбираемся очень подробно с фдб, и л3 уровень тоже подключаем. Скорей всего ассиметрия и где-то не происходит обучение

Это, пардон, будет на свиче доступа. А ядро - оно сильно дальше и если там потом происходит непонятка, не свяазнная никак с подделкой мак-ов, флудом, спуфингом и т.д. - как вам это поможет?

Тогда никак, но в плане инвентаризации и наведения порядка очень даже.

Можно и проще. Маки прибиты к портам. Ип прибиты к мак-ам, один мак на порт. Дхцп снупинг + арп инспекция + ип сурсгуадр. Если охватить всю сеть - результат почти железный, порядок, чистота. И при этом описанная человеком проблема - запросто может иметь место и никак она при этом не связана с юзерами, неавторизованными устройствами, хак. активностью и т.д. Чисто сетевые заморочки.

Когда устройств много и они разнородны, так сложнее за ними следить. А через группы на радиус удобно.

Чем это мониторить? Сейчас у ребят какая-то не самая последняя версия Zabbix, но что-то не помню, чтобы там подобный функционал имелся.

Если радиус использовать то вариантов мониторить масса.

В смысле, мониторить? Любое новое устройство не должно втыкаться в сеть просто так, а проходить через соотв. специалистов. А уж в радиусе они что-то куда-то занесут или еще что-то где-то настроят - второй вопрос. При нарушении, например включении в сеть левого девайса - будут логи. Имейте их в паре централизованных точек, далее все и так понятно. Радиус единичная точка отказа, в малой или средней сети я бы не стал его городить и усложнять. До 200-300 хостов описанная мной схема более чем жизнеспособна, надежна и проста.