Linux下使用tc限制接口带宽

Linux下使用tc限制接口带宽

我有一个 Linux 路由器,它外部有一个 10GBe 接口,内部有绑定的千兆以太网接口。

我们目前的预算是 2GBit/s。如果一个月内平均超出该费率 5% 以上,我们将支付整个 10Gbit/s 容量的费用。从美元角度来看,这是一个相当大的进步。

所以,我想在 10GBe 接口上将其限制为 2GBit/s。

TBF 过滤器可能是理想的,但这个评论值得关注。

在除 Alpha 之外的所有平台上,它都能够塑造高达 1mbit/s 的正常流量,具有理想的最小突发性,并按照配置的速率准确发送数据。

我是否应该使用 TBF 或其他过滤器将此速率应用于接口,以及如何操作。我不明白这里给出的示例: 交通管制指南

特别是“示例 9. 创建 256kbit/s TBF”

tc qdisc add dev eth0 handle 1:0 root dsmark indices 1 default_index 0
tc qdisc add dev eth0 handle 2:0 parent 1:0 tbf burst 20480 limit 20480 mtu 1514 rate 32000bps

256K bit/s 速率是如何计算的?在此示例中,32000bps = 32k 字节/秒。由于 tc 使用 bps = 字节/秒。我猜突发和限制会发挥作用,但您如何选择合理的数字来达到所需的速率?

这不是错误。我测试了一下,结果给出的速率接近 256K,但并不完全是这个数字。


编辑

经过大量阅读和测试后,我得出结论,TBF 不合适,因为涉及带宽。无论我尝试哪种设置,我都无法让 TBF 提供 > ~50Mbit/s 的带宽。根据 lartc.org/lartc.pdf,RED 方法更适合调整 > 100Mbit/s 的带宽,因此我将尝试使用该方法。

但是,选择 min 的值(即,标记成为可能的平均队列大小)。给出的示例如下:

您应该通过计算您希望的最高可接受基本排队延迟并将其乘以带宽来设置最小值。例如,在我的 64kbit/s ISDN 链路上,我可能希望基本排队延迟为 200ms,因此我将最小值设置为 1600 字节。

  1. 您将如何选择最高可接受的基本排队延迟?示例为 64kbit/s。

  2. 对于 2Gbit/s 来说什么是可以接受的?

答案1

  1. 您应该根据流量类型选择可接受的排队延迟。

    • 例如,对于语音来说,排队超过 200 毫秒就已经是一个问题了。
    • 而对于 ftp/torrent 流量来说,拥有 500ms 的缓冲区根本不是一个大问题。
  2. 排队延迟/策略是流量类型的问题,而不是接口速度的问题。例如,VOIP 可能根本不应该排队。不幸的是,tc RED 文档不是很清楚,您最好阅读 Juniper/Cisco 网站上的一些 RED 信息,并将这些知识应用于 tc。

答案2

256K bit/s 的速率是如何计算的?在此示例中,32,000bps = 每秒 [32,000] 字节。

是的,那里的计算是正确的。如果您看到的数字接近 256k,则可能略低一些。您从哪里测量该数字?如果是浏览器的下载或类似的东西,它们不会计算数据包标头的开销,而是tc计算所有内容。

答案3

根据我的经验,qdisc TBF 可以轻松将带宽限制为 1 Gbps,因此我猜它也会扩展到 2 Gbps。但是,您可能需要一个真正的 CPU 来完成这项工作,而不是一些低端边缘路由器。像 4 GHz i3 这样的处理器肯定就足够了。

尝试类似

tc qdisc add dev "$DEV" root handle 1: \
  tbf rate "$UPLINK_RATE" burst "$UPLINK_BURST" latency "$TBF_LATENCY"

在哪里

DEV="$(ip route | grep "^default " | grep -Po "(?<=dev )[^ ]+")"
UPLINK_RATE="2000Mbit"
UPLINK_BURST="6500"
TBF_LATENCY="14ms"

请注意,要使用低延迟 TBF,您可能需要运行 PREEMPT 内核(例如 Ubuntu linux-lowlatency-hwe-*包),否则系统可能无法处理所有这些包。

也可以看看:https://networkengineering.stackexchange.com/a/54404/36597

相关内容