pavelak

более чем интересно

итак -- во первых нужно отталкиваться от того что задачка может решаться двумя разными способами 1. определить полосу на всех пользователей и отдельно для каждого создать подклассы 2. определить полосы под конкретные сервисы а остальное поделить на всех ИМХО -- второй вариант проще итого создаём очереди для приоритетного трафика подготовка tc qdisc del root dev $interface rmmod cls_flow rmmod cls_u32 rmmod sch_htb rmmod sch_sfq insmod sch_sfq insmod sch_htb insmod cls_flow insmod cls_u32 tc qdisc add dev $interface root handle 1: htb default 10 # r2q 3 #создаём очередь для высокоприоритетного трафика гарантированной шириной в 10мбит с расшарением до 20мбит и максимальным приоритетом tc class add dev $interface parent 1:1 classid 1:5 htb rate 10Mbit ceil 10mbit rate 20mbit prio 0 #разрешаем использовать полосу нашей сети равномерно через netfilter-conntrack по хостам в нашей сети в случае если conntrack не используется можно использовать ключ dst tc filter add dev $interface parent 5: protocol ip handle 10 flow hash keys nfct-dst divisor 512 #то-же самое делаем для менее приоритетного трафика -- единственное отличие в приоритете tc class add dev $interface parent 1:1 classid 1:10 htb rate 80mbit ceil 90mbit prio 6 tc qdisc add dev $interface parent 1:10 handle 10: sfq perturb 10 #устанавливаем фильтр, который как раз и отвечает за равномерное распределение, опять-же смотрим на ключ nfct-dst и заменяем его на dst если conntrack не используется tc filter add dev $interface parent 5: protocol ip handle 5 flow hash keys nfct-dst divisor 512 tc filter add dev $interface parent 10: protocol ip handle 10 flow hash keys nfct-dst divisor 512 #divisor отвечает за то, сколько хостов в сети (максимальный дивизор на sfq равен 1024), в нашем случае сеть /24 - поэтому используем 512 #устанавливаем фильтры для типа трафика, в данном случае для всей нашей сети 10.0.10.0/24 будет использоваться только высокоприоритетная очередь, и амксимальная скорость соответственно будет 20мбит tc filter add dev $interface parent 1: protocol ip prio 2 u32 match ip dst 10.0.10.0/24 flowid 1:5 #соответственно в данном случае для высокоприоритетного трафика (потому как он обычно разномастный) удобнее всего использовать выставление меток на уровне iptables -j MARK/CONNMARK с последующим просовыванием его в определённую очередь на основе этой метки

sirmax продакшен продакшену рознь, и использование виртуализции имеет свои области применения стоит пару серверов поддержки базовой IT инфраструктуры. задавайте.

если именно xen -- то лучше сразу на сайт citrix -- если нужна виртуализация рекомендую присмотреться к последнему CentOS и KVM.

поставить openvpn, настроить, и соеденить в бридж -- всё легко и просто на winxp -- никакой транслячии и маршрутизации -- полноченный ethernet поверх ip.

ipt_netflow

во первых между двумя wifi линками особой скорости всё равно не получить -- к тому-же эту самую инкапсуляцию по условиям задачи нужно делать на linux'овых машинах -- и самая дохлый писюк легко это осилит даже на перле. ansi c программистов насколько я могу ошибаться найти довольно просто везде и всюду.

Если вы это мне - абсолютно не наш вариант. Мы раздаём фиксированные, но разные полосы и ничего между ними не делим. Не хватает аплинка - подключаем второй. Смысл использования imq/ifb появляется только тогда, когда исходящий трафик идёт на разных логических линках (не бондится). Если аплинк один - исходящий интерфейс и есть тот самый ifb/imq, и без всяких извращений типа патча в и так дырявое ведро. весь мой пост сводился к тому, что нужно чаще использовать склассификатор flow как более удобную замену хешам, пост ^^^ не асилил.

а как на текущий момент сделан shaper?

посмотрел сегодня на vtun.sf.net -- там практически всё что нужно для решения задачи способом, предложенным мной. модуль ядра писать -- это изврат -- легче заюзать netfilter tproxy, а там как-раз можно и на перле написать быстренько.

http://forum.nag.ru/forum/index.php?showto...0&start=100

например нам нужно поделить полосу в 10 мегабит на сетку, в случае неиспользования кем-то полосы , она делиться на остальных равномерно tc qdisc del root dev $interface опционально rmmod cls_flow rmmod cls_u32 rmmod sch_htb rmmod sch_sfq insmod sch_sfq insmod sch_htb insmod cls_flow insmod cls_u32 сам шэйпер tc qdisc add dev $interface root handle 1: htb default 20 # r2q 3 tc class add dev $interface parent 1:1 classid 1:10 htb rate 10mbit ceil 10mbit prio 1 tc qdisc add dev $interface parent 1:10 handle 10: sfq perturb 10 tc filter add dev $interface parent 10: protocol ip handle 10 flow hash keys nfct-dst divisor 512 #divisor отвечает за то, сколько хостов в сети (максимальный дивизор на sfq равен 1024) tc filter add dev $interface parent 1: protocol ip prio 2 u32 match ip dst 192.168.0.0/24 flowid 1:10 #в данном случае наша сеть 192.168.0.0/24 шайпер "вешается" на исходящий на пользователей интерфейс , в случае использования динамических интерфейсов на самом шэйпере необходимо использовать либо imq либо ifb P.S. это всё для Linux

не нужно ничего сжимать -- это сильно усложняет. а если делать через socat - то достаточно написать небольшую программу которая умеет stdio и функцию таймера

для "ускорения" передачи kernel-userspace для не ядерных реализаций коллекторов советую присмотреться к http://web.yl.is.s.u-tokyo.ac.jp/~tosh/kml/

подробнее можно?

я готового решения не втречал, НО есть стандартный интерфейс tap SOCAT с ним может работать. если мелкие пакеты маркировать через iptables, и роутить через tap на SOCAT то вполне можно решить данную проблему, хоть и через описанные костыли. с другой стороны небольшую программу написать которая будет сама открывать/передавать/закрывать tap интерфейс и склеивать пакеты и по таймеру/размеру их передавать/ принимать ИМХО не большая проблема... хотя....

товарищъъъ zatei постоянно ищет на форумах какие-то идеальные решения -- частенько бывает на opennet'е -- человек без головы. всё это делается очень просто корневой класс htb подклассы на каждый офис с определённым rate'ом и максимальным ceil'ом для всех подклассов по одномы фильтру с flow на каждый подклас по одному sfq и это ^^^ если использовать стандартный не патченый kernel и задачу минимизировать нагрузку.

ИМХО -- государство запустило очередную пэарь-акцию, поэтому и взялись за торрентсру http://www.lenta.ru/conf/noskova/

Java Apache Mail Enterprise Server (JAMES) smtp+pop3+imap Thunderbird в качестве клента

конкуренция конечно дело хорошее -- но зачем же так ссылка на картинку Thunderbird'а на rapidshare.ru вот -- хотел поинтересоваться у кого ещё была такие светлые идеи -- и кто ещё из провайдеров Екатеринбурга воплотил её в жизнь