[SokolovS]

ты не понял, если как в доках у всех правил prio 5, то удаляются все и не важно, что тарифы раз в сутки меняются, может кто-то из клиентов любит выключать свой инет через личный кабинет при выключении компа, тогда настаёт трындец абсолютно всем правилам. чтобы реплейс сделать, тоже надо хэндл вычислить, иначе как указать какое правило заменить? либо как у меня счас через разный prio.

 

Если НАТа нет, то я бы раскидал правила по интерфейсам так: http://forum.nag.ru/forum/index.php?showtopic=47674

у меня так и было, просто начал проводить эксперименты на этой неделе, ищу наилучшую конфигурацию. сегодня утром вернул обратно на оба интерфейса, но через u32, т.е. отказался от ингресс. нагрузка ничуть не изменилась. тут не сказывается, htb это или простой полисер, жрёт процессор исключительно u32. буду хеширование делать. вот только думаю, не скажется ли то, что у всех правил разный prio указываю, т.е. насколько я понял это порядок просмотра правил, а они в разные таблицы будут вставляться?

У фильтра prio это порядок просмотра, внутри таблицы, по сути неважно, т.к. в одной таблице не будет много фильтров. Я вот только не понимаю зачем разные prio, у вас что правила дергаются на каждое подключение/отключение? А вот с prio в классх следует быть осторожнее, т.к. это приоритет трафика!

Изменено 15 марта, 2009 пользователем SokolovS

[Max P]

для удаления одного правила из фильтра нужно обязательно полный хендл указывать, у меня сейчас без ветвления выглядит примерно как 800::user_id, юзер_ид ессно в 16ричном виде вычисляется, если при удалении указывать полностью - то удаляется нормально, с хэшированием пока не получилось сделать что то ввиде 2:2b:user_id

[Max P]

кстати, со схемой хэширования у меня дефолтовый трафик перестает работать, видимо уходит в таблицу по hashkey 10.0.0.0/8, не находит там нужного айпишника и там остается, у кого нить еще такие проблемы есть?

[Max P]

чтобы не вычислять хэндл каждый раз - можно его задавать сразу самому :) например шаблон:

 

tc filter $JOB dev $ROOTDEV protocol ip prio 2 parent 1:0 handle 2:$LASTNUM_CLIENT_IP:$RULE_ID u32 ht 2:$LASTNUM_CLIENT_IP: match ip dst $CLIENT_IP/32 flowid 1:$RULE_ID

 

и при удалении просто указывать данный handle - удалится только это правило

[BETEPAH]

Я вот только не понимаю зачем разные prio, у вас что правила дергаются на каждое подключение/отключение?

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

чтобы не вычислять хэндл каждый раз - можно его задавать сразу самому :) например шаблон:

пробовал и так тоже, тогда tc не принимает правило, пришлось сделать небольшой костыль, на включение стандартно:

$tc filter add dev eth0 protocol ip parent 1: prio 5 u32 ht 2:${iphex}: match ip dst ${3} flowid 1:${2}

а на выключение:

handle1=`tc filter show dev eth0 | grep "1:${2}" | awk -F" " '{ print $10 }'`
$tc filter del dev eth0 protocol ip parent 1: prio 5 handle ${handle1} u32 match ip dst ${3} flowid 1:${2}

 

сегодня всю ночь делал хеширование, как обычно не обошлось без подводных камней, но первые результаты радуют, посмотрю, что будет в ЧНН

Изменено 16 марта, 2009 пользователем BETEPAH

[SokolovS]

Я ушел от модели "дергать tc при подключении/отключении". Правила обновляюстя полностью раз в 4 часа, этого достаточно.

[Jugernault]

точность правда невысокая, но мне это и не требуется и путём экспериментов выяснил, что надо burst вычислять, должно быть примерно 1/100 к rate

ну а насчёт нагрузки, вот график:

А у меня вопрос - использую пппое, на каждый ппп-интерфейс навешиваю HTB (4-8 классов) фильтрую по U32 + полисер ingress (4-8 шт), имеет ли смысл заморачиваться с хешами, имхо нет...

[Max P]

BETEPAH, у меня на удаление достаточно $tc filter del dev ${DEV} parent 1:0 protocol ip prio 2 handle 2:$LASTNUM_CLIENT_IP:$RULE_ID u32 и тогда всё замечательно удаляется, ессно prio и ht должно быть ваше

 

слушайте, а шейпер на влан-интерфейсе шейпит весь интерфейс или только свой указанный?

[BETEPAH]

дык я об этом уже выше говорил, что prio разный нужен и по нему замечательно удаляется, а тут, в случае хеша не всё так просто, если делать prio отличный от prio у хеш-таблицы, то получается ерунда и вот и приходится делать одинаковый prio и вычислять handle

 

про вилан и ппп ничего не могу сказать.

 

к вопросу ухода от марка к хешу u32, вот график, неделю назад - марк, в конце недели - u32 без хеша, сегодня - с хешем, но с не до конца оптимизированными правилами:

 

Изменено 16 марта, 2009 пользователем BETEPAH

[SokolovS]

2Jugernault: ты можешь не заморачиваться насчет хэширвоания, на про приоритезацию и QoS можешь забыть при таком подходе, весь тарфик на реальном физ. интерфейсе одинаков.

[Max P]

кто нибудь шейпит на влан-интерфейсах?

[Jugernault]

кто нибудь шейпит на влан-интерфейсах?

Нууу.... Подозреваю что я шейпит...

Только не совсем пойму суть вопроса - интересует щейпинг на eth0.2, eth0.3, eth0.4 или шейпинг на eth0 при наличии eth0.2, eth0.3, eth0.4?

 

2Jugernault: ты можешь не заморачиваться насчет хэширвоания, на про приоритезацию и QoS можешь забыть при таком подходе, весь тарфик на реальном физ. интерфейсе одинаков.

Понятно... QoS пока не актуален...

[Max P]

да всё, нашел свой косяк - на физическом eth0 остался висеть левый шейпер :) вот кстате по поводу хэшей еще статейку нарыл:

 

http://brownian.org.ua/?page_id=6

[Ivan Rostovikov]

U32 с хеш-фильтрами показал приличное быстродействие по сравнению с "витвистым" iptables.

В моем случае, я совсем перестал ощущать задержки.

 

Шейпирующий бридж.

2500 фильтров на каждый интерфейс.

поток 150 Мб/c

Xeon 2Г

 

Возможно задержки таки появятся с ростом потока.Отпишусь.