Comments 42
Отличная статья. Мужик!
имхо, стоит слово «шейпинг» добавить в теги, иначе будет трудно найти статью
Одна большая и толстая дока пишет о том что sfq надо не хотеть. Ну и да про хеши надо в обязательном порядке, это существенно ускоряет обработку.
Я так понимаю, что шейпить входящий канал посредством манипулирования tcp window никакие утилиты так и не умеют?
Тупо зажать window наверное возможно простым модулем нетфильтра, но тогда скорость каждой tcp сессии будет зависеть от RTT узла. А вот чтобы канал между сессиями делился и по разному приоритизировался — то бесплатных таких программ нет. Более того, сомневаюсь, что есть вообще реализации этого в виде софта — есть точно железячные шейперы которые умеют, но это очень уже дорого.
(сейчас работаю по подобному проекту просто — но заказчик почему-то не хочет за свои деньги делать freeware продукт :-)
(сейчас работаю по подобному проекту просто — но заказчик почему-то не хочет за свои деньги делать freeware продукт :-)
Входящий tcp (и только tcp для остального эффекта почти ноль) можно перенаправляя его в IMQ www.linuximq.net/ а дальше тот же htb или вот даже RED.
htb.init скрипт сделал настройку htp запутаной и непрзрачной,
сам автор htb расписал все очень понятным языком
luxik.cdi.cz/~devik/qos/htb/manual/userg.htm
сам автор htb расписал все очень понятным языком
luxik.cdi.cz/~devik/qos/htb/manual/userg.htm
Да видимо что про iproute на хабре инфы маловато
вот только это и вообщем-то всё.
Что выбрать HTB или CBQ? — это старый холивар.
С другой стороны пользоваться одним htbinit'ом или cbqinit'ом можно.
Но настоящую гибкость даёт чистый iproute. Правда инфа про него слижком уж замысловата.
Вспомним один только lartc
Думаю стоит преобразить даный утиль в хаброформат, ибо для /dev/habruman он не совсем съедобный.
вот только это и вообщем-то всё.
Что выбрать HTB или CBQ? — это старый холивар.
С другой стороны пользоваться одним htbinit'ом или cbqinit'ом можно.
Но настоящую гибкость даёт чистый iproute. Правда инфа про него слижком уж замысловата.
Вспомним один только lartc
Думаю стоит преобразить даный утиль в хаброформат, ибо для /dev/habruman он не совсем съедобный.
UFO just landed and posted this here
А у кого-то под линухом получалось решить такую задачу:
есть, скажем, 1000 клиентов. Каждому надо отдать одинаковую полосу (скажем, 256к). клиенты не ppp, так что повесить на каждый интерфейс отдельную очередь не выйдет.
Как порезать трафик не создавая 1000 очередей?
Интересен аналог решения на cisco
есть, скажем, 1000 клиентов. Каждому надо отдать одинаковую полосу (скажем, 256к). клиенты не ppp, так что повесить на каждый интерфейс отдельную очередь не выйдет.
Как порезать трафик не создавая 1000 очередей?
Интересен аналог решения на cisco
А как вам альтернативное решение — все равно ведь основной трафик — http/ftp, то зарубить лишнее на файрволе, а http пускать через сквида. Он уже вроде неплохо может через delay pools канал делить.
Через использование htb и хешей. Вопрос больше в другом, вы понимаете что если у вас нехватает канала, то о гарантированной скорости речь идти не будет? :)
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 клиентов.
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 клиентов.
Это cisco.
Мимо кассы — фактически Вы предлагаете по vlan на клиента и фиксированые. Автор вопроса не хочет создавать очередь/vlan/ppp отдельно для каждого клиента и в идеале надо шейспить на динамических ip. Ваш же пример — пример _отельного_ vlan для конкретного клиента.
ну на сколько я знаю, очередь пакетов не создать в воздухе, она должна быть либо на виртуальном либо реальном интерфейсе. можно конечно запихивать их в базу 0_о и от туда с определенной скоростью уже выдавать на интрерфейс =). Ну если я конечно правильно понимаю под шейпингом как управление очередью пакетов.
Можно пустить весь трафик на интерфейс а там фильтрами ваши динамические IPшники шейпить.
максимально близкое к тому что вы сказали это думаю фильтрация по ипам и запуск этих отфильтрованных пакетов в свой класс с определённой шириной шейпа, это я описывал тут: habrahabr.ru/blogs/sysadm/88624/#comment_2665215
огромное спасибо
UFO just landed and posted this here
Шейпировать можно только исходящий из интерфейса трафик
А вы слышали о ingress и ifb?
А вы слышали о ingress и ifb?
Ну есть они и чо? Один черт входящий трафик вы контролировать как исходящий не можете. Лучше уж при наличии двух интерфейсов контролировать его там где он является исходящим.
Как зануда — зануде. Из 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'.
To 'shape' incoming traffic which you are not forwarding, use the Ingress Policer. Incoming shaping is called 'policing', by the way, not 'shaping'.
UFO just landed and posted this here
Ужас. Вот из-за такого колдовства над шейперами и файрволлами в Linux, перешел в свое время на FreeBSD — линуксовые показались слишком низкоуровневыми, если нужно быстро сделать нат и порезать канал — на ipfw делается за 10 минут без копания в дебрях iproute2.
а может кто напишет статью о flow classify, а то канал режется по потокам, а не по ip. Торрент как забивал весь дозволенный канал своими потоками так и продолжает забивать… на шейпер.
Only those users with full accounts are able to leave comments. Log in, please.
Шейпирование трафика в Linux