タグ付けされた質問 「tc」

ここに書かれているように、Linuxゲートウェイでトラフィックシェーピングを設定しようとしています。複数のLANインターフェイスがあるため、スクリプトをカスタマイズする必要があります。LAN側を形成するために、次のようなifb疑似デバイスを作成する予定です。 modprobe ifb ip link set dev ifb0 up /sbin/tc qdisc add dev $WAN_INTERFACE ingress /sbin/tc filter add dev $WAN_INTERFACE parent ffff: protocol ip u32 match u32 0 0 action mirred egress redirect dev ifb0 上記の要点リポジトリのスクリプトには、次の行があります。 /sbin/tc qdisc add dev $WAN_INTERFACE handle ffff: ingress /sbin/tc filter add dev $WAN_INTERFACE parent …

20 traffic-shaping  tc 

tcとnetemを使うのは初めてです。特定のIPアドレスに送信されるパケットを遅延させたい。ただし、次のコマンドにより、IPアドレス1.2.3.4だけではなく、システム上のすべてのパケットが遅延します。 tc qdisc del dev eth0 root tc qdisc add dev eth0 root handle 1: prio tc qdisc add dev eth0 parent 1:1 handle 2: netem delay 500ms tc filter add dev eth0 parent 1:0 protocol ip pref 55 handle ::55 u32 match ip dst 1.2.3.4 flowid 2:1 私の推測では、残りのすべてのトラフィックがnetemを通過しないように指定するには、最後に何らかのキャッチオールフィルターが必要です。しかし、何も機能しません。これをどのように機能させるのですか？

20 linux  traffic-shaping  tc 

私は一時的にレート制限されたキューの規律を設定し、それを少し後で削除しようとしています： # /sbin/tc qdisc add dev eth1 root tbf rate 600kbit latency 50ms burst 1540 # /sbin/tc qdisc del dev eth1 root 残念ながら、これによりキューの規則が完全に削除され、キューが削除された後に送信データ転送が機能しなくなります。 私はキューの規律をデフォルトにリセットできることを望んでいました： qdisc pfifo_fast 0: dev eth1 root refcnt 2 bands 3 priomap 1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 …

13 linux  tc 

ハッシュフィルタリングを備えた、Linuxブリッジで構築された素晴らしいシェーパーがあります。要するに、br0接続externalとinternal物理インターフェース、VLANタグ付きパケットは「透過的に」ブリッジされます（つまり、VLANインターフェースはありません）。 現在、異なるカーネルは異なる方法でそれを行います。正確なカーネルバージョンの範囲が間違っている可能性がありますが、ご容赦ください。ありがとう。 2.6.26 したがって、debianでは、2.6.26以降（2.6.32まで、私は信じています）---これは動作します： tc filter add dev internal protocol 802.1q parent 1:0 prio 100 \ u32 ht 1:64 match ip dst 192.168.1.100 flowid 1:200 ここで、「カーネル」は0x8100の「プロトコル」フィールドの2バイトに一致しますが、IPパケットの先頭を「ゼロ位置」としてカウントします（少し不明瞭な場合は英語でごめんなさい）。 2.6.32 繰り返しますが、debian（私はバニラカーネルを構築していません）では、2.6.32-5 ---これは動作します： tc filter add dev internal protocol 802.1q parent 1:0 prio 100 \ u32 ht 1:64 match ip dst 192.168.1.100 at 20 …

12 vlan  linux-networking  traffic-shaping  linux-kernel  tc 

現在、ISPレベルの企業向けのトラフィックシェーピングソリューションに取り組んでおり、興味深い（一種の哲学的な）問題に遭遇しました。 システムが処理するエンドポイントの数（約20k程度）を見ると、より多くのユーザーのトラフィックをポリシー化/シェーピングする必要がある場合に何が起こるか少し心配になりました。現在、ネットワーク全体でHFSCシェーピングツリーを使用しているので（tc-hfscを参照してください。ほとんどがよく知られているHTBと同じです）、より多くのClassIDを使用する必要があります（明らかに、通信網）。私が見つけた問題は、TC ClassIDの種類が限られていることでした-それらは16ビットの数値であり、このソリューションによって形成された最大64kユーザーの可能性があります。 同様に、TCフィルターを効率的に管理したい場合（「すべての手法を使用しない」など）、個々のフィルターエントリを削除または変更できる必要があります。（LARTC [1]のハッシュテーブルに似たものを使用しています）。繰り返しますが、これで動作していると思われる唯一の方法は、個々の優先順位を使用してすべてのフィルターに番号を付けることです（tc filter add dev ... prio 1）。この目的に使用できる他のパラメーターはありません。残念ながら、prioも16ビットのみです。 私の質問は次のとおりです：「tc class」コマンドの32ビットclsid、「tc filter」の32ビット優先度（またはその他の変更ハンドル）など、利用可能な「識別子スペース」を拡大するための良い方法はありますかコマンド？ どうもありがとう、 -mk （ところで、これは「64kユーザーですべての人に十分なはずです」シナリオに行かないことを願っています...）

12 linux  networking  isp  traffic-shaping  tc