как оценить пропускную способность сети
 

Имеется ЛВС в которой порядка 150 рабочих станций. Структура сети - плоская. Задумался, а как определить насколько сеть загружена бродкастами, как определить когда имеет смысл разбивать ее на подсети. Можно например управляемым свитчом перехватить трафик, но как его проанализировать, т.е выявить степень загруженности сети. Вот хотелось бы мнение услышать авторитеных специалистов. :)

а что значит "структура сети - плоская"?

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

одноранговая сеть?

Если броадкаст то и зеркалить не надо порт , а так лучше отзеркалить порт маршрутизатора и расколупать с помощью tcpdump/wire(TS)shark или аналогом , bandwidthd еще не плох в плане загрузки канала, но то не для броадкаст а из старого пропоиетарного network instruments observer в картинках красиво показывать умеет, я чистым tcpdump смотрю обычно там горы фильтров ориентируюсь просто по таймстэмп и количеству , а так можно и в файл записать с фильтром и его скормить чему-нить или tcpreplay-ем выкинуть в пустой интерфейс и даркстат например натравить...но не заморачивался настолько

В нормальноработающей сети (без вирей) если это медь 100/1000 150 тачек это ерунда

В одном коллизионом домене по броадкасту в смысле

Еще как вариант порты помониторить на коммутаторах, но резать на подсети имеет смысл, если есть сегменты по радио соединеных например чтоб не гонять много мелких пакетов бкстных или др медленные линки, а так просто убрать паразитный трафф( Вири,Ipx,ненужный мультикаст и проч) должно хватить.

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

2-Gochy >а это уже и значит что загружена броадкастами

10-напаяхЪ > не критично :)

2-Gochy > Ну да, сеть одноранговая. Что-то я туплю с терминологией :)

в 6-7 падаван тебе правду открыл :)

13-Gochy > не зли меня , тут и так стим спалил, что gochy в kf-е :) я кстати больше 50 вендовых тачек целенаправленно без ад не крутил, так что могу ошибаться :)

[quote=701054;23429490] 13-Gochy > не зли меня , тут и так стим спалил, что gochy в kf-е :) [/quote]
[filolog]пох[/filolog], я в отпуске и ваще не колышет!
PS: кстати кто то аж с пятницы забыл вырубить стим и палился на нашем нормале )))

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

ну вернее я то сам себя напряг, я ж не знал, что там такой косяк и весь этот "бронепаровоз" двухнедельной возни прийдется резко переподнимать за 2 вечера :)

Во всех "правильных" тестированиях сетей есть один большой-большой минус. Они не учитывают мгновенное значение нагрузки в динамично меняемом векторе выполняемых работ, что именно делают юзеры, а не как тупит сеть. Узнать что приводит к ощущению юзерами "тормозов" и собсна - вот чего хочется избежать. Лучшее тестирование, имхо, это анкетирование вменяемых пользователей, принятое после каких либо значимых мер (напр. уничтожение оставшихся старых хабов на запущенных сегментах). Примерно при таких же объемах (150 машин) - нам заметную пользу принесло принесло "лоскутное" внедрение гигабитных сегментов на отделы, где много обмениваются между собой файлами или юзают шары на серверах, плюс много крутят внутренние web-сервисы (их штук пять на десяток приложений), плюс на пару особо нагруженных машин-невыделенных-серверов сделали мосты из двух интеловских плат. В итоге все юзеры сказали - сеть работает в два раза быстрее. Админ был счастлив :-))

18 economist > Согласен, и вот тут как раз мне кажется, нужна четкая методика, которая позволила бы четко это дело определить. ибо опрос юзеров - это хорошо, но не всегда объективно. Вот может имеет смысл делать так: при помощи jperf мерять скорость, потом (если скорость низка) применять сниферы и анализировать трафик

у себя померял - в среднем 80 Мб\сек

так j(i)perf сам канал и нагрузит или остаток от того что там есть, смысл только узнать сколько физически там можно прогнать, если свитчи управляемые, натравить zabbix/cacti или ещё что-нить, там в графиках легко понять нагрузки как средние так и пиковые

спасибо, буду спотреть-пробовать

15 - ай йай йай... ;) Палимсо.
Поздр. с отпуской.