브리지 인터페이스에서 네트워크 손실을 시뮬레이션하려고 합니다.
내 서버에는 현재 연결이 끊어진 br0 및 eth0에 브리지된 4개의 네트워크 인터페이스 eth1, eth2 및 eth3이 있습니다. 실제로 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합니다 .netemoutgoing
이해하기 쉬운 예는 다른 브리지를 추가 eth1하고 veth링크를 첫 번째 브리지와 쌍을 이루는 것입니다. 그런 다음 이 추가 브리지의 인터페이스 tc에 규칙을 적용할 수 있습니다 . 들어오는 패킷이 이 인터페이스를 통해 나가기 때문에 예상대로 작동합니다. .vetheth1veth
하지만 사실중간 펑션블록 장치 ( ifb0)네트워크 흐름에서 수신/입국 인터페이스 바로 뒤에 인공적인 내부 송신 인터페이스를 삽입하여 이러한 문제를 해결하도록 설계되었습니다. ifb0여전히 대부분의 다른 네트워크 계층 앞에 위치하며 대부분 눈에 띄지 않습니다. 나가는/나가는 것(그러나 내부만 해당)이므로 netem처리됩니다.
그러니까 이건 해결해야 할 netem문제 야들어오는바꾸다나가는eth1ifb0다음 예에서 채택된 기술을 사용하여 인터페이스의 트래픽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다리 위에서도 작동합니다.