Network-Computing-Test: Drei UTM-Appliances auf dem Prüfstand

Optimaler UDP-Durchsatz und Latency

Anschließend führten wir dieselbe Messung mit 1-Prozent-Schritten und dem größten Frame-Format durch. Auf diese Weise ermittelten wir die maximal erreichbare Durchsatzleistung sowie die damit verbundene Latency.

Die Referenzmessung ohne Appliance ergab 100 Prozent oder 1 GBit/s und eine Latency von 28 μs. Clavisters SG3210 kam bei diesem Verfahren auf einen Durchsatz von 380 MBit/s. Die Latency betrug bei dieser Leistung 154 μs. Funkwerks Packetalarm-UTM2500 erreichte in dieser Disziplin einen Durchsatz von 370 MBit/s. Dabei lag die Latency bei 279 μs. Und Gateprotects GPX-800 schaffte das volle GBit/s mit einem Latency-Wert von 299 μs.

Bei der TCP-Performance-Messung baut die Messtechnik Verbindungen durch die Appliance auf und generiert Datenströme. Bei der Messung geht der Hauptdatenstrom als Download vom Reflector zum Avalanche. Die generierte Last ähnelt insgesamt einer unidirektionalen Smartbits-Messung mit größeren UDP-Paketen.

Die Appliance ist mit der Messtechnik, dem Avalanche und Reflector von Spirent, angeschlossen. Es handelt sich hierbei um einen normalen Download, bei dem in Upload-Richtung kleine Frames mit den entsprechenden Requests, und in Download-Richtung automatisch die größtmöglichen Frames verwendet werden.

Frame-Formate werden also nicht explizit eingestellt. Die Messtechnik simuliert so die Kommunikation zwischen Client-Systemen im internen Netzwerk sowie Rechnern im externen Netz und protokolliert das Verhalten der Appliance.

Auch hier waren von Anfang an alle UTM-Funktionen aktiviert, außer der QoS-Priorisierung. Allerdings ging hier der TCP-Verkehr am HTTP-Proxy vorbei. Wir haben so zunächst 100 User simuliert, die jeweils einen beziehungsweise zehn Requests je 10.000 Byte pro TCP-Connection starten.

Auch diese Messung haben wir zunächst mit dem Testaufbau ohne dazwischen geschaltete Appliance durchgeführt und dann die Leistungswerte der einzelnen Teststellungen ermittelt. Der Testaufbau selbst kam auf 696.993 beziehungsweise 773.260 Transaktionen und 948 beziehungsweise 970 MBit/s.

Clavisters SG3210 schaffte hier 282 098 beziehungsweise 290.297 Transaktionen und einen maximalen Durchsatz von 360 MBit/s. Funkwerks Packetalarm-UTM2500 erreichte 57.339 und 214.710 Transaktionen und 211 MBit/s beziehungsweise 270 MBit/s. Allerdings konnte die Messung nicht fehlerfrei durchlaufen, da die Connection-Capacity nicht ausreichte und ab der Hälfte des Testdurchlaufes keine neuen TCP-Verbindungen mehr aufgebaut werden konnten.

Gateprotects GPX-800 erreichte einen Wert von 758.010 Transaktionen und einen maximalen Durchsatz von 960 MBit/s, also auch hier quasi Leitungsgeschwindigkeit.

Als nächstes wollten wir wissen, welche Durchsatzleistungen die Appliances ermöglichen, wenn der HTTP-Verkehr mit dem URL- und Antivirus-Filter analysiert wird. Wir haben 100 User simuliert, die jeweils zehn Requests je 10.000 Byte pro TCP-Connection starten.

Clavisters SG3210 schaffte hier 89.749 Transaktionen und erreichte einen Durchsatz von 115 MBit/s. Funkwerks Packetalarm-UTM2500 erzielte 5240 Transaktion und einen Durchsatz von 6 MBit/s. Gateprotects GPX-800 erreichte hier 9260 Transaktionen und einen Durchsatz von 11 MBit/s.

Anschließendwollten wir wissen, wie sich die Teststellungen bei einem Mix aus UDP-Datenströmen und HTTP-Durchsatz verhalten. Dazu generierten wir mit den Smartbits 1 MBit/s UDP-Datenlast. Zusätzlich simulierten wir mit dem Avalanche den Zugriff von 100 Usern.

