我正在尝试模拟桥接接口上的网络丢失。
我的服务器上有 4 个网络接口 eth1、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 定义为网络接口，为什么传输运行良好？
答案1
此行为的原因在tc-netem(8)（粗体我的）：
延迟
将所选延迟添加到传出到所选网络接口的数据包。
或者
随机损失
添加一个独立的损失概率从所选网络接口发出的数据包。
所以tc ... netem仅适用于外向的数据包并且没有影响传入数据包来自eth1.应用该规则可以eth3达到netem预期的效果，因为它现在是外向的视频流量接口。
如果eth3不应该应用这样的规则，因为它应该正常处理与无关的流量eth1，并且只有传入来自的流量eth1应遵守这些规则，然后应在网桥之间放置一个中间接口，eth1以便netem在一侧应用outgoing。
一个易于理解的示例是添加另一个桥接器eth1，并与veth第一个桥接器配对链接：然后tc可以将规则应用于veth此附加桥接器的接口：因为传入的数据包eth1将通过此veth接口传出，它将按预期工作。
但实际上中间功能块设备 ( 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 match u32 0 0 是用于接受过滤命令的最简单的 ANY 过滤器。
当然，eth1在桥上时它也有效。