web-dev-qa-db-ja.com

TCを使用したLinuxトラフィックシェーピング

私のインターネット接続は次のようになります：

インターネット<-128kbpsリンク-> Ciscoルーター（パブリックIP）<-LAN-> Linuxルーター/サーバー（パブリックIP）<-LAN->通常のPC（パブリックIP）

Ciscoルーター：

  • 私の機関に割り当てられた最初のパブリックIP（/ 29）
  • linuxルーターを介してすべてのパケットを送信するようにプログラムされています

Linuxルーター

  • 私の機関に割り当てられた2番目のパブリックIP
  • 通常のPCとCiscoルーター間でパケットを転送するようにプログラムされています
  • サーバーとしても機能します（メール、Webなど）

通常のPC（4台）：

  • 残りのパブリックIP
  • linuxルーターをゲートウェイとして使用する

Linuxルーターでiptablesパケットロギングを有効にしたところ、次のことがわかりました。

  • 一部のパケットは大きく、20KBを超えます。それは正常ですか？ （はい、それは正常です。これらはパケットではなく、Some Guyが親切に説明したようにIPデータグラムです）
  • （インターネットに）送信されたデータが16KBを超える回数が多すぎました。たとえば、特定の秒で10572バイトが入力され（問題ありません）、63521バイトが（Ciscoルーターに）送信されました。その64KBを128kbpsリンク経由で送信するには少なくとも4秒かかります。その間、Linuxルーターはより多くのデータをCiscoルーターに送信し、そのバッファーを詰まらせています。良くない。

では、次のような方法でトラフィックをシェーピングするようにLinuxルーターを構成するにはどうすればよいですか。

  1. トラフィックがこれらの通常のPCとLinuxサーバーの間である場合、伝送速度を最大に保ちます。
  2. 使用可能なすべて（またはほぼすべて）の帯域幅（128 kbps）を使用して、「アウトライン」回線の詰まりを回避するために、外界へのトラフィックを遅くします。トレースに「> 16KBアウト秒」はもうありません。
  3. 通常の各PCに24kbps、Linuxサーバーに24kbpsをいつでも保証します。 （必要に応じてオーバーヘッド用に8bkpsを残しました）。 IOW、5（疑似）「バンド」、各24kbps。
  4. フルバンドを使用していないPCがある場合は、残りの送信PC間でアイドル帯域幅を公平に共有します。
  5. 特定のパケット（DNSルックアップ、制御パケット）を優先し、他のパケットから優先し（torrent !!!）、各バンド内で、他のバンドに影響を与えないようにします。

各PCの各発信パケットを（IPテーブル--set-xmarkオプションを使用して）すでにマークしています。

  1. 外の世界へのLinuxルーター、高い優先順位
  2. 外界へのLinuxルーター、通常のプリオ
  3. 外の世界へのLinuxルーター、低優先度
  4. 外の世界への最初のレギュラーPC、高価格

... 等々。

各着信パケットも、16から始まるこのスキームを使用してマークされます。

この長い質問をお詫びしますが、tcコマンドを使用してこれを設定することを諦めました。トラフィックシェーピングに関するドキュメントが少なすぎて、次にどこに行くべきかわかりません。

linuxtraffic-shapingtraffic-management
7
Yanko Hernández Álvarez

Eth0がCiscoルーターへの100メガビットイーサネット接続であると仮定すると、次のようになります（そうではありませんか？）。

tc qdisc add dev eth0 root handle 1: htb default 2
# 100 mbps
tc class add dev eth0 parent 1: classid 1:1 htb rate 100mbit
# To LAN traffic
tc class add dev eth0 parent 1:1 classid 1:2 htb rate 99000kbit ceil 100mbit
# IN traffic
tc class add dev eth0 parent 1:1 classid 1:3 htb rate 120kbit
# OUT traffic
tc class add dev eth0 parent 1:1 classid 1:4 htb rate 120kbit

# IN “bands” (one for each PC)
tc class add dev eth0 parent 1:3 classid 1:10 htb rate 24kbit ceil 120kbit
tc class add dev eth0 parent 1:3 classid 1:11 htb rate 24kbit ceil 120kbit
tc class add dev eth0 parent 1:3 classid 1:12 htb rate 24kbit ceil 120kbit
tc class add dev eth0 parent 1:3 classid 1:13 htb rate 24kbit ceil 120kbit
tc class add dev eth0 parent 1:3 classid 1:14 htb rate 24kbit ceil 120kbit

