Подскажите по Qos в Linux

[rus-p]

Добрый день!

 

Подскажите для чего придуман IMQ в линукс?

Допустим есть серер к которому подключаются клиенты создавая ppp сессии.

В QoS HOW-TO для HTB сказано, что управлять можно только трафиком покидающим интерфейс (pppX), т.е. в нашем случае, который идет к клиенту.

С этим все понятно.

А для управления входящим от клиента якобы придуман IMQ. (можно еще через ингресс, но это не рассматриваем, там нет классов)

Но ведь управлять входящим, например, трафиком в интерфейсе pppX, можно на исходящем интерфейсе в мир.

Т.е. клиентским исходящим трафиком можно управлять на допустим eth1, который смотрит во внешний мир, вешая HTB с фильтром на IP адреса клиента. В чем я не прав?

 

И еще вопрос, а если я вешаю HTB, на интерфейсы pppX, оно в ядре будет выглядеть цепочкой? Т.е. при большом числе ppp соединений мне нужно применять схему с хешированием по IP, чтобы уменьшить затраты процессорного времени, или поиск всегда будет ограничен правилами присоединенными на конкретное ppp соединение по которому пришел пакет?

Edited October 26, 2006 by rus-p

[calculator]

rus-p

Входящий трафак считается относительно внешнего провайдера(eth0). Исходищий - из локалки.

Обозвать конечно вх/исх можно по своему, но смысл в том что входящий трафик от провайдера _нельзя контролировать_. Я пробовал вешать HTB на инрерфейс локалки(eth1) чтобы регулировать входящий трафик, но должным обазом такая схема не работает. IMQ решил вопрос.

http://gazette.linux.ru.net/rus/articles/taleLinuxTC.html

[rus-p]

Спасибо

Насколько я понял из Вашего поста, Вы привели схему управления трафиком для организации у которой на eth0 соединение с провайдером, на eth1 - локалка.

Суть не меняется. Почему у Вас не получилось управлять Вашим входящим от провайдера трафиком, вешая HTB на eth1?

Ведь алгоритм работы этого HTB (при привышении срабатывает аналог TBF), это позволяет.

[edo]

проблемы возникают, когда на компьютере есть локальный трафик. применительно к интернет-шлюзу - proxy и smtp например

[mike_k]

проблемы возникают, когда на компьютере есть локальный трафик. применительно к интернет-шлюзу - proxy и smtp например

Это не самая большая проблема.

 

Для случая локалки, шлюза с NAT и статическими адресами могу кинуть чудесно работающий скриптец. В конфиге описываем полосы, RATE, CEIL для групп адресов, безлимиты, остальных... (есть пара ограничений на адресное пространство из-за ограниченного числа индексов в iproute2/tc) Шейпим исходящий от клиента в сторону тырнета по iptables mark, приходящий (но пришедший к клиенту из вне помечаем так же) по dst ip. Трафик к/от самого шлюза - в отдельную полосу. Тут особых проблем нет.

 

Проблемы с ppp-сессиями (адреса которых никак не зависят от адресов eth-интерфейсов) порождали непредсказуемое поведение в случае использования локального ip в качестве критерия отбора в моем случае... тоесть оно то шейпится, то нет, то не совсем так как надо... Логически это в голове не укладываось - вот и подумал о выделенной машине, работающей в режиме бриджа:

чтобы адрес шлюзa по умолчанию не менять

бриджу наплевать на ppp сессии - он просто шейпит по ip

 

http://forum.nag.ru/index.php?showtopic=29708 Но что-то дело не движется =(

[rus-p]

Проблемы с ppp-сессиями (адреса которых никак не зависят от адресов eth-интерфейсов) порождали непредсказуемое поведение в случае использования локального ip в качестве критерия отбора

Вот тут не понял, какого локального IP?

 

При поднятии сессии на сервере мы его конечно имеем в скрипте ip-up.local, но зачем он нам. Ведь нам нужен как раз remote IP (т.е. клиентский), его мы тоже имеем в момент поднятия тоннеля. И его как раз хочется использовать в качестве "критерия отбора" в u32 или MARK в iptables.

 

Насчет локального трафика полностью согласен, это не проблема, коли есть фильтр на IP.

 

А что можно сказать по поводу организации кучи очередей в ядре при ~1000 сессиях, нужно ли применять хеширование? Когда исходящий вешается на на eth понятно нужно, а когда шейпим входящий поинтерфейсно (pppX), ядро сразу прыгает на нужную очередь или все в цепочке и также необходимо хеширование?

[mike_k]

 

Проблемы с ppp-сессиями (адреса которых никак не зависят от адресов eth-интерфейсов) порождали непредсказуемое поведение в случае использования локального ip в качестве критерия отбора

Вот тут не понял, какого локального IP?

 

При поднятии сессии на сервере мы его конечно имеем в скрипте ip-up.local, но зачем он нам. Ведь нам нужен как раз remote IP (т.е. клиентский), его мы тоже имеем в момент поднятия тоннеля. И его как раз хочется использовать в качестве "критерия отбора" в u32 или MARK в iptables.

Я и имел в виду клиентский. (локальным его обозвал, ибо планируется некоторым клиентам реальные ip раздавать; пока все статические, без ppp*)

У меня получалось, что оно некорректно шейпит, если это ppp-сессия.

 

Про хеширование толком не скажу. У нас узверей не так много... Но где-то были интересные трюки на эту тему.

[Pe3ucTop]

rus-p :

Hash sobstvenno takzhe kak i TC rabotajut na interfeisah, poetomu vse pppX v odnu strukturu ne zapihnut', i hash ne sdelat' (esli rasmatrivat' traffic k klientu i bez IMQ).

Ishodjashij trafik mozhno sheipit' na ishodjashem v net interfeise za iskljucheniem sluchaev s NAT-om t.k. vse kto za NATom vyhodjat s odnoi IP i sheipitsja budet tol'ko ona..

Ja posovetoval by ispol'zovat' IMQ t.k. ves' trafik pppX mozhno tuda zapihnut' i uzhe na IMQ interfeise sheipit' traffik v obe storony i uzhe bazirujas' na IP i s ispol'zovaniem HASHa.. a o IP na pppX interfeisah mozhno i ne zabotitsja.. :)

[rus-p]

Сенкс. Действительно, не запихнуть, не додумал сразу.

[desperado]

а мануалы только дураки читают, мы не такие.