Так как в DES-3028 присутствует проблема с недостаточным размером (?) хэша, из-за чего некоторые МАСи не могут добавиться в таблицу коммутации, хотелось бы узнать алгоритм вычисления этого самого хэша.
Требуется для двух вещей:
а) у пары абонентов "конфликтующие" МАС-адреса. решили одному сменить МАС (просто придумав его, задав в соответствующих битах какого-либо редкого вендора) Как узнать, что он не будет конфликтовать с кем-то из оставшихся 1000 абонентов и не придется менять МАС повторно
б) подключается новый абонент. При подключении сразу "на берегу" проверить, не конфликтует ли его МАС, и при необходимости сразу его перебить

МАС-адреса всех абонентов (и "не-абонентов", то что прилетело через трапы) хранятся в SQL базе, так что зная принцип вычисления хэша проверить МАС на конфликтность можно просто.
В живую на свиче проверить конфликтность можно только для активных абонентов (компьютеры которых сейчас включены) просто попробовав добавить статическую запись. Но это не перекрывает всю абонентскую базу и плохо автоматизируется.

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

Я думаю на этот ответ вам ответ не дадут... ибо все алгоритмы закрыты.

_________________
LiveComm

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

а я прошу алгоритм с ошибкой :-) которого лучше бы и не видеть, но как бы приходится через силу

Дак не длинк ошибку допустили)) а разработчик чипсета.

_________________
LiveComm

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

P.S.: но если уж появился сей алгоритм, то можно тогда и мне его прислать.

То что ошибка в чипсете понятно. Но разработчики и поставщики чипсета не связаны со мной никакими гарантийными обязательствами, поэтому обратиться я к ним напрямую тоже не могу.

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

А по телефону советуют нарезать все на виланы и включить proxy-arp. Но это только для протокола IP применимо. Плюс тянет за собой повышение нагрузки на аплинки сети (которой как раз хотелось бы избежать)

Я решился поменять МАСи у абонентов. Но проблема в том, что не знаю на какие, так как большая вероятность что опять будет конфликт. У меня при включенных ~800 машинах в сегменте "конфликтуют" 32 пары. Это получается 5% машин.

Нам тоже интересен алгоритм, и ситуация такая же что все маки хранятся в базе.

Это закрытая, нераспространяемая информация. Вопрос может решаться только в частном порядке в телефонном разговоре с Дёминым Иваном (095) 744-00-99, доб 390.