Ich richte ein virtuelles Netzwerk mit MacVLANs ein und habe Traffic-Control TC mit jedem von ihnen verbunden. Ich habe die Verzögerung für jedes auf 90 ms eingestellt. Aber beim Ping erhalte ich eine Zeit von 0,02 Sekunden. Warum funktioniert TC auf MacVLAN nicht?
Ich verwende die folgenden Befehle:
tc qdisc add dev m1 root netem delay 90ms
tc qdisc add dev m2 root netem delay 90ms
und dann Ping von der IP von M1 zur IP von M2. M1 und M2 sind MacVLANs.
Antwort1
Ihr Problem bezieht sich auf die Art und Weise des Routings, nicht auftc,netemoderAbonnieren.
Beim Erreichen einer anderen IP-Adresse des Hosts von einer IP-Adresse des Hosts verwendet die Route die lo(Loopback-)Schnittstelle, indem sie die lokale Routing-Tabelle konsultiert (versteckt, try ip route show table local), und verwendet nie die tatsächlichen Schnittstellen, denen die IP-Adressen zugewiesen wurden.
Sie können dies überprüfen, indem Sie den Kernel fragen, welche Route er wählen wird. Wenn beispielsweise die Adressen aufm1Undm2waren 192.0.2.2/24 und 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>
Wenn Sie Tests mit diesen Schnittstellen durchführen müssen, benötigen Sie ein anderes System mit eigenem Routing-Stack, mit dem Sie sie testen können. Dieses System könnte ein echter Host, eine VM, ein Container oder einfach ein (oder mehrere) zusätzliche Netzwerk-Namespaces sein, wie Sie es wahrscheinlich bereits begonnen haben.
In meinem hypothetischen Fall oben, wenn 192.0.2.1 inm1's LAN (und diem2Schnittstelle wurde deaktiviert, um mögliche nicht damit zusammenhängende ARP-Probleme zu vermeiden), ping 192.0.2.1würde die Verzögerung anzeigen, weilm1würde verwendet werden:
# 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
Der allererste Ping würde normalerweise die doppelte Verzögerungsstrafe in Anspruch nehmen, da zuvor auch eine ARP-Anfrage zur Auflösung der IP-Verbindung erfolgte, die ebenfalls verzögert wird.