Повторяю свой вопрос.
Как данная проблема отразится на мультикасте?
И что такое по мнению dlink правильная топология для мультикаста где проблем не будет. А то складывается впечатление что Вы сами не знаете
характеристик того что производите или правильная топология ещё не определена и колеблется вместе с багами коммутатора.

Это не вариант по понятным причинам, которые я думаю Вам Иван Дёмин объяснил.



Мы не врали, просто, изначально, перед появлением DES-3200, мы уточняли у BCM: "Есть ли такая проблема на DES-3200 как на DES-3028!?", нам ответили, что именно такой нет. Далее, когда у нас появился DES-3200, мы попробовали вбить два МАС адреса, которые коллизируют на DES-3028, оба МАС адреса добавились в FDB таблицу, и только попозжа мы разобрались в моментах, т.е. в отличиях DES-3028 и DES-3200, которые Вы можете наблюдать в нашем отчёте, и что, проблема с hash на DES-3200 не так критична, как её хотят преподнести некоторые люди.



Вы имеете ввиду модель DES-3028 или DES-3200?

_________________
С уважением,
Бигаров Руслан.

Нас бы вполне устроила замена DES3028 на DES3200-28 с доплатой разницы. Такое возможно?

При всем уважении к Руслану и Ивану. Хотелось бы выразить им благодарность за то, что они делают. Я прекрасная понимаю что нет в этом их вины, надеюсь что другие участники обсуждения тоже постараются это понять и не будут вымещать свой негатив на них. Их, к сожалению, ограничивает в возможностях и высказываниях политика компании. Было бы неплохо что-бы все об этом помнили.

Это было лирическое отступление, теперь попробуем вернуться в конструктивное русло.

Вопрос первый:
У всех вышеперечисленных коммутаторов в технических характеристиках до сих пор числится 8K MAC Adresses, выглядит очень странно учитывая что у 3028 и 3200-28 эти цифры недостижимы или достижимы в очень специфичных условиях.
Если я не ошибаюсь это называется несоответствие товара заявленным характеристикам, и продажа такого товара является на мой взгляд не очень легальной (но тут я могу и ошибаться не юрист). В любом случае выглядит не очень красиво.
Хотелось бы что бы эти характеристики поменялись на что-то более вменяемое и правдивое. И было бы очень хорошо если бы эта информация появилась рядом со всеми коммутаторами которые могут этим страдать. Например: 512 адресов - 100% (исходя из ваших тестов, применимо к 3200-28 ).
Я конечно понимаю что от этого может пострадать маркетинг, и вроде выходом было бы написать например, что "8K MAC адресов (используется одноуровневое хеширование)", но для меня до сегодняшнего момента было загадкой что за этим скрывается, хотя некоторых это может заставит задуматься и поискать что же это значит. Может быть найдется какой-то способ донести эту информацию не уронив лицо. Очень на это надеюсь.

Вопрос второй:
Проскакивало то ли здесь то ли на наге такое предложение. Очень надеюсь что оно реализуемо. Суть его вот в чем: что если сделать функцию хеширования софтово отключаемой, понятно что при этом упадет максимальное количество возможных записей, но коммутатор хотя бы честно будет запоминать n-ное кол-во записей.
Ну и неплохо было бы во всех коммутаторах подверженных таким симптомам хоть и с низкой вероятностью сделать аналог функции flood_fdb с 3028. Если проблема появляется оператор должен быть в курсе. Мне кажется это будет правильным.

