Barracuda NG Firewall VF und Hyper-V 2012 – Spaß mit Hindernissen

Barracuda NG Firewall VF und Hyper-V 2012 – Spaß mit Hindernissen

Kurz vor Weihnachten testete ich eine Barracuda VF25 Next Generation Firewall als virtuelle Appliance unter Microsoft Hyper-V – dabei kamen keine Freude-Freude-Gefühle auf. Letztlich konnte das Problem gefixt, die Ursache Reproduziert und abgestellt werden – aber der Reihe nach:

Barracudas Next Generation Firewall ist neben “klassischen” Boxen auch als virtuelle Appliance für eine Vielzahl von Umgebungen erhältlich, unter anderem auch für VMware, Hyper-V, AWS und Azure. Da ein angepasster Linux-Kernel im inneren Werkelt, sollte dies bei der Virtualisierung nun wirklich kein Problem darstellen.

Mein Setup bestand aus 1 virtuellen CPU, 2 GB RAM, 2 NICs, ansonsten wurden alle Einstellungen beim Import der VM nach Hyper-V unverändert vom Produktdownload übernommen. Die Installation lief problemlos ab und nach einer knappen Stunde begann ich den Probebetrieb über unseren VDL-Anschluss, und genau hier schwand meine gute Laune sofort: 5,8 MBit/s im Download – und das auf einer 50MBit-Leitung!

Erster Hinweis: Im Hyper-V Manager wurde der Status der Netzwerkschnittstellen als: Degraded, also Herabgestuft, angezeigt. Auch andere Hinweise zeigten in Richtung nicht aktueller Integrationstools. Ich war entsetzt, denn vor einem halben Jahr hatte ich mit dem Barracuda-Support gesprochen und mir wurde zugesichert, dass die Integrationstools für Hyper-V 2012 in der Version 7.0 der Firmware inbegriffen seien. Doch nicht?

Ich stieß bei meiner Recherche auch einen sehr hilfreichen KB-Artikel (genau genommen: nicht hilfreich, aber erhellend): KB2956569 sagt nämlich aus, dass diese Fehlermeldungen bei Nicht-Windows-Gastsystemen ignoriert werden können…

Da mein Testsystem Boradcom Net-Xtreme Schnittstellen nutzt, deaktivierte ich sicherheitshalber noch Virtual Machine Queueing (VMQ), aber dies brachte keinen Effekt. Ich deaktivierte dann im Hyper-V-Manager bei den virtuellen Switches die gemeinsame Nutzung mit dem Gast-OS, um der Sache hier nachzugehen, und es tat sich etwas: Die Transferrate ging noch einmal merklich auf 2,9 MBit/s zurück!

Es musste hier ein definitives Hyper-V-Problem vorliegen, denn die Umgehung der Parent Partition hatte das Problem ja noch einmal vergößert anstatt zu lindern. Bei meiner Recherche stieß ich immer wieder auf VMQ, fand aber in einem sehr langem und trolligen Forenthread schließlich einen Fingerzeig, der generell in Richtung der Netzwerkoptimierung zeigte und riet, einfach einmal alle Features auf der Netzwerkschnittstelle zu deaktivieren.

Ich tat wie empfohlen und Bingo: RSS (Receive Side Scaling) war die Ursache. Diese technik dient dazu, dass in Multiprozessorsystemen nicht immer die erste CPU den kompletten Netzwerkverkehr aller virtuellen Maschinen verarbeiten muss, sondert verteilt dies auf alle CPUs des Systems. Mit dem Deaktivieren von RSS ging der Durchsatz der virtuellen Firewall schlagartig von 2,9 MBit/s auf 49,8 MBit/s im Downstram und 10,1 MBit/s im Upstream an die Grenze des verwendeten ADSL-Anschlusses.

Unter Hyper-V 2012 sind standardmäßig alle Optimierungsoptionen wie VMQ und RSS standarsdmäßig aktiviert. Besonders problematisch wird dies, wenn der Treiber der Netzwerkschnittstelle dieses Feature nicht zur Deaktivierung auflistet – wie ich nun an einem zweiten Testsystem feststellen musste. Auch die Tatsache, dass RSS in deutschen GUI bisweilen als Empfangsseitige Dingsbums verballhornt wird, erleichtert die Fehlersuche und die -Behebung nicht wirklich!

Schreibe einen Kommentar