How do I slice my WAN connection in two and prioritizing traffic in each part?

I've got a 100/10 (down/up) mbit line and I want to slice it into two parts: 80/9 and 20/1. Each part will go to a different switch and several machines will be behind each switch. So it will effectively become two separate networks.

There will be people doing gaming, VoIP, streaming, browsing, BitTorrent, etc, in each network and as I understand it gaming and VoIP need prioritization so as not to lag, so I'd like that too.

Additionally, it would be really nice if the (or a) WiFi SSID got attached to the first network and abide by its limits.

Can all this be done with OpenWRT?

If yes, what's the term for the things I want to do? Would be nice to first read about them in general, and then see how can they be achieved with OpenWRT.

When one of the networks is idle or uses only part of its share, do you want to donate the bandwidth to the other network (perhaps up to the full 100/10), or would you consider the slices as hard limits?

How did you arrive at this particular bandwith split? 20/1 is quite asymmetric, and 1 Mbit/s is quite slow.

How about Video telephony?

Yes, I believe this is possible. There may even be a solution that prioritizes gaming and VoIP automatically, without explicit configuration: SQM with cake. Start with a single instance (no bandwith split) and run the DSLreports speed test when the network is otherwise idle. Post the results here for discussion if you want.

The term for the bandwidth limitation is "traffic shaping". Cake does this, and more.

Which make and model is your OpenWrt router? This will give me an idea of its CPU performance.

Ideally yes. But I'm okay if it doesn't.

This is a personal matter. Will it make a difference in the technical aspect of the question?

I thought it as equivalent to VoIP (albeit requiring more bandwidth) so I didn't include it. Is it any different?

I haven't bought it yet for this exact reason: I don't know what kind of CPU performance I'll be needing.

Would you like to recommend a router? If yes, here is some info.

Right now I have a 100mbit line and a router that can take care of that would be fine. But if the price is not astronomical, it would be nice to have room for future expansion, lets say 200, 250, or 300mbits. It would also be nice if I could get the router from my local market (and not order from abroad). There are quite a few AVM Fritz!Box routers on the local shops the 7530 and 7490 can take OpenWRT.

The Fritz!Box 7490 is not yet supported by OpenWrt, and its SoC is underpowered anyway (~50 Mbit/s with SQM enabled).
The 7530 looks like a good choice to me, but you will pay for features you cannot use, such as the xDSL modem. No matter if your link is cable or xDSL, you will need a separate modem in any case.
Another option could be the Fritz!Box 4040 or other routers with an IPQ40xx SoC.

I suggest not to buy an overpowered router now, unless you plan to upgrade your bandwidth in the near future. This forum also has some benchmarks.

Well, that's the point. VoIP uses much less than its fair share and is prioritized automatically by fq_codel or cake, but the high bandwidth requirement of Video does not allow that. It could still work well without prioritization when enough bandwidth was available, and latency well controlled. On the other hand, prioritization cannot make up for a lack of bandwidth, and it carries the risk of starving other services if done wrong.

I wanted to know if there were any requirements these numbers stem from. In this case, I would have looked for a solution meeting these requirements that did not rely on such drastic limits.
But apparently, this is purely a policy decision.

I suggest to upgrade your 10 Mbit/s uplink rate if possible, and to reconsider your choice of 1 Mbit/s.

I suggest to build up the configuration in multiple steps.

  1. Set up SQM with cake on the wan inferface and check the result using the DSLreports speed test. If done right, it will decrease the network latency and result in equal bandwith sharing between network flows. Note there is also a second wiki page with SQM details. It is not strictly necessary, but the Per-Host Isolation could be quite useful in your busy network. The result will be equal bandwith sharing between hosts, which helps to fence in protocols with many flows, such as BitTorrent.
  2. Note the download and upload speeds configured for SQM. Calculate the shares according to your policy. Remove the cake instance from wan and add two cake instances, one to each lan interface (say, br-lan and br-lan2). Configure the bandwidth shares, but be sure to swap the Upload and Download values. Test again. The result should be like 1. but adhere to the desired bandwith split. Sharing of unused bandwith is not possible yet, and traffic between the two LANs is subject to the bandwidth limits, which may not be desired.
  3. This will be an advanced configuration beyond the capability of sqm-scripts, and maybe beyond my own capability as well. It requires manual configuration - refer to the Linux Advanced Routing & Traffic Control HOWTO for details, and the tc documentation. The HOWTO is a bit outdated, but could still help you get started.
    Disable sqm-scripts. For each direction (up/down), set up one classfull qdisc (e.g. HTB, HFSC) which is shared by both LANs. For each LAN, add a class with the desired bandwidth limit, allowing bandwidth sharing. Add cake (without bandwidth limit) or fq_codel as the leaf qdiscs. Set up tc filters to assign traffic to the classes, perhaps based on the LAN IP addresses.
    You may have noticed that I avoided mentioning particular interface names where the qdiscs are attached. The reason is that I am not sure which is best. Applied to the WAN interface like 1., it may not be possible to use the LAN IP addresses as the filter argument because of NAT. When applied on the LAN side like 2., traffic for both LANs must be somehow sent through a single interface, for which I don't have an easy solution either.