И третий вопрос, заключительный:
Я на самом деле был поражен, действительно очень сильно удивился когда прочитал про "ну мы спросили, нам сказали что нет, проблемы не будет". Понятно что это не Ваша вина, и Ваши возможности дальше как спросить и не позволяют, да и не включено это наверное в Ваши рабочие обязанности.
Но коммутатор же кто-то разрабатывал, проектировал, читал спеки, даташиты. Неужели его никто не пробовал хоть раз протестировать по основным функциям до начала продаж?! Должен же быть человек или отдел отвечающий за тестировании продукции. Ведь как оказалось проверить сможет ли запомнить коммутатор 8000 уникальных & не броадкастовых & не мультикастовых мак адресов совсем не сложно. Ну или по крайней мере если такого человека/отдела не было, он мне казалось должен бы был появиться после косяков с 3028.
Я прекрасно понимаю что есть немала вероятность того, что вы (фирма д-линк, не вы лично конечно) заказывали его у какого нибудь OEM производителя, но в таком случае опять же либо они должны были его протестировать и нести ответственность, либо у вас кто то должен был его принимать.

И получается в итоге что:
1) Кто-то где-то нехило просчитался, и я очень надеюсь что не намеренно, иначе это получается вообще саботаж и обман. По другому и не назовешь.
2) Мучиться в итоге нам (операторам), вам (тех. поддержке), и скорее всего клиентам операторов. Геморроя в итоге принесло всем, только видимо не тому кто виноват на самом деле.
3) Репутация подмочена. И не столько потому что оказалось не только один д-линк страдает подобным, с этим еще хоть как-то можно смириться (хотя вспоминается пример 3526 и никак, ну никак не хочется). А потому что задавались прямые вопросы будет ли так все плохо, на что давались ответы что нет не будет, а оказалось что конечно не так плохо как раньше, но и не так уж и хорошо.
4) Раньше был 3526. Теперь же 2 пути, 3528, но учитывая цены на интернет и соответственно доходы операторов, не очень радужно выглядит. Либо 3200-28 и "жди-когда-вылезет-прикручивай-мониторинг-и-т.д."

Мне если честно от всего этого только грустно и досадно. И то 3028 у меня единицы, а 3200-28 вообще нет. Представьте себе какие эмоции испытывают те у кого их навалом.

Нет, конечно. И дело не в том, что Вы написали, а ещё и в том, что в построение сетей в России отличается от остального Мира.



Спасибо за поддержку и понимание.

Ответ на первый вопрос: Даже если эти 8k МАС адресов достижимы при определённых условиях, давайте, посмотрим на эту ситуацию с другой стороны. Разогнав работу чипа и ускорив работы FDB таблицы, уменьшив до одного уровня hash-ирование, как побочный эффект получаем hash фичу. Если рассматривать hash проблему на одном кольце максимум из 20 коммутаторов DES-3200-26 или DES-3200-28 имеем 24 пользователя * 20 коммутаторов = 480 МАС адресов + 20 МАС адресов коммутаторов + МАС адреса шлюзов L3 коммутатора(агрегатора) + Multicast адреса, в итоге имеем в районе 600 МАС адресов плюс/минус. При таких условиях проявление hash проблемы стремится к нулю, что уже доказано и практикой и тестами(random и chain). Конечно, Вы можете закладывать в свой проект до 8k МАС адресов в одном домене, и что о вас будут думать другие админы MAN сетей можно прочитать на том же NAG-е. Так что, размер таблицы МАС адресов коммутатора уровня доступа я считаю чисто номинальной при правильном подходе построении сети как в целом, так и исходя из hash проблемы.


Ответ на второй вопрос: Мы уже думали над решением проблемы путём отказа от hash-ирования, но разработчики нам сказали, что это невозможно. А добавить функцию Flood FDB в серию DES-3200 можно и мы над этим уже работаем.

Ответ на третий вопрос: Мы тоже не юристы и не сразу обратили внимание на нюанс ответа. Но наученные опытом, теперь мы отслеживаем и проблему и чтобы у нового оборудования, которое запланировано на выпуск имели показатели по тестам близкие к показателям DES-3526 и DES-3528, как видно из тестов, проблема потихонечку невилируется.



Да, chipset-ы Broadcom-а и Marvell-а не только D-Link использует, но и все остальные вендоры, и каждый по-своему решает эту проблему.

