Есть linux (пробовал ядра 2.6 и 3.2)
На нем 51 vlan интерфейс
50 смотрят на разные сети (пользователей), 52-й выход в внешний мир.
Имена имеют eth0.1001-eth0.1052Делаю так
# Удаление очередей
/sbin/tc qdisc del dev eth0.1001 ingress
/sbin/tc qdisc del dev eth0.1001 root handle 1:# Ограничение скорости отдачи
/sbin/tc qdisc add dev eth0.1001 root handle 1: htb default 10 r2q 1
/sbin/tc class add dev eth0.1001 parent 1: classid 1:10 htb rate 10mbit quantum 8000 burst 16k# Ограничение скорости загрузки
/sbin/tc qdisc add dev eth0.1001 handle ffff: ingress
/sbin/tc filter add dev eth0.1001 parent ffff: protocol ip prio 50 u32 match ip src 0.0.0.0/0 police rate 5mbit burst 16k drop flowid :1Данный шейпер на интерфейсе eth0.1001 работает только в однй сторону - сторону исходящего трафика с итерфейса. Входящий он не ограничивает.
Попробовал более простой вариант - ограничить через дисциплину tbf
tc qdisc add dev eth0.1001 root tbf rate 4mbit burst 15kb latency 70ms peakrate 5mbit minburst 1540результат аналогичный. Исходящий с eth0.1001 шейпируется, входящий нет.
Под нешейпируется я понимаю как полностью отсутсвие огранияесний, так и некоррекнтую работу (т.е. скорость может отличаться в десятки раз от заданной).
Для Вас возможно это будет неожиданностью но shaper linux ограничивает только исходящий трафик. А остальное достигается либо 2 сетевыми картами либо loopback интерфейсами.ЗЫ Воспользуйтесь поиском по форуму, здесь есть примеры настроек.
> Для Вас возможно это будет неожиданностью ноДля Вас, возможно, это будет неожиданностью, но вы не внимательны.
Топикстартер знает про слово ingress, а вы, видимо, еще нет.
> А остальное достигается либо 2 сетевыми картами либо loopback интерфейсами.Но таки да, чаще всего делают именно так. Не сильно силен в теме, но по loopback-интерфейсам ключевые слова: "imq", "ifb".
>>Для Вас возможно это будет неожиданностью но shaper linux ограничивает только исходящий трафик. А остальное достигается либо 2 сетевыми картами либо loopback интерфейсами.Ну а если трафик исходит во внутреннюю сеть , то это уже входящий трафик. Т. е. нужны две сетевые карты
>>>Для Вас возможно это будет неожиданностью но shaper linux ограничивает только исходящий трафик. А остальное достигается либо 2 сетевыми картами либо loopback интерфейсами.
> Ну а если трафик исходит во внутреннюю сеть , то это уже
> входящий трафик. Т. е. нужны две сетевые картыСтоп. А vlan интерфейсы разве не являются с точки зрения системы половозрелыми интерфейсами?
Про loopback можно подробней?PS. Аналогичные правила на ppp интерфейсах работают на ура. Может на vlan есть какие-то затыки?
включите шейпер на 52й влан(который в мир смотрит)
> включите шейпер на 52й влан(который в мир смотрит)Да я уже сделал через фильтры на исходящих. Вопрос открытый - vlan являются полноценныйми интерфейсами?
>> включите шейпер на 52й влан(который в мир смотрит)
> Да я уже сделал через фильтры на исходящих. Вопрос открытый - vlan
> являются полноценныйми интерфейсами?полноценными
>>>>Для Вас возможно это будет неожиданностью но shaper linux ограничивает только исходящий трафик. А остальное достигается либо 2 сетевыми картами либо loopback интерфейсами.
>> Ну а если трафик исходит во внутреннюю сеть , то это уже
>> входящий трафик. Т. е. нужны две сетевые карты
> Стоп. А vlan интерфейсы разве не являются с точки зрения системы половозрелыми
> интерфейсами?cat /proc/net/vlan/ваш_vlan
смотрим REORDER_HDR. если включен, то полноценным - иначе могут быть варианты.
> Про loopback можно подробней?
можно. когда не было imq все делалось ч/з loopback ).
> PS. Аналогичные правила на ppp интерфейсах работают на ура. Может на vlan
> есть какие-то затыки?
>> Для Вас возможно это будет неожиданностью но
> Для Вас, возможно, это будет неожиданностью, но вы не внимательны.
> Топикстартер знает про слово ingress, а вы, видимо, еще нет.Фууу ).
Контролировать приход ВНЕШНЕГО трафика этим средством не возможно - только рубить то, что уже пришло. тогда проще это делать и ч/з пакетный фильтр. а пытаться управлять внешним входящим трафиком можно только средствами протокола TCP (в самом простом случае).
>> А остальное достигается либо 2 сетевыми картами либо loopback интерфейсами.
> Но таки да, чаще всего делают именно так. Не сильно силен в
> теме, но по loopback-интерфейсам ключевые слова: "imq", "ifb".
В написанном есть какой-то практический смысл? Я его не нашел.> Контролировать приход ВНЕШНЕГО трафика этим средством не возможно - только рубить то,
> что уже пришло.Ну так цель-то не в проводокЕ до роутера скорость пакетов ограничить, а управлять скоростью обрабатываемого хостом/транзитного через роутер потока.
>тогда проще это делать и ч/з пакетный фильтр.
Пакет. Пришел. Стал в очередь шейпера/полисера. Полисер выпустил пакет с задержкой/дропнул при переполнении.
Каким боком тут "пакетный фильтр" и как "проще" это через него сделать, поясните пожалуйста ваше утверждение.
> а пытаться управлять внешним входящим трафиком можно только средствами протокола TCP
> (в самом простом случае).Поясните, пожалуйста, самый простой случай, _как_ на промежуточном роутере на линукс вы можете управлять трафиком протокола TCP средствами этого протокола.
Очень хочется прочитать ваши пояснения, иначе вышенаписанное сообщение не имеет никакого смысла и полностью бесполезно. Пустое сотрясение воздуха (электронов).
1)
входящий ВНЕШНИЙ трафик можно ПОПЫТАТЬСЯ ограничить ТОЛЬКО используя возможности сетевых протоколов. над входящим трафиком Вы никакого контроля не имеете и можете только попросить передающую сторону уменьшить скорость отправки данных.2)
смысла рубить невалидный пришедший трафик на шейпере нет (он уже пришел = канал загружен)3)
шейпинг входящего трафика актуален только в пределах ограниченной (читай локальной сети).4)
шейпить надо исходящий трафик. по Ломоносову: "Если где то убудет то в другом месте прибудет". входящее на одном интерфейсе = исходящее на другом.1=аксиома, остальное следствия.
PS
все высказывания даны с точки зрения организации шлюза в инет.
Рассмотрим аксиому и "следствия".> 1)
> входящий ВНЕШНИЙ трафик можно ПОПЫТАТЬСЯ ограничить ТОЛЬКО используя возможности сетевых
> протоколов. над входящим трафиком Вы никакого контроля не имеете и можете
> только попросить передающую сторону уменьшить скорость отправки данных.Так какие там средства управления скоростью потока предоставляет IP-протокол?
Как в общем случае попросить уменьшить скорость отправки данных по UDP?Какими средствами Linux, не внося задержку в прохождение сквозь роутер входящих пакетов потока (и, естественно, без их дропа), попросить уменьшить скорость отправки данных по TCP?
> 3)
> шейпинг входящего трафика актуален только в пределах ограниченной (читай локальной сети).- Вы за всех решили, что кому актуально, а что нет?
- Наоборот, трафик внутри локальной сети /чаще всего/ ограничивать не требуется, пусть всё работает на маскимальной скорости, а вот "канал в мир" много уже, и требуется разграничить/приоритезировать доступ.
> 4)
> шейпить надо исходящий трафик. по Ломоносову: "Если где то убудет то в
> другом месте прибудет". входящее на одном интерфейсе = исходящее на другом.Ага. А интереснее всего когда входящее идет с нескольких интерфейсов, уходит опять же на несколько интерфейсов, а политика распределения должна собрать всё воедино.
> 2)
> смысла рубить невалидный пришедший трафик на шейпере нет (он уже пришел =
> канал загружен)п.4 - шейпить надо исходящий трафик. А на исходящем интерфейсе, при переполнении очереди, дропов значит не будет, да ? На одном интерфейсе - смысла нет, а на другом интерфейсе - волшебным образом - есть... Ну-ну.
> 1=аксиома, остальное следствия.
> PS
> все высказывания даны с точки зрения организации шлюза в инет.Хорошего дня =)
> Рассмотрим аксиому и "следствия".
>> 1)
>> входящий ВНЕШНИЙ трафик можно ПОПЫТАТЬСЯ ограничить ТОЛЬКО используя возможности сетевых
>> протоколов. над входящим трафиком Вы никакого контроля не имеете и можете
>> только попросить передающую сторону уменьшить скорость отправки данных.
> Так какие там средства управления скоростью потока предоставляет IP-протокол?никакую
> Как в общем случае попросить уменьшить скорость отправки данных по UDP?
спросите у разработчиков uTorrent - они видимо ответ нашли)
> Какими средствами Linux, не внося задержку в прохождение сквозь роутер входящих пакетов
> потока (и, естественно, без их дропа), попросить уменьшить скорость отправки данных
> по TCP?окно.
и не факт , что Ваше пожелание будет адекватно обработано другой стороной (примеров в моей практике - туча).Итого:
- Linux тут вообще по боку, как любая друга ОС.
- ТСП разве не сетеовй протокол (транспорт - да, но тем не менее)?=> с чем Вы не согласны?
>> 3)
>> шейпинг входящего трафика актуален только в пределах ограниченной (читай локальной сети).
> - Вы за всех решили, что кому актуально, а что нет?
> - Наоборот, трафик внутри локальной сети /чаще всего/ ограничивать не требуется, пусть
> всё работает на маскимальной скорости, а вот "канал в мир" много
> уже, и требуется разграничить/приоритезировать доступ.тут не сеть - сетИ. стало быть какое-то управление по TCP имеет место быть. роутинг м/ду vlan например.
просто в локальной сети/ях как правило все подкрнтролем => при LAN->WAN можно воспользоваться п.1 при необходимости (окно работает). однако хреновый подход ИМХО шейпить на входе.
>> 4)
>> шейпить надо исходящий трафик. по Ломоносову: "Если где то убудет то в
>> другом месте прибудет". входящее на одном интерфейсе = исходящее на другом.
> Ага. А интереснее всего когда входящее идет с нескольких интерфейсов, уходит опять
> же на несколько интерфейсов, а политика распределения должна собрать всё воедино.это Вы про что? абстракция. давайте конкретный пример или я посоветую ставить шейпер на/за/перед гейтом - получится 1 входящий - один исходящий интерфейс - дальше ТОЛЬКО проблемы настроить шейпер).
>> 2)
>> смысла рубить невалидный пришедший трафик на шейпере нет (он уже пришел =
>> канал загружен)
> п.4 - шейпить надо исходящий трафик. А на исходящем интерфейсе, при
> переполнении очереди, дропов значит не будет, да ? На одном интерфейсе
> - смысла нет, а на другом интерфейсе - волшебным образом -
> есть... Ну-ну.дропы будут, только в канал пакеты с исходящего интерфейса уже не пойдут (и следующее устройство не нагрузят - хоть в LAN оно стоит, хоть в WAN - это хорошая политика), а на входящий уже пришли. => на исходящем интерфейсе не загружаем канал говном, а на входящем - просто дропаем, но загрузку не уменьшаем.
>> 1=аксиома, остальное следствия.
>> PS
>> все высказывания даны с точки зрения организации шлюза в инет.без разницы.
> Хорошего дня =)
И Вам того же.
PS
1) Ломоносов мне кажется прав.
2) шейпинг входа сводится к простому дропу - пакеты УЖЕ пришли и УЖЕ канал загружен.
3) для разгрузки канала шейпинг актуален только на выходе - ибо над входящим трафиком (пропустим RFC - банально: атаки, флуд, дураки-админы, итд) у Вас контроля НЕТ.
4) все ИМХО.
Аналогичная проблема, решил так
ethtool ethX -K gro off