tc for traffic shape and limit-rate

[heap]

Почитал по докам, по этому форуму в частности - много встречается упоминаний о колоссальной прожорливости u32 классификатора в iproute2. Да и при помощи oprofile гонял ядрышко и не раз в этом убеждался.

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

 

На данный момент, когда поднимается pppX (тунель - не важно для pptp или pppoe), на него навешивается шейпер на исходящий трафик и лимит рейт на входящий. Сам навес выглядит примерно так:

$tc qdisc del dev $DEV root

$tc qdisc add dev $DEV root handle 1 htb default 30 r2q 100

$tc class add dev $DEV parent 1: classid 1:2 htb rate $speed_out

$tc class add dev $DEV parent 1:2 classid 1:10 htb rate $speed_out

$tc qdisc add dev $DEV parent 1:10 handle 10 sfq

$tc filter add dev $DEV parent 1:0 protocol ip prio 100 u32 match ip dst $REMOTE_IP/32 classid 1:10

 

$tc qdisc del dev $DEV ingress

$tc qdisc add dev $DEV handle ffff: ingress

$tc filter add dev $DEV parent ffff: protocol ip prio 50 u32 match ip src 0.0.0.0/0 police rate $speed_in buffer 10k drop flowid :1

 

Как видим в обоих случаях приходится иметь дело с u32 - а когда из всех поднятых туннелей, почти на каждом висит такое, а объемы трафика с каждым днем растут - нужно придумать что-то более веселое. Что тут можно предпринять?

[Ivan Rostovikov]

Маркировать пакеты iptables ?

Тогда U32 ненужен...

[heap]

Маркировать пакеты iptables ?

Тогда U32 ненужен...

Тогда возникает иного плана вопрос - насколько эффективнее проверять метку на пакете? И как замаркировать входящий трафик, чтобы сделать лимит рейт? Получается придется на исходящем интерфейсе делать shape при условии, что такой интерфейс один.

Кроме того - возможно есть какой-то путь вообще ничего не проверять и заворачивать весь трафик? Ведь на pppX бегает трафика как правило только на одно направление (по крайней мере в данном случае) - вот его весь и надо шейпить не сверяя подробностей. Только как?

[DemYaN]

Если один ppp-интерфейс на пользователя, зачем его классифицировать по u32? Просто скидывать все в default-класс:

 

tc qdisc del dev $DEV root
tc qdisc add dev $DEV root handle 1: htb default 1
tc class add dev $DEV parent 1: classid 1:1 htb rate ${RATE}kbit quantum 1500

Можно заменить htb на tbf и посмотреть, какой из них больше кушает процессорного времени.

[heap]

Если один ppp-интерфейс на пользователя, зачем его классифицировать по u32? Просто скидывать все в default-класс:

 

tc qdisc del dev $DEV root
tc qdisc add dev $DEV root handle 1: htb default 1
tc class add dev $DEV parent 1: classid 1:1 htb rate ${RATE}kbit quantum 1500

Можно заменить htb на tbf и посмотреть, какой из них больше кушает процессорного времени.

Спасибо. Такая схемка завелась. А вот с police rate на входящий трафик убрать u32 не получилось. Когда убираю - трафик не лимитится. o_O Это пытались лечить?

Edited October 6, 2008 by heap

[user_anonymous]

ИМХО tbf будет кушать гораздо меньше ресурсов, чем htb, так как устроен гораздо проще.

Я тут кстати пишу пакет программулек, чтобы настройки tbf брать из базы (поддерживается только PostgreSQL) и рулить всем этим делом через веб-интерфейс. Вебморда пока недоделана до конца, но впринципе все уже работает. Будет желание попробовать - обращайтесь.

[heap]

ИМХО tbf будет кушать гораздо меньше ресурсов, чем htb, так как устроен гораздо проще.

Я тут кстати пишу пакет программулек, чтобы настройки tbf брать из базы (поддерживается только PostgreSQL) и рулить всем этим делом через веб-интерфейс. Вебморда пока недоделана до конца, но впринципе все уже работает. Будет желание попробовать - обращайтесь.

Попробовать интересные вещи никогда не лишне. :) А насчет из базы - у меня в некотором смысле пока так и происходит. В radius-reply приезжают параметры обжимки, а в ipup скрипте они применяются на ppp. Ну а радиус их уже тем или иным способом берет из базы - тут вариантов много.