Гость Опубликовано 9 сентября, 2004 · Жалоба Добрый день. Столкнулся вот с довольно неприятной ситуацией: конструкция вида /sbin/tc qdisc add dev $DEVICE root tbf rate 32Kbps latency 50ms burst 32768 абсолютно не желает накладывать ограничение пропускной способности на апстрим (т.е., траффик, исходящий из $DEVICE). Даунстрим (входящий клиенту в $DEVICE траффик) шейпится корректно. Из документации ничего подобного не следует, попытка копания в исходниках тоже мало что дала. Не мог бы кто поделиться своими соображениям? Буду премного благодарен. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Zakrutkin Yuri Опубликовано 10 сентября, 2004 · Жалоба попробуй по htb это же замутить. только в tc filter - 2 строчки, которые указывали на твою подсеть tc filter ..... to 192.168.1.0/24(твоя подсеть) tc filter ..... from 192.168.1.0/24(твоя подсеть) у меня работает. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kostyk Опубликовано 13 сентября, 2004 · Жалоба Э-э... Это у тебя рутер что ли с двумя сетевухами или просто пользовательская машина с одной сетевушкой? Если второе - тогда сюда 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). Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Bushi Опубликовано 14 сентября, 2004 · Жалоба В документации сказано, что sfq шейпит только исходящий трафик с интерфейса. То есть для ограничения трафика от клиента шейпер нужно вешать не на клиентский интерфейс, а на интерфейс, который покидают клиентские пакеты. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Radik Опубликовано 15 сентября, 2004 · Жалоба Нет, господа, смотрите, спрашивают вот о чем ППТП-туннели нужно шейпить, причем в обе стороны, симметрично, причем каждый туннель в отдельности, а не все сразу. Я тоже столкнулся с проблемой - шейпится только исход. При этом, как вы понимаете, шейпить на другом устройстве не совсем возможно. Или я неправ ? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
UglyAdmin Опубликовано 16 сентября, 2004 · Жалоба Прав. Входящее можно только резать, ну или шейпить на исходящем интерфейсе рутера, но это не то. Как вариант - шейпить на устройстве как можно ближе к юзеру, например на свитче или промежуточном рутере, но тоже не совсем то. :( Это не только на линуксе так, на цисках так же - это есть ограничение пакетной технологии. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Zakrutkin Yuri Опубликовано 16 сентября, 2004 · Жалоба А что мешает шейпить на том интерфейсе где открыт порт PPTP - адреса внутренние... а не те, которые выделяет PPTP ? и не на PPP+ а на eth :) Если меняются внутренние - написать скрипт, который будет смотреть на то какой у него сейчас внутренний ИП:) Я думаю если подумать в этом направлении реально решить задачку.. но всё зависит от организации сети Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
UglyAdmin Опубликовано 17 сентября, 2004 · Жалоба А какая хрен разница? Шейпить всё равно можно только исходящий трафик, так что никто не запретит юзеру забить весь канал, если у него какой вирус завёлся - он же шейпить не будет :( Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Sultan Опубликовано 17 сентября, 2004 · Жалоба dummynet на freebsd умеет ограничивать входящий трафик, altq не умеет... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
UglyAdmin Опубликовано 17 сентября, 2004 · Жалоба Ограничить - это значит порезать тот трафик, что уже пришел :( Он уже пришёл на маршрутизатор, понимаете? И занял определённую полосу в каналах связи. :( Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kostyk Опубликовано 17 сентября, 2004 · Жалоба Нет, ограничить - значит уменьшить возможную полосу для всех последующих пакетов, которые придут буквально через секунду. Короче всё равно работать будет. Пример дать? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Zakrutkin Yuri Опубликовано 17 сентября, 2004 · Жалоба Ограничить - это значит порезать тот трафик, что уже пришел :(Он уже пришёл на маршрутизатор, понимаете? И занял определённую полосу в каналах связи. :( Вы ощущаете разницу между unicast и multicast ? TCP пакеты, не будут идти пока не получат подтверждение доставки. шейперы же режут в том числе подтверждение или отслыслают его позже... Поэтому шейперы прекрасно делят полосу :) и реально делят. Флуд в счёт не берём :)))) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Radik Опубликовано 21 сентября, 2004 · Жалоба Ограничить - это значит порезать тот трафик, что уже пришел :(Он уже пришёл на маршрутизатор, понимаете? И занял определённую полосу в каналах связи. :( Да, пришел, и занял, но на самом деле, это не фатально. Эдак если за каждый пакет трястись то можно и перегреться... ;) пойдут дропы, соотв-но пойдут запросы на повторную пересылку и отправитель сбросит скорость передачи. Т.о. в итоге мы достигнем того, чего хотим. Вопрос: КАК же это сделать в линуксе? натолкните меня на мысль плз. Циски шейпят в обе строны на одном и том же интерфейсе без малейших проблем, кстати. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
UglyAdmin Опубликовано 21 сентября, 2004 · Жалоба Флуд в счёт не берём :)))) Вот именно что. Если у юзера завёлся червь, то зашейпить его не получится - весь канал сожрёт :( Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Zakrutkin Yuri Опубликовано 22 сентября, 2004 · Жалоба Добрый день. Столкнулся вот с довольно неприятной ситуацией: конструкция вида /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" Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Гость Опубликовано 23 сентября, 2004 · Жалоба 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 а как-то его можно еще "обработать напильником", интересно? ;) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Zakrutkin Yuri Опубликовано 23 сентября, 2004 · Жалоба Собственно на ингресс я и смотрю, но работает ли он с 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 для ограничение как входящего , так и исходящего трафика (на второй машине). - как я описал в предыдущем сообщении.... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Гость Опубликовано 23 сентября, 2004 · Жалоба хм... ты весь исходящий трафик на интерфейсе $dev зарезал до 8kbit ?? Учти, что если ты каждому юзеру хочешь выделить аплоад 8 kpbs, на каждого отдельно придётся писать фильтр... Да я это на ppp-интерфейсе самого юзера сделал, так что чего бы и нет. ;) Классы мне не нужны, а вот если эта конструкция сработает, будет весьма удобно. tbf, кстати, сам по себе classless. ;) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
repa Опубликовано 27 сентября, 2004 · Жалоба Sultan, dummynet и altq на одной машине на одних и тех де интерфейсах живут? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...