Ну вообщем-то, не все так печально, хотя flood_fdb и на DES3200 нужен

Мыши плакали, кололись, но продолжали жрать кактус

_________________
SkyNet Telecom
http://sknt.ru

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

Я вот у себя смотрел и не встретил более 140 маков на vlan при схеме vlan на дом. Тут смущает другое. Согласно этому тесту проблемы быть не должно, но потенциально она возможна и гарантированно ее предотвратить также не возможно получается. Только отслеживать.

Cогласно расчетам ученым вероятность падения метеорита на Землю тоже ненулевая.
И что? люди как то живут уже много тысяч лет

Проблема не в технике, проблем а в мозгах (психике).
Просто меньше парьтесь этим .

В любой сети есть много других более вероятных проблем.

Абсолютно согласен.

1. Чипсеты всех современных моделей подвержены данным проблемам.
Поскольку основных производителей всего два: Broadcom и Marvell, то у
многих вендоров наблюдается данная проблема в той или иной степени на
разных сериях коммутаторов. Старые чипсеты имели 2-х уровневый хеш, а
не одноуровневый как новые, поэтому на них практически отсутствует
данная проблема, что и показывают тесты. Производители чипсетов
увеличили скорость работы FDB таблицы, но как побочный эффект получили
проблему с хешами. Также многое зависит от того, как реализованная
память под FDB таблицу и сколько бит отпущено под одну хеш запись.

Ситуация потихонечку исправляется, так как в новых моделях остаётся тотже
одноуровневый хеш, но производители находят новые решения по
нивелированию проблемы с хешами.


2. Наличие проблемы хэширования вовсе не говорит о том, что данная
модель плохая! Каждая модель коммутатора имеет свою маркетинговую нишу
и предполагает ее правильно использование. Например модели DES-3028 и
DES- 3200 в большей степени рассчитаны на использование с операторской
моделью QinQ. Модель DES-3528 расчитана на корпоративный сегмент, где
цена оборудования имеет меньше значения нежели требуемый функционал.
Модель DES-1210-xx рассчитана на использование с операторской моделью
без QinQ.

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

4. Как показывает практика в большинстве операторских сетей часто
встречаются средней длины последовательности из-за ограниченного
количества производителей сетвых устройств. Жестких критериев
случайности как в функции Random в реальных условиях не возникнет.
Повторюсь, единственная модель подверженная в данном случае проблемам
DES-3028 (с которой и столкнулось большинство операторов), по которой мы
уже дали рекомендации и внесли дополнения в ПО для решения таких проблем.

5. Дополнительно были проведены тесты по возникновению коллизий в
небольших сегментах c DES-3200-28:

250 MAC адресов – коллизий нет (5 повторов теста)

512 MAC адресов – коллизий нет (5 повторов теста)

1024 MAC адресов – 4 коллизии (5 повторов теста)



Вывод: поскольку на сети оператора нет такого жесткого распределения
со случайными MAC адресами проблем возникать не должно, но это не
говорит о том, что сеть можно строить как попало – раздувая один или
несколько огромных L2 доменов. Чем грамотней построена сеть тем
меньше будет в ней проблем, в том числе проблем напрямую связанных с
ограничениями технологии Ethernet (MAC, STP, и т.д).

Не вдаваясь в математические расчеты, приводим результаты практических
тестов.



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

RANDOM LONG CHAIN

DES-3526 8190 8190


DES-3528 8125 8190


DES-3200-XX 5951 8168


DES-3028 5157 4652

Интересно было б посмотреть результат 256 адресов и 1000 повторений теста (т.е. берем сеть на 1000 домов при схеме влан на дом).

Организуйте что мешает. scapy и вперед.

Было б не плохо, чтоб Длинк это сделал. Они же защищают свое оборудование)

и привел пример методики тестирования, дабы проверить можно было

А что значит "правильный" или "неправильный" дизайны? В какой момент времени смотреть и оценивать? Соглашусь, здесь все просто если рассматривать сеть как модель или чертеж на бумаге и при этом обладать неограниченными средствами. А на практике, как правило, нельзя все привести к идеальному варианту мгновенно. Так или иначе, пройдется пройти определенную последовательность шагов. И здесь бы очень хотелось, чтобы оборудование было достаточно "гибким" для того, чтобы можно было безболезненно переходить от одной схемы к другой.

_________________
D-Link Switches: Tips & Tricks

Вопрос к Дёмину Ивану.

Как данная проблема отразится на мультикасте?

На текущий момент касаемо Multicast ситуация пока не изучена до конца (на примере DES-3028), но по первым исследованиям при "правильной" логической схеме сети эффект от неё минимален. Выкладки приведём позже после глубоких тестов.

Всем у кого есть вопросы просьба указать в личку Ваш телефон.

Иван, просьба, освещайте пожалуйста результаты тестирования публично (на сколько это возможно).

пипец

Как видите мы не скрываем проблему, и пытаемся максимально предоставить всю информацию по ней. Также с каждым по отдельности обсуждаем эту проблему и объясняем подробно все её аспекты.

Как только будут закончены все тесты мы осветим и этот момент.

2 all > В тестах мы использовали модуль pktgen и скрипт.

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