The best solution would probably be to run PCQ download (from Internet to user) on MTK1 - that way traffic gets thrown away on ingress and doesn’t take up bandwidth on the backbone when you’re just going to throw it away later. PCQ upload (from user to Internet) should be on MTK2 and MTK3 - again close to ingress.
The easiest scalable scheme is probably to assign either static IPs or DHCP/PPPoE address pools via RADIUS (the pool names, of course, scale a lot better - if User Manager can do that. Other RADIUS servers can). Then summarize the address space as appropriate and use it to identify service levels. For example, 64k/512k gets addresses from a pool that can be summarized as 10.1.0.0/24, 128k/1m gets addresses from a pool that can be summarized as 10.1.1.0/24, and so on. That way you can identify service level by source/destination IP throughout the entire network.
Alternatively you can also come up with a way to mark packets with DSCP when they enter the Internet or customers routers (which is carried in the IP header between routers). Then you can, on each router, mark the connection based on the DSCP value of a packet, and from there apply packet marks bidirectionally and make queuing decisions. That’s the big boy way of doing it, but it’s also a lot more involved and complicated.
Ok. I can set a pool name in usermanager.
For ex. user1=pool_1m, user2=pool_2m… and so.
And now, in every router, ip pools:
For 1024k up - 256k down
-----------------------------
pool_1m:
MTK2 - 10.11.0.0/24
MTK3 - 10.11.1.0/24
For 2048k up - 512k down
-----------------------------
pool_2m:
MTK2 - 10.12.0.0/24
MTK3 - 10.12.1.0/24
Correct ?
Now, in theory, i can track user from src-address.