tc хэш таблицы

У вас там SNAT/MASQRADE случаем нет?

Есть конечно! Куда без них.

В конечном итоге совершенно не ясно как шейпить upload траффик? Куда хоть копать?

> Есть конечно! Куда без них.

шейпер срабатывает после iptables, поэтому все src-ip видны как один 192.168.0.2 - из-за этого в дефолтный класс весь трафик и валится. Сейчас Вам нужно посмотреть на

iptables -t mangle -A POSTROUTING <условия отбора> -j MARK <num>

то есть, маркировать трафик по условиям (src ip и т.д.), а в tc ловить эту маркировку и на её основе распихивать трафик по классам.

Тоже думал об этом. Когда за snatом висит 2000 машин производительность упадет ниже плинтуса.

шейпер срабатывает после iptables,

Подозревал это! Толи маны умалчивают об этом, то ли я не заметил.

Возможно ли tc заставить работать после между (mangle)postrouting и (nat)postrouting? Очень уж не хочется iptables сюда привинчивать

Не так уж и сильно просядет производительность если шейпинг будет через маркировку пакетов. По сравнению с u32 с 'tc filter' конечно просядет, но тот же u32 можно и в iptables заюзать - вроде модулёк был(если мне не изменяет склероз).

Но если так критична производительность, то сделайте двухуровневый
шлюз: через один траф проходит без НАТа - только шейпинг; через второй отшейпленное уже НАТирутся. Для ~2000 машин выделить одну самую слабенькую для НАТа думаю можно, а для шейпинга лучше помощнее машинку взять.

Если хочется решения на одном шлюзе (шейпинг сквозь НАТ), то придётся тупо мощь шлюза наращивать, чтобы взять числодробилкой.

Возможно ли tc заставить работать после между (mangle)postrouting и (nat)postrouting?

я не знаю такого способа.

Очень уж не хочется iptables сюда привинчивать

придётся :(. Или вторую машинку в каскад добавлять.

Видимо на первое время пользовать придется всетаки Iptables. В конечном итоге на upload не такая большая нагрузка идет, может и поятнет пока что. Спасибо за совет. Сам тоже думал, что так и придется поступать, но надеялся, что есть способ обойтись без iptables.

Можно входящий на eth1 трафик отправить в IFB и там и шейпить.

>Можно входящий на eth1 трафик отправить в IFB и там и шейпить.
А мана подробная есть? Я гуглил, но что-то ничего особо симпатичного не глянулось

$TC qdisc del dev eth0 ingress 2>/dev/null
$TC qdisc add dev eth0 ingress
$TC filter add dev eth0 parent ffff: protocol ip prio 10 u32 \
   match u32 0 0 flowid 1:1 \
   action mirred egress redirect dev $netif
interface ifb1

Скопипастил из гугла, у меня так работает. на ифб делай классы и фильтры для шейпинга. Иптейблс не нужно использовать, для 2000 машин при шейпенге 1 ип - один класс по сравнению с хештаблицами tc просядет конкретно. Сколько у вас трафика, и какое железо?

Железо - 2,5 2 ядерный ксенончик. Не сильно мощный. Сервак сейчас не под рукой. Конечно просядет! Я уж про преоритезацию молчу. Траффика 200 мегабит.90% загрузка.

что в

net.netfilter.nf_conntrack_max
net.netfilter.nf_conntrack_count
net.netfilter.nf_conntrack_buckets

Но так скажем, то собрали до меня и в «лобовую» ваерфолом. То что не тянет - естественно.

Сделал шейпинг через ifb. Класс. Очень хорошо. Но столкнулся с одним очень интересным явлением.
Я в таблице mangle держу несколько правил такого вида
/sbin/iptables -t mangle -A POSTROUTING -p tcp --sport 8000:8085 -j MARK --set-mark 12

Идейно маркирует пакеты выходящие из любого интерфейса. Сейчас их получается 4 штуки: eth0, eth1, ifb0, ifb1.
Сделаны они так:
modprobe ifb
ip link set dev ifb0 up
ip link set dev ifb1 up
service iptables restart

Но вот сюда пакеты не идут. Не ловит мышей...
/sbin/tc filter add dev ifb0 parent 4:0 protocol ip prio 3 handle 12 fw flowid 4:4
В свою очередь: tc -s class show dev ifb0 говорит:

class htb 4:4 parent 4:1 leaf 4: prio 4 rate 2000Kbit ceil 2000Kbit burst 1600b cburst 1600b
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
rate 0bit 0pps backlog 0b 0p requeues 0
lended: 0 borrowed: 0 giants: 0
tokens: 6250 ctokens: 6250

Почему 0? iptables не маркирует пакеты. Для проверки делаю так:
tc filter add dev ifb0 parent 4:0 protocol ip prio 4 u32 match ip dst 0.0.0.0/0 flowid 4:4

Счетчик начинает крутится. Где прикол?
Пробовал в PREROUTING. Эффекта 0

Соответственно попробовал так:
pkts bytes target prot opt in out source destination

0 0 MARK tcp  — * ifb0 0.0.0.0/0 0.0.0.0/0 tcp spts:8000:8500 MARK xset 0xb/0xffffffff
0 0 MARK tcp  — * ifb0 0.0.0.0/0 0.0.0.0/0 tcp dpts:8000:8500 MARK xset 0xb/0xffffffff

В прероутинге тоже 0, если ifb0 меняю на входящий

не идут потому что пакет приходит из сети на eth0 и action ingres mirred редиректит его на ифб, после шейперов на ифб пакет попадает в нетфильтр. Весь шейпинг на ифб обрабатывантся раньше. Вообще используйте как можно меньше иптейблс.

Спасибо. Что хотел сделать - сделал. Вроде получилось отлично. Написал фильтрами tc. Только повозиться пришлось с расчетом диапозонов портов через маски. Не хотел я это делать...

Напишите пожалуйста как в итоге выглядит последовательность правил.