Shaping in Linux (vlan + nat + in/out)?

Question

linux

I know that a huge number of articles have been written about this, but unfortunately so far they have not brought clarity to all of them. =(
There is a linux router (in a small home provider, distro - gentoo), distributing the Internet to 150+ users.
It is necessary to provide speed limits both in and out for users according to their tariffs.
Each house has its own vlan, then all these vlan- You come to the router.Output is one eth interface to the Internet.All users sit behind nat.The
scheme is as follows:
{vlan1,vlan2,...,vlann}eth0 => (pc-router)[nat] =>
eth1 limit the speed of both incoming and outgoing for each of the users according to his TP
Do not offer: Diversity among different cars, cisco.
You need to do it on one wheelbarrow. At least the fryakha copes with this task in another segment with a bang (I’ll switch to it if I still can’t master the shaper in Linux, but still I don’t want to give up so easily).
In theory, you need to make a virtual ifb interface, but I can’t figure out how to make friends with in + out + nat + vlan.

Answer 1

And what, exactly, is the problem? Mark through iptables in mangle::FORWARD, after which the usual HTB on vlan* and eth1, drive traffic through filter fw acc. classes.
You will shape the outcome from the interface accordingly. NAT is absolutely not a hindrance since traffic coloring occurs before it.

Answer 2

Frankly speaking, the shaper in ipfw is MUCH more convenient than iproute2, so it’s quite possible to switch to a fryaha is the right decision ... Although it’s a Linuxoid itself, it’s all the same.

Answer 3

Shaper in Linux is harsh. The tc syntax only contributes to this. Especially if you need to honestly split the incoming bandwidth, I don’t know a simple native way to do this. Only with crutches in the form of IFB or IMQ, better than IFB, it is ideologically correct, and even it seems that there is no need to patch the kernel and iptables. Outgoing traffic (going from the router to users in the wilans) I would shape directly on their network interfaces. Incoming from users labeled and wrapped in IFB. The HTB class tree is hung on the IFB and users get each on their own leaf (leaf) by brand filters. I have traffic redirected with this wonderful command
$TC filter add dev $VLAN parent ffff: protocol ip prio 1 u32 match u32 0 0 flowid 1:1 action ipt -j MARK --set-mark $VID action mirred egress redirect dev $IFB
In short, put a freebie there, if you understand it, it will be easier for you and more reliable for users