tcpdumpの記録にTcqdiscの遅延が見られない
2つのLinuxコンテナがveth-pairに接続されています。 1つのコンテナのveth-interfaceで、tc qdisc netem delayを設定し、そこから他のコンテナにトラフィックを送信します。 tcpdump/Wiresharkを使用して両側のトラフィックを監視すると、送信者と受信者の同じパケットのタイムスタンプが、選択した遅延によって異ならないことがわかります。
Libpcapがtcqdiscに対応する出力トラフィックにタイムスタンプを配置する時点をより詳細に理解したかったのです。インターネットでスキーム/画像を検索しましたが見つかりませんでした。このトピックを見つけました（ wiresharkパケットキャプチャポイント ）が、もう1つのコンテナ/インターフェイスを使用して間接参照を導入することをお勧めします。これは私の状況では可能な解決策ではありません。追加の中間インターフェースを導入せずに（つまり、トポロジーを変更せずに）、すでに与えられたvethインターフェースで記録するだけで、遅延が見られるような方法で問題を解決する方法はありますか？
更新：
私は速すぎたので間違えました。以下に示す私の解決策（@ A.Bの答えの解決策の最初の変形と同じ）も、@ A.BのIFBを使用した解決策（私はすでにチェックしました）も私の問題を解決しません。問題は、トポロジ内の送信者のインターフェイスa1-eth0の送信キューのオーバーフローにあります。
[a1-br0 ---3Gbps---a1-eth0]---100Mbps---r1---100Mbps---r2
私は速すぎて、a1-eth0とルーターr1の間のリンクで10msの遅延しかチェックしませんでした。今日、私は遅延をより高くしようとしました：100ms、200ms、そして結果（私が得るパケットごとの遅延とレートグラフ）は上記のトポロジーと通常のトポロジーで異なり始めます：
[a1-eth0]---100Mbps---r1---100Mbps---r2
したがって、確かに、正確なテストのために、追加のリンクを設定することはできません。Linuxブリッジ、このIFB、または他の3番目のシステムによって導入されることもありません。輻輳制御方式をテストします。そして、私は特定のトポロジーでそれをやりたいと思っています。また、プロットのためだけにトポロジを変更することはできません。つまり、レートと遅延の結果/プロットが同時に変更された場合です。
更新2：
したがって、以下に示すように、解決策が見つかったように見えます（NFLOGソリューション）。
更新3：
ここでは、NFLOGソリューションのいくつかの欠点（大きなリンク層ヘッダーと間違ったTCP出力のチェックサムTCPペイロードがゼロのパケット））について説明し、これらの問題のいずれも持たないNFQUEUE： 長さがゼロの出力パケット（iptablesでキャプチャされた）のTCPチェックサムが間違っている 。ただし、私のタスク（輻輳制御スキームのテスト）には、NFLOGもNFQUEUEも適していません。同じリンクで説明されているように、パケットがカーネルのiptablesからキャプチャされると、送信速度が抑制されます（これが私が理解している方法です）。したがって、インターフェイスからキャプチャして送信者で記録すると（つまり、定期的に）、2ギガバイトのダンプが取得されます。 、iptablesからキャプチャして送信者で記録すると、1ギガバイトのダンプが得られます。大まかに言えば。
更新4：
最後に、私のプロジェクトでは、以下の自分の回答で説明されているLinuxブリッジソリューションを使用しています。
NetfilterおよびGeneral Networkingのパケットフロー 回路図によると、tcpdumpはegress（qdisc）の後に（AF_PACKET）をキャプチャします。したがって、tcpdumpに遅延が表示されないのは正常です。遅延は最初のキャプチャ時にすでに存在していました。
1ステップ早くキャプチャする必要があるため、3番目のシステムを使用します。
S1：system1、発信インターフェイスでtcpdumpを実行します
R：ルーター（またはブリッジ、都合の良いときに、これは何も変更しません）、qdiscnetemを実行します
S2：system2、着信インターフェイスでtcpdumpを実行します
__________________ ________________ __________________
| | | | | |
| (S1) -- tcpdump -+---+- (R) -- netem -+---+- tcpdump -- (S2) |
|__________________| |________________| |__________________|
つまり、3つのネットワークstacksが関係していて、実際、vm、ネットワーク名前空間（ip netns、LXCなどを含む）
オプションで、 [〜＃〜] ifb [〜＃〜] インターフェイスとmirredを使用して、ルーター（またはブリッジ）のすべての特別な設定をだまして移動することもできます。トラフィック：トリック（この場合専用）によって、出力ではなく入力の後にnetemを挿入できるようにします。
_______ ______________________________________________ _______
| | | | | |
| (S1) -+---+- tcpdump -- ifb0 -- netem -- (R) -- tcpdump -+---+- (S2) |
|_______| |______________________________________________| |_______|
tc mirredのマンページに基本的なIFBの使用例があります：
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でnetemを使用するだけです（初期以外のネットワーク名前空間では、ip link add name ifbX type ifb modprobeなしで正常に動作します）。
これでも、適切に機能するには3つのネットワークスタックが必要です。
[〜＃〜] nflog [〜＃〜] を使用
JenyaKhからの提案の後、tcpdump、before egress（つまり、qdiscの前）でパケットをキャプチャし、次にegress（qdiscの後）でキャプチャすることが可能であることがわかりました。 iptables（またはnftables）は、完全なパケットをnetlinkログインフラストラクチャに記録し、それでもtcpdump、次に、出力インターフェイスでtcpdumpを再度使用します。これにはS1の設定のみが必要です（ルーター/ブリッジはもう必要ありません）。
したがって、S1でiptablesを使用すると、次のようになります。
iptables -A OUTPUT -o eth0 -j NFLOG --nflog-group 1
tcpdumpフィルターはnflogインターフェイスで制限されているため（wiresharkはそれをより適切に処理する必要があります）、実行されたテストに一致するように特定のフィルターを追加する必要があります。
回答のキャプチャが必要な場合（ここでは別のグループで行われるため、追加のtcpdumpが必要です）：
iptables -A INPUT -i eth0 -j NFLOG --nflog-group 2
必要に応じて、代わりにraw/OUTPUTおよびraw/PREROUTINGに移動することもできます。
tcpdumpの場合：
# tcpdump -i nflog:1 -n -tt ...
別のグループ（= 2）が入力に使用された場合：
# tcpdump -i nflog:2 -n -tt ...
それから同時に、いつものように：
# tcpdump -i eth0 -n -tt ...
更新：
だから私はついにこのソリューションを使用しました。それは私のソリューションに存在します。結局、それは私にとってうまくいきました。
I (the topic starter) have solved my problem using Linux bridge. Here [ https://www.linuxquestions.org/questions/linux-networking-3/transferring-all-traffic-through-an-extra-interface-4175656515 ] I wrote that I managed to use Linux bridge but dismissed the possibility: "But this solution does not suit my needs, as there is an extra Ethernet link between h1-br0 and h1-eth0 interfaces in reality. I need this stuff for performance measurements so I cannot have any extra Ethernet links. I mean this solution with bridge messes up my topology by introducing extra links."
a1
-----------------
|a1-br0---a1-eth0|---------local network
------------------
なぜ最初に解決策を却下したのですか？最初、私のトポロジーは次のとおりです。
a1---3Gbps---r1---100Mbps---r2
リンクr1---r2ではネットレートを100Mbpsに設定していますが、リンクa1---r1ではレート制限はありません。ルーターr1に接続しているルーターr2の送信キューは1000パケットであるため、a1からr2にトラフィックを送信すると、キューのオーバーフロー（一部のパケットがドロップされる）の影響がありました。そして、これは大丈夫でした。これは、ボトルネックリンクの場合にルーターキューがオーバーフローする現実の世界で発生する方法です。
今、私はこのすべての調査を行って、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からr2に流れるトポロジでトラフィックを開始しました。 a1-eth0の送信キューのバックログ（キュー内の現在のパケット数）を500ms間隔でコマンドtc -s qdisc show dev a1-eth0を呼び出し、同様のコマンドを使用してa1-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の間のリンクは、a1とルーターr1の間のリンク（vethペアリンク）とは異なります。なぜそうなのかわかりません。たとえば、netem遅延設定をa1-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)-----