NSX ALB: Fehlerbehebung bei Service Skalierung im N+M Mode (HTTP 408 Error)

Peter Summa
4. Januar 2024
Reading time: 3 min
NSX ALB: Fehlerbehebung bei Service Skalierung im N+M Mode (HTTP 408 Error)

Der NSX Advanced Load Balancer bietet die Möglichkeit Services über mehrere Service Engines (SE) zu skalieren. Dabei gibt es 2 Modi, N+M Mode und Active/Active.

Im N+M Mode wird standardmäßig jeder Service auf einer SE platziert.

Dabei ist N die minimale Anzahl an SE´s und M die Anzahl der zusätzlichen SE´s in der Service Engine Group. Diese Berechnung wird anhand des „virtual services per Service Engine“ Parameter auf der jeweiligen SE-Group ermittelt.

Um die Ausfallzeit von einer SE zu minimieren lassen sich die Services über mehrere SE´s in der Service Engine Group verteilen, somit wird einer höhere Performance und Ausfallsicherheit erzielt.

Ein Kunde hatte das Problem mit 408 Errors beim Skalieren von Services im NSX ALB. Solange der Service nicht skaliert wurde und nur auf einer SE platziert, wurde gab es keine Fehler. 

Bei dem n+m Scaleout des Services auf eine weitere Node kam es bei etwa 50% das Fällen zu einem 408 Error, welchen man auch über die UI im NSX ALB sehen konnte.

NSX ALB Log 1

Hier ist die Verbindung, welche ein 200 zurück gibt und welche ohne Probleme wie gewünscht funktioniert.

NSX ALB Log 2

In diesem Ausschnit ist die gleiche Verbindung zu sehen allerdings mit einem 408 Error nachdem der Server nicht mehr geantwortet hatte.

Problem hierbei ist der scaleout Mechanismus des NSX ALB und wie er mit dem Datenverkehr innerhalb der SE´s umgeht. Dies im Zusammenhang mit der Physischen Firewall war für die 408 Fehler verantwortlich.

Autoscale Service Engines

Bei einem Service welcher über mehrere SE´s verteilt ist, werden alle Anfragen an die Primary Node geschickt. Diese leitet die Pakete auf dem Layer 2 an die MAC-Adresse der neuen SE weiter. Diese terminiert die TCP-Verbindung und leitet die Verbindung an den Ziel Server weiter.

Dabei macht sie ein Source NAT, sodass der Rückweg wieder über die jeweilige Service Engine läuft.

Dabei ist aufgefallen, dass nun die Pakete über die 2. Service Engine laufen und nicht über die Primary, welche die Pakete zuvor angenommen hatte.

Dieses Verhalten führt auf der Physischen Firewall zu Problem, da diese die Sessions aufgrund der wechselnden NAT IP nicht zuordnen konnte und letztendlich die Pakete Dropt, was zu dem http 408 Fehler führt.
Um dieses Problem zu lösen, gibt es eine Einstellung, welche auf die Service Engine Group per CLI oder API gesetzt werden muss.

>configure serviceenginegroup Default-Group
>serviceenginegroup> se_tunnel_mode 1
>serviceenginegroup> save


Diese Einstellung aktiviert den „SE_Tunnel_Mode“ auf der gesamten Service Engine Group. Dieser sorgt dafür, dass Pakete auf dem gleichen Weg den Loadbalancer verlassen, wie sie reingekommen sind. Nämlich über die Primary Service Engine Node.

Auszug aus der API:

se_tunnel_mode (optional)

Integer Determines if Direct Secondary Return (DSR) from secondary SE is active or not 0 Automatically determine based on hypervisor type. 1 Enable tunnel mode – DSR is unconditionally disabled. 2 Disable tunnel mode – DSR is unconditionally enabled. Tunnel mode can be enabled or disabled at run-time. Allowed values are 0-2. Field introduced in 17.1.1. Allowed in Enterprise edition with any value, Essentials edition(Allowed values- 0), Basic edition(Allowed values- 0), Enterprise with Cloud Services edition. format: int32

Quelle: https://avinetworks.com/docs/latest/api-guide/ServiceEngineGroup/index.html

Diese Einstellung sorgt dafür das „DSR – Direct Secondary Return“ dauerhaft ausgeschaltet ist und somit Pakete nur über die Primary Service Engine den Loadbalancer verlassen.
Dadurch wird der Datenverkehr auf der Firewall akzeptiert und die Pakete wieder zum Client zurückgeschickt.