Комментарии 15
Для DES-3200-** следует указывать ревизию.
Железки или прошивки?
Для этой железки серии (A1/B1) и (C1) два разных коммутатора, с разными прошивками.
Железки конечно. Как верно заметили выше, A/B и C серии — разные коммутаторы.
Аппаратная ревизия. К примеру A и B по синтаксису схожи, а вот C коренным образом отличается, в ней другой чипсет, иной функционал PCF. Вообще в приличном обществе ведндору бы канделябром закатили за такое. Модель одна, а фактически это разные железки. Даже прошивка имеет иную нумерацию.
Эта привычка D-link-а (да и не только его) — увы, много крови портит. Берут индекс успешной на рынке железки, делают новую с тем же индексом, но с новой «ревизией», делают ее плохо — и все «счастливы».
Иные организации берут партию, скажем, свичей, для дальнейшего построения сети, а потом получают, что SNMP от старой «такой же» по индексу индексу модели коммутатора не подходит к этим новым устройства. Что в новых новые же и баги, можно не говорить.
Что мешает брать для нового железа новый индекс — мне сложно понять. Маркетологи, вероятно!
Остается одно — покупать, внимательно читаю спецификацию для букв ревизии.
Иные организации берут партию, скажем, свичей, для дальнейшего построения сети, а потом получают, что SNMP от старой «такой же» по индексу индексу модели коммутатора не подходит к этим новым устройства. Что в новых новые же и баги, можно не говорить.
Что мешает брать для нового железа новый индекс — мне сложно понять. Маркетологи, вероятно!
Остается одно — покупать, внимательно читаю спецификацию для букв ревизии.
Уважаемый автор, не совсем понятен орг-вывод по коммутатору 3526, предлагающий уменьшить количество vlan’нов. Как это влияет на количество хеш-коллизий? Разве не наоборот, раскидываем MAC-адреса по vlan, чтобы попытаться сделать более разнообразные хеши?
Если посмотреть на природу хеш-коллизий, они возникают из-за того, что два разных MAC-адреса имеют одинаковое значение хеша. Поэтому, по идее, размер таблицы MAC не имеет определяющего значения при возникновении хеш-коллизий. Основная причина в самом алгоритме вычисления. Поэтому, на мой взгляд, стоило бы переформулировать название таблицы: зависимость количества проблем от количества MAC-адресов. Плюс, добавить табличку со средним значением количества проблем по моделям коммутаторов (т.е. кто и в какой степени этим страдает). Думаю, было бы интересно.
Если посмотреть на природу хеш-коллизий, они возникают из-за того, что два разных MAC-адреса имеют одинаковое значение хеша. Поэтому, по идее, размер таблицы MAC не имеет определяющего значения при возникновении хеш-коллизий. Основная причина в самом алгоритме вычисления. Поэтому, на мой взгляд, стоило бы переформулировать название таблицы: зависимость количества проблем от количества MAC-адресов. Плюс, добавить табличку со средним значением количества проблем по моделям коммутаторов (т.е. кто и в какой степени этим страдает). Думаю, было бы интересно.
Ну, понятно, что раскидывание по vlan-ам не спасёт, если у вас просто хеш функция будет общая. Более того, если в таком зоопарке плодить vlan-per-user — у нас ещё и мак роутера в паре с разными VlanID позабивает таблицу весьма. Так что «правильно» — меньше абонов в сегиенте, меньше сегментов в свиче. Идеально, наверное — по vlan-у на свич. Таблички подобью, но среднее — не вполне репрезентабельно. Думаю, правильно нарисовать среднее и максимальное количество проблем от количества маков. Нарисую, да.
Да, извините — действительно, коллизионный домен при vlan-per-user сократится, если только свич не проходной для других собратьев, а чисто абонентский — тогда будет работать.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Ещё раз про хеш-коллизии в коммутаторах