web-dev-qa-db-ja.com

Linuxトラフィック制御：ブリッジとqdiscを使用してトラフィックに優先順位を付ける方法は？

ネットワーク内のLinuxベースのソフトウェアブリッジよりもトラフィックを優先させようとしています。ローカルで（ブリッジをホストしているマシンで）トラフィックを生成すると、トラフィックの優先順位が正しく設定されます。ただし、「ブリッジ」を通過する他のノードからの「リモート」トラフィックは優先されません（すべての送信者への同じ帯域幅配分）。多分誰かが理由を知っていますか？

I350ネットワークアダプター用のブリッジは次のように設定されています（Linux 5.1.8-1-MANJARO＃1 SMP PREEMPT Sun Jun 9 20:44:14 UTC 2019 x86_64 GNU/Linux）：

brctl addbr br0
ip link set dev enp1s0f0 promisc on
ip link set dev enp1s0f1 promisc on
ip link set dev enp1s0f2 promisc on
ip link set dev enp1s0f3 promisc on

brctl addif br0 enp1s0f0
brctl addif br0 enp1s0f1
brctl addif br0 enp1s0f2
brctl addif br0 enp1s0f3

ip link set dev br0 up

tc qdisc del dev enp1s0f0  root
tc qdisc add dev enp1s0f0  root prio
tc qdisc del dev enp1s0f1  root
tc qdisc add dev enp1s0f1  root prio
tc qdisc del dev enp1s0f2  root
tc qdisc add dev enp1s0f2  root prio
tc qdisc del dev enp1s0f3  root
tc qdisc add dev enp1s0f3  root prio

ip addr add 192.168.1.1/24 dev br0

UDPトラフィックはiperf3で生成され、TOSフィールドを適切に設定することで生成されます。

Low-Prio Sender: iperf3 -c 192.168.1.140 -u -b 100m -S 0x2 -p 5201 -t 30
Hi-Prio Sender : iperf3 -c 192.168.1.140 -u -b 100m -S 0x0 -p 5202 -t 30

Prioマップはデフォルト設定のままです：priomap 1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1

トラフィックを明示的に分類すると、リモートトラフィックの優先順位付けが機能します。

tc filter add dev enp1s0f1 parent 1: protocol ip prio 10 u32 match ip dst 192.168.1.140 match ip dport 5201 0xffff flowid 1:1
tc filter add dev enp1s0f1 parent 1: protocol ip prio 20 u32 match ip dst 192.168.1.140 match ip dport 5202 0xffff flowid 1:2

しかし、デフォルト設定ではありません...多分それはレイヤー2 /レイヤー3の問題ですか？

linux-networkingqos
2
BigK

それまでの間、私はなんとか解決策を見つけました:)

Linuxブリッジ（brctl）は、レイヤー2デバイスとして機能します。

TOSマーキングはIEEE P802.1p（これはIEEE_802.1Qに属します）の一部であり、IPヘッダーに属しています（ https://en.wikipedia.org/wiki/IEEE_802.1Q ）

Linuxブリッジはレイヤー2で動作するため、このフィールドは無視されるようです。 （ただし、OSIモデルによると https://en.wikipedia.org/wiki/OSI_model 802.1Qはレイヤー2に属します）その結果、すべてのパケットが同じqdiscクラス（私の設定ではクラス1：2）私は次のコマンドでそれを理解しました：

tc -s -s -d c ls dev enp1s0f1

これにより、実行時にさまざまなqdiscクラスのキューを監視できます。後で、「リモート」トラフィックは、他のストリーム（たとえば、ブリッジをホストするマシンからの「ローカル」ストリーム）を使用してクラス1：2からのトラフィックとしてスケジュールされ、正しい結果が得られました。いくつかのユースケース.....だから注意してください！ ;）

私のために働いたのは、プロキシARPでネットワーク接続をブリッジすることでした（つまり、レイヤー3を強制する https://wiki.debian.org/BridgeNetworkConnectionsProxyArp ）

まず、IP転送とプロキシARPをアクティブにします。

echo 1 > /proc/sys/net/ipv4/conf/all/proxy_arp
echo 1 > /proc/sys/net/ipv4/ip_forward

その後、ルートをノードに追加します。

ip ro add <node IP>/32 dev <local interface>

例：

    ip ro add 192.168.1.12/32 dev enp1s0f0
1
BigK

ブリッジングとプリオキュースケジューラのソースコードを読みました。そして、私はいくつかの結果を持っています：

  • Prio qdiscは、skb->priorityフィールドを使用して、priomapでパケットを分類します。
  • デフォルトでは、L [2]トランジットフレームのskb-priorityフィールドは入力されていません。
  • したがって、正しい方法は、すべてのブリッジポートに分類子を追加して、フレームをToS/DSCPフィールドで分類することです。
  • デフォルトでは、プリオマップは1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1のように見えます。
  • ToSとキューバンドの間の同じマッピングは、分類子を使用して実行できます（ルートqdiscのハンドルは1:0なので、子クラスは1:1-1:3のクラスIDを持ちます）：
tc filter add dev eth0 parent 1: protocol ip flower ip_tos 0x00 classid 1:2
tc filter add dev eth0 parent 1: protocol ip flower ip_tos 0x02 classid 1:3
tc filter add dev eth0 parent 1: protocol ip flower ip_tos 0x04 classid 1:3
tc filter add dev eth0 parent 1: protocol ip flower ip_tos 0x06 classid 1:3
tc filter add dev eth0 parent 1: protocol ip flower ip_tos 0x08 classid 1:2
tc filter add dev eth0 parent 1: protocol ip flower ip_tos 0x0a classid 1:3
tc filter add dev eth0 parent 1: protocol ip flower ip_tos 0x0c classid 1:1
tc filter add dev eth0 parent 1: protocol ip flower ip_tos 0x0e classid 1:1
tc filter add dev eth0 parent 1: protocol ip flower ip_tos 0x10 classid 1:2
tc filter add dev eth0 parent 1: protocol ip flower ip_tos 0x12 classid 1:2
tc filter add dev eth0 parent 1: protocol ip flower ip_tos 0x14 classid 1:2
tc filter add dev eth0 parent 1: protocol ip flower ip_tos 0x16 classid 1:2
tc filter add dev eth0 parent 1: protocol ip flower ip_tos 0x18 classid 1:2
tc filter add dev eth0 parent 1: protocol ip flower ip_tos 0x1a classid 1:2
tc filter add dev eth0 parent 1: protocol ip flower ip_tos 0x1c classid 1:2
tc filter add dev eth0 parent 1: protocol ip flower ip_tos 0x1e classid 1:2
2
Anton Danilov