veth ペアで接続された 2 つの Linux コンテナがあります。 1 つのコンテナの veth インターフェースで tc qdisc netem delay を設定し、そこから他のコンテナにトラフィックを送信します。 tcpdump/wireshark を使用して両側のトラフィックを監視すると、送信側と受信側の同じパケットのタイムスタンプが、選択した遅延によって異ならないことがわかります。
libpcap が tc qdisc に対応する出力トラフィックにタイムスタンプを付けるポイントをもっと詳しく知りたかったのです。インターネットでスキーム/イメージを検索しましたが、見つかりませんでした。このトピックを見つけました (Wireshark パケットキャプチャポイント) ですが、もう 1 つのコンテナー/インターフェイスを追加して間接性を導入することを推奨しています。これは、私の状況では可能な解決策ではありません。追加の中間インターフェイスを導入せず (つまり、トポロジを変更せず)、すでに指定されている veth インターフェイスでのみ記録し、遅延を確認できるようにすることで、問題を解決する方法はありますか?
アップデート：
私はあまりにも急いでいたので、間違えてしまいました。以下に示す私の解決策（@AB の回答の最初の解決策と同じ）も、@AB の IFB を使用した解決策（すでに確認済み）も、私の問題は解決しません。問題は、a1-eth0トポロジ内の送信者のインターフェイスの送信キューのオーバーフローにあります。
[a1-br0 ---3Gbps---a1-eth0]---100Mbps---r1---100Mbps---r2
a1-eth0私はあまりに急いでいて、とルータ間のリンクで 10 ミリ秒の遅延のみをチェックしましたr1。今日は、遅延を 100 ミリ秒、200 ミリ秒と高くしてみましたが、結果 (取得したパケットごとの遅延とレートのグラフ) は、上記のトポロジと通常のトポロジで異なり始めました。
[a1-eth0]---100Mbps---r1---100Mbps---r2
したがって、正確なテストを行うために、Linux ブリッジ、この IFB、その他のサード システムによって導入されたリンク以外のリンクを使用することはできません。私は輻輳制御スキームをテストします。そして、特定のトポロジでテストを行いたいと考えています。また、プロットのためだけにトポロジを変更することはできません。つまり、同時にレートと遅延の結果/プロットが変更されるということです。
更新2:
したがって、以下に示すように、解決策が見つかったようです (NFLOG ソリューション)。
更新3:
ここでは、NFLOG ソリューションのいくつかの欠点 (大きなリンク層ヘッダーと、ペイロードがゼロの出力 TCP パケットの間違った TCP チェックサム) について説明し、これらの問題がない NFQUEUE を使用したより優れたソリューションを提案します。長さゼロの出力パケットの TCP チェックサムが間違っている (iptables でキャプチャ)ただし、私のタスク (輻輳制御スキームのテスト) には、NFLOG も NFQUEUE も適していません。同じリンクで説明されているように、パケットがカーネルの iptables からキャプチャされると、送信速度が抑制されます (これが私の理解です)。したがって、インターフェイスからキャプチャして送信側で記録すると (つまり、定期的に) 2 ギガバイトのダンプが取得されますが、iptables からキャプチャして送信側で記録すると 1 ギガバイトのダンプが取得されます。大まかに言えば。
アップデート4:
最後に、私のプロジェクトでは、下の回答で説明した Linux ブリッジ ソリューションを使用します。
答え1
によるNetfilter と一般的なネットワークにおけるパケットフロー概略図、tcpdump キャプチャ (AF_パケット） 後出力 (qdisc)したがって、tcpdump で遅延が表示されないのは正常です。遅延は最初のキャプチャ時にすでに存在していました。
1 ステップ早くキャプチャする必要があるため、3 番目のシステムが必要になります。
S1: system1、送信インターフェースでtcpdumpを実行します。R
: router (またはbridge、都合に合わせて、何も変更しません)、qdisc netemを実行します
。S2: system2、受信インターフェースでtcpdumpを実行します。
__________________ ________________ __________________
| | | | | |
| (S1) -- tcpdump -+---+- (R) -- netem -+---+- tcpdump -- (S2) |
|__________________| |________________| |__________________|
つまり3つのネットワークスタック関係するものは、実空間、仮想マシン、ネットワーク名前空間（IPネットワーク、LXC、...)
オプションとして、ルーター（またはブリッジ）上のすべての特別な設定を、国際FBインターフェースミラーリングトラフィック: トリック (この場合専用) によって、出力時ではなく入力時に netem を挿入できるようになります。
_______ ______________________________________________ _______
| | | | | |
| (S1) -+---+- tcpdump -- ifb0 -- netem -- (R) -- tcpdump -+---+- (S2) |
|_______| |______________________________________________| |_______|
IFBの基本的な使用例がtcミラーリングマニュアルページ:
ifb インターフェイスを使用すると、sfq のインスタンスを介して入力トラフィックを送信できます。
# modprobe ifb # ip link set ifb0 up # tc qdisc add dev ifb0 root sfq # tc qdisc add dev eth0 handle ffff: ingress # tc filter add dev eth0 parent ffff: u32 \ match u32 0 0 \ action mirred egress redirect dev ifb0
ただ使うだけネットムsfq の代わりに ifb0 で (非初期ネットワーク名前空間では、ip link add name ifbX type ifbmodprobe なしで正常に動作します)。
適切に動作するには、依然として 3 つのネットワーク スタックが必要です。
使用してNFLOG
JenyaKhからの提案により、パケットをキャプチャすることが可能であることが分かりました。tcpダンプ、前に出力（qdiscの前）と出力（qdiscの後）で次のようにします。iptables（またはnftables）は、完全なパケットをネットリンクログインフラストラクチャに記録し、tcpダンプ、そして再びtcpダンプ出力インターフェイスで。これには S1 の設定のみが必要です (ルーター/ブリッジは不要になります)。
だからiptablesS1では次のようになります:
iptables -A OUTPUT -o eth0 -j NFLOG --nflog-group 1
おそらく、行われたテストに合わせて特定のフィルターを追加する必要があるでしょう。tcpダンプフィルターは nflog インターフェースに制限されています (wireshark の方が適切に処理できるはずです)。
回答キャプチャが必要な場合（ここでは別のグループで行われるため、追加のtcpダンプ):
iptables -A INPUT -i eth0 -j NFLOG --nflog-group 2
必要に応じて移動することも可能です生/出力そして生/プレルーティングその代わり。
とtcpダンプ:
# tcpdump -i nflog:1 -n -tt ...
入力に別のグループ (= 2) が使用された場合:
# tcpdump -i nflog:2 -n -tt ...
そして、いつものように同時に:
# tcpdump -i eth0 -n -tt ...
答え2
アップデート：
そこで、最終的にこのソリューションを使用しました。このソリューションは私のソリューションに含まれています。結局、私にとってはうまく機能しました。
私（トピックの投稿者）は Linux ブリッジを使用して問題を解決しました。ここで [https://www.linuxquestions.org/questions/linux-networking-3/transferring-all-traffic-through-an-extra-interface-4175656515] Linux ブリッジを使用することができたが、その可能性を否定したと書きました。「しかし、このソリューションは私のニーズに合いません。実際には、h1-br0 と h1-eth0 インターフェイスの間に追加のイーサネット リンクがあるからです。パフォーマンス測定にはこれが必要なので、追加のイーサネット リンクは持てません。つまり、ブリッジを使用するこのソリューションは、余分なリンクを導入することでトポロジを台無しにします。」
a1
-----------------
|a1-br0---a1-eth0|---------local network
------------------
なぜ最初にソリューションを却下したのでしょうか? 当初、私のトポロジーは次のとおりです。
a1---3Gbps---r1---100Mbps---r2
リンクでは、r1---r2netem レートを 100 Mbps に設定していますが、リンクにはa1---r1レート制限はありません。r1ルータに接続するルータの送信キューは 1000 パケットなので、からr2にトラフィックを送信すると、キュー オーバーフロー (一部のパケットがドロップされる) が発生しました。 これは問題ありませんでした。 これは、ボトルネック リンクの場合にルータ キューがオーバーフローする実際の状況です。a1r2
今、私は遅延とレート制限も追加するためにこの調査をすべて行っていますa1---r1。そこで、Linux ブリッジを使用したこのソリューションを思いつきました。しかし、このソリューションは機能しないと思いました。以下に、Linux ブリッジを使用した新しいトポロジを示します。
[a1-br0 ---3Gbps---a1-eth0]---100Mbps---r1---100Mbps---r2
したがって、このソリューションの問題点は、キュー オーバーフローがインターフェイス の送信キューに存在すると予想していたことですa1-eth0。つまり、これは、オーバーフローがr1に接続するのインターフェイスで発生した前の図と同じですr2。類似しています。
そして、このオーバーフローは望ましくありません。通常のトポロジでは、遅延測定の目的で Linux ブリッジを使用しない場合、送信キューのオーバーフローは発生しませんa1-eth0。
[a1-eth0]---100Mbps---r1---100Mbps---r2
しかし、昨日、Linux ブリッジを使用してトポロジ (上記で描いた の 3 番目のトポロジ) を再度作成し、 から に流れるトポロジでトラフィックを開始しましたa1。 500 ミリ秒間隔でコマンドを呼び出すr2の送信キューのバックログ (キュー内の現在のパケット数)と、同様のコマンドを使用した の送信キューのバックログを確認しました。a1-eth0tc -s qdisc show dev a1-eth0a1-br0
これは私が見たものでa1-eth0、次のようなメッセージを受け取りました:
qdisc netem 8112: root refcnt 2 limit 1000 delay 10.0ms
Sent 9461862 bytes 6393 pkt (dropped 0, overlimits 0 requeues 0)
backlog 133380b 90p requeues 0
qdisc netem 8112: root refcnt 2 limit 1000 delay 10.0ms
Sent 15280534 bytes 10323 pkt (dropped 0, overlimits 0 requeues 0)
backlog 133380b 90p requeues 0
qdisc netem 8112: root refcnt 2 limit 1000 delay 10.0ms
Sent 21110722 bytes 14257 pkt (dropped 0, overlimits 0 requeues 0)
backlog 118560b 80p requeues 0
qdisc netem 8112: root refcnt 2 limit 1000 delay 10.0ms
Sent 26952766 bytes 18199 pkt (dropped 0, overlimits 0 requeues 0)
backlog 102258b 69p requeues 0
qdisc netem 8112: root refcnt 2 limit 1000 delay 10.0ms
Sent 32788882 bytes 22137 pkt (dropped 0, overlimits 0 requeues 0)
backlog 103740b 70p requeues 0
qdisc netem 8112: root refcnt 2 limit 1000 delay 10.0ms
Sent 38635372 bytes 26082 pkt (dropped 0, overlimits 0 requeues 0)
backlog 102258b 69p requeues 0
qdisc netem 8112: root refcnt 2 limit 1000 delay 10.0ms
Sent 44477416 bytes 30024 pkt (dropped 0, overlimits 0 requeues 0)
backlog 102258b 69p requeues 0
qdisc netem 8112: root refcnt 2 limit 1000 delay 10.0ms
Sent 50332798 bytes 33975 pkt (dropped 0, overlimits 0 requeues 0)
backlog 102258b 69p requeues 0
qdisc netem 8112: root refcnt 2 limit 1000 delay 10.0ms
Sent 56157058 bytes 37905 pkt (dropped 0, overlimits 0 requeues 0)
backlog 125970b 85p requeues 0
qdisc netem 8112: root refcnt 2 limit 1000 delay 10.0ms
Sent 61969532 bytes 41828 pkt (dropped 0, overlimits 0 requeues 0)
backlog 133380b 90p requeues 0
qdisc netem 8112: root refcnt 2 limit 1000 delay 10.0ms
Sent 67784900 bytes 45752 pkt (dropped 0, overlimits 0 requeues 0)
backlog 133380b 90p requeues 0
qdisc netem 8112: root refcnt 2 limit 1000 delay 10.0ms
Sent 73600268 bytes 49676 pkt (dropped 0, overlimits 0 requeues 0)
backlog 133380b 90p requeues 0
qdisc netem 8112: root refcnt 2 limit 1000 delay 10.0ms
Sent 79415636 bytes 53600 pkt (dropped 0, overlimits 0 requeues 0)
backlog 133380b 90p requeues 0
qdisc netem 8112: root refcnt 2 limit 1000 delay 10.0ms
Sent 85244342 bytes 57533 pkt (dropped 0, overlimits 0 requeues 0)
backlog 120042b 81p requeues 0
qdisc netem 8112: root refcnt 2 limit 1000 delay 10.0ms
Sent 91080458 bytes 61471 pkt (dropped 0, overlimits 0 requeues 0)
backlog 102258b 69p requeues 0
qdisc netem 8112: root refcnt 2 limit 1000 delay 10.0ms
Sent 96923984 bytes 65414 pkt (dropped 0, overlimits 0 requeues 0)
backlog 102258b 69p requeues 0
qdisc netem 8112: root refcnt 2 limit 1000 delay 10.0ms
Sent 102761582 bytes 69353 pkt (dropped 0, overlimits 0 requeues 0)
backlog 102258b 69p requeues 0
qdisc netem 8112: root refcnt 2 limit 1000 delay 10.0ms
Sent 108606590 bytes 73297 pkt (dropped 0, overlimits 0 requeues 0)
backlog 103740b 70p requeues 0
これは私が見たものでa1-br0、次のようなメッセージを受け取りました:
qdisc noqueue 0: root refcnt 2
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
qdisc noqueue 0: root refcnt 2
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
qdisc noqueue 0: root refcnt 2
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
qdisc noqueue 0: root refcnt 2
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
qdisc noqueue 0: root refcnt 2
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
qdisc noqueue 0: root refcnt 2
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
qdisc noqueue 0: root refcnt 2
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
qdisc noqueue 0: root refcnt 2
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
qdisc noqueue 0: root refcnt 2
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
qdisc noqueue 0: root refcnt 2
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
qdisc noqueue 0: root refcnt 2
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
qdisc noqueue 0: root refcnt 2
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
qdisc noqueue 0: root refcnt 2
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
qdisc noqueue 0: root refcnt 2
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
qdisc noqueue 0: root refcnt 2
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
qdisc noqueue 0: root refcnt 2
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
qdisc noqueue 0: root refcnt 2
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
qdisc noqueue 0: root refcnt 2
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
したがって、 ではオーバーフローは発生せずa1-eth0、実際には がa1-br0何かを送信しているようには「見えません」が、実際には送信しています。したがって、 と 間のリンクはa1-bro、とルータa1-eth0間のリンク (veth ペア リンク) とは異なります。なぜそうなるのかはわかりません。たとえば、 で netem 遅延設定を設定できることを確認できたので、奇妙です。つまり、通常のインターフェイスのようです。a1r1a1-br0
とにかく、ブリッジを使用したソリューションがすべてのニーズを満たしていることを確認しました。ただし、なぜそれが機能するのかはまだ調べていません (上で説明した意味、つまりキューのオーバーフローなど)。
参考までに、ホストで実行したコマンドを以下に示しますa1。ただし、コンテキストなしでは完全に理解するのは難しいと思います。しかし、将来誰かの役に立つかもしれません。
brctl addbr a1-br0
brctl addif a1-br0 a1-eth0
ip link set dev a1-br0 up
ip addr add dev a1-br0 11.0.0.1/30
ip addr flush dev a1-eth0
route add default gw 11.0.0.2 dev a1-br0
ifconfig a1-eth0 0.0.0.0 up
ethtool -K a1-br0 tx off sg off tso off ufo off
コマンドを適用した IP アドレスを含むトポロジもここにあります。Linuxルータの1つのインターフェースをこのルータの別のインターフェースでpingするトポロジは次のとおりです。
------ ------ ------
| a1 | | r1 | | r2 |
| | a1-eth0-----------r1-eth0 | |r1-eth1--------------r2-eth1| |
-----(11.0.0.1/30) (11.0.0.2/30)----(11.0.0.9/30) (11.0.0.10/30)-----