☰

Wird die Verkehrssteuerung innerhalb des Namespace auf von OpenvSwitch erstellten Ports unterstützt?

tag-icon • tag-icon linux networking ip tc namespace
Wird die Verkehrssteuerung innerhalb des Namespace auf von OpenvSwitch erstellten Ports unterstützt?

Ich versuche, die Bandbreite einer Schnittstelle innerhalb eines Namespace mit tc zu begrenzen, ohne großen Erfolg. Scheint nicht unterstützt zu werden gemäßhttps://lists.linux-foundation.org/pipermail/containers/2009-September/020473.html

Dies ist auf CentOS 6.5. Das Merkwürdige ist, dass es normal funktioniert, wenn ich die Anleitung hier verwende:http://gigawhitlocks.com/2014/08/18/network-namespaces.htmlEs muss also etwas Besonderes mit diesem von OpenStack innerhalb des Namespace erstellten Port passieren. Der Port, der nicht funktioniert, ist ein Port, der als Gateway für einen virtuellen Router innerhalb von OpenStack dient.

Edit2: Noch ein paar Infos zur Schnittstelle, die mit tc nicht funktioniert:
ip netns exec qrouter-6a080f37.. ethtool -S qr-a9b3962f-d4 no stats available

Bearbeiten: Anscheinend hat jemand anderes das gleiche Problem mit Ports, die von Openvswitch in einem Namespace erstellt wurdenhttp://openvswitch.org/pipermail/discuss/2014-May/013925.html

Der folgende Befehl schlägt mit RTNETLINK-Antworten einfach fehl: Ungültiges Argument:

# 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

Antwort1

Ich hatte ein ähnliches Problem. Es meldet keinen Fehler wie Ihr Qdisc-Befehl, wenn ich Qdisc zum internen QR-Port hinzufüge, aber der Datenverkehr wird einfach nicht gedrosselt und läuft die ganze Zeit mit der Leitungsgeschwindigkeit. Ich habe eine Weile gegoogelt und kann keine Lösung finden. Eine hässliche Möglichkeit, den Datenverkehr zu drosseln, ist die Verwendung des Limit-Moduls von iptable, mit dem es unmöglich ist, eine stabile Rate für den TCP-Fluss zu erreichen, und es ist schwierig, das Limit-Argument in die tatsächliche Bandbreite zu übersetzen.

verwandte Informationen