Ich habe mit Firecracker zwei MicroVMs auf meinem Ubuntu 18.04 LTS-Host eingerichtet und an jede von ihnen ein Tun/Tap-Gerät angeschlossen. Jetzt versuche ich, eine Verzögerung zwischen den beiden VMs einzustellen (sagen wir 100 ms), sodass tcich eine RTT von 200 ms zwischen ihnen bekomme, aber ich kriege es einfach nicht hin.
Idealerweise würde ich die beiden Geräte direkt angeben wollen, tcaber es scheint, dass ich ihre Netzwerke angeben muss, damit es funktioniert.
So werden die Abgriffe eingerichtet (entsprechend derFirecracker-Dokumentation), eine für jede Maschine A und 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
Wie Sie sehen, weise ich jeder Maschine ein kleines dediziertes Netzwerk zu ( 10.0.0.28/30für A und 10.0.0.32/30B) und spezifiziere die IP-Adressen, die die Taps auf der Host-Seite erhalten. Ich boote die Maschinen mit Adressen 10.0.0.30/30für A und 10.0.0.34/30B (Konfiguration beim Booten festgelegt) und kann sie erfolgreich voneinander und vom Host aus anpingen.
Durch meine Recherchen habe ich die Befehle gefunden, tcvon denen ich erwarte, dass sie funktionieren:
# 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
Ich würde erwarten, dass dies eine Verzögerung für alle ausgehenden Pakete von A nach B und umgekehrt hinzufügt, aber nichts passiert. Seltsamerweise funktioniert das Setzen dieser Filter:
# 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
Wenn ich das richtig verstehe, bedeutet das, dass tceingehende Pakete geprüft und der richtige Filter angewendet wird. Aber das ist nicht wirklich das, was ich erwartet habe. Ich hätte es vorgezogen, wenn ausgehende Pakete gefiltert und verzögert würden. Oder übersehe ich etwas?
Antwort1
Ich habe noch ein bisschen weiter recherchiert und glaube, ich fange an zu verstehen, was hier vor sich geht. Wenn sich jemand über die Einzelheiten sicher ist, hinterlassen Sie bitte unten eine Antwort, aber für alle, die darauf stoßen, hinterlasse ich hier auch meine Erklärung.
Übersicht über Pakete in einem Ping-Befehl
Ich dachte, dass ein Tap für die MicroVM und den Host gleich aussieht, aber ich glaube nicht, dass das ganz richtig ist. Wie Sie im Bild sehen können (das die Schritte eines einfachen pingBefehls zeigt), ist das Paket, wenn ich einen Ping von Maschine A an Maschine B sende, aus der Perspektive von A ausgehend, aber aus der Perspektive des Hosts eingehend, da das tapAGerät des Hosts an ein eth0Gerät in A angeschlossen ist. Beide Geräte zusammen bilden eigentlich das tun/tap. Daher ist das Paket auch auf „tapB“ ausgehend und (das macht Sinn) auf B eingehend.
Da tcnur ausgehende Pakete verwaltet werden können, aber keine eingehenden (zumindest, wenn Sie sie nicht über eine andere virtuelle Schnittstelle umleiten), kann ich nur die A->B-Verzögerung auf tapB(wenn das Paket an B ausgeht) und die B->A-Verzögerung auf anwenden tapA.
Vorerst behalte ich diesen Workaround bei, bis etwas Besseres kommt.