| 1.1, Elenium (ok), 00:37, 08/10/2009 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
было бы оч круто, еслибы в ядре либо в сетевой подсистеме был агрегатор сетевой статистики с краником в субд. из каробки так сказать без libpcap, ulog итд (вприницпе костылей)
почему его досих пор нету непонятно
| | |
| |
| |
| 3.4, Аноним (-), 01:59, 08/10/2009 [^] [^^] [^^^] [ответить]
| +/– | |
>Потому что он называется ipt_NETFLOW, но про него мало кто знает.
он кривоват, уже пробовал на centos 5.2, и это тоже костыль только другой :)
те потенциально целый пакет проходит из иптаблес в модуль ipt_netflow дальше этот модуль его опять обрабатывает и складывает статистику
зачем? если пакет уже прошел роутинг и иптаблес, можно ведь при попадании на каком то начальном этапе попадания пакета в стек стоял счетчик и плюсовал где-то у себя и обязательно куда-то скидывал статистику, возможно другой модуль этим занимается. те что-то типа статистики нестат только с большим кол-вом данных и настройками агрегации, и продуманной модульной системой отдачи циферок либо в базу либо еще куда-то.
| | |
| |
| 4.6, Ну типа имя (?), 07:16, 08/10/2009 [^] [^^] [^^^] [ответить]
| +/– |
>[оверквотинг удален]
>он кривоват, уже пробовал на centos 5.2, и это тоже костыль только
>другой :)
>те потенциально целый пакет проходит из иптаблес в модуль ipt_netflow дальше этот
>модуль его опять обрабатывает и складывает статистику
>зачем? если пакет уже прошел роутинг и иптаблес, можно ведь при попадании
>на каком то начальном этапе попадания пакета в стек стоял счетчик
>и плюсовал где-то у себя и обязательно куда-то скидывал статистику, возможно
>другой модуль этим занимается. те что-то типа статистики нестат только с
>большим кол-вом данных и настройками агрегации, и продуманной модульной системой отдачи
>циферок либо в базу либо еще куда-то.
man ipcad
| | |
| |
| 5.11, аноним (?), 10:23, 08/10/2009 [^] [^^] [^^^] [ответить]
| +/– |
ipcad тот же костыль, но работает с большим количеством костылей, типа libpcap, ulog и т.д.
ни о какой интеграции с ядром не идет речи.
особенно нравится, когда идет флуд и ipcad кладет систему по загрузке cpu.
| | |
|
|
|
| 2.12, svn (??), 12:00, 08/10/2009 [^] [^^] [^^^] [ответить]
| +1 +/– | |
>в ядре либо в сетевой подсистеме был агрегатор сетевой статистики
Он есть уже давно. Называется Conntrack. Пасёт соединения, считает трафик, имеет интерфейс в виде netlink сокета.
>с краником в субд
Нечего ему делать в ядре. Это дело пользовательской программы, вытаскивать данные из ядра и складывать в субд. Её к сожалению пока никто не написал, одни костыли и копипасты на основе pcap.
| | |
| |
| 3.18, Elenium (ok), 13:14, 08/10/2009 [^] [^^] [^^^] [ответить]
| +/– |
Поправьте если не так. на коннтрак и нетлинке несваяешь нормальную систему статистики. тк
1. коннтрак разрабатывался для отслеживания соединений, статистика по байтам есть, НО отдавать через некий сокет нормально он неумеет ее, либо велика вероятность дропа, те неотдал/непарснул итд - коллектор неплюсанул, статистика непопала, вообщем непродакшен нефига
2. нетлинк вообще принципиально разрабатывается не как Public userspace API а исключительно API между продуктами серии коннтрак
в итоге нормальной сборки статистики (я подчеркиваю не биллинга или веб морды, а некий алгоритм поведения с этой статистикой чтобы непропадала - сейвилась где-то, агрегировалась наконец) нету нефига в лине к огромному сожалению :(((
причем впринципе ходы выходы из ядра в узерспайс есть, полдела с коннтрак и нетлинк сделано и все было бы стройно и красиво, но блин... omg
| | |
| |
| 4.19, Elenium (ok), 13:21, 08/10/2009 [^] [^^] [^^^] [ответить]
| +/– |
и вообще коннтракт это система отслеживания соединений и работы с ними, а не сбор статистики и свое дело коннтракт делает
кстати ему реально непомешал бы ipt_conntrack_torrent на подобии ipt_conntrack_ftp и sip :))
| | |
|
|
| 2.13, Aleksey (??), 12:18, 08/10/2009 [^] [^^] [^^^] [ответить]
| +/– |
Да чего мелочится. Давайте в ядро биллинговую систему встроим. Было бы оффигительно круто.
| | |
| |
| 3.14, аноним (?), 12:30, 08/10/2009 [^] [^^] [^^^] [ответить]
| +/– |
не нужно перегибать палку. вполне подошел бы netflow на уровне анализа пакетов, без дополнительных извратов ulog, ipq, pcap и другой мути.
| | |
| |
| 4.20, Elenium (ok), 13:23, 08/10/2009 [^] [^^] [^^^] [ответить]
| +/– |
>не нужно перегибать палку. вполне подошел бы netflow на уровне анализа пакетов,
>без дополнительных извратов ulog, ipq, pcap и другой мути.
да было бы неплохо, но мне видится модульная система типа кому надо пусть данные льются на коллектор нетфлоу кому надо в мускул итд можно много чего придумать
в узерспейсе конечно пусть пидорит куда хочешь :)
просто если сразу в нетфлоу малоли может кому то это ненадо и придется это перепарсивать
| | |
|
|
| 2.25, eye (?), 18:05, 08/10/2009 [^] [^^] [^^^] [ответить]
| +/– |
 ng_netflow (да и вообще netgraph) на FreeBSD просто чудо. в линухе такого наверное не будет
| | |
| 2.26, crypt (??), 19:14, 08/10/2009 [^] [^^] [^^^] [ответить]
| +1 +/– |
Почему бы тебе не написать тестовый модуль ядра с нужным тебе функционалом? Модуль вроде не очень сложно пишется. Заодно и проверить свои идеи.
| | |
|
| 1.3, Просто Лось. (?), 01:12, 08/10/2009 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Жаль, что закрытая, и что так мало докладов выложено. Неужели так трудно снять два дня видео и выложить на youtube..
| | |
| |
| 2.5, hatelinux (?), 02:11, 08/10/2009 [^] [^^] [^^^] [ответить]
| –1 +/– | |
>Жаль, что закрытая, и что так мало докладов выложено. Неужели так трудно снять два дня видео и выложить на youtube..
бггг
бояться что их инновационные идеи украдет M$ )))))
| | |
| |
| 3.23, User294 (ok), 17:28, 08/10/2009 [^] [^^] [^^^] [ответить]
| +/– |
M$ до сих пор не умеет в своем "advanced" виндоус файрволе диапазоны портов открывать! Это в крутом и дорогом 2008 сервер то. Так что если и украдет что-то такое - то лет через хренадцать, не раньше.
| | |
|
|
| 1.9, Аноним (-), 09:56, 08/10/2009 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
Уважаемые господа сетевики. Есть такая проблема. Хочется поиметь шейпер. С HTB и CBQ поверхостно знаком, но ситуация не совсем стандартна.
Есть порядка 2k клиентов и 5 тарифных планов, хочется малой кровью пошейпить канал в соответствии с потребностями клиентов и их тарифами.
Как наиболее оптимально это сделать ?
Заранее благодарен
| | |
| |
| 2.10, pavel_simple (ok), 09:58, 08/10/2009 [^] [^^] [^^^] [ответить]
| +/– |
>Уважаемые господа сетевики. Есть такая проблема. Хочется поиметь шейпер. С HTB и
>CBQ поверхостно знаком, но ситуация не совсем стандартна.
>
>Есть порядка 2k клиентов и 5 тарифных планов, хочется малой кровью пошейпить
>канал в соответствии с потребностями клиентов и их тарифами.
>
>Как наиболее оптимально это сделать ?
>
>Заранее благодарен
по форуму поискать для порядка желательно
например
http://www.opennet.me/openforum/vsluhforumID1/86587.html
| | |
| |
| 3.21, kran (??), 14:32, 08/10/2009 [^] [^^] [^^^] [ответить]
| +/– |
Поделитесь знаниями, как сделать на PF шейпинг для каждого из 2k клиентов. Т.е. выделить каждому клиенту гарантированную полосу (при условии что канала хватает).
| | |
| |
| |
| 5.28, kran (??), 00:24, 09/10/2009 [^] [^^] [^^^] [ответить]
| +/– |
2k очередей? какая машинка это прожуёт на 100мбитном канале 30-40kpps
| | |
| |
| 6.30, eye (?), 10:38, 09/10/2009 [^] [^^] [^^^] [ответить]
| +/– | |
>2k очередей? какая машинка это прожуёт на 100мбитном канале 30-40kpps
3k пайпов (dummynet) 300мбитный канал 80-100kpps жует 2xQuadXeon. хоть и с трудом
| | |
| |
| 7.32, Mike (??), 20:32, 09/10/2009 [^] [^^] [^^^] [ответить]
| +1 +/– |
Зачем стёрли комментарий? Ведь реально, же - ужасно...
Pentium 4 Dual 3.0Ghz справлялся с нагрузкой в 3к pppN соединений, с правилами CBQ на каждом.
| | |
|
|
|
|
|
| 2.27, Mike (??), 20:51, 08/10/2009 [^] [^^] [^^^] [ответить]
| +/– |
Такая же была задача в своё время. Только тарифов больше.
У нас схема была простая.
Для соединения клиентов использовался PPTP.
При поднятии интерфейса pppN, radius-сервер по мимо различных атрибутов передавал данные о тарифе (сколько туда и обратно).
Данные о тарифе передавались небольшой, написанной на С программе, которая на pppN-интерфейс вешала определённое правило на CBQ, с различными параметрами для шейпинга (в зависимости от того, что radius-сервер передал).
При опускании pppN интерфейса, нет необходимости в чистке просил шейпинга - ядро само их уберёт.
Всё работало быстро, без нареканий.
| | |
|
|
