[BUG] DES-3028 - MAC-адреса не добавляются в таблицу коммутации свитча (auto-learning bug).

Описание:
При прохождении ARP-пакета через любой из портов, MAC отправителя не добавляется в динамическую таблицу коммутации свитча если в ней присутствует определённый MAC-адрес.
ПО коммутатора видимо считает что MAC-адрес "A" равен MAC-адресу "B" и уже добавлен в таблицу коммутации, хотя в действительности они абсолютно разные. Таким образом MAC-адреса "A" и "B" не могут одновременно находиться в таблице коммутации в пределах одного VLAN'а.
На 300 MAC-адресов, попадается примерно 5-7 таких пар.

Как воспроизвести данную ситуацию ?
1. Подключаем к свитчу DES-3028 три устройства, интерфейсы которых имеют МАС-адреса/IP-адреса:
A) 00:1d:93:fa:ca:6c / 10.0.0.2
B) 00:1a:4d:f8:e5:19 / 10.0.0.3
C) любой MAC-адрес / 10.0.0.1

2. Выполняем arping (или ping) устройства "C" через интерфейс устройства "A". (10.0.0.2 -> 10.0.0.1)
3. Выполняем arping (или ping) устройства "С" через интерфейс устройства "B". (10.0.0.3 -> 10.0.0.1)
4. В таблицу коммутации свитча будут добавлены только МАС-адреса устройств "A" и "C".
Либо вместо "A" будет "B" если свитч добавил МAC-адреса устройства "B" перед тем как получил пакет от устройства "A".

Последствия:
Увеличение нагрузки на все порты коммутатора в следствие того, что МАС-адрес получателя пакетов не может быть добавлен в таблицу коммутации и пакеты отправляются на все порты сразу.

Версия FW/HW:
Hardware Version A1
Boot PROM Version Build 1.00-B04
Firmware Version Build 2.20.B07

Так же баг присутствует и в версиях FW:
Build 1.00-B32
Build 2.00.B27

P.S. На свитче DES-3010G (Boot PROM: 1.01.009; FW: 4.20.B27) данная проблема не обнаружена.

Знаем эту проблему. Дилинковцы считают ее не "багом", а "фичей"
Из-за этого продолжаем покупать 3526, вместо 3028...

Добавляю ещё один баг сюда же, т.к. считаю что они оба зависят от одной и той же ошибки в алгоритме хеширования либо сверки MAC-адресов.
[BUG] DES-3028 - Не возможно добавить статические MAC-адреса в таблицу коммутации.

Описание: При попытке добавить пару MAC-адресов "A" и "B" в таблицу коммутации свитча, после добавления одного из них, добавление второго становится не возможным (сообщение свитча - fail).

Как врспроизвести ситуацию ?
1. Проверяем таблицу коммутации свитча



2. Прописываем MAC-адрес "A" - 00:1d:93:fa:ca:6c на любой из портов в default VLAN:

3. Прописываем MAC-адрес "B" - 00:1a:4d:f8:e5:19 на любой из портов в default VLAN:


4. После сообщения об ошибке, снова проверим таблицу коммутации, чтобы удостоверится в том что MAC-адрес "B" в ней отсутствует:



Версия FW/HW:
Hardware Version A1
Boot PROM Version Build 1.00-B04
Firmware Version Build 2.20.B07

Я очень надеюсь что это не так, т.к. придётся отправить около 20 таких девайсов на металлолом =/ Ошибки коммутации на L1 ни к чему хорошему не приводят... =(

Мы как раз тоже 20 взяли, хорошо установить не успели, баг этот обнаружили, обменяли на 3526, спасибо поставщику.
С дилинком ругались - бестолку, предложили два решения:
1. Менять MAC у пользователя.
2. Делать VLAN per customer.

Очень удивлен! Представители длинк как-нибудь прокомментируют эту ситуацию?

Проверил у себя:


Т.е. мак всё-таки появился в таблице fdb static. А вот в если делать sh fdb то мака 00-1D-93-FA-CA-6C там нет.

_________________
SkyNet Telecom
http://sknt.ru

Гордый обладатель сертификата "Коммутированные сети(basic) на основе оборудования D-Link" №00-0117

Появляется, но толку от того что он там появился - нет. Проверьте, все пакеты, предназначающиеся этому MAC, рассылаются на все порты.

Данный баг так же можно причислить к уязвимостям:
Имеем хост с МАC-адресом "А" пакеты к которому проходят через 3028, находим пару "B" для этого MAC'а, шлём пакеты на несуществующий МАС-адрес с МАС-src = "B", дожидаемся пока обновится таблица коммутации. В итоге получаем прописанный на 3028 МАС-адрес "B" и пакеты предназначенные для хоста "A" посылаются на все порты коммутатора.

Если таким образом провести "атаку" на определённый процент МАС-адресов в сегменте, сегмент будет перегружен "левым" трафиком. Также некая альтернатива ARP-спуфингу, только построена на особенности оборудования.

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

viewtopic.php?t=58066&start=0&postdays=0&postorder=asc&highlight=
После прошивки ничего так и не поменялось. На уже установленных свитчах пришлось отключить DLF ограничитель и сделать вид что все так и должно быть.
Сейчас покупаем 3526. Проблем нет, но вызывает опасение, что эту линейку могут закрыть в пользу 3028/3528

А еще у этой железки есть такой баг viewtopic.php?p=478835#478835
И надеюсь этого достаточно, что бы таки заставить програмеров посмотреть в сторону алгоритма работы с таблицей комутатиции и исправить его. А то небось, как написали для 3526 лет шесть назад, так и копипастят по всем железякам.

Это невезуха какая-то, думал что лажанулся выбрав 35-ю серию. в 30-й не лучше, но по-другому (

_________________
Если пушки в цене - значит дело к войне,
Кто не хочет платить тот заплатит вдвойне.

Думаю нас спасет 32хх серия, которая уже на подходе!

Не флейма ради, кто будет менять то что уже есть7 и за какие такие деньги? )

не-не-не, мне нужно взлетать с тем что есть )

_________________
Если пушки в цене - значит дело к войне,
Кто не хочет платить тот заплатит вдвойне.

А кому нужны флудящие свичи? У меня всего несколько штук в сети, а такой гемор из-за них... Заменим при первой возможности. Держу из-за того, что это пока единственная моель с 4-мя SFP портами.