Configuré dos microVM usando Firecracker en mi host Ubuntu 18.04 LTS y conecté un dispositivo tun/tap para cada uno de ellos. Ahora estoy intentando establecer un retraso entre las dos máquinas virtuales (digamos 100 ms) tcpara obtener un RTT de 200 ms entre ellas, pero parece que no puedo hacerlo funcionar correctamente.
Lo ideal sería especificar los dos dispositivos directamente, tcpero parece que tengo que especificar sus redes para que funcione.
Aquí se explica cómo se configuran los grifos (de acuerdo con lasDocumentación de petardos), uno para cada máquina A y 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
Como puede ver, le doy a cada máquina una pequeña red dedicada ( 10.0.0.28/30para A y 10.0.0.32/30para B) y especifico las direcciones IP que obtendrán los grifos en el lado del host. Estoy arrancando las máquinas con direcciones 10.0.0.30/30para A y 10.0.0.34/30B (configuración configurada en el arranque) y puedo hacer ping entre sí y desde el host.
A partir de mi investigación, encontré los tccomandos que espero que funcionen:
# 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
Esperaría que esto agregue un retraso en todos los paquetes salientes de A a B y viceversa, pero no sucede nada. Por extraño que parezca, configurar estos filtros funciona:
# 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
Si entiendo correctamente, esto significa que tcverifica los paquetes entrantes y aplica el filtro correcto. Pero eso no es realmente lo que esperaba que sucediera; preferiría que los paquetes salientes fueran filtrados y retrasados. ¿O me estoy perdiendo algo?
Respuesta1
He investigado un poco más y creo que estoy empezando a comprender lo que está sucediendo aquí. Si alguien está seguro de los detalles, deje una respuesta a continuación, pero para cualquiera que pueda encontrarse con esto, también dejo mi explicación aquí.
descripción general de los paquetes en un comando ping
Pensé que un grifo tiene el mismo aspecto tanto para el microVM como para el host, pero no creo que sea del todo correcto. Como puede ver en la imagen (que muestra los pasos de un pingcomando simple), cuando envío un ping desde la máquina A a la máquina B, el paquete sale desde la perspectiva de A pero entrante desde la perspectiva del host, ya que los hosts tapAEl dispositivo está conectado a un eth0dispositivo en A. Ambos dispositivos juntos forman en realidad el archivo tun/tap. Por lo tanto, el paquete también sale por `tapB`` y (esto tiene sentido) entra por B.
Dado que tcsolo puedo administrar paquetes salientes y no entrantes (al menos si no los redirige a través de alguna otra interfaz virtual), solo puedo aplicar el retraso A->B tapB(donde el paquete sale a B) y el B ->Un retraso en tapA.
Por ahora mantendré esta solución hasta que aparezca algo mejor.