iproute2+tc: организация шейпинга up&down-стримов

[Guest]

Добрый день.

Столкнулся вот с довольно неприятной ситуацией: конструкция вида

 

/sbin/tc qdisc add dev $DEVICE root tbf rate 32Kbps latency 50ms burst 32768

 

абсолютно не желает накладывать ограничение пропускной способности на апстрим (т.е., траффик, исходящий из $DEVICE). Даунстрим (входящий клиенту в $DEVICE траффик) шейпится корректно. Из документации ничего подобного не следует, попытка копания в исходниках тоже мало что дала. Не мог бы кто поделиться своими соображениям? Буду премного благодарен.

[Zakrutkin Yuri]

попробуй по htb это же замутить.

только в tc filter - 2 строчки, которые указывали на твою подсеть

tc filter ..... to 192.168.1.0/24(твоя подсеть)

tc filter ..... from 192.168.1.0/24(твоя подсеть)

 

у меня работает.

[kostyk]

Э-э... Это у тебя рутер что ли с двумя сетевухами или просто пользовательская машина с одной сетевушкой?

Если второе - тогда сюда http://gazette.linux.ru.net/rus/articles/a...ment-howto.html

(Идея такая: создать виртуальное устройство, которое и будет отвечать за скорость в одном направлении. А за другое направление отвечает реальная карта.)

Если первый вариант, то, как выше, следует одна сетевушка за исходящий отвечает (которая к интернету), вторая (которая к локалке) - за входящий.

 

А то что Zakrutkin Yuri говорит должно выглядеть примерно так:

tc filter add dev eth0 protocol ip parent 1: match ip src 192.168.1.0/24 flowid 1:11

 

(то есть to и from нету, а есть dst и src).

[Bushi]

В документации сказано, что sfq шейпит только исходящий трафик с интерфейса. То есть для ограничения трафика от клиента шейпер нужно вешать не на клиентский интерфейс, а на интерфейс, который покидают клиентские пакеты.

[Radik]

Нет, господа, смотрите, спрашивают вот о чем

ППТП-туннели нужно шейпить, причем в обе стороны, симметрично, причем каждый туннель в отдельности, а не все сразу.

Я тоже столкнулся с проблемой - шейпится только исход.

При этом, как вы понимаете, шейпить на другом устройстве не совсем возможно. Или я неправ ?

[UglyAdmin]

Прав.

Входящее можно только резать, ну или шейпить на исходящем интерфейсе рутера, но это не то.

Как вариант - шейпить на устройстве как можно ближе к юзеру, например на свитче или промежуточном рутере, но тоже не совсем то. :(

Это не только на линуксе так, на цисках так же - это есть ограничение пакетной технологии.

[Zakrutkin Yuri]

А что мешает шейпить на том интерфейсе где открыт порт PPTP - адреса внутренние... а не те, которые выделяет PPTP ? и не на PPP+ а на eth :)

 

 

Если меняются внутренние - написать скрипт, который будет смотреть на то какой у него сейчас внутренний ИП:)

 

 

Я думаю если подумать в этом направлении реально решить задачку.. но всё зависит от организации сети

[UglyAdmin]

А какая хрен разница?

Шейпить всё равно можно только исходящий трафик, так что никто не запретит юзеру забить весь канал, если у него какой вирус завёлся - он же шейпить не будет :(

[Sultan]

dummynet на freebsd умеет ограничивать входящий трафик, altq не умеет...

[UglyAdmin]

Ограничить - это значит порезать тот трафик, что уже пришел :(

Он уже пришёл на маршрутизатор, понимаете? И занял определённую полосу в каналах связи. :(

[kostyk]

Нет, ограничить - значит уменьшить возможную полосу для всех последующих пакетов, которые придут буквально через секунду.

Короче всё равно работать будет.

Пример дать?

[Zakrutkin Yuri]

Ограничить - это значит порезать тот трафик, что уже пришел :(

Он уже пришёл на маршрутизатор, понимаете? И занял определённую полосу в каналах связи. :(

 

Вы ощущаете разницу между unicast и multicast ?

 

TCP пакеты, не будут идти пока не получат подтверждение доставки. шейперы же режут в том числе подтверждение или отслыслают его позже...

 

Поэтому шейперы прекрасно делят полосу :) и реально делят.

 

Флуд в счёт не берём :))))

[Radik]

Ограничить - это значит порезать тот трафик, что уже пришел :(

Он уже пришёл на маршрутизатор, понимаете? И занял определённую полосу в каналах связи. :(

Да, пришел, и занял, но на самом деле, это не фатально. Эдак если за каждый пакет трястись то можно и перегреться... ;)

пойдут дропы, соотв-но пойдут запросы на повторную пересылку и отправитель сбросит скорость передачи.

Т.о. в итоге мы достигнем того, чего хотим.

Вопрос: КАК же это сделать в линуксе? натолкните меня на мысль плз.

 

Циски шейпят в обе строны на одном и том же интерфейсе без малейших проблем, кстати.

[UglyAdmin]

Флуд в счёт не берём :))))

