为什么这个“tc filter”规则没有按预期对流量进行分类?

为什么这个“tc filter”规则没有按预期对流量进行分类?

我正在尝试配置一些基本的流量分类,以将本地网络中每台机器的最大入口带宽限制为 3 Mbps。我正在操作网关 192.168.2.1,其中接口eth1连接到交换机,为 处的主机提供 Internet 连接192.168.2.0/24

分类很简单:入口流量分为两类,第一类1:20是默认的未分类流量作为后备,第二类1:30将入口带宽限制为 3 Mbps。然后我使用 将tc filter来自每个主机的流量分类为 类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

但是,规则并没有按预期发挥作用。主机的下载速度仍然是 中指定的较高带宽1:20,而不是1:30。我的错误是什么?

答案1

你的内核版本是什么?

我正在尝试配置类似的东西,并强烈感觉到内核 debian 4.15.0-23-generic 有问题。问题不在于 HTB 本身,而在于对数据包进行分类,以便获得正确的 classid 流。

甚至这个教育示例也失败了:

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

什么时候

tc -s -d filter show dev int0

你看,所有数据包都正确通过了 1:13

但如果你这样做

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

工作方式很奇怪,每隔几分钟只有几个数据包按预期运行,其他仍然通过默认方式运行

下一个尝试分类的例子:

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

工作原理相同(从统计上看,似乎比前面的例子有更多的数据包正确通过)

日志中没有错误或警告,只需像这样工作

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

这里有一些内核网络开发人员?

我会在报告之前尝试其他版本:)

答案2

tc 正在对上传进行操作。因此,如果您想要调整入口流量,则必须在 lan 接口上设置规则。

假设这就是您正在做的事情,您的规则应该匹配目标 192.168.2.0/24,而不是源。

相关内容