The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка  RSS
"Шейперы работают только в одну сторону."
Вариант для распечатки  
Пред. тема | След. тема 
Форум Открытые системы на сервере (Квоты, ограничения, QoS / Linux)
Изначальное сообщение [ Отслеживать ]

"Шейперы работают только в одну сторону."  +/
Сообщение от Гриша Одноглазов on 07-Сен-12, 15:55 
Есть 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 шейпируется, входящий нет.

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


Ответить | Правка | Cообщить модератору

Оглавление

Сообщения по теме [Сортировка по времени | RSS]


1. "Шейперы работают только в одну сторону."  +2 +/
Сообщение от _uznik_ on 08-Сен-12, 08:16 
Для Вас возможно это будет неожиданностью но shaper linux ограничивает только исходящий трафик. А остальное достигается либо 2 сетевыми картами либо loopback интерфейсами.

ЗЫ Воспользуйтесь поиском по форуму, здесь есть примеры настроек.

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

2. "Шейперы работают только в одну сторону."  –1 +/
Сообщение от PavelR (ok) on 08-Сен-12, 08:21 
> Для Вас возможно это будет неожиданностью но

Для Вас, возможно, это будет неожиданностью, но вы не внимательны.
Топикстартер знает про слово ingress, а вы, видимо, еще нет.


> А остальное достигается либо 2 сетевыми картами либо loopback интерфейсами.

Но таки да, чаще всего делают именно так. Не сильно силен в теме, но по loopback-интерфейсам ключевые слова: "imq", "ifb".

Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

3. "Шейперы работают только в одну сторону."  –1 +/
Сообщение от Вася (??) on 08-Сен-12, 11:50 
>>Для Вас возможно это будет неожиданностью но shaper linux ограничивает только исходящий трафик. А остальное достигается либо 2 сетевыми картами либо loopback интерфейсами.

Ну а если трафик исходит во внутреннюю сеть , то это уже входящий трафик. Т. е. нужны две сетевые карты

Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

4. "Шейперы работают только в одну сторону."  +/
Сообщение от Гриша Одноглазов on 13-Сен-12, 09:03 
>>>Для Вас возможно это будет неожиданностью но shaper linux ограничивает только исходящий трафик. А остальное достигается либо 2 сетевыми картами либо loopback интерфейсами.
> Ну а если трафик исходит во внутреннюю сеть , то это уже
> входящий трафик. Т. е. нужны две сетевые карты

Стоп. А vlan интерфейсы разве не являются с точки зрения системы половозрелыми интерфейсами?
Про loopback можно подробней?

PS. Аналогичные правила на ppp интерфейсах работают на ура. Может на vlan есть какие-то затыки?

Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

5. "Шейперы работают только в одну сторону."  +/
Сообщение от alexmasz (ok) on 14-Сен-12, 10:20 
включите шейпер на 52й влан(который в мир смотрит)

Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

6. "Шейперы работают только в одну сторону."  +/
Сообщение от Гриша Одноглазов on 17-Сен-12, 15:02 
> включите шейпер на 52й влан(который в мир смотрит)

Да я уже сделал через фильтры на исходящих. Вопрос открытый - vlan являются полноценныйми интерфейсами?

Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

7. "Шейперы работают только в одну сторону."  +/
Сообщение от alexmasz (ok) on 17-Сен-12, 18:17 
>> включите шейпер на 52й влан(который в мир смотрит)
> Да я уже сделал через фильтры на исходящих. Вопрос открытый - vlan
> являются полноценныйми интерфейсами?

полноценными

Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

9. "Шейперы работают только в одну сторону."  +/
Сообщение от LSTemp (ok) on 22-Сен-12, 23:54 
>>>>Для Вас возможно это будет неожиданностью но shaper linux ограничивает только исходящий трафик. А остальное достигается либо 2 сетевыми картами либо loopback интерфейсами.
>> Ну а если трафик исходит во внутреннюю сеть , то это уже
>> входящий трафик. Т. е. нужны две сетевые карты
> Стоп. А vlan интерфейсы разве не являются с точки зрения системы половозрелыми
> интерфейсами?

cat /proc/net/vlan/ваш_vlan

смотрим REORDER_HDR. если включен, то полноценным - иначе могут быть варианты.

> Про loopback можно подробней?

можно. когда не было imq все делалось ч/з loopback ).

> PS. Аналогичные правила на ppp интерфейсах работают на ура. Может на vlan
> есть какие-то затыки?

Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

8. "Шейперы работают только в одну сторону."  +/
Сообщение от LSTemp (ok) on 22-Сен-12, 23:36 
>> Для Вас возможно это будет неожиданностью но
> Для Вас, возможно, это будет неожиданностью, но вы не внимательны.
> Топикстартер знает про слово ingress, а вы, видимо, еще нет.

