tcpdump 记录中未看到 Tc qdisc 延迟

tcpdump 记录中未看到 Tc qdisc 延迟

我有两个通过 veth-pair 连接的 Linux 容器。在一个容器的 veth 接口上,我设置了 tc qdisc netem 延迟并将流量从它发送到另一个容器。如果我使用 tcpdump/wireshark 观察两侧的流量,可以看到发送方和接收方的同一数据包的时间戳不会因所选延迟而有所不同。

我想更详细地了解 libpcap 在哪一点将时间戳放入与 tc qdisc 相对应的出口流量中。我在互联网上搜索了方案/图像但没有找到。我发现了这个话题(wireshark抓包点)但它建议通过多一个容器/接口来引入一种间接。对于我的情况来说,这不是一个可能的解决方案。有没有办法解决这个问题,不引入额外的中间接口(即不改变拓扑),只通过在已经给定的 veth 接口处记录,但以这样的方式可以看到延迟?

更新:

我太快了,所以搞错了。下面给出的我的解决方案(与@AB答案的第一个解决方案变体相同)和@AB的IFB解决方案(我已经检查过)都不能解决我的问题。问题在于a1-eth0拓扑中发送方接口的传输队列溢出:

[a1-br0 ---3Gbps---a1-eth0]---100Mbps---r1---100Mbps---r2

我太快了,只检查了a1-eth0与路由器之间的链路是否有 10 毫秒的延迟r1。今天,我尝试提高延迟:100ms、200ms,结果(我得到的每个数据包延迟和速率图)对于上面的拓扑和正常拓扑开始有所不同:

[a1-eth0]---100Mbps---r1---100Mbps---r2

所以,当然,为了准确的测试,我不能有额外的链接:也不能由 Linux 桥引入,也不能由这个 IFB 引入,也不能由任何其他第三系统引入。我测试拥塞控制方案。我想在特定的拓扑中做到这一点。我不能仅仅为了绘图而改变拓扑——我的意思是如果同时我的速率和延迟结果/图发生改变。

更新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 中看不到延迟是正常的:延迟在初始捕获时已经存在。

您必须提前一步捕获它,因此涉及第三个系统:

S1:system1,在传出接口上运行 tcpdump
R:路由器(或网桥,在您方便时,这不会改变任何内容),运行 qdisc netem
S2:system2,在传入接口上运行 tcpdump

 __________________     ________________     __________________
|                  |   |                |   |                  |
| (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

只需使用内特姆在 ifb0 而不是 sfq 上(并且在非初始网络命名空间中,ip link add name ifbX type ifb工作正常,无需 modprobe)。

这仍然需要 3 个网络堆栈才能正常工作。


使用神经网络日志

经过 JenyaKh 的建议后,事实证明可以使用以下命令捕获数据包tcp转储,出口(因此在 qdisc 之前)然后在出口(在 qdisc 之后):通过使用iptables(或者nftables)将完整数据包记录到 netlink 日志基础设施,并仍然使用tcp转储,然后再次使用tcp转储在出口接口上。这仅需要 S1 上的设置(并且不再需要路由器/网桥)。

所以与iptables在 S1 上,类似:

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---r2我将网络速率设置为 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 网桥创建了拓扑(上面绘制的第三个拓扑),并在拓扑中启动了从a1到 的流量r2。我检查了以 500ms 间隔循环a1-eth0调用命令的传输队列的积压(队列中的当前数据包数量)以及使用类似命令的传输队列的积压。tc -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不同于a1和 router之间的链接(veth 对链接) r1。我不知道为什么会这样。这很奇怪,因为我检查过我可以将 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 路由器的一个接口 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)----- 

相关内容