我有两个linux容器与一个veth对连接。在一个容器的veth-接口上,我设置了tc qdisc网络延迟,并将流量从它发送到另一个容器。如果我使用tcpdump/wireshark观察双方的通信量,可以看到发送方和接收方相同数据包的时间戳并不因所选延迟而不同。
我想更详细地了解libpcap在何时将时间戳用于输出与tc对应的流量。我在网上寻找一个计划/图像,但没有找到。我发现了这个主题(wireshark包捕获点),但是它建议通过多一个容器/接口来引入一个间接的方向。在我的情况下,这不是一个可能的解决办法。有没有办法解决这个问题,不引入额外的中间接口(即不改变拓扑),只通过记录已经给定的veth-接口,但这样的方式可以看到延迟?
我太快了,所以搞错了。下面的解决方案(与@A.B的答案的第一个变体相同)和使用IFB的@A.B(我已经检查过)的解决方案都没有解决我的问题。问题在于,在拓扑结构中,发送方的接口a1-eth0的传输队列溢出:
[a1-br0 ---3Gbps---a1-eth0]---100Mbps---r1---100Mbps---r2我太快了,只检查了a1-eth0和路由器r1之间的链路上的延迟10 at。今天,我试图使延迟更高:100 to、200 to和结果(我得到的每包延迟和速率图)对于上面的拓扑和正常的拓扑开始有所不同:
[a1-eth0]---100Mbps---r1---100Mbps---r2因此,当然,为了进行准确的测试,我不能有额外的链接:也不能由Linux桥、这个IFB或者其他任何第三个系统引入。我测试拥塞控制方案。我想在一个特定的拓扑中完成。我不能仅仅为了绘图而改变拓扑--我的意思是,如果同时改变我的速率和延迟结果/图。
所以看起来已经找到了解决方案,如下所示(NFLOG解决方案)。
本文描述了NFLOG解决方案的一些缺点(大链路层报头和错误的TCP校验和用于零有效负载的出口TCP包),并提出了一种更好的解决方案,它不存在这些问题:零长度出口数据包的TCP校验和错误(用iptables捕获)。但是,对于我的任务(测试拥塞控制方案),NFLOG和NFQUEUE都不适合。正如同一链接所解释的那样,当从内核的iptable捕获数据包时,发送速率会受到限制(我就是这样理解的)。因此,当您通过从接口(即定期捕获)记录发送方时,您将获得2G的转储,而如果您通过从iptables捕获发送方记录,则可以获得1G的转储。粗略地说。
最后,在我的项目中,我使用了在我自己的答案中描述的Linux解决方案。
发布于 2019-06-28 09:15:27
根据Netfilter和通用网络中的分组流原理图,tcpdump捕获(AF_PACKET)在出口(qdisc)之后。所以,在tcpdump中没有看到延迟是正常的:延迟在初始捕获时已经存在。
您必须提前一步捕获它,因此需要使用第三个系统:
S1: system1,在输出接口上运行tcpdump
R:路由器(或者网桥,在方便的情况下,这不会改变什么),运行qdisc netem。
S2: system2,在传入接口上运行tcpdump
__________________ ________________ __________________
| | | | | |
| (S1) -- tcpdump -+---+- (R) -- netem -+---+- tcpdump -- (S2) |
|__________________| |________________| |__________________|这意味着涉及3个网络堆栈,无论它们是真实的,vm,网络名称空间(包括ip网,LXC,.)
另外,还可以通过使用带有镜像通信量的IFB接口来欺骗和移动路由器(或网桥)上的每个特殊设置:允许通过一个技巧(专门用于本例)在入口后而不是在出口上插入netem排序-of-of:
_______ ______________________________________________ _______
| | | | | |
| (S1) -+---+- tcpdump -- ifb0 -- netem -- (R) -- tcpdump -+---+- (S2) |
|_______| |______________________________________________| |_______|在tc镜像手册中有一个基本的IFB使用示例:
使用ifb接口,可以通过sfq:#mod探针ifb # ip链路设置ifb0设置# tc + dev ifb0根sfq # tc添加dev eth0句柄ffff: ingress # tc筛选器添加dev eth0父ffff: u32 \ match u32 0\ action镜像出口重定向dev ifb0的实例发送入口流量。
只需在图腾上使用ifb0而不是sfq (并且在非初始的网络命名空间中,ip link add name ifbX type ifb工作得很好,没有non探测)。
这仍然需要3个网络栈才能正常工作。
使用
根据JenyaKh的建议,可以使用tcpdump、出口之前(因此在qdisc之前)和出口(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 ...发布于 2019-06-28 17:45:59
所以我终于用了这个解决方案。它存在于我的解决方案中。这对我来说还是很好的。
我(主题初学者)已经使用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的发送队列连接到路由器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 (上面画的第三个拓扑)创建了拓扑,并在从a1到r2的拓扑中启动了流量。我检查了a1-eth0的传输队列的待办事项(队列中的当前数据包数),使用类似的命令调用500 of间隔的循环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对链接)。我不知道为何会这样。这很奇怪,因为我检查了一下,例如,我可以在a1-br0上设置netem延迟设置--所以它就像一个正常的接口。
不管怎样,我检查了桥的解决方案是否满足了我的所有需求。但是,我还没有探究它为什么工作(我指的是上面所解释的--队列溢出等等)。
下面是我在主机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路由器的一个接口与该路由器的另一个接口连接起来。以下是拓扑结构:
------ ------ ------
| 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)----- https://unix.stackexchange.com/questions/523600
复制相似问题