Фууу ).

Контролировать приход ВНЕШНЕГО трафика этим средством не возможно - только рубить то, что уже пришло. тогда проще это делать и ч/з пакетный фильтр. а пытаться управлять внешним входящим трафиком можно только средствами протокола TCP (в самом простом случае).

>> А остальное достигается либо 2 сетевыми картами либо loopback интерфейсами.
> Но таки да, чаще всего делают именно так. Не сильно силен в
> теме, но по loopback-интерфейсам ключевые слова: "imq", "ifb".

Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

11. "Шейперы работают только в одну сторону."  +/
Сообщение от PavelR (ok) on 23-Сен-12, 09:22 

В написанном есть какой-то практический смысл? Я его не нашел.

> Контролировать приход ВНЕШНЕГО трафика этим средством не возможно - только рубить то,
> что уже пришло.

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

>тогда проще это делать и ч/з пакетный фильтр.

Пакет. Пришел. Стал в очередь шейпера/полисера. Полисер выпустил пакет с задержкой/дропнул при переполнении.

Каким боком тут "пакетный фильтр" и как "проще" это через него сделать, поясните пожалуйста ваше утверждение.


> а пытаться управлять внешним входящим трафиком можно только средствами протокола TCP
> (в самом простом случае).

Поясните, пожалуйста, самый простой случай, _как_ на промежуточном роутере на линукс вы можете управлять трафиком протокола TCP средствами этого протокола.


Очень хочется прочитать ваши пояснения, иначе вышенаписанное сообщение не имеет никакого смысла и полностью бесполезно. Пустое сотрясение воздуха (электронов).

Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

10. "Шейперы работают только в одну сторону."  +/
Сообщение от LSTemp (ok) on 23-Сен-12, 00:05 
1)
входящий ВНЕШНИЙ трафик можно ПОПЫТАТЬСЯ ограничить ТОЛЬКО используя возможности сетевых протоколов. над входящим трафиком Вы никакого контроля не имеете и можете только попросить передающую сторону уменьшить скорость отправки данных.

2)
смысла рубить невалидный пришедший трафик на шейпере нет (он уже пришел = канал загружен)

3)
шейпинг входящего трафика актуален только в пределах ограниченной (читай локальной сети).

4)
шейпить надо исходящий трафик. по Ломоносову: "Если где то убудет то в другом месте прибудет". входящее на одном интерфейсе = исходящее на другом.

1=аксиома, остальное следствия.

PS
все высказывания даны с точки зрения организации шлюза в инет.


Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

12. "Шейперы работают только в одну сторону."  +/
Сообщение от PavelR (ok) on 23-Сен-12, 09:44 

Рассмотрим аксиому и "следствия".

> 1)
> входящий ВНЕШНИЙ трафик можно ПОПЫТАТЬСЯ ограничить ТОЛЬКО используя возможности сетевых
> протоколов. над входящим трафиком Вы никакого контроля не имеете и можете
> только попросить передающую сторону уменьшить скорость отправки данных.

Так какие там средства управления скоростью потока предоставляет IP-протокол?
Как в общем случае попросить уменьшить скорость отправки данных по UDP?

Какими средствами Linux, не внося задержку в прохождение сквозь роутер входящих пакетов потока (и, естественно, без их дропа), попросить уменьшить скорость отправки данных по TCP?


> 3)
> шейпинг входящего трафика актуален только в пределах ограниченной (читай локальной сети).

- Вы за всех решили, что кому актуально, а что нет?
- Наоборот, трафик внутри локальной сети /чаще всего/ ограничивать не требуется, пусть всё работает на маскимальной скорости, а вот "канал в мир" много уже, и требуется разграничить/приоритезировать доступ.


> 4)
> шейпить надо исходящий трафик. по Ломоносову: "Если где то убудет то в
> другом месте прибудет". входящее на одном интерфейсе = исходящее на другом.

Ага. А интереснее всего когда входящее идет с нескольких интерфейсов, уходит опять же на несколько интерфейсов, а политика распределения должна собрать всё воедино.


> 2)
> смысла рубить невалидный пришедший трафик на шейпере нет (он уже пришел =
> канал загружен)

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

> 1=аксиома, остальное следствия.
> PS
> все высказывания даны с точки зрения организации шлюза в инет.

Хорошего дня =)

Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

14. "Шейперы работают только в одну сторону."  +/
Сообщение от LSTemp (ok) on 17-Окт-12, 05:34 
> Рассмотрим аксиому и "следствия".
>> 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) все ИМХО.

Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

13. "Шейперы работают только в одну сторону."  +/
Сообщение от disappointed (??) on 02-Окт-12, 22:48 
Аналогичная проблема, решил так
ethtool ethX -K gro off

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру