ブリッジインターフェイスでネットワーク損失をシミュレートしようとしています。
私のサーバーには、現在切断されている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これらの規則に準拠し、ブリッジ間に中間インターフェイスを配置して片側に適用する必要がありますeth1。netemoutgoing
わかりやすい例は、別のブリッジを追加し、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足の上でも動作します。