CA-PA-Erklärung (Hyper-V SDN)

CA-PA-Erklärung (Hyper-V SDN)

Ich betreibe mehrere VMs in Azure. VMs laufen in einem Subnetz mit NSG. NICs verwenden keine NSGs, wir nutzen kein beschleunigtes Networking.

Mir fällt auf, dass, wenn eine VM über TCP mit einer anderen VM desselben Subnetzes kommuniziert, der MSS-Wert in den SYN-Paketen um 42 reduziert wird. Das bedeutet, wenn ich ein TCP SYN mit MSS=876 an eine andere VM desselben Netzwerks sende, erfasst die andere VM ein TCP SYN mit MSS=834:

Klient:

18:49:27.526527 IP 10.56.142.25.49614 > 10.56.142.108.ssh: Flags [S], seq 3092614737, win 17520, options [mss 876,sackOK,TS val 2936204423 ecr 0,nop,wscale 7], length 0
18:49:27.528398 IP 10.56.142.108.ssh > 10.56.142.25.49614: Flags [S.], seq 1710658781, ack 3092614738, win 28960, options [mss 1418,sackOK,TS val 390195731 ecr 2936204423,nop,wscale 7], length 0
18:49:27.528430 IP 10.56.142.25.49614 > 10.56.142.108.ssh: Flags [.], ack 1, win 137, options [nop,nop,TS val 2936204425 ecr 390195731], length 0

Server:

18:49:27.527362 IP 10.56.142.25.49614 > 10.56.142.108.ssh: Flags [S], seq 3092614737, win 17520, options [mss 834,sackOK,TS val 2936204423 ecr 0,nop,wscale 7], length 0
18:49:27.527682 IP 10.56.142.108.ssh > 10.56.142.25.49614: Flags [S.], seq 1710658781, ack 3092614738, win 28960, options [mss 1460,sackOK,TS val 390195731 ecr 2936204423,nop,wscale 7], length 0
18:49:27.529167 IP 10.56.142.25.49614 > 10.56.142.108.ssh: Flags [.], ack 1, win 137, options [nop,nop,TS val 2936204425 ecr 390195731], length 0

Wir verwenden mehrere NVAs, und unsere SYN-Pakete durchlaufen mehrere Hops. Tatsächlich sehen wir, dass die MSS mehrfach reduziert wird. Ursprünglich haben wir eine Reduzierung um 84 gemessen, in einigen Fällen haben wir auch eine Reduzierung um 138 gemessen (tatsächlich kein Vielfaches von 42). Das heißt, wir reduzieren die Effizienz unseres Netzwerks um mehr als 10 %.

Ich habe einige Zeit damit verbracht, zu untersuchen, wie verschiedene Netzwerkgeräte mit dem MSS umgehen. In den meisten Fällen ist der MSS auf einen festen Wert eingestellt, indem er entweder an einen statischen Wert oder an die Pfad-MTU geklammert wird. PaloAlto verwendet eine „Anpassung“, die relativ zur MTU einer Netzwerkschnittstelle ist, die ein fester Wert ist. Arista ermöglicht es Ihnen, einen Höchstwert für eingehenden oder ausgehenden Datenverkehr festzulegen, auch hier handelt es sich um absolute Werte. Einige Firewall-Anbieter wie PaloAlto reduzieren den MSS im Falle eines DoS-Angriffs und aktivierter SYN-Cookies, aber der MSS ist in diesem Fall einer von 8 möglichen Werten.

Ich glaube, dass dieser MSS -= 42-Mechanismus TCP unterbricht: Wenn der Client Jumbo-Frames unterstützt und einen MSS von 8860 sendet, empfängt der Server in Azure 8876, antwortet selbst mit 1330, aber der Client empfängt 1246. Der Client stimmt zu, dass Pakete eine Nutzlast von 1246 Byte haben sollten, während der Server eine Nutzlast von 1330 Byte sendet.

Das größte Problem sind Fälle, in denen der Verkehr „zufällig“ funktioniert. Die Klemmung wird auf der Expressroutenseite nicht richtig durchgeführt, aber aufgrund dieser -42 hier und da wird die MSS tatsächlich auf einen Wert reduziert, der „passt“, bis es eine kleine Änderung in der Art und Weise gibt, wie Pakete geroutet werden, und Sie plötzlich feststellen, dass irgendwo eine Fehlkonfiguration vorlag.

Irgendeine Idee, wie diese Verringerung zu erklären ist? Ich glaube, dieses Verhalten ist nirgendwo dokumentiert.


BEARBEITEN

Nur lesenRFC879

Die MSS können in jeder Datenflussrichtung völlig unabhängig voneinander verwendet werden. Das Ergebnis können sehr unterschiedliche Maximalgrößen in den beiden Richtungen sein.

Laut RFC sieht es also legitim aus. Trotzdem ein seltsames Verhalten.

Antwort1

Im Gegensatz zu physischen Netzwerken verbraucht SDN-Netzwerke zusätzliche „Bytes“ für Kapselungsheader (GRE). Die sichtbaren IPs sind CA (Kundenadresse), aber es gibt auch PA (Anbieteradresse), die Routing beim Cloud-Anbieter erfordert. Daher stehen weniger MSS zur Verfügung, da der Cloud-Anbieter zusätzliche TCP-Klemmungen in der Infrastruktur anwendet, damit Backend-Routing erfolgen kann.

CA-PA-Erklärung (Hyper-V SDN)

https://docs.microsoft.com/en-us/windows-server/networking/sdn/technologies/hyper-v-network-virtualization/hyperv-network-virtualization-technical-details-windows-server

verwandte Informationen