netem を使用したブリッジインターフェイスでのパケット損失のシミュレーション

netem を使用したブリッジインターフェイスでのパケット損失のシミュレーション

ブリッジインターフェイスでネットワーク損失をシミュレートしようとしています。
私のサーバーには、現在切断されているbr0とeth0にブリッジされている4つのネットワークインターフェイスeth1、eth2、およびeth3があります。実際、eth2も接続が失われました(閉じています)。 eth1を映像伝送装置に接続し、eth3をネットワークスイッチに直接接続した。
受信デバイスは同じスイッチに接続されていますが、別のポートにあります。私はnetemを使ってルートのネットワーク障害をシミュレートしています。以下はnetemコマンドの例です
sudo tc qdisc add dev eth1 root netem delay 100ms 50ms loss 20%
トランスミッタにpingを実行すると、このコマンドで設定された時間遅延、ジッタ、およびパケット損失が正しく表示されますが、これはトランスミッタとデコーダ間のネットワーク転送には何の影響もありません。 eth3で同じコマンドを実行すると、発信者と受信者の間のリンクが失われ始めますが、問題は、eth1をネットワークインターフェイスとして定義すると、送信が正しく機能するのはなぜですか?

答え1

このような行動の理由はtc-netem(8)(太字):

遅延

選択した遅延を次に追加します。選択したネットワークインターフェイスに送信されるパケット

または

ランダム損失

独立した損失確率を追加選択したネットワークインターフェイスから送信されたパケット

したがって、tc ... netem以下にのみ適用されます。出るパケットには影響しません。着信パケットはから来ますeth1。このルールを適用すると、今のような効果がeth3現れます。netem出るビデオトラフィックインターフェイス。

eth3これらの規則は通常、無関係なトラフィックのみを処理する必要があるため、適用しないでくださいeth1着信着信トラフィックはeth1これらの規則に準拠し、ブリッジ間に中間インターフェイスを配置して片側に適用する必要がありますeth1netemoutgoing

わかりやすい例は、別のブリッジを追加し、eth1リンクvethを最初のブリッジとペアにすることです。その後、この追加ブリッジのインターフェイスtcにルールを適用できます。着信パケットはこのインターフェイスを通過するため、期待どおりに機能します。 。vetheth1veth

しかし実際には中間ファンクションブロック装置(ifb0ネットワークフローでは、受信/入口インターフェイスの直後に人工的な内部送信インターフェイスを挿入することで、これらの問題を解決するように設計されています。ifb0それでも他のほとんどのネットワーク層の前にあり、ほとんど目立たない。発信/発信(ただし内部のみ)なのでnetem処理されます。

だからこれは解決すべきnetem問題です。着信変える出るeth1ifb0次の例で採用されている技術を使用したインターフェイスのトラフィックtc-mirred(8).:

ip link add ifb0 type ifb || :
ip link set ifb0 up
tc qdisc add dev ifb0 root netem delay 100ms 50ms loss 20%
tc qdisc add dev eth1 handle ffff: ingress
tc filter add dev eth1 parent ffff: u32 match u32 0 0 action mirred egress redirect dev ifb0

u32 match u32 0 0 は、フィルタコマンドを許可する最も単純な ANY フィルタです。

もちろん、eth1足の上でも動作します。

関連情報