☰

¿Se admite el control de tráfico dentro del espacio de nombres en los puertos creados por OpenvSwitch?

tag-icon • tag-icon linux networking ip tc namespace
¿Se admite el control de tráfico dentro del espacio de nombres en los puertos creados por OpenvSwitch?

Estoy intentando limitar el ancho de banda de una interfaz dentro de un espacio de nombres usando tc sin mucho éxito. Parece que no es compatible segúnhttps://lists.linux-foundation.org/pipermail/containers/2009-September/020473.html

Esto está en CentOS 6.5. Lo extraño es que cuando uso el tutorial que se describe aquí funciona normalmente:http://gigawhitlocks.com/2014/08/18/network-namespaces.htmlEntonces debe ser algo especial lo que le está sucediendo a este puerto creado por Openstack dentro del espacio de nombres. El puerto que no funciona es un puerto que sirve como puerta de enlace para un enrutador virtual dentro de openstack.

Edit2: Más información sobre la interfaz que no funciona con tc:
ip netns exec qrouter-6a080f37.. ethtool -S qr-a9b3962f-d4 no stats available

Editar: Parece que alguien más está encontrando el mismo problema con los puertos creados por openvswitch en un espacio de nombreshttp://openvswitch.org/pipermail/discuss/2014-May/013925.html

El siguiente comando simplemente falla con las respuestas RTNETLINK: Argumento no válido:

# ip netns exec qrouter-6a080f37-4da0-4646-ad36-062b748d15be tc qdisc add dev qr-a9b3962f-d4 root netem loss 30%
RTNETLINK answers: Invalid argument
[root@node-1 ~]# ip netns exec qrouter-6a080f37-4da0-4646-ad36-062b748d15be ip a
43: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
44: qg-4bda7108-d2: <BROADCAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN 
    link/ether fa:16:3e:95:cc:7b brd ff:ff:ff:ff:ff:ff
    inet 119.81.159.206/27 brd 119.81.159.223 scope global qg-4bda7108-d2
    inet 119.81.159.207/32 brd 119.81.159.207 scope global qg-4bda7108-d2
    inet 119.81.159.209/32 brd 119.81.159.209 scope global qg-4bda7108-d2
    inet6 fe80::f816:3eff:fe95:cc7b/64 scope link 
       valid_lft forever preferred_lft forever
47: qr-a9b3962f-d4: <BROADCAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN 
    link/ether fa:16:3e:c2:64:dd brd ff:ff:ff:ff:ff:ff
    inet 192.168.99.1/24 brd 192.168.99.255 scope global qr-a9b3962f-d4
    inet6 fe80::f816:3eff:fec2:64dd/64 scope link 
       valid_lft forever preferred_lft forever
# ip netns exec qrouter-6a080f37-4da0-4646-ad36-062b748d15be tc qdisc add dev qr-a9b3962f-d4 root tbf rate 1mbit burst 10kb limit 100kb
RTNETLINK answers: Invalid argument

Respuesta1

Me encontré con un problema similar. No informa errores como lo hizo su comando qdisc cuando agregué qdisc al puerto qr interno; sin embargo, el tráfico simplemente no se limitó y fue a velocidad de línea todo el tiempo. Busqué en Google un rato y no encuentro la solución. Una forma fea de limitar el tráfico es utilizar el módulo de límite de iptable, que es imposible obtener una velocidad estable en el flujo TCP y es difícil traducir el argumento de límite al ancho de banda real.

información relacionada