veth-pairを介して接続された2つのLinuxコンテナがあります。コンテナの veth インターフェイスで tc qdisc netem 遅延を設定し、ここから別のコンテナにトラフィックを送信します。 tcpdump / wiresharkを使用して両方のトラフィックを観察すると、送信者と受信者の同じパケットのタイムスタンプが選択した遅延によって変わらないことがわかります。
libpcapがtc qdiscに対応する送信トラフィックにタイムスタンプを挿入するタイミングをもっと詳しく知りたいです。インターネットでスキーム/画像を検索しましたが、何も見つかりませんでした。このトピックを見つけました（Wiresharkパケットキャプチャポイント）しかし、1つ以上のコンテナ/インタフェースを介して間接参照を導入することをお勧めします。これは私の状況では考えられる解決策ではありません。追加の中間インターフェイスを導入せずに（つまり、トポロジを変更せずに）既に提供されている veth インターフェイスにロギングするだけで待機時間が表示されるようにこの問題を解決する方法はありますか？
修正する:
早すぎてミスをしました。下記の私の解決策（@ABの答えの最初の解決策と同じ）と@ABのIFBソリューション（私が確認したもの）はどちらも私の問題を解決しませんでした。問題は、a1-eth0トポロジで送信者インターフェイスの送信キューがオーバーフローすることです。
[a1-br0 ---3Gbps---a1-eth0]---100Mbps---r1---100Mbps---r2
私は速すぎて、a1-eth010ミリ秒の待ち時間の間だけルーターへのリンクをチェックしましたr1。今日、私は遅延時間を100ms、200msに増やしました。結果（私が得た遅延時間とパケットあたりの速度グラフ）は、上記のトポロジと通常のトポロジで変化し始めました。
[a1-eth0]---100Mbps---r1---100Mbps---r2
したがって、もちろん、正確なテストのために追加のリンクを持つことはできません。 Linux ブリッジ、またはこの IFB または他の第 3 システムで導入されていないリンク。輻輳制御方式をテストします。特定のトポロジでこれを実行したいと思います。単にフローティングのためにトポロジを変更することはできません。つまり、速度と待機時間の結果/プロットが同時に変更されることを意味します。
アップデート2：
それで、以下のように解決策を見つけたようです（NFLOGソリューション）。
アップデート3：
NFLOGソリューションのいくつかの欠点がここに説明されています（ペイロードがゼロの送信TCPパケットの大きなリンク層ヘッダーと無効なTCPチェックサム）。これらの問題を経験しないより良いNFQUEUEソリューションが提案されている。長さゼロの送信パケットのTCPチェックサムエラー（iptablesを使用してキャプチャされます）。しかし、私の仕事（輻輳制御方式テスト）にはNFLOGとNFQUEUEの両方が適していません。同じリンクで説明されているように、カーネルのiptablesからパケットをキャプチャすると、転送速度が制限されます（私は理解しています）。したがって、インターフェイスでキャプチャして（つまり定期的に）送信者側にログオンすると2 GBのダンプが得られますが、iptablesでキャプチャされて送信者側にログオンすると1 GBのダンプが得られます。大まかに言えば。
アップデート4：
最後に、私のプロジェクトは私の答えで説明されているLinuxブリッジングソリューションを使用します。
ベストアンサー1
~によると一般ネットワークのNetfilterとパケットフロー回路図、tcpdumpキャプチャ（AF_PACKET) 後ろにエクスポート(qdisc)。したがって、tcpdumpで遅延が表示されないのは正常です。遅延は、初期キャプチャ時点に既に存在する。
一歩先にこれを捉える必要があるので、3番目のシステムが必要です。
S1：system1、発信インターフェイスでtcpdumpを実行する
R：ルータ（または利便性によってブリッジ、何も変わらない）、qdisc netemを
実行
__________________ ________________ __________________
| | | | | |
| (S1) -- tcpdump -+---+- (R) -- netem -+---+- tcpdump -- (S2) |
|__________________| |________________| |__________________|
これは3つのネットワークを意味します。スタック物理かどうかに関係なく、仮想マシン、ネットワークネームスペース（含む）IPネットワーク,LXC,...)
または、なりすましを使用してルーター（またはブリッジ）の各特殊設定を移動するIFBとインターフェース鏡フロー：トリックを介して送信の代わりに受信後に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つのネットワークスタックが必要です。
使用ニューラルネットワークログ
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 ...