1

I'm trying to configure some basic traffic classification to limit the maximum ingress bandwidth for every machine in my local network to 3 Mbps. I'm operating the gateway 192.168.2.1, where the interface eth1 is attached to a switch to provide Internet connection for hosts at 192.168.2.0/24.

The classification is simple: ingress traffic is classified info two classes, the first class 1:20 is for the unclassified traffic by default as fallback, the second class 1:30 would limit the ingress bandwidth to 3 Mbps. Then I use a tc filter to classify the traffic originated from every host as class 1:30.

# Clear the qdisc first.
tc qdisc del root dev eth1

# Set a HTB qdisc on the root, and use class 1:20 by default
tc qdisc add dev eth1 root handle 1: htb default 20

# Create class 1:1, limit the total ingress bandwidth to 8 Mbps.
tc class add dev eth1 parent 1: classid 1:1 htb rate 8mbit burst 15k

# Class 1:20
tc class add dev eth1 parent 1:1 classid 1:20 htb rate 5mbit ceil 5.5mbit burst 15k

# Class 1:30
tc class add dev eth1 parent 1:1 classid 1:30 htb rate 3mbit ceil 4mbit burst 15k

# Attach fq_codel w/ ECN on each class to control latency / bufferbloat.
tc qdisc add dev eth1 parent 1:20 handle 20: fq_codel ecn
tc qdisc add dev eth1 parent 1:30 handle 30: fq_codel ecn

# Match the LAN range and classify them as class 1:30
tc filter add dev eth1 parent 1: protocol ip prio 2 u32 match ip src 192.168.2.0/24 flowid 1:30

However, the rule doesn't work as intended. The download speed for hosts is still the higher bandwidth specified in 1:20, not 1:30. What is my mistake?

ConfusedUser001
  • 11
  • 1
  • 2

2 Answers2

2

Whats Your kernel version?

I'm trying to configure similar thing, and becoming to have strong feeling that kernel debian 4.15.0-23-generic is broken. Problem is not with HTB itself, but with classifying packets fo correct classid flow.

Even this educational example fails:

tc qdisc add dev int0 root handle 1:0 htb r2q 100000 default 13
tc class add dev int0 parent 1:0 classid 1:1 htb rate 10Gbit
tc class add dev int0 parent 1:1 classid 1:11 htb rate 1Gbit ceil 2Gbit
tc class add dev int0 parent 1:1 classid 1:12 htb rate 1Gbit ceil 2Gbit
tc class add dev int0 parent 1:1 classid 1:13 htb rate 1Gbit ceil 2Gbit

when do

tc -s -d filter show dev int0

You see, that all packets go correctly through 1:13

but if You do 

iptables -t mangle -A POSTROUTING -j MARK --set-mark 11
tc filter add dev int0 parent 1:0 protocol ip handle 11 fw flowid 1:12

works in strange way, only few packets every few minutes goes as expected, other still go through default

next example of try to classify:

ipset create SHAPER4 hash:net family inet skbinfo
ipset add SHAPER4 10.0.0.0/8 skbprio 1:12
iptables -t mangle -A POSTROUTING -j SET --map-set SHAPER4 src,dst --map-prio

works same (it seems that statistically more packets goes right than in previous example)

There is no errors or warning in logs, just work like this

tc -s -d class show dev int0

class htb 1:13 parent 1:1 prio 0 quantum 1250 rate 1Gbit ceil 10Gbit 
linklayer ethernet burst 1375b/1 mpu 0b overhead 0b cburst 0b/1 mpu 0b 
overhead 0b level 0
 Sent 74139067325 bytes 53655936 pkt (dropped 0, overlimits 48986938 requeues 0)
backlog 0b 0p requeues 0
lended: 41808373 borrowed: 11847563 giants: 0
tokens: -81 ctokens: -4

class htb 1:11 parent 1:1 prio 0 quantum 1000 rate 10Mbit ceil 100Mbit 
linklayer ethernet burst 1600b/1 mpu 0b overhead 0b cburst 1600b/1 mpu 0b overhead 0b level 0
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
lended:  borrowed: 0 giants: 0
tokens: 20000 ctokens: 20000

class htb 1:12 parent 1:1 prio 0 quantum 1000 rate 5Mbit ceil 30Mbit 
linklayer ethernet burst 1600b/1 mpu 0b overhead 0b cburst 1593b/1 mpu 0b 
overhead 0b level 0
Sent 4704 bytes 48 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
lended: 48 borrowed: 0 giants: 0
tokens: 37550 ctokens: 6247

Some kernel networking developer here?

I will try other versions before report it :)

Tomáš Šimek
  • 21
  • 3
  • The problems probably comes from the value you set for r2q. It is way too large. Generally you don't even need to set it, because the default value of 10 suits most setups. Setting it this high means most packets will get dropped, unless you have a whooping 150MBps connection to meet the MTU. – AdminXVII Mar 04 '19 at 11:07
0

tc is operating on upload. So if you want to shape the ingress traffic, you have to place the rules on the lan interface.

Assuming that's what you're doing, your rule should match destination 192.168.2.0/24, not source.

setenforce 1
  • 1,200
  • 6
  • 10
  • Clarification: eth0 is my WAN interface, eth1 is my LAN interface connected to an Ethernet switch to provide LAN for machines in the subnet `192.168.2.0/24`. So I don't think there is a problem here. – ConfusedUser001 Apr 13 '18 at 14:51
  • Try `tc filter add dev eth1 parent 1: protocol ip prio 2 u32 match ip dst 192.168.2.0/24 flowid 1:30` instead – setenforce 1 Apr 15 '18 at 09:58