Ладно пришлю но только смысла не вижу т.к. коммутатор находится на тесте с минимальной конфигурацией и сковозь него по вланам проброшен трафик на цыски.

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



ты не по тому пути пошёл; тебе нужно просто самому поставить семпл рейт таким, чтоб свитч его больше не менял, и соответственно увеличить величину расчётного (либо дискретного) периода. сбрасывает до 8 - поставь сам 16 для надёжности, и считай юзера и показывай ему статистику в масштабах полного месяца.

это не беда, что у тебя будет выбираться один пакет из вроде аж как 4к - если расчётный период у тебя месяц (что обычно так и есть) - на юзере протянувшем за этот месяц через сетку 100 гиг (что при нынешних скоростях для месяца есть сущие понты ) ты ошибёшься меньше чем на пол-процента, и что немаловажно - в его пользу (так что если он и заметит погрешность - будет только рад). вот и отдай ему эти 100 гиг в месяц за Х денег, а перелезет за 100 - тарифицируй каждый гиг сверх нормы, точность это уже позволит. и ему счастье, полноскоростной канал без ограничений по полосе, и тебе гарантия от неоплачиваемых перегрузок сети слишком активными юзерами, без покупки кошек с netflow за 2 камаза зелёных денег.

После уточнения выяснили что коммутатор меняет sampling rate чтобы снизить загрузку CPU. Если больше 20 пакетов выбриается в секунду то свитч удваивает значение интервала выборки.

Выложите на ftp или вышлите плз
"Информацию по командам настройки sflow "

Я Вам описание выслал. По поводу SNMP OID в котором можно считать текущее значение sampling rate. Вот он:

sFlowFsPacketSamplingRate
and the OID is 1.3.6.1.4.1.171.12.36.1.5.1.4

Повторите плз еще раз описание
Сработал grey-лист в почте

ну и как народ, кто победил Sflow?
какова точность посравнению с NetFlow просто дан свичь 3627г сейчас просто выглядит как просто L3, так хочется чтобы он инфу сливал на сервер билинга кто сколько прокачал... локальный то понятно что можно и +- лапоть, а вот инет как?

Я как понимаю от Sflow единственная польза так это мониториг трафика в сети все приблизительно для обобщенной оценки где, кто и когда.
С такой точностью дотошные клиенты до суда доведут.
Вот если бы Dlink сделал версию DGS-36XX который стоил на десятку тысяч рублей дороже - но имел бы возможность на аппаратном уровне работать с Netflow то наверно был бы хитом номер один с руками отрывали бы.
Точный подсчет трафика - это одна из самых головных болей для провайдера.
А про Dlink - хорошие железки выпускают - но все недоделки то этого то другого не хватает для полного счастья. В DES-72XX тоже похоже ничего такого нет.

Если у вас есть сертифицированная биллинговая система и сертифициорванное под нее оборудование то никакой суд никому не поможет)
Помоему (я сейчас говорю про москву) с нашими скоростями и тарифами как то особо большой точности не требуется.

не надо гонять интернет трафик в целях его учета через D-Link свич, т.к. его учитывать надо не на нем и не его средствами ... хотите netflow? реализовывать его лично я советую на том железе/софте на котором он зародился, на ктором он - неотъемлемая часть софта (индусы до сих пор не смогли/захотели реализовать netflow в железе, а раз там нету, то маловероятно найти это где-то еще)

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

у клиентов на компе?
под разные схемы подключения обсчет будет разный, под туннели одно, под нат другое, под прокси третье, хотя в итоге получается что считается он там где туннелируется/проксируется, хотя можно ставить прозрачный бридж специально для обсчета.

нет говоря:
я прежде всего имел ввиду это
считать локалку, если ее конечно нужно считать - нужно через sflow, а вот считать инет ... учет инета посредством netflow, в эпоху тотальных анлимов, нужен в основном для того чтобы можно было, если вдруг понадобится, точно сказать кто именно из клиентов был на сайте kremlin.ru в определенный момент, который так же сообщат

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

Первый момент NetFlow в железе нет и похоже не будет. Я имею ввиду вообще ни у кого. У нас на DES-72XX планируется поддержка отдельным модулем на аппаратном уровне IPFix, что является аналогом NetFlow v9. При этом есть информация что его несложно при жалении прикрутить к биллингу.

я об этом и говорил ... цисковские индусы не придумали как сделать его в железе, а остальным хотя бы договорится об использовании проприетарщины ...
а вот с этого места поподробнее! формат netflow v9 известен, а вот как будет посылать пакеты IPFix - это вопрос требующий уточнения
Иван, не нужно никакой информации ... если IPFix будет посылать данные в формате близком к netflow 1-8, то берется flow-fanout и запускается, например, как нить так:

фсе! биллинг на localhost будет получать netflow 5-й версии (самая распространенная среди биллингов)

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

Спасибо! По поводу формата я запрошу информацию. Как только будут новости сообщу.