That's all I can say for now. Let me know if I should fill in more details somewhere.
If you want to go with step 3 (qdisc hierarchy), we could try to find other forum members who can improve my sketch of a solution.

Because OpenWRT doesn't do "dialing"? Maybe I could use the ISP router-modem as "input"?

I see that 7530 and 4040 have the same CPU and RAM, and the only difference beeing the flash memory. The 4040 is veeeery cheap! This sounds very good. I can also find a refurbished x86 mini PC, which will probably have better performance.

So, in other words, the only thing I can do for Video is to limit the other traffic (web, torrent, etc), yes?

Perhaps there is a way to tell the router, that when it detects Video to give it as much bandwidth as the Video requests?

Also, Video traffic is UDP, yes? What if I put a global rule to prioritize all UDP traffic?

I don't understand this.

Is step 3 necessary for what I want to do, or is it optional?

Some more questions:

  • Is cake better than simple SQM? This whole process sounds borderline to what I can handle and I'm considering off-the-self solutions that have just FQ-CODE (in addition to Basic Queue and Advanced Queue).

  • Can a computer with 1 or 2 LAN ports do the task I want?

No, that's not the reason. Which kind of link do you have: xDSL, cable, ...?

Yes. This works best when it is set to bridge mode, and OpenWrt is the only router with NAT.

With regard to network throughput, I doubt that performance would differ, it is limited by the 100/10 line speed. For other measures of "better", I guess it's a good idea to run your own experiments.

Yes, that's the idea. Or provide more bandwith.

This will cause other services to fail unless they still are allowed to use a small amount.

I suggest to look for a solution without explicit priorities first.

You probably want:

  • WAN<->LAN: 9 Mbit/s <--> 80 MBit/s
  • WAN<->LAN2: 1 Mbit/s <--> 20 MBit/s
  • LAN<->LAN2: unlimited (wire speed)

After step 2, you get instead:

  • WAN<->LAN: 9 Mbit/s <--> 80 MBit/s
  • WAN<->LAN2: 1 Mbit/s <--> 20 MBit/s
  • LAN<->LAN2: 1 Mbit/s <--> 9 Mbit/s

I imagine this problem could be fixed using some of the tools from step 3.

The solution in step 2 is OK if there is no traffic between LAN and LAN2, and the sharing of unused bandwith is expendable. Otherwise, a different solution is needed. Step 3 sketches one such solution (still incomplete), and there might be others.

For simple configurations, I consider cake an improvement over fq_codel plus a separate shaper.
Your bandwidth policy calls for an advanced configuration, where the answer may not be so clear-cut.

Yes, if you add a managed switch, which could also be provided by any OpenWrt router with a built-in switch.

I've got VDSL2. And I just found out that if I want the ISP's VoIP to work I have to use my ISPs router for dialing and then bridge to the OpenWRT router.

Ok. I can try that and see if it becomes a problem. What's this setting called in OpenWRT?

Good idea to keep the ISP router for now.
However, most such devices do not support bridging mode and VoIP at the same time, but instead work as a router with NAT and serve private IPv4 addresses via DHCP on their LAN side when VoiP is in use. This may be undesired, but does not have to be a problem.

You asked why the VDSL2 modem must be separate from the OpenWrt router:
The SoCs with xDSL modems which are supported by OpenWrt are too slow to handle routing and traffic shaping at 100 Mbit/s. Separate devices allow you to choose more powerful hardware for the OpenWrt router.

I use SQM with cake, which does not have such settings, but assigns the priorities dynamically, and I am happy with its performance for my use. There are other traffic shaping solutions in OpenWrt; I haven't investigated whether they provide such options.
It is surely possible to configure per-service bandwidth allocations with tc, but this may result in a complex solution, and I will not be able to assist much there.

Recently, I came across the following topic, where a problem similar to your initial question was discussed:

It may not be applicable to your case directly, but some of the opionions given there could still be interesting.