mickvav Oct 12 2015 at 11:29

Ещё раз про хеш-коллизии в коммутаторах

3 min

23K

System Analysis and Design*Development of communication systems*

Comments 15

Obramko Oct 12 2015 at 12:16

Для DES-3200-** следует указывать ревизию.

mickvav Oct 12 2015 at 12:26

Железки или прошивки?

xBrowser Oct 12 2015 at 13:34

Для этой железки серии (A1/B1) и (C1) два разных коммутатора, с разными прошивками.

mickvav Oct 12 2015 at 14:04

Организуем…

mickvav Oct 12 2015 at 16:43

3200-26 A1 три штуки на всю сеть и никаих выбросов на них нет, так что нерепрезентативно,
можно считать, что все 3200 на картинке — C.

Obramko Oct 12 2015 at 13:50

Железки конечно. Как верно заметили выше, A/B и C серии — разные коммутаторы.

Yoda33 Oct 12 2015 at 14:28

Аппаратная ревизия. К примеру A и B по синтаксису схожи, а вот C коренным образом отличается, в ней другой чипсет, иной функционал PCF. Вообще в приличном обществе ведндору бы канделябром закатили за такое. Модель одна, а фактически это разные железки. Даже прошивка имеет иную нумерацию.

mickvav Oct 12 2015 at 15:34

Ну да, dlink подобными финтами грешен и нетолько в свичах, но и в домашних роутерах. 3200-xx — что-то не могу сходу найти ни одного A или B, только C. К вечеру скриптик, подбивающий эти циферки, отработает — отчитаюсь.

Obramko Oct 12 2015 at 16:58

A и B — фактически тот же коммутатор. Там изменения не касались функционала, да и прошивка для них общая.
А вот C — другое дело, он даже выглядит совсем по-другому.

mickvav Oct 12 2015 at 17:06

Ну нету у нас A и B в значимых количествах. И артефактов на тех, которые есть — не видно.

achekalin Oct 12 2015 at 16:00

Эта привычка D-link-а (да и не только его) — увы, много крови портит. Берут индекс успешной на рынке железки, делают новую с тем же индексом, но с новой «ревизией», делают ее плохо — и все «счастливы».

Иные организации берут партию, скажем, свичей, для дальнейшего построения сети, а потом получают, что SNMP от старой «такой же» по индексу индексу модели коммутатора не подходит к этим новым устройства. Что в новых новые же и баги, можно не говорить.

Что мешает брать для нового железа новый индекс — мне сложно понять. Маркетологи, вероятно!

Остается одно — покупать, внимательно читаю спецификацию для букв ревизии.

mickvav Oct 12 2015 at 16:48

Да, пора уже писать искуственный интеллект, который глядя на рекурсивный вывод snmpwalk-a и вооружившись какими-нибудь разумными эвристиками и google-fu раскладывает OID-ы по полочкам сам :)

ksg222 Oct 12 2015 at 15:10

Уважаемый автор, не совсем понятен орг-вывод по коммутатору 3526, предлагающий уменьшить количество vlan’нов. Как это влияет на количество хеш-коллизий? Разве не наоборот, раскидываем MAC-адреса по vlan, чтобы попытаться сделать более разнообразные хеши?

Если посмотреть на природу хеш-коллизий, они возникают из-за того, что два разных MAC-адреса имеют одинаковое значение хеша. Поэтому, по идее, размер таблицы MAC не имеет определяющего значения при возникновении хеш-коллизий. Основная причина в самом алгоритме вычисления. Поэтому, на мой взгляд, стоило бы переформулировать название таблицы: зависимость количества проблем от количества MAC-адресов. Плюс, добавить табличку со средним значением количества проблем по моделям коммутаторов (т.е. кто и в какой степени этим страдает). Думаю, было бы интересно.

mickvav Oct 12 2015 at 15:31

Ну, понятно, что раскидывание по vlan-ам не спасёт, если у вас просто хеш функция будет общая. Более того, если в таком зоопарке плодить vlan-per-user — у нас ещё и мак роутера в паре с разными VlanID позабивает таблицу весьма. Так что «правильно» — меньше абонов в сегиенте, меньше сегментов в свиче. Идеально, наверное — по vlan-у на свич. Таблички подобью, но среднее — не вполне репрезентабельно. Думаю, правильно нарисовать среднее и максимальное количество проблем от количества маков. Нарисую, да.

mickvav Oct 12 2015 at 15:36

Да, извините — действительно, коллизионный домен при vlan-per-user сократится, если только свич не проходной для других собратьев, а чисто абонентский — тогда будет работать.