2

I have a small engineering network with a Linux router, LAN nodes on the one side of the router, and a WAN link attached to the router. The WAN link is a 16mbit/s wireless channel, while the LAN nodes have 100mbit/s fast ethernet connections. The LAN nodes generate traffic, including commands and data. Commands are small packets (hundreds bytes) with 10-15 pps rate with a real-time need. Data is the other type with a few Mbps rate.

What I'm trying to do is to share the WAN link in a best way: high priority packets (commands) should occupy the WAN first, then everything else for other data.

So after I have read a lot of docs across the Internet I realized to organize kind of traffic management on the Linux router using tc and HFSC Scheduling in particular.

Now I think about next simple config:

# eth0 is the WAN link tc qdisc add dev eth0 root handle 1:0 hfsc default 20 # Define overall bandwidth tc class add dev eth0 parent 1:0 classid 1:1 hfsc sc rate 16mbit ul rate 16mbit # This class is for commands tc class add dev eth0 parent 1:1 classid 1:10 hfsc rt m2 16mbit # And this one is for everything else tc class add dev eth0 parent 1:1 classid 1:20 hfsc ls m2 16mbit ul m2 16mbit

And a filtering part: 

# This is for commands tc filter add dev eth0 parent 1: protocol ip prio 1 u32 match ip dst 224.0.0.0/4 flowid 1:20 # This is for everything else tc filter add dev eth0 parent 1: protocol ip prio 2 u32 match ip dst 0.0.0.0/0 flowid 1:10

And some tuning with SFQ as queue inside each class:

# tc qdisc add dev eth0 parent 1:10 handle 10: sfq perturb 10 # tc qdisc add dev eth0 parent 1:20 handle 20: sfq perturb 10

So using this config I expect that packets with commands should be processed as fast as possible with minimum delay. Is this config fine and complete or totally wrong?

Unfortunately I can't test this config on a production network before I'm sure that it will work.

Improve this question
0

1 Answer 1

Reset to default
1

I don't know the specifics of QoS configuration for your router or switch(es), but this is how QoS should work for the requirements you have described. You may be able to use this to come up with a configuration for your needs.

QoS is really several separate things working together, and your need is fairly common.

First, you should use shaping on the WAN port if the port's native line rate is higher than your CIR. For instance, if your WAN port is a 1 Gb ethernet port connecting to a device providing a 16 Mb path, shaping is in order. On the other hand, if the native line rate of the port really is 16 Mb, you don't need to shape. Shaping can be a little more complex than it first seems. Your CIR is 16 Mb. You should account for some protocol overhead, and if there are many small packets, you will need to account for more protocol overhead since smaller packets have a smaller payload-to-overhead ratio than larger packets. You should set a shape rate at some percentage of the CIR. You can narrow this down by traffic observation, and fine tune it later. This percentage may be as low as 80% or so, or it may approach 97% or 98%. It all depends on the protocol overhead of your traffic mix.

Next, you should identify and mark the various classes of traffic as close to the source of the traffic as possible. For instance, as traffic comes into the router, or, better yet, on the switch if it supports QoS marking. Mark traffic like the commands with a higher priority and ordinary traffic as best effort or various marking(s) that fit your needs. You can have multiple classes of traffic, each marked differently.

Finally, you get to queuing. You should create a priority queue for the priority traffic. This queue can have a guaranteed minimum bandwidth, or percentage of the bandwidth, and it can be served before any other queues. You assign the the traffic marked for priority to this queue. Create queue(s) for the other class(es) of traffic that you have identified and marked and assign to the respective queue(s). Other, multiple queues can have various bandwidths, or bandwidth percentages, assigned, but they may not necessarily be priority queues with guarantees.

Improve this answer
5
  • Thank you, Ron, for the detailed explanation. But I know this more or less. Seems like I should clarify my question a bit more. The network is pretty simple. Few nodes connected through not-smart fast-ethernet switch to the Linux router. Which is in the same time connected to the other network using wireless channel. The main thing is to deliver command packets with as lowest as possible delay even when wireless channel is on a heavy load. Commented Oct 4, 2015 at 19:17
  • I just didn't see anything in your configuration example to suggest that you were doing it in the proper phases. This sounds very similar to marking VoIP traffic as EF, but I don't see anywhere you are actually marking the IP packets (maybe on the switch), and then having the priority queue to see that the packets marked EF go first. You will probably have more luck asking on the Linux forum. Commented Oct 4, 2015 at 22:54
  • OK, I should update my question with a filtering part. Commented Oct 5, 2015 at 5:35
  • @AlexeyS., the 224.0.0.4/4 traffic is link-local multicast that should be blocked from being forwarded off the link on which it originated. Commented Oct 5, 2015 at 19:34
  • My bad, should be just <code>224.0.0.0/4</code> defining all multicast traffic. Thank you for the tip. Commented Oct 6, 2015 at 4:58

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.