Modelado de tráfico usando tc-netem en macvlan

Modelado de tráfico usando tc-netem en macvlan

Estoy configurando una red virtual usando macvlans y he conectado tc de control de tráfico a cada uno de ellos. Configuré el retraso para cada uno en 90 ms. Pero en el ping obtengo un tiempo de 0,02 segundos. ¿Por qué tc no funciona en macvlan?

Estoy usando los siguientes comandos:

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

y luego hacer ping desde la ip de m1 a la ip de m2. m1 y m2 son macvlans.

Respuesta1

Su problema está relacionado con cómo se realiza el enrutamiento, no contc,netemomacvlan.

Cuando se llega desde una dirección IP que pertenece al host a otra dirección IP que pertenece al host, la ruta utiliza la lointerfaz (loopback), consultando la tabla de enrutamiento local (oculta, try ip route show table local) y nunca usa las interfaces reales donde estaban las direcciones IP. asignado a.

Puede verificar esto preguntando al kernel la ruta que elegirá. Por ejemplo, si las direcciones enm1ym2fueron 192.0.2.2/24 y 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> 

Si necesita realizar pruebas con esas interfaces, necesitará otro sistema con su propia pila de enrutamiento para probarlas. Este sistema podría ser un host real, una máquina virtual, un contenedor o simplemente usar uno (o varios) espacios de nombres de red adicionales, como probablemente comenzó a hacer.

En mi caso hipotético anterior, si 192.0.2.1 estuviera enm1LAN de (y elm2interfaz se mantuvo baja para evitar posibles problemas ARP no relacionados), ping 192.0.2.1mostraría el retraso, porquem1Sería usado:

# 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 

El primer ping normalmente conllevaría el doble de penalización por retraso porque también se realiza antes una solicitud ARP para resolver el enlace IP, que también se retrasa.

información relacionada