# OUT “bands” (one for each PC)
tc class add dev eth0 parent 1:4 classid 1:15 htb rate 24kbit ceil 120kbit
tc class add dev eth0 parent 1:4 classid 1:16 htb rate 24kbit ceil 120kbit
tc class add dev eth0 parent 1:4 classid 1:17 htb rate 24kbit ceil 120kbit
tc class add dev eth0 parent 1:4 classid 1:18 htb rate 24kbit ceil 120kbit
tc class add dev eth0 parent 1:4 classid 1:19 htb rate 24kbit ceil 120kbit

このようなものを私に得るでしょう：

+-----------------------------------------------------------+
|                      100 mbits (1:1)                      |
+---------+------------------------+------------------------+
| 99mbits |   120 kbits In (1:3)   |  120 kbits Out(1:4)    |
+  (1:2)  +----+----+----+----+----+----+----+----+----+----+
+---------+ PC1| PC2| PC3| PC4| PC5| PC1| PC2| PC3| PC4| PC5|
          |1:10|1:11|1:12|1:13|1:14|1:15|1:16|1:17|1:18|1:19|
          +----+----+----+----+----+----+----+----+----+----+

そして各バンドのために：

# PC1, IN
tc qdisc add dev eth0 parent 1:10 handle 20: prio
tc qdisc add dev eth0 parent 20:1 handle 22: sfq perturb 10
tc qdisc add dev eth0 parent 20:2 handle 23: sfq perturb 10
tc qdisc add dev eth0 parent 20:3 handle 24: sfq perturb 10

# PC1, OUT
tc qdisc add dev eth0 parent 1:15 handle 21: prio
tc qdisc add dev eth0 parent 21:1 handle 25: sfq perturb 10
tc qdisc add dev eth0 parent 21:2 handle 26: sfq perturb 10
tc qdisc add dev eth0 parent 21:3 handle 27: sfq perturb 10

+--------------------++--------------------+
|       PC1 IN       ||      PC1 OUT       |
+--------------------++--------------------+
|     PRIO (20:0)    ||     PRIO (21:0)    |
|      |      |      ||      |      |      |
| Prio | Prio | Prio || Prio | Prio | Prio |
|   1  |   2  |   3  ||   1  |   2  |   3  |
|(20:1)|(20:2)|(20:3)||(21:1)|(21:2)|(21:3)|
+------+------+------++------+------+------+
|  SFQ |  SFQ |  SFQ ||  SFQ |  SFQ |  SFQ |
|(22:0)|(23:0)|(24:0)||(25:0)|(26:0)|(27:0)|
+------+------+------++------+------+------+

等々。

ルールは次のようになります

# PC1, OUT
tc filter add dev eth0 protocol ip parent 1:0 prio 1 handle 1 fw flowid 21:1
tc filter add dev eth0 protocol ip parent 1:0 prio 1 handle 2 fw flowid 21:2
tc filter add dev eth0 protocol ip parent 1:0 prio 1 handle 3 fw flowid 21:3

# PC1, IN
tc filter add dev eth0 protocol ip parent 1:0 prio 1 handle 16 fw flowid 20:1
tc filter add dev eth0 protocol ip parent 1:0 prio 1 handle 17 fw flowid 20:2
tc filter add dev eth0 protocol ip parent 1:0 prio 1 handle 18 fw flowid 20:3

等々。

提案、コメントなどはありますか？ （私はその分野での経験がありません）

4
Yanko Hernández Álvarez

見てください ここ -htbqosメカニズムの使い方はとても簡単なチュートリアルです。本質的には、iptablesでパケットにマークを付けてから、マークに応じて異なるキューに割り当てます。

あるいは、 hfsc を見るかもしれませんが、私はそれを使用したことはありませんが、実際にはそのような遅いインターネット接続でうまくいくかもしれません。

パケットサイズに関して-20kBの大きなパケットは想像できません。イーサネットのジャンボフレームでさえ短い[9kB]。

edit：Some Guyが説明するように-LENはデフラグされたIPパケットの長さであり、ワイヤー上のフレームのサイズではありません。

2
pQd