Simulação de perda de pacotes em interface em ponte usando netem

Question

Estou tentando simular uma perda de rede em uma interface em ponte.
Eu tenho 4 interfaces de rede no meu servidor eth1, eth2 e eth3 são conectadas em br0 e eth0, que atualmente está desconectada. Na verdade, a eth2 também está desconectada (abaixo). Eu conectei a eth1 um dispositivo de transmissão de vídeo e o eth3 está conectado diretamente ao switch de rede.
Um dispositivo receptor está conectado ao mesmo switch, mas em outra porta. Eu estou usando o netem para simular deficiências de rede no caminho. Este é um exemplo do meu comando netem:
sudo tc qdisc add dev eth1 root netem delay 100ms 50ms loss 20% .
Se eu fizer ping no transmissor, estou obtendo exatamente o atraso de tempo, o jitter e a perda de pacotes configurados com esse comando, mas isso de alguma forma não afeta o transporte da rede entre o transmissor e o decodificador. Se eu executar o mesmo comando na eth3, o link entre o transmissor e o receptor começa a cair, mas a questão é por que o transporte está funcionando bem se eu definir eth1 como uma interface de rede?

    

Answer 1

O motivo desse comportamento é descrito no tc-netem(8) ( meu negrito):

delay

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

ou

loss random

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

Portanto, tc ... netem funciona apenas nos pacotes de saída e não tem efeito nos pacotes recebidos de eth1 . A aplicação da regra a eth3 permite que netem tenha o efeito desejado, pois agora é uma interface saída para o tráfego de vídeo.

Se eth3 não deveria ter essas regras aplicadas, porque ele deveria se comportar normalmente com o tráfego não relacionado a eth1 , e somente o tráfego entrada de eth1 deveria sofrer essas regras, uma interface intermediária deve ser colocada entre eth1 e a ponte para que netem seja aplicado em outgoing .

Um exemplo fácil de entender seria adicionar outra ponte para escravizar eth1 e também vinculado com um par veth à primeira ponte: a regra tc pode ser aplicada na interface veth de esta ponte adicional: uma vez que os pacotes recebidos de eth1 seriam então enviados através desta interface veth , funcionaria como pretendido.

Mas, na verdade, o dispositivo Intermediate Functional Block ( ifb0 ) foi projetado para ser usado tipo de problema, inserindo uma interface de saída interna artificial no fluxo de rede, logo após a interface de entrada / entrada. ifb0 ainda estará localizado antes da maioria das outras camadas da rede e permanecerá praticamente invisível. Como é de saída / saída (mas apenas internamente), netem funcionará.

Então, aqui está a solução para ter netem funcionando para o tráfego entrada em vez de saída na interface eth1 , usando o truque de ifb0 adaptado de um exemplo de 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 corresponde u32 0 0 é o filtro mais simples possível para o comando filter ser aceito.}}

É claro que também funciona quando eth1 está em uma ponte.