我试图模拟桥接接口上的网络丢失.
我的服务器eth1上有4个网络接口,eth2和eth3在br0和eth0中桥接,目前已断开连接.事实上,eth2也是断开的(向下).我已将eth1连接到视频传输设备,eth3直接连接到网络交换机.
接收设备连接到同一个交换机,但在另一个端口上.我正在使用netem来模拟路径上的网络损伤.这是我的netem命令的一个例子：
sudo tc qdisc add dev eth1 root netem delay 100ms 50ms loss 20％.
如果我对发送器执行ping操作,我将获得使用此命令配置的时间延迟,抖动和数据包丢失,但这不会影响发送器和解码器之间的网络传输.如果我在eth3上运行相同的命令,发送器和接收器之间的链接开始下降,但问题是如果我将eth1定义为网络接口,那么传输运行正常？

解决方法:

在tc-netem(8)(粗体矿)中描述了这种行为的原因：

delay

adds the chosen delay to the packets outgoing to chosen network
interface.

要么

loss random

adds an independent loss probability to the packets outgoing from the
chosen network interface.

所以tc … netem仅适用于传出数据包,对来自eth1的传入数据包没有影响.将规则应用于eth3允许netem具有意图效果,因为它现在是视频流量的传出接口.

如果eth3不应该应用这样的规则,因为它应该正常运行与eth1无关的流量,并且只有来自eth1的传入流量应该受到这些规则的影响,那么应该在eth1和桥接器之间放置一个中间接口以便使用netem适用于外向的一方.

一个易于理解的例子是添加一个其他网桥奴役eth1并且还与一个veth对链接到第一个网桥：然后tc规则可以应用于这个附加网桥的veth接口：因为来自eth1的传入数据包将会通过这个veth接口传出,它将按预期工作.

但实际上,Intermediate Functional Block device (ifb0)设计用于通过在传入/入口接口之后在网络流中插入人工内部出口接口来用于此类问题. ifb0仍将位于大多数其他网络层之前,并且几乎不可见.由于它是传出/出口(但仅在内部),因此netem将对其起作用.

所以这里有一个解决方案,让netem工作在eth1接口上的传入而不是传出流量,使用ifb0的技巧改编自tc-mirred(8)的例子：

ip link add ifb0 type ifb || :
ip link set ifb0 up
tc qdisc add dev ifb0 root netem delay 100ms 50ms loss 20%
tc qdisc add dev eth1 handle ffff: ingress
tc filter add dev eth1 parent ffff: u32 match u32 0 0 action mirred egress redirect dev ifb0

u32匹配u32 0 0是最简单的ANY过滤器,用于接受过滤命令.

当然,当eth1处于桥梁中时,它也可以工作.