我发现了一篇有趣的文章,它描述了如何模拟网络问题 (就像丢失的包)在linux服务器上。
在Ubuntu测试VM上,我检查了用于internet连接的接口,它被称为ens33。
然后,我添加了一条使用tc引入丢包的规则:
$ sudo tc qdisc add dev ens33 root netem loss 30% 50% 然后我让ping运行了一段时间,结果和预期的一样,一些数据包丢失了:
$ ping www.google.com
...
97 packets transmitted, 84 received, 13% packet loss当ping运行时,我想我也可以使用ip -s link show ens33来监视正在进行的数据包丢失,但是它显示了RX和TX的0丢弃数据包。
当ping运行时,我要做的是实时监控数据包丢失。
发布于 2023-04-07 18:46:07
tc还接受一个-s参数,其含义相同:统计信息。
示例在veth链接上应用到地址为10.0.3.128的LXC容器的根:
# echo; tc qdisc del dev vethlzYQu1 root 2>/dev/null; \
ip neigh flush all; \
tc qdisc add dev vethlzYQu1 root netem loss 30% 50%; \
tc -s qdisc show dev vethlzYQu1 root; \
ping -q -c 10 10.0.3.128; \
tc -s qdisc show dev vethlzYQu1 root
qdisc netem 8010: root refcnt 5 limit 1000 loss 30% 50%
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
PING 10.0.3.128 (10.0.3.128) 56(84) bytes of data.
--- 10.0.3.128 ping statistics ---
10 packets transmitted, 8 received, 20% packet loss, time 9193ms
rtt min/avg/max/mdev = 0.030/125.218/1001.185/331.084 ms
qdisc netem 8010: root refcnt 5 limit 1000 loss 30% 50%
Sent 826 bytes 9 pkt (dropped 3, overlimits 0 requeues 0)
backlog 0b 0p requeues 0在这里,应该发送9+3=12数据包,其中两个丢弃的数据包来自ping,另一个可能是重试的ARP请求。
如果需要在shell中解析tc的S输出,最好沿着jq使用它的JSON输出:
# tc -s -json qdisc show dev vethlzYQu1 root | jq '.[].drops'
3https://unix.stackexchange.com/questions/742268
复制相似问题