Если брать только D-Link, то основной негатив из-за модели DES-3028, а если брать серию DES-3200 и обсуждение проблемы в этом топике, то всё выше описанное по данной серии - это следствие этого негатива, хотя не всё так плохо как пишут.

_________________
С уважением,
Бигаров Руслан.

Ну так весь мир еще недавно стоил сети доступа на DSLAM.
А те кто сейчас строит насколько я знаю делают vlan-per-subscriber+service-vlan. Хотя могу и ошибаться.

У нас проблемы с des3200 нет вообще, т.к. сегменты не более 60-100 абонентов (vlan-per-house), но вот с des3028 проблемы есть в таких сегментах, понятно что заменим на des3200 и т.д., но поменять сразу 300+ коммутаторов сложно, потому и был вопрос, как побыстрее избавится с минимальными фин.затратами.

На самом деле все это лирика связанная с des3028 и не более.

смелое заявление. по сути вас спасает от этой проблемы или то что ради 10 свичей этим лень заниматься или то что снять несколько тысяч свичей очень сложно - им вдь еще и замена нужна на время разбирательства. а если вспомнить как взрослые компании поступают в таких ситуациях? например таёта отзывает машины на доработки очень крупными партиями при очень мелких проблемах.


допустим, и что с того? это запрещено? где в документации написано "использовать только в схемах изображенных на рисунке номер 3, иначе мы не отвечаем за результат", ваше личное мнение о том как надо и как не надо строить сети к сожалению к делу не приложишь.
то что происходит это несоответствие заявленым характеристикам, у вас заявлено 8к маков? более того у вас спросили все ли нормально - вы ответили ДА.


лукавите! 8к маков НЕДОСТЕЖИМЫ, не будет этот свич работать на 8к маков.
проблема не в хешах а в том что вы опять нас обманываете.


разогнав? 3526 что медленно свичил ?
насчет уровней хеширования - зачем вы нам расказываете об архитектурных особенностях? чтобы отвлечь внимание от проблемы и сфокусироваться на понимании откуда она берется?
и опять подмена понятий - эта не фича это КРИТИЧЕСКАЯ ошибка. скоро отсутствие свича в коробке будите называть "фичей"



руслан, эта единственно возможная схема? это официальный ответ?где об этом написано в документации?
на 3526 можно использовать другие схемы?


да у нас притензия не к чипсету. а к недокументированости вашего продукта, к тому что мы выступаем в роли тестеров. к тому что закупаем оборудование на десятки милионов а оно не работает, клиенты недовольны, а вы нам расказываете о том что это по большому счету не проблема.

вот опять. у нас все хорошо это вы не умеете строить сети.

А архитектура чипа позволит за счет уменьшения размера FDB уменьшить вероятность коллизий ? Это был бы идеальный выход из создавшейся ситуации.

Оно теперь и так уже уменьшено в два раза в серии DES3200 для того что бы запоминать два коллизионных мака, куда дальше? А вдруг этих маков будет 8к с одним и тем же хешем(я конечно утрирую), но где та грань, 3 мака с одинаковым хешем, 4, 5, 6...?
Вот вам список маков с одинаковым хешем. А вдруг у вас в сети в одном сегменте будут эти маки: насколько тогда надо урезать fdb таблицу что бы это работало?
00-1E-EC-16-57-99
00-16-76-1D-E8-8B
00-1D-60-EE-0A-28
00-13-72-36-E9-C6
00-14-2A-87-C2-A2
00-22-15-28-67-7E
00-14-0B-43-72-5A
00-03-20-00-E0-FD
00-1D-60-80-01-EC
00-26-2D-64-5A-39
00-17-31-57-3F-27
00-19-C5-8C-AF-96
00-01-6C-DF-02-82
00-00-21-D8-80-1F
00-19-5B-7C-88-A9
00-22-15-2C-D3-B9
00-14-85-89-26-D2
00-19-5B-73-87-36
00-11-5B-4E-95-8C
00-01-6C-D8-75-BA
00-12-CF-C8-64-80
00-1D-72-AB-91-4F
00-1F-C6-44-62-4D
00-19-D1-ED-86-92
00-E0-4C-7E-63-A0
00-05-5D-2E-18-52
00-1D-60-DF-F9-7E
00-0F-EA-3E-9B-C4
00-1D-60-78-61-54
00-19-DB-66-CF-56
00-11-5B-63-2B-B6
00-80-48-46-94-00
00-14-0B-0A-2D-B6
00-E0-4C-82-D7-BC