Вот именно что. Если у юзера завёлся червь, то зашейпить его не получится - весь канал сожрёт :(

[Zakrutkin Yuri]

Добрый день.

Столкнулся вот с довольно неприятной ситуацией: конструкция вида

 

/sbin/tc qdisc add dev $DEVICE root tbf rate 32Kbps latency 50ms burst 32768

 

абсолютно не желает накладывать ограничение пропускной способности на апстрим (т.е., траффик, исходящий из $DEVICE). Даунстрим (входящий клиенту в $DEVICE траффик) шейпится корректно. Из документации ничего подобного не следует, попытка копания в исходниках тоже мало что дала. Не мог бы кто поделиться своими соображениям? Буду премного благодарен.

 

Изучив матчасть, делюсь ключевыми пунктами:

 

Конструкция типа root (tc qdisc dev $Device root ....) шейпит downstream, т.е. исключительно исходящий трафик интерфейса $device, т.е. входящий трафик юзеров которые через этот интерфейс подключены.

Пример: $device = eth1, айпишник eth1 192.168.0.1, он же шлюз для юзеров 192.168.0.2-254. Конструкция root будет шейпить исключительно входящий трафик клиентов 192.168.0.2-254(downstream), т.е. исходящий трафик eth1

 

Для шейпинга upstream у клиентов используется конструкция ingress.

tc qdisc $device handle ffff: ingress .....

tc filter ......handle ffff:

 

Замечу, что к ingress не присабачить tc class... вся мутатень с определением скоростных параметров(и параметров шейпинга) совершается через tc filter

 

я проверил - это реально работает.

 

 

Есть второй вариант ограничения скорости раздельно для upstream и downstream без использования ingress (не во всех конфигурация сетей подойдет):

 

Допустим есть некий простой роутер:

 

eth1: 1.1.1.1 (к нему подключена сеть из клиентов 1.1.1.1-254)

eth0: 2.2.2.101 , шлюз 2.2.2.2.1 (это айпишники провайдера, через патч корд подключается к трансиверу провайдера:) )

Провайдер роутит сеть класса С 1.1.1.0/24 к нам.

 

 

И так. Шейпить downstream клиентов:

tc qdisc dev eth1 root....

tc class dev eth1...

tc filter ....1.1.1.22...... (для клиента 1.1.1.22)

 

Шейпить upstream клиентов:

tc qdisc dev eth0 root....

tc class dev eth0....

tc filter ....1.1.1.22.... ( для клиента 1.1.1.22)

 

 

 

 

Всю матчасть можно найти через google.com или ya.ru по ключевым словам "tc qdisc dev root" и "tc qdisc dev ingress"

[Guest]

Zakrutkin Yuri, вот-вот! Большое спасибо. Собственно на ингресс я и смотрю, но работает ли он с tbf, как-то не очень ясно. У меня получилось нечто вот такое:

 

/sbin/tc qdisc add dev $DEV root tbf rate 8Kbps latency 50ms burst 8192

/sbin/tc qdisc add dev $DEV handle ffff: ingress

/sbin/tc filter add dev $DEV parent ffff: protocol ip prio 50 u32 match ip src 0.0.0.0/0 police rate 8Kbps burst 8192 drop

 

а как-то его можно еще "обработать напильником", интересно? ;)

[Zakrutkin Yuri]

Собственно на ингресс я и смотрю, но работает ли он с tbf, как-то не очень ясно.  

 

К сожалению нет. Ingress очень ограничен в функциональности по сравнению с egres(root), к нему нельзя накрутить классов.

Исключительно фильтры...

 

У меня получилось нечто вот такое:  

/sbin/tc qdisc add dev $DEV root tbf rate 8Kbps latency 50ms burst 8192

/sbin/tc qdisc add dev $DEV handle ffff: ingress

/sbin/tc filter add dev $DEV parent ffff: protocol ip prio 50 u32 match ip src 0.0.0.0/0 police rate 8Kbps burst 8192 drop

 

хм... ты весь исходящий трафик на интерфейсе $dev зарезал до 8kbit ??

Учти, что если ты каждому юзеру хочешь выделить аплоад 8 kpbs, на каждого отдельно придётся писать фильтр...

 

а как-то его можно еще "обработать напильником", интересно? ;)

 

Изменить конфигурацию сети .... НАТ с интернетом на одной машине, а там где pptp-сервер отключить НАТ и включить простую маршрутизацию( с дефолтом на тачку с натом) на втором сервере. В этом случае на второй машине ты сможешь пользоваться всеми прелестями tc qdisc root для ограничение как входящего , так и исходящего трафика (на второй машине). - как я описал в предыдущем сообщении....

[Guest]

хм... ты весь исходящий трафик на интерфейсе $dev зарезал до 8kbit ??  

Учти, что если ты каждому юзеру хочешь выделить аплоад 8 kpbs, на каждого отдельно придётся писать фильтр...  

 

Да я это на ppp-интерфейсе самого юзера сделал, так что чего бы и нет. ;) Классы мне не нужны, а вот если эта конструкция сработает, будет весьма удобно. tbf, кстати, сам по себе classless. ;)

[repa]

Sultan, dummynet и altq на одной машине на одних и тех де интерфейсах живут?