Jump to content
Калькуляторы

Работа с шейпером в linux Работа с шейпером в linux

Надоели юзвери в попытках положить канал торрентами...

Захотелось придумать решение на основе шейпера под линукс.

Решение: дать ICMP, www, smtp наибольший приоритет, а оставшимся портам всё остальное.

Условно, канал 100 мегабит

Путём ковыряния документации вышло следющее:

eth0 - внешний интерфейс

eth1 - внутренний интерфейс

зы: ессно между ними нат.

# clean shaper

tc filter del dev eth1 parent 1: prio 1

tc qdisc del dev eth1 root handle 1: htb

tc filter del dev eth0 parent 1: prio 1

tc qdisc del dev eth0 root handle 1: htb

# install shaper

# download rules

tc qdisc add dev eth1 root handle 1: htb default 20

tc class add dev eth1 parent 1: classid 1:1 htb rate 100mbit

tc class add dev eth1 parent 1:1 classid 1:20 htb rate 50mbit prio 2

tc class add dev eth1 parent 1:1 classid 1:30 htb rate 100mbit prio 1

tc qdisc add dev eth1 parent 1:20 handle 20: sfq perturb 10

tc qdisc add dev eth1 parent 1:30 handle 30: sfq perturb 10

# ssh, www, smtp

tc filter add dev eth1 parent 1:0 protocol ip prio 10 u32 match ip sport 22 0xffff flowid 1:30

tc filter add dev eth1 parent 1:0 protocol ip prio 10 u32 match ip sport 25 0xffff flowid 1:30

tc filter add dev eth1 parent 1:0 protocol ip prio 10 u32 match ip sport 80 0xffff flowid 1:30

# ICMP

tc filter add dev eth1 parent 1:0 protocol ip prio 10 u32 match ip protocol 1 0xff flowid 1:30

# upload rules

tc qdisc add dev eth0 root handle 1: htb default 20

tc class add dev eth0 parent 1: classid 1:1 htb rate 100mbit

tc class add dev eth0 parent 1:1 classid 1:20 htb rate 50mbit prio 2

tc class add dev eth0 parent 1:1 classid 1:30 htb rate 100mbit prio 1

tc qdisc add dev eth0 parent 1:20 handle 20: sfq perturb 10

tc qdisc add dev eth0 parent 1:30 handle 30: sfq perturb 10

# ssh, www, smtp

tc filter add dev eth0 parent 1:0 protocol ip prio 10 u32 match ip dport 22 0xffff flowid 1:30

tc filter add dev eth0 parent 1:0 protocol ip prio 10 u32 match ip dport 25 0xffff flowid 1:30

tc filter add dev eth0 parent 1:0 protocol ip prio 10 u32 match ip dport 80 0xffff flowid 1:30

# ICMP

tc filter add dev eth0 parent 1:0 protocol ip prio 10 u32 match ip protocol 1 0xff flowid 1:30

 

Для того чтоб дополнительно ограничить по скорости некоторых клиентов - я маркирую их в iptables и обрабатываю в шейпере по примеру подобного:

 

# download

tc class add dev eth1 parent 1: classid 1:100 htb rate 1024kbit burst 12k

tc filter add dev eth1 protocol ip parent 1:0 prio 1 handle 100 fw flowid 1:100

tc qdisc add dev eth1 parent 1:100 handle 100: sfq perturb 10

# upload

tc class add dev eth0 parent 1: classid 1:100 htb rate 1024kbit burst 12k

tc filter add dev eth0 protocol ip parent 1:0 prio 1 handle 100 fw flowid 1:100

tc qdisc add dev eth0 parent 1:100 handle 100: sfq perturb 10

 

Так вот, ограничение по скорости коиентов - работает на ура.

Но канал по приоритетам не делится... может я где не прав?

Share this post


Link to post
Share on other sites

Возможно лучше будет иное решение:

http://l7-filter.sourceforge.net/

Там есть так же примеры, как выявлять торренты. Далее делать можно все что угодно.

Share this post


Link to post
Share on other sites
л7 разве работает?...
у меня - да, на 2,6,27

но вообще зависит от протокола по моему...

Share this post


Link to post
Share on other sites
л7 разве работает?...
А чего ему не работать? На этом многие компании зарабатывают очень хорошие деньги.

А если l7-filter использовать в связке с http://www.ipp2p.org/, то ещё лучше работает :-)

Тут важно помнить 2 особенности:

1. Шифрованный трафик классифицировать нельзя

2. Любой анализ на 7 уровне это, прежде всего, возрастание нагрузок на процессор.

Edited by NoFate

Share this post


Link to post
Share on other sites

Подскажите пример правил в линкусе. Задача: ничего шейпить и резать не нужно. нужно только приоритет трафика, т.е. что бы icmp в первую очередь обрабатывались, ssh, telnet во вторую, www в третью, pop-smtp-imap в четвертую, а все остальное потом :)

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

 

на маны ссылать не нужно, читал, не все понял. живой пример бы очень помог.

Share this post


Link to post
Share on other sites

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

 

- жестко закрывать, заставляя использовать статические порты и их деприоретизировать,

- пересматривать свою ценовую политику, ибо если вы клиенту продаете 2 мегабита - будьте добры - не нужно разграничивать что это 2 мегабита на веб, 512к на торренты и все такое..

 

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

Share this post


Link to post
Share on other sites

А я считаю оба варианта неправильными в отдельности

 

1)Создать более дорогой тариф, как альтернативу

2)Тот который приходится лимитировать - описать по возможности, что дешевый сыр только в мышеловке, и если вам "много надо" - ваш тариф более дорогой.

 

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this