h1g Mar 24 2010 at 16:17

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

6 min

36K

System administration*

+51

Comments 42

mitnlag Mar 24 2010 at 19:42

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

spanasik Mar 24 2010 at 20:38

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

evil_random Mar 25 2010 at 03:00

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

norguhtar Mar 24 2010 at 20:39

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

alex_www Mar 25 2010 at 01:00

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

norguhtar Mar 25 2010 at 05:07

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

braintorch Mar 25 2010 at 00:30

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

xenon Mar 25 2010 at 03:34

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

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

alex_www Mar 25 2010 at 05:48

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

braintorch Mar 25 2010 at 11:05

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

alex_www Mar 25 2010 at 00:59

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

eox425 Mar 25 2010 at 01:12

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

norguhtar Mar 25 2010 at 05:09

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

NickyX3 Mar 25 2010 at 08:18

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

norguhtar Mar 25 2010 at 08:28

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

list Mar 25 2010 at 01:18

habrahabr.ru/blogs/linux/60095/

UFO just landed and posted this here

nicolnx Mar 25 2010 at 01:23

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

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

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

xenon Mar 25 2010 at 03:37

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

nicolnx Mar 25 2010 at 03:39

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

nicolnx Mar 25 2010 at 03:43

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

norguhtar Mar 25 2010 at 05:10

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

nicolnx Mar 25 2010 at 05:22

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

norguhtar Mar 25 2010 at 06:25

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

ufik Mar 25 2010 at 08:36

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 Mar 25 2010 at 08:36

Это cisco.

alex_www Mar 25 2010 at 14:44

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

alex_www Mar 25 2010 at 14:42

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

ufik Mar 25 2010 at 14:55

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

ufik Mar 25 2010 at 15:14

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

ufik Mar 25 2010 at 15:16

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

Antex Mar 25 2010 at 07:32

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

UFO just landed and posted this here

nicosha Mar 25 2010 at 08:11

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

Anton_Shevtsov Mar 25 2010 at 08:18

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

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

-1

norguhtar Mar 25 2010 at 08:30

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

Anton_Shevtsov Mar 25 2010 at 08:39

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

ashcan Mar 25 2010 at 22:48

Как зануда — зануде. Из 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 Mar 26 2010 at 07:00

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

UFO just landed and posted this here

salvator Mar 25 2010 at 10:52

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

watcher_fox May 20 2011 at 15:34

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

Show the best of all time