Опубликовано краткое содержание выступлений с закрытой конференции Netconf 2009 (день первый (http://vger.kernel.org/netconf2009_notes_1.html), день второй (http://vger.kernel.org/netconf2009_day2.html)), проходившей 19 и 20 сентября. На конференции обсуждались достижения и планы по развитию различных сетевых подсистем Linux. Например, прозвучали доклады о технологии сглаживания TX-прерываний, поддержке двунаправленной маршрутизации на 10-гигабитных каналах, поддержке протокола DCCP, реализации технологии "multiqueue" с отдельным прерыванием для каждой очереди, поддержке сетевых мостов для Multicast трафика, оценке производительности форвардинга пакетов в IPV4 стеке и т.д.
URL: http://vger.kernel.org/netconf2009.html
Новость: https://www.opennet.ru/opennews/art.shtml?num=23765
было бы оч круто, еслибы в ядре либо в сетевой подсистеме был агрегатор сетевой статистики с краником в субд. из каробки так сказать без libpcap, ulog итд (вприницпе костылей)
почему его досих пор нету непонятно
Потому что он называется ipt_NETFLOW, но про него мало кто знает.
>Потому что он называется ipt_NETFLOW, но про него мало кто знает.он кривоват, уже пробовал на centos 5.2, и это тоже костыль только другой :)
те потенциально целый пакет проходит из иптаблес в модуль ipt_netflow дальше этот модуль его опять обрабатывает и складывает статистику
зачем? если пакет уже прошел роутинг и иптаблес, можно ведь при попадании на каком то начальном этапе попадания пакета в стек стоял счетчик и плюсовал где-то у себя и обязательно куда-то скидывал статистику, возможно другой модуль этим занимается. те что-то типа статистики нестат только с большим кол-вом данных и настройками агрегации, и продуманной модульной системой отдачи циферок либо в базу либо еще куда-то.
>[оверквотинг удален]
>он кривоват, уже пробовал на centos 5.2, и это тоже костыль только
>другой :)
>те потенциально целый пакет проходит из иптаблес в модуль ipt_netflow дальше этот
>модуль его опять обрабатывает и складывает статистику
>зачем? если пакет уже прошел роутинг и иптаблес, можно ведь при попадании
>на каком то начальном этапе попадания пакета в стек стоял счетчик
>и плюсовал где-то у себя и обязательно куда-то скидывал статистику, возможно
>другой модуль этим занимается. те что-то типа статистики нестат только с
>большим кол-вом данных и настройками агрегации, и продуманной модульной системой отдачи
>циферок либо в базу либо еще куда-то.man ipcad
ipcad тот же костыль, но работает с большим количеством костылей, типа libpcap, ulog и т.д.
ни о какой интеграции с ядром не идет речи.
особенно нравится, когда идет флуд и ipcad кладет систему по загрузке cpu.
> большим количеством костылей, типа libpcap, ulogоткуда такие неверные познания?
>в ядре либо в сетевой подсистеме был агрегатор сетевой статистикиОн есть уже давно. Называется Conntrack. Пасёт соединения, считает трафик, имеет интерфейс в виде netlink сокета.
>с краником в субд
Нечего ему делать в ядре. Это дело пользовательской программы, вытаскивать данные из ядра и складывать в субд. Её к сожалению пока никто не написал, одни костыли и копипасты на основе pcap.
Поправьте если не так. на коннтрак и нетлинке несваяешь нормальную систему статистики. тк
1. коннтрак разрабатывался для отслеживания соединений, статистика по байтам есть, НО отдавать через некий сокет нормально он неумеет ее, либо велика вероятность дропа, те неотдал/непарснул итд - коллектор неплюсанул, статистика непопала, вообщем непродакшен нефига
2. нетлинк вообще принципиально разрабатывается не как Public userspace API а исключительно API между продуктами серии коннтрак
в итоге нормальной сборки статистики (я подчеркиваю не биллинга или веб морды, а некий алгоритм поведения с этой статистикой чтобы непропадала - сейвилась где-то, агрегировалась наконец) нету нефига в лине к огромному сожалению :(((
причем впринципе ходы выходы из ядра в узерспайс есть, полдела с коннтрак и нетлинк сделано и все было бы стройно и красиво, но блин... omg
и вообще коннтракт это система отслеживания соединений и работы с ними, а не сбор статистики и свое дело коннтракт делает
кстати ему реально непомешал бы ipt_conntrack_torrent на подобии ipt_conntrack_ftp и sip :))
Да чего мелочится. Давайте в ядро биллинговую систему встроим. Было бы оффигительно круто.
не нужно перегибать палку. вполне подошел бы netflow на уровне анализа пакетов, без дополнительных извратов ulog, ipq, pcap и другой мути.
>не нужно перегибать палку. вполне подошел бы netflow на уровне анализа пакетов,
>без дополнительных извратов ulog, ipq, pcap и другой мути.да было бы неплохо, но мне видится модульная система типа кому надо пусть данные льются на коллектор нетфлоу кому надо в мускул итд можно много чего придумать
в узерспейсе конечно пусть пидорит куда хочешь :)
просто если сразу в нетфлоу малоли может кому то это ненадо и придется это перепарсивать
Все уже давно придумано. ipcad + radius
ng_netflow (да и вообще netgraph) на FreeBSD просто чудо. в линухе такого наверное не будет
Почему бы тебе не написать тестовый модуль ядра с нужным тебе функционалом? Модуль вроде не очень сложно пишется. Заодно и проверить свои идеи.
Жаль, что закрытая, и что так мало докладов выложено. Неужели так трудно снять два дня видео и выложить на youtube..
>Жаль, что закрытая, и что так мало докладов выложено. Неужели так трудно снять два дня видео и выложить на youtube..бггг
бояться что их инновационные идеи украдет M$ )))))
Гениально Ватсон!
А M$ тоже улучшает сетевую подсистему Linux? )
M$ до сих пор не умеет в своем "advanced" виндоус файрволе диапазоны портов открывать! Это в крутом и дорогом 2008 сервер то. Так что если и украдет что-то такое - то лет через хренадцать, не раньше.
Уважаемые господа сетевики. Есть такая проблема. Хочется поиметь шейпер. С HTB и CBQ поверхостно знаком, но ситуация не совсем стандартна.Есть порядка 2k клиентов и 5 тарифных планов, хочется малой кровью пошейпить канал в соответствии с потребностями клиентов и их тарифами.
Как наиболее оптимально это сделать ?
Заранее благодарен
>Уважаемые господа сетевики. Есть такая проблема. Хочется поиметь шейпер. С HTB и
>CBQ поверхостно знаком, но ситуация не совсем стандартна.
>
>Есть порядка 2k клиентов и 5 тарифных планов, хочется малой кровью пошейпить
>канал в соответствии с потребностями клиентов и их тарифами.
>
>Как наиболее оптимально это сделать ?
>
>Заранее благодаренпо форуму поискать для порядка желательно
например
https://www.opennet.ru/openforum/vsluhforumID1/86587.html
>Как наиболее оптимально это сделать ?PF+ALTQ
ifpw+dummynet
Поделитесь знаниями, как сделать на PF шейпинг для каждого из 2k клиентов. Т.е. выделить каждому клиенту гарантированную полосу (при условии что канала хватает).
Написать скрипт на шэле или на пёрле который будет по заданным параметрам генерировать pf.conf с очередями hfsc
2k очередей? какая машинка это прожуёт на 100мбитном канале 30-40kpps
>2k очередей? какая машинка это прожуёт на 100мбитном канале 30-40kpps3k пайпов (dummynet) 300мбитный канал 80-100kpps жует 2xQuadXeon. хоть и с трудом
Зачем стёрли комментарий? Ведь реально, же - ужасно...
Pentium 4 Dual 3.0Ghz справлялся с нагрузкой в 3к pppN соединений, с правилами CBQ на каждом.
>Зачем стёрли комментарий? Ведь реально, же - ужасно...
>Pentium 4 Dual 3.0Ghz справлялся с нагрузкой в 3к pppN соединений, с
>правилами CBQ на каждом.сколько пакетов? сколько мегабит?
Такая же была задача в своё время. Только тарифов больше.
У нас схема была простая.
Для соединения клиентов использовался PPTP.
При поднятии интерфейса pppN, radius-сервер по мимо различных атрибутов передавал данные о тарифе (сколько туда и обратно).
Данные о тарифе передавались небольшой, написанной на С программе, которая на pppN-интерфейс вешала определённое правило на CBQ, с различными параметрами для шейпинга (в зависимости от того, что radius-сервер передал).
При опускании pppN интерфейса, нет необходимости в чистке просил шейпинга - ядро само их уберёт.
Всё работало быстро, без нареканий.