WinsDark, вспоминай теорию вероятности. вероятность коллизии существует на любом коммутаторе. но на 3526 вероятность например 1 из млн, а на 3028 1 из ста.

потому надо понять какая вероятность допустима для вашей сети.

а в 32 серии как я понял длину хеша увеличили с 12 до 15 бит, что уменьшило вероятность в 2^3=8 раз. что подтверждается тестами.

Вопрос по des-3528:

1. Как реализован хэш для des-3528 двухступенчатый как у des-3526 или как у des-3200?

2. Есть ли подобные проблемы с хешем у des-3528?

О чём я выше и писал.



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



Есть общие правила(принципы) построения больших сетей, а также: RFC, IEEE, для примера ещё добавлю ПДД, Вы в своём праве использовать их или нет, ни кто на это право не покушается.



Вы решили подать в суд на D-Link или BCM!?



Пожалуйста, уточните о чём шла речь, а главное когда.



У Вас mega мечта построить сеть с доменами по 8k МАС адресов или для Вас это дело принципа!?

Я, извиняюсь, Вы какого провайдера представляете!? (Сам ответил на свой вопрос, пробил по IP)



Вы утрируете. О том, что это критическая ошибка, Вы можете это объяснить BCM.



Что касаемо схем: Схемы с большим доменом несут не только проблемы с hash-ами, но и другие проблемы, о которых Вы умалчиваете, акцентируя внимание только на эту проблему.

P.S.: Имя с маленькой буквы воспринимать как не уважение ко мне лично!?



Т.е. если мы добавим в manual информацию об этой особенности, то Вас это устроит!?

_________________
С уважением,
Бигаров Руслан.

я один считаю что стопицот МАС-ов на одном свиче - это не ошибка длинка (вместо D-Link можно вставить любой бренд), это скорее диагоноз для админа который даже в теории предполагает у себя в сети подобное?

_________________
с уважением, БП

У DES-3028 13 бит под одну hash запись, а на DES-3200 толи 14 бит, толи 15 бит(точно не помню) и две банки, а также решена проблема с последовательными МАС адресами, поэтому и результаты лучше.



Вы результаты тестов смотрели?

Тест – посылка 8192 MAC адресов (случайная выборка и длинная
последовательность)

________| RANDOM | LONG CHAIN
------------------------------------------
DES-3528 | 8125 | 8190

_________________
С уважением,
Бигаров Руслан.

Приcоединяюсь к snark-у - в сети с нормальной конфигурацией тысяч маков в таблицах не будет.
Да, бывают косяки у длинка, но это не тот случай - "не то лечим!"

З.Ы. Кстати, на том NAG.RU прям в ответ на заглавный пост так и спросили "вы мне скажите нахрена на доступе 7кМак? на сеточки надо делить- на вланчики.. по 256-512 максимум в сегменте Л3..."

З.З.Ы. В бытность мою сисадмином был у нас сотрудник, который, дабы доказать мне, что антивирус Касперского полный отстой, делал следующее - запускал одновременно полную проверку диска Касперским, полную дефрагментацию, запускал фильм и открывал Автокад. Естественно, что автокад еле ворочался при таком раскладе. На что он мне радостно заявлял: "Видишь, твой Касперский-то дрянь!".
Мне кажется, что ситуация аналогичная.
(сразу скажу, что это не (анти)реклама Касперскому. вообще речь не о нем)

_________________
не важно, из какого места растут золотые руки