macvlan에서 tc-netem을 사용한 트래픽 조절

macvlan에서 tc-netem을 사용한 트래픽 조절

나는 macvlans를 사용하여 가상 네트워크를 설정하고 있으며 각각에 트래픽 제어 tc를 연결했습니다. 각각의 지연을 90ms로 설정했습니다. 하지만 ping에서는 0.02초의 시간이 걸립니다. TC가 macvlan에서 작동하지 않는 이유는 무엇입니까?

다음 명령을 사용하고 있습니다.

tc qdisc add dev m1 root netem delay 90ms
tc qdisc add dev m2 root netem delay 90ms

그런 다음 m1의 ip에서 m2의 ip로 ping을 보냅니다. m1과 m2는 macvlan입니다.

답변1

귀하의 문제는 라우팅이 수행되는 방식과 관련이 있습니다.TC,네템또는맥블란.

호스트에 속한 IP 주소에서 호스트에 속한 다른 IP 주소에 도달할 때 경로는 lo로컬 라우팅 테이블(hidden, try ip route show table local)을 참조하여 (루프백) 인터페이스를 사용하고 IP 주소가 있었던 실제 인터페이스를 사용하지 않습니다. 할당.

커널이 선택할 경로를 물어보면 이를 확인할 수 있습니다. 예를 들어 주소가m1그리고m2192.0.2.2/24 및 192.0.2.3/24입니다.

# ip route get from 192.0.2.2 to 192.0.2.3
local 192.0.2.3 from 192.0.2.2 dev lo table local uid 0 
    cache <local> 

해당 인터페이스로 테스트를 수행해야 하는 경우 이를 테스트할 자체 라우팅 스택이 있는 다른 시스템이 필요합니다. 이 시스템은 실제 호스트, VM, 컨테이너일 수도 있고 이미 시작했던 것처럼 단순히 (또는 여러) 추가 네트워크 네임스페이스를 사용하는 것일 수도 있습니다.

위의 가상 사례에서 192.0.2.1이m1의 LAN(및m2관련되지 않은 ARP 문제를 피하기 위해 인터페이스가 유지되었습니다.) ping 192.0.2.1지연이 표시됩니다.m1다음과 같이 사용됩니다:

# ip route get from 192.0.2.2 192.0.2.1
192.0.2.1 from 192.0.2.2 dev m1 uid 0 
    cache 

첫 번째 핑은 일반적으로 지연 페널티를 두 배로 받습니다. 왜냐하면 IP 링크를 확인하기 전에 수행된 ARP 요청도 있기 때문에 이 요청 역시 지연되기 때문입니다.

관련 정보