web-dev-qa-db-ja.com

HTBを使用したLinuxでのトラフィックシェーピング：奇妙な結果

Linuxサーバーでいくつかの単純な帯域幅調整を設定しようとしていますが、一見些細な設定にもかかわらず、非常に奇妙なものに遭遇しています。

特定のクライアントIP（10.41.240.240）に到達するトラフィックを最大75Kbit/sに整形したいと思います。シェーピングの設定方法は次のとおりです。

# tc qdisc add dev eth1 root handle 1: htb default 1 r2q 1

# tc class add dev eth1 parent 1: classid 1:1 htb rate 75Kbit
# tc class add dev eth1 parent 1:1 classid 1:10 htb rate 75kbit 

# tc filter add dev eth1 parent 1:0 protocol ip prio 1 u32 match ip dst
10.41.240.240 flowid 1:10

テストするために、上記のクライアントマシンからHTTP経由でファイルのダウンロードを開始し、FirefoxでKb/s）を確認して、結果の速度を測定します。

現在、動作はかなり不可解です。DLは約10Kbyte/sで始まり、約75Kbytes/sで安定するまで速度を上げていきます（キロバイト、構成されたキロビットではありません！）。 、まったく同じファイルの複数の並列ダウンロードを開始すると、各ダウンロードは約45Kバイト/秒で安定します。したがって、これらのダウンロードの合計速度は、構成された最大値を大幅に超えます。

デバッグ情報についてtcをプローブすると次のようになります

[root@kup-gw-02 /]# tc -s qdisc show dev eth1
qdisc htb 1: r2q 1 default 1 direct_packets_stat 1
 Sent 17475717 bytes 1334 pkt (dropped 0, overlimits 2782 requeues 0)
 rate 0bit 0pps backlog 0b 12p requeues 0

[root@kup-gw-02 /]# tc -s class show dev eth1
class htb 1:1 root rate 75000bit ceil 75000bit burst 1608b cburst 1608b
 Sent 14369397 bytes 1124 pkt (dropped 0, overlimits 0 requeues 0)
 rate 577896bit 5pps backlog 0b 0p requeues 0
 lended: 1 borrowed: 0 giants: 1938
 tokens: -205561 ctokens: -205561

class htb 1:10 parent 1:1 prio 0 **rate 75000bit ceil 75000bit** burst 1608b cburst 1608b
 Sent 14529077 bytes 1134 pkt (dropped 0, overlimits 0 requeues 0)
 **rate 589888bit** 5pps backlog 0b 11p requeues 0
 lended: 1123 borrowed: 0 giants: 1938
 tokens: -205561 ctokens: -205561

私が一生理解できないのは、これです。「レート75000ビットセル75000ビット」の構成で「レート589888ビット5pps」を取得するにはどうすればよいですか。実効レートが設定されたレートよりもはるかに高くなるのはなぜですか？私は何が間違っているのですか？なぜそれがそのように振る舞うのですか？

助けてください、私は困惑しています。みんなありがとう。

linuxtchtb
1
DADGAD

私はちょっと問題を修正したと思います：qdiscs/classesをETHデバイスではなくIMQデバイスに結び付ける必要がありました。それをしたら、シェイパーが動き始めました。

しかしながら！

マシンに着信するトラフィックを制限するようにシェイパーを取得することはできましたが、トラフィックを公平に分割することはできませんでした（HTBにSFQをアタッチしたにもかかわらず）。

何が起こったのか：ダウンロードを開始しました。 75Kバイト/秒に制限されました。ここで、2回目のダウンロードを開始すると、トラフィックを2つのDLセッション（35Kバイト/秒+ 35Kバイト/秒）に均等に分割する代わりに、セッション1の速度がほとんど低下せず、セッション2になりました。わずか500b/s。数分後、分割は65Kbyte/s + 10 Kbyte/sのようなものに落ち着きました。憤慨してそれは公平ではありません！:)

そこで、構成を解体し、先に進んで、トラフィックシェーパーモジュールを備えたClearOS 5.2（ファイアウォールシステムが事前に構築されたLinuxディストリビューション）をセットアップしました。このモジュールは、私が手作業で構成したものと非常によく似たHTB + SFQセットアップを使用します。

同じ公平性の問題！全体的な制限は適切に実施されていますが、公平性はありません。 -2つのダウンロードは、35/35ではなく65/15の同じ奇妙な比率で共有されます。

何かアイデアはありますか？

2
DADGAD

代わりに、次の例を使用してみてください。

# tc qdisc add dev eth1 root handle 1: htb default 10

# tc class add dev eth1 parent 1: classid 1:1 htb rate 75Kbit
# tc class add dev eth1 parent 1:1 classid 1:10 htb rate 1Kbit ceil 35Kbit
# tc class add dev eth1 parent 1:1 classid 1:20 htb rate 35kbit

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

# tc filter add dev eth1 parent 1:0 protocol ip prio 1 u32 \
    match ip dst 10.41.240.240 flowid  1:20

これにより、レート制限が75Kbit/sのhtbバケットが作成され、その下に2つのsfq（フェアキューイングqdisc）が作成されます。

デフォルトでは、全員が最初のキューに入れられ、保証レートは1Kビット、最大レートは30Kビットです。これで、10.41.240.240のIPは35Kビットが保証され、選択されていないトラフィックが使用されている場合は75Kビットもかかる可能性があります。 .240からの2つの接続は平均化され、接続ごとに同じである必要があり、.240と非.240の間の接続は、キュー間で35：1の比率で並列化されます。

これは4月から死んでいるようです...だから、この情報がまだあなたにとって価値があることを願っています。

2
Regan W

これはこれに関連している可能性があります：

差出人： http://www.shorewall.net/traffic_shaping.htm

Xenユーザーへの警告

Dom0でトラフィックシェーピングを実行していて、トラフィックシェーピングが発信トラフィックを適切に制限していないように見える場合は、domUの「チェックサムオフロード」が原因である可能性があります。 「shorewallshowtc」の出力を確認してください。そのコマンドの出力からの抜粋を次に示します。

class htb 1:130 parent 1:1 leaf 130: prio 3 quantum 1500 rate 76000bit ceil 230000bit burst 1537b/8 mpu 0b overhead 0b cburst 1614b/8 mpu 0b overhead 0b level 0 
 Sent 559018700 bytes 75324 pkt (dropped 0, overlimits 0 requeues 0) 
 rate 299288bit 3pps backlog 0b 0p requeues 0 
 lended: 53963 borrowed: 21361 giants: 90174
 tokens: -26688 ctokens: -14783

上記の出力には、2つの明らかな問題があります。

  • レート（299288）は、上限（230000）よりもかなり大きくなっています。
  • 多数（90174）の巨人が報告されています。

この問題は、ethtoolユーティリティを使用してdomUで「チェックサムオフロード」を無効にすることで修正されます。手順については、Xenの記事の1つを参照してください。

1
Xantor