tc & match ip

Ага, внимательно почитав lartc.org/howto

понял что мне скорей всего надо смотреть в сторону «The route classifier» и u32 match ip.

то есть должно быть что-то типа такого:

tc filter add dev eth1 parent 1:0 protocol ip prio 100 route from 2 u32 match ip dst xxx.xxx.xxx.xxx сlassid 1:2

В правильном направление гляжу?

Нифига, match и route нельзя юзать одновременно.

Так что проблема остается открытой: как резать инет-трафик, не трогая локальный трафик и при этом не юзать маркировку через iptables

Заюзать route classifier как советовали либо сделать весь шейпинг на eth0(upload)+редирект download c eth0 на ifb0 + шейпинг на ifb0 downloadа, при этом локальный трафик просто не будет попадать на интерфейс где шейпинг.

А вот такой вариант может проконать?

Навеяло когда прочитал про хэш-фильтры.

Сначала поймать фильтром по route classifier, направить в хэш-таблицу и там уже разбирать по match ip?

Правильно ли я понял, что в tc можно делать вложенные условия?

Типа если пришел с того роута, то иди проверься в том фильтре. В том фильтре проверился иди либо в следующий фильтр, либо раз не подходишь под условия свободен ( и т.д.)

или я не правильно понял прочитанный материал?

Правильно понял, вложенные условия и реализуются таблицами.

Ок. спасибо. Буду возиться с реализацией, если пол... КОГДА все получиться отпишусь =)

Короче забороть проблему, как хотелось, не получилось.

Направить пакет по фильтру route не получается (он сразу этот трафик к классу какому то только привязывает, а не может отправить в какою нить хеш таблицу), то есть опять же проблема все таже либо весь трафик, либо ни какой...

З.Ы. Немного пофантазировав пришел к идее: замаркировать локальный трафик через iptables и в tc его ловить и кидать в «неограниченный» канал (при попадание в фильтр, он же дальнейшие фильтры проверять не будет)... а инетовский трафик ловить с помощью хеш-фильтров и резать как надо. (через опу, но работать должно, осталось проверить будет ли это работать быстрее чем текущая схема)