Ubuntu 18.04 LTS 호스트에서 Firecracker를 사용하여 두 개의 microVM을 설정하고 각각에 대해 tun/tap 장치를 연결했습니다. 이제 두 VM 사이에 200ms의 RTT를 얻을 수 있도록 두 VM 사이에 지연(예: 100ms)을 설정하려고 하는데 tc제대로 작동하지 않는 것 같습니다.
이상적으로는 두 장치를 직접 지정하고 싶지만 tc작동하려면 해당 네트워크를 지정해야 할 것 같습니다.
탭이 설정되는 방법은 다음과 같습니다(규정에 따라).폭죽 문서), 각 머신 A와 B에 대해 하나씩:
# create a tap device
sudo ip tuntap add tapA mode tap
sudo ip tuntap add tapB mode tap
# set up tap device ip address
sudo ip addr add 10.0.0.29/30 dev tapA
sudo ip addr add 10.0.0.33/30 dev tapB
# set up tap device
sudo ip link set tapA up
sudo ip link set tapB up
# enable forwarding
sudo sh -c "echo 1 > /proc/sys/net/ipv4/ip_forward"
# add iptables config
sudo iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
sudo iptables -A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
sudo iptables -A FORWARD -i tapA -o eth0 -j ACCEPT
sudo iptables -A FORWARD -i tapB -o eth0 -j ACCEPT
보시다시피 각 컴퓨터에 작은 전용 네트워크( 10.0.0.28/30A 및 10.0.0.32/30B용)를 제공하고 탭이 호스트 측에서 얻을 IP 주소를 지정합니다. 10.0.0.30/30A와 B에 대한 주소(부팅 시 설정된 구성)를 사용하여 머신을 부팅하고 10.0.0.34/30있으며 서로 및 호스트에서 성공적으로 핑할 수 있습니다.
tc연구를 통해 작동할 것으로 예상되는 명령을 발견했습니다 .
# create a qdisc for tapA
tc qdisc add dev tapA root handle 1: htb default 1
tc class add dev tapA parent 1: classid 1:1 htb rate 10.0Gbit
tc class add dev tapA parent 1: classid 1:2 htb rate 10.0Gbit ceil 10.0Gbit
# add a delay of 100ms
tc qdisc add dev tapA parent 1:2 handle 2: netem delay 100.0ms
# only apply that delay when the packet comes from A's network and goes to B's network
tc filter add dev tapA protocol ip parent 1: prio 5 u32 match ip dst 10.0.0.32/30 match ip src 10.0.0.28/30 flowid 1:2
# do the same for tapB
tc qdisc add dev tapB root handle 1: htb default 1
tc class add dev tapB parent 1: classid 1:1 htb rate 10.0Gbit
tc class add dev tapB parent 1: classid 1:2 htb rate 10.0Gbit ceil 10.0Gbit
tc filter qdisc add dev tapB parent 1:2 handle 2: netem delay 100.0ms
# but this time going from B's network to A's network
tc filter add dev tapB protocol ip parent 1: prio 5 u32 match ip dst 10.0.0.28/30 match ip src 10.0.0.32/30 flowid 1:2
나는 이것이 A에서 B로 나가는 모든 패킷에 지연을 추가할 것으로 기대하지만 그 반대의 경우도 마찬가지입니다. 그러나 아무 일도 일어나지 않습니다. 이상하게도 다음 필터를 설정하면 작동합니다.
# matching destination of A on A's tap
# this should match incoming packets from B to A on tapA
tc filter add dev tapA protocol ip parent 1: prio 5 u32 match ip dst 10.0.0.28/30 match ip src 10.0.0.32/30 flowid 1:2
# and vice versa for tapB
tc filter add dev tapB protocol ip parent 1: prio 5 u32 match ip dst 10.0.0.32/30 match ip src 10.0.0.28/30 flowid 1:2
내가 올바르게 이해했다면 이는 tc들어오는 패킷을 확인하고 올바른 필터를 적용한다는 의미입니다. 그러나 그것은 실제로 내가 예상했던 일이 아닙니다. 나는 나가는 패킷을 필터링하고 지연시키는 것을 선호합니다. 아니면 내가 뭔가를 놓치고 있는 걸까?
답변1
나는 좀 더 많은 연구를 해왔고 여기서 무슨 일이 일어나고 있는지 이해하기 시작했다고 생각합니다. 자세한 내용을 아시는 분은 아래에 답변을 남겨주세요. 혹시 혹시 혹시 모르시는 분들을 위해 여기에도 설명을 남깁니다.
나는 탭이 호스트뿐만 아니라 microVM에도 동일하게 보인다고 생각했지만 그것은 옳지 않다고 생각합니다. 그림에서 볼 수 있듯이(간단한 ping명령의 단계를 보여줌) A 머신에서 B 머신으로 ping을 보내면 패킷은 A의 관점에서는 나가고 호스트의 관점에서는 들어오게 됩니다. tapA장치는 A의 장치에 연결됩니다 eth0. 두 장치가 함께 실제로 tun/tap. 따라서 패킷은 `tapB`로 나가고 B로 들어오게 됩니다.
나가는 패킷만 관리할 수 있고 들어오는 패킷은 관리할 수 없기 때문에 tc(적어도 다른 가상 인터페이스를 통해 리디렉션하지 않는 경우) A->B 지연 tapB(패킷이 B로 나가는 위치)과 B 에만 적용할 수 있습니다. -> 에 지연이 있습니다 tapA.
지금은 더 나은 방법이 나올 때까지 이 해결 방법을 유지하고 있습니다.