Насчет флуда. Если dst mac нету в FDB, то обычное поведение это отправить пакет на все порты чтобы начать процесс обучения. А так как по каким либо причинам он не может его обучить то во все порты (поднятые) постоянно льется трафик.
Не такая ли у вас ситуация получилась?
Коменты раз в 5 минут оставляют время на подумать.
Этот вопрос я изучал гдето год назад, некоторые вещи мог не правильно понять.
Но я себе представляю это так.
Приходит пакет.
Железка считает для него хэш и проверяет есть ли он в таблице форвардинга.
Если его нету, то она добавляет туда хэш, мак, порт, влан.
Приходит пакет с другого порта но хэш получается таким же.
Дальше все зависит от вендора — он может как перезаписать запись в таблице так и не трогать ее.
Получается что мак с другого порта может быть не выучен и соответственно он может как отбросить пакет, так и послать флудом на все порты.
В итоге получается что хотели сэкономить в памяти на железе (очевидно что хранить 8к записей по 8 байт дороже чем по 8к записей по 6байт). Ну и плюс операции поиска по идее должны быть быстрее на меньших объемах данных.
Хэш обычно считается как функция от мак, порт, влан.
Т.е. допустим мак+порт+влан имеют длину допустим 64бита.
А хэшфункция из них делает 48бит или меньше даже, за счет этого таблица форвардинга меньше но при поиске по ней два порта(точнее тройки мак, порт, влан) могут иметь одинаковый хэш и тогда возможны варианты, например флуд во все порты или зеркалирование трафика по двум портам у которых совпал хэш.
Часто возникает на недорогих чипах, когда длина хэша не очень большая.
Причем насколько помню для того же DES3028 ограничение чисто железное, софтом оно никак не исправляется.
На практике сталкивался с коллизиями на DES3028, сейчас перешли на EdgeCore, вроде там таких проблем явно не заметно.
Но надо будет потестить.
Не такая ли у вас ситуация получилась?
Этот вопрос я изучал гдето год назад, некоторые вещи мог не правильно понять.
Но я себе представляю это так.
Приходит пакет.
Железка считает для него хэш и проверяет есть ли он в таблице форвардинга.
Если его нету, то она добавляет туда хэш, мак, порт, влан.
Приходит пакет с другого порта но хэш получается таким же.
Дальше все зависит от вендора — он может как перезаписать запись в таблице так и не трогать ее.
Получается что мак с другого порта может быть не выучен и соответственно он может как отбросить пакет, так и послать флудом на все порты.
В итоге получается что хотели сэкономить в памяти на железе (очевидно что хранить 8к записей по 8 байт дороже чем по 8к записей по 6байт). Ну и плюс операции поиска по идее должны быть быстрее на меньших объемах данных.
Т.е. допустим мак+порт+влан имеют длину допустим 64бита.
А хэшфункция из них делает 48бит или меньше даже, за счет этого таблица форвардинга меньше но при поиске по ней два порта(точнее тройки мак, порт, влан) могут иметь одинаковый хэш и тогда возможны варианты, например флуд во все порты или зеркалирование трафика по двум портам у которых совпал хэш.
Причем насколько помню для того же DES3028 ограничение чисто железное, софтом оно никак не исправляется.
На практике сталкивался с коллизиями на DES3028, сейчас перешли на EdgeCore, вроде там таких проблем явно не заметно.
Но надо будет потестить.
habrastorage.org/storage2/cbe/2ee/a5b/cbe2eea5b64fc85b5b675492923328dd.jpg
Не только папка которая пошарена.
А новые может не ставят так как цены на них сильно выросли.
2 диска
Может вы OEM брали? Хотя еще от редакции зависит…