Performance Probleme mit NAT
Nach dem Wechsel auf neuere Hardware (10G) und damit verbunden auch auf den aktuellsten Softwarestand von FreeBSD haben die NAT Kisten sporadisch massive Probleme. Ein glücklicher Zufall gestattete zuerst die Diagnose und dann die Lösung des Problems. CPU Last fällt von 90% (pro Prozeß) auf einstellige Werte.
Spikes
Immer wieder kommt es auf einer NAT Kiste zu akuten Performance-Problemen. Dabei bricht der maximal erreichbare Durchsatz pro TCP-Session auf unter 10Mbps zusammen. Oft ist der Gesamtdurchsatz des Systems auf knapp 200Mbps begrenzt, obwohl da drei mal 10G anstecken. (Für den Anschluß des vierten Interfaces fehlt aktuell ein Rack.)
Im CPU Graphen schaut das dann so aus.
Um kurz nach 18 Uhr hatte die betreffende Maschine ein Lastproblem. Allerdings war es schon nach wenigen Minuten wieder weg.
In den meisten Fällen bisher waren die Lastspitzen noch deutlich kürzer, so daß man sie in diesem Graphen nicht mal richtig sieht.
Da allerdings das Problem nur sporadisch auftritt, nicht reproduzierbar ist, und die Beeinträchtigung der Kunden auch nicht lange genug anhält, um zu spezifischen Störungsmeldungen zu führen, war bisher eine Fehlersuche ergebnislos.
Glückliche Zufälle
Gestern erst hatte ich im Zusammenhang mit FreeBSD ein WTF-Erlebnis, das mit NAT zusammenhängt.
Und heute zeigte eine Maschine erstmals einen stabilen Fehlerzustand.
Wow, was für ein gewaltiger Vorfall! Endlich mal Zeit zum Debuggen.
Mit dem Hintergedanken des gestrigen Erlebnisses im Kopf fiel irgendwann in einem glücklichen Mitschnitt auf, daß es Pakete gibt, bei denen Quell- und Ziel-IP gleich sind. Noch dazu sind diese IPs auch die öffentlichen IPs des NAT.
Ganz offensichtlich kommt es vor, daß irgendein kruder Netzscanner Pakete schickt, die das NAT als gültig ansieht und nattet. Dabei entstehen Pakete, bei denen Quell- und Ziel-IP gleich sind. Und diese landen dann wieder beim NAT. Dabei entstehen Pakete, bei denen Quell- und Ziel-IP gleich sind. Und diese landen dann wieder beim NAT. Dabei entstehen Pakete, bei denen Quell- und Ziel-IP gleich sind. Und diese landen dann wieder beim NAT. Ähm, das Prinzip sollte klar sein.
Also kurz eine Firewallregel hinzugefügt, die Pakete von NAT-IPs an NAT-IPs verwirft.
Jul 26 17:13:37 server12 kernel: ipfw: 2 Deny UDP 178.19.233.4:63647 178.19.233.4:57691 in via vlan94 Jul 26 17:13:37 server12 kernel: ipfw: 2 Deny UDP 178.19.233.4:64584 178.19.233.4:57691 in via vlan94 Jul 26 17:13:37 server12 kernel: ipfw: 2 Deny TCP 91.137.21.7:42512 91.137.21.7:3888 in via vlan94 Jul 26 17:13:37 server12 kernel: ipfw: 2 Deny UDP 178.19.233.4:62012 178.19.233.4:49655 in via vlan94 Jul 26 17:13:37 server12 kernel: ipfw: 2 Deny UDP 178.19.233.4:6763 178.19.233.4:57691 in via vlan94 Jul 26 17:13:37 server12 kernel: ipfw: 2 Deny TCP 91.137.17.4:14938 91.137.17.4:64906 in via vlan94
Und schon fällt die CPU Last der Netzwerk-Interrupts auf einstellige Prozentzahlen.
Fazit
Ursächlich für den Vorfall ist ein Wechsel von quagga zu bird.
Früher mußten die einzelnen NAT-IPs lokal geroutet werden, nun genügt es, die betreffenden Netze im OSPF zu announcen und sie per ipfw auf den Uplinkports abzugreifen. Eine lokale Route gibt es also nicht mehr.
Sollten solche Pakete trotzdem lokal erzeugt werden, verlassen sie das Gerät und kommen vom nächsten Router wieder zurück. Dabei werden sie wieder dem NAT vorgeworfen.
Es ist zwei glücklichen Zufällen zu verdanken, dieses Problem überhaupt finden zu können: Weil es lange genug andauerte und das betreffende Muster gerade frisch bekannt war.
Und nun können die Kisten endlich mal richtig Last aufnehmen. Ich bin gespannt.