Шейпирование трафика в Linux

[mitnlag]

Отличная статья. Мужик!

[spanasik]

имхо, стоит слово «шейпинг» добавить в теги, иначе будет трудно найти статью

[evil_random]

да, на шейпинг надо походить

[norguhtar]

Одна большая и толстая дока пишет о том что sfq надо не хотеть. Ну и да про хеши надо в обязательном порядке, это существенно ускоряет обработку.

[alex_www]

а esfq надо хотеть? Статью бы почитал с аргументами.

[norguhtar]

Как бе
www.opennet.ru/docs/RUS/LARTC/x1075.html#HIERARCHICALTOKENBUCKET

[braintorch]

Я так понимаю, что шейпить входящий канал посредством манипулирования tcp window никакие утилиты так и не умеют?

[xenon]

Тупо зажать window наверное возможно простым модулем нетфильтра, но тогда скорость каждой tcp сессии будет зависеть от RTT узла. А вот чтобы канал между сессиями делился и по разному приоритизировался — то бесплатных таких программ нет. Более того, сомневаюсь, что есть вообще реализации этого в виде софта — есть точно железячные шейперы которые умеют, но это очень уже дорого.

(сейчас работаю по подобному проекту просто — но заказчик почему-то не хочет за свои деньги делать freeware продукт :-)

[alex_www]

Входящий tcp (и только tcp для остального эффекта почти ноль) можно перенаправляя его в IMQ www.linuximq.net/ а дальше тот же htb или вот даже RED.

[braintorch]

На практике такая схема не очень-то работает. При большом количестве соединений (p2p) очередь ложится.

[alex_www]

htb.init скрипт сделал настройку htp запутаной и непрзрачной,
сам автор htb расписал все очень понятным языком
luxik.cdi.cz/~devik/qos/htb/manual/userg.htm

[eox425]

Да видимо что про iproute на хабре инфы маловато
вот только это и вообщем-то всё.
Что выбрать HTB или CBQ? — это старый холивар.
С другой стороны пользоваться одним htbinit'ом или cbqinit'ом можно.
Но настоящую гибкость даёт чистый iproute. Правда инфа про него слижком уж замысловата.
Вспомним один только lartc
Думаю стоит преобразить даный утиль в хаброформат, ибо для /dev/habruman он не совсем съедобный.

[norguhtar]

CBQ обладает малой производительностью проверяли мы ужо.

[NickyX3]

насколько малой?
поток в 400 мегабит он таки переваривал на 1800 MHz Celeron, 2GB RAM. Правда при CPU Load в 90-95%.
Xeon 5120 такой же поток напрягает примерно на 4%.

[norguhtar]

Давно это было, но если я правильно помню разница порядка 40 процентов.

[list]

habrahabr.ru/blogs/linux/60095/

[nicolnx]

А у кого-то под линухом получалось решить такую задачу:

есть, скажем, 1000 клиентов. Каждому надо отдать одинаковую полосу (скажем, 256к). клиенты не ppp, так что повесить на каждый интерфейс отдельную очередь не выйдет.
Как порезать трафик не создавая 1000 очередей?

Интересен аналог решения на cisco

[xenon]

А как вам альтернативное решение — все равно ведь основной трафик — http/ftp, то зарубить лишнее на файрволе, а http пускать через сквида. Он уже вроде неплохо может через delay pools канал делить.

[nicolnx]

основной трафик нынче — p2p, увы. сквид тут не подойдет

[nicolnx]

+ боюсь, пара сотен мегабит нагнет сквида так что мало не покажется. тут нужно ядерное решение.

[norguhtar]

Через использование htb и хешей. Вопрос больше в другом, вы понимаете что если у вас нехватает канала, то о гарантированной скорости речь идти не будет? :)

[nicolnx]

насколько я понимаю написанное в LARTC, хеши можно использовать только в фильтрах. Но 1000 классов все равное же придется создавать? Вот от этого и хочется уйти.
p.s.: из 1000 работают всего порядка 30% в каждый момент времени, так что с полосой все ок.

[norguhtar]

Прийдется если вы хотите изолированных очередей. То что они есть, ничего страшного. Сканирование идет только по фильтрам, дальше сканирования нет осуществялется переход по известному ID.

[ufik]

interface FastEthernet0/0.45
encapsulation dot1Q 45
ip address 192.168.14.129 255.255.255.224
ip access-group IntBlock in
ip nat inside
ip virtual-reassembly
rate-limit input 512000 128000 160000 conform-action transmit exceed-action drop
rate-limit output 512000 128000 160000 conform-action transmit exceed-action drop
no cdp enable
!
VLAN на пользователя, модульная структура в виде — агрегирующий свитч на 1000 вланов, роутер который это всё режет и натит и уже антагет трафик льётся в сторону аплинков, либо по кольцу либо по тому что у вас есть.
Так обрабатывается больше 1000 клиентов.

[ufik]

Это cisco.

[alex_www]

Per vlan или per interface шэйпинг есть во всем, вопрос про то как _НЕ_ _делать_ _отдального_ для каждого клиента vlan/ppp/queue/traffic-engineering tunnel etc. Вот такое решение было бы интересно.

[alex_www]

Мимо кассы — фактически Вы предлагаете по vlan на клиента и фиксированые. Автор вопроса не хочет создавать очередь/vlan/ppp отдельно для каждого клиента и в идеале надо шейспить на динамических ip. Ваш же пример — пример _отельного_ vlan для конкретного клиента.

[ufik]

ну на сколько я знаю, очередь пакетов не создать в воздухе, она должна быть либо на виртуальном либо реальном интерфейсе. можно конечно запихивать их в базу 0_о и от туда с определенной скоростью уже выдавать на интрерфейс =). Ну если я конечно правильно понимаю под шейпингом как управление очередью пакетов.

[ufik]

Можно пустить весь трафик на интерфейс а там фильтрами ваши динамические IPшники шейпить.

[ufik]

максимально близкое к тому что вы сказали это думаю фильтрация по ипам и запуск этих отфильтрованных пакетов в свой класс с определённой шириной шейпа, это я описывал тут: habrahabr.ru/blogs/sysadm/88624/#comment_2665215

[Antex]

огромное спасибо

[nicosha]

Так это и хорошо, т.к. большинство статей в инете про шейпинг — одни вступления.

[Anton_Shevtsov]

Шейпировать можно только исходящий из интерфейса трафик

А вы слышали о ingress и ifb?

[norguhtar]

Ну есть они и чо? Один черт входящий трафик вы контролировать как исходящий не можете. Лучше уж при наличии двух интерфейсов контролировать его там где он является исходящим.

[Anton_Shevtsov]

как исходящий конечно не можете, но что-то делат можно… например dropать пакеты которые идут со скоростью большей чем вам надо…

[ashcan]

Как зануда — зануде. Из LARCT howto:
To 'shape' incoming traffic which you are not forwarding, use the Ingress Policer. Incoming shaping is called 'policing', by the way, not 'shaping'.

[Anton_Shevtsov]

Чёрт… =)) день не удался…

[salvator]

Ужас. Вот из-за такого колдовства над шейперами и файрволлами в Linux, перешел в свое время на FreeBSD — линуксовые показались слишком низкоуровневыми, если нужно быстро сделать нат и порезать канал — на ipfw делается за 10 минут без копания в дебрях iproute2.

[watcher_fox]

а может кто напишет статью о flow classify, а то канал режется по потокам, а не по ip. Торрент как забивал весь дозволенный канал своими потоками так и продолжает забивать… на шейпер.