Clavisters SG3210 kam hierbei auf eine Latency von rund 70 μs. Griffen zusätzlich die simulierten HTTP-User auf das Netz zu, stieg die Latency auf 400 μs. Funkwerks Packetalarm- UTM2500 kam auf eine Latency von 110 μs für UDP, und mit zusätzlichem HTTP-Traffic erhöhte sich die Latency auf 150 μs.

Gateprotects GPX-800 erreichte eine Latency ohne HTTP-Last von rund 100 und mit von rund 115 μs.

In der letzten Testreihe testen wir, inwieweit die Datenpriorisierung Einfluss auf die Latency-Werte hat. Dabei haben wir niedrig und hoch priorisierte UDP-Datenströme von jeweils 1 MBit/s gesendet und zugleich wieder die Zugriffe von 100 Usern simuliert.

Bei Clavisters SG3210 waren praktisch keine Unterschiede zwischen den unterschiedlich priorisierten Datenströmen feststellbar. Beide kamen auf eine Latency von rund 380 μs. Funkwerks Packetalarm-UTM2500 erzeugte beim Transport der hoch priorisierten Datenströme eine Latency von 160 μs. Die niedrig priorisierten Datenströme transportierte das System dagegen mit einer Verzögerung von 280 μs.

Gateprotects GPX-800 kam bei der gleichen Messung mit hoch priorisierten Datenströmen auf eine Latency von 120 μs. Die niedrig priorisierten Daten hatten dagegen eine Latency von 325 μs.

Die Hersteller der UTM-Appliances haben sich viel vorgenommen. Ihre digitalen Torwächter müssen die Daten, die möglichst in Leitungsgeschwindigkeit und mit der gewünschten Übertragungsqualität an ihrem Ziel ankommen sollen, genauestens untersuchen. Das sollen sie möglichst gründlich machen, aber auch ohne nennenswerte Bearbeitungszeiten zu benötigen.

Die vorliegenden Testergebnisse haben gezeigt, dass die Systeme den Datentransport mit gewissen Einschränkungen durchaus beherrschen. Wie sicher sie wirklich sind und welche Kompromisse die Hersteller zu Gunsten der übrigen Funktionen eingehen, werden wir im kommenden Frühjahr mithilfe eines neuen erweiterten Testverfahren prüfen.

Als Lastgenerator und Analysator haben wir in unseren Real-World Labs einen »Smartbits 6000C Traffic Generator/ Analysator« von Spirent Communications eingesetzt. Das System ist mit der Software »SmartFlow« ausgestattet und mit 24 Gigabit-Ethernet-Kupfer-Ports bestückt. Alle Ports können softwareseitig als Lastgeneratorausgang und/oder als Analysatoreingang eingesetzt werden.

Für die TCP-Messungen verwendeten wir »Avalanche« und »Reflector « von Spirent. Bei allen Messungen handelt es sich um Zangenmessungen, bei denen entsprechende Datenströme generiert und analysiert werden.

Um vergleichbare, gültige und aussagefähige Ergebnisse zu erzielen, haben wir im Vorfeld die Einstellungen der UTM-Appliances festgelegt und ein für alle Tests verbindliches Standard-Rule-Set vorgegeben. Für die korrekte Konfiguration sorgten wir gemeinsam mit den Ingenieuren des jeweiligen Herstellers, die ihr eigenes System im Test begleiteten.

Die einzelnen Netzsegmente haben wir mithilfe von LAN-Switches eingerichtet. Diese Systeme leisteten in den Kontrollmessungen, die den Tests vorangingen, volle Leitungsgeschwindigkeit und sind aus diesem Grund in Hinsicht auf das Datenrahmenverlustverhalten des Testaufbaus vollständig transparent.

Mit Hilfe der drei Linux-Intel-PC-Clients in den einzelnen überprüften wir die korrekte Firewall-Konfiguration und -Funktion jeweils vor den einzelnen Testläufen.

1. Network-Computing-Test: Drei UTM-Appliances auf dem Prüfstand
2. Gateprotect GPX-800
3. Optimaler UDP-Durchsatz und Latency