Einmal durchsieben

von Benjamin Pfister

Mit steigenden Datenraten im Rechenzentrum wachsen auch die Anforderungen an Sicherheit und Segmentierung. Klassische Switches stoßen hier schnell an ihre Grenzen – vor allem beim Stateful Firewalling im Ost-West-Traffic. Der HPE Aruba CX 10000 kombiniert erstmals leistungsfähiges Switching mit einer integrierten DPU, die Sicherheitsfunktionen direkt im Datenpfad ermöglicht. Im Test zeigt sich, wie gut Mikrosegmentierung und Firewalling in virtualisierten Umgebungen tatsächlich funktionieren.

Rechenzentren stehen zunehmend unter Druck, nicht nur steigende Datenmengen zu bewältigen, sondern gleichzeitig auch eine stärkere Sicherheitsarchitektur bereitzustellen. Besonders der interne Datenverkehr – der sogenannte Ost-West-Traffic zwischen Servern – entzieht sich oft klassischen Schutzmechanismen. Üblicherweise kommen hier Stateful Firewalls zum Einsatz, die Subnetze voneinander trennen. Doch diese Ansätze bremsen den Datenfluss spürbar aus, kosten Ressourcen und bieten kaum Kontrolle über Kommunikation innerhalb eines Subnetzes. Eine feinere, hardwarebasierte Mikrosegmentierung direkt auf Switching-Ebene könnte hier Abhilfe schaffen – genau an diesem Punkt setzt der HPE Aruba CX 10000 an.

So haben HPE Aruba und AMD mit dem Gerät das Ziel, die Leistungsfähigkeit eines Layer-3-Switches mit einer echten Stateful Packet Inspection zu vereinen, die auf einer Pensando Data Processing Unit (DPU) basiert. In unserem Test unterzogen wir diesen Switch einer umfassenden Prüfung, um herauszufinden, wie sich die Verwaltungs- und Sicherheitsfunktionen in der Praxis bewähren – insbesondere in Verbindung mit einer VMware-vSphere-Infrastruktur.

Viel Leistung auf einer Höheneinheit

Der Switch kommt in einer Höheneinheit daher und ist, wie für Rechenzentrums-Switches üblich, in zwei Varianten erhältlich: mit Kühlung von vorn nach hinten oder umgekehrt. Er unterstützt zwei Netzteile und sechs Lüfter, selbstverständlich hot-swappable. Der maximale Stromverbrauch lag in unserem Test bei 753 Watt, während er sich im normalen Betrieb auf etwa 550 Watt belief. Das Gerät wiegt 9,75 kg und ist mit einer Intel-Xeon-D-1637-Sechskern-CPU mit 2,9 GHz, 32 GByte Arbeitsspeicher und einer 64-GByte-SSD ausgestattet. Für das Queuing steht ein 32 MByte großer Pufferspeicher zur Verfügung.

Auf der Vorderseite verfügte unser Testgerät über 48 Ports für 1/10/25GbE (SFP/ SFP+/SFP28) sowie sechs 40/100GbE-Ports (QSFP+/QSFP28). Zur internen Verarbeitung dieser hohen Übertragungsraten bietet das Gerät ein Linerate-Switching mit einer Kapazität von bis zu 3,6 TBit/s sowie eine Durchsatzrate von bis zu 2 Milliarden Paketen pro Sekunde (2000 Mpps). Die Ports unterstützen Jumbo-Frames bis zu einer Größe von 9 KByte.

Wer die zusätzlichen DPU-Funktionen nutzen möchte, kann auf Stateful Services wie Layer-4-Firewalling oder NAT mit einem Durchsatz von bis zu 800 GBit/s zurückgreifen. Für die IPSec-Verschlüsselung, die beispielsweise für die Rechenzentrumskopplung zum Einsatz kommt, ist ein Vollduplex-Durchsatz von bis zu 540 GBit/s möglich – allerdings abhängig von der jeweiligen Framegröße und daher potenziell auch niedriger. Eine Line-Rate-Verschlüsselung per MACSec bleibt außen vor, obwohl dies konzeptionell eine sinnvolle Ergänzung wäre.

HPE positioniert den Switch als Top-of-Rack-Switch im Rechenzentrum beziehungsweise als Leaf in einer EVPN/ VXLAN-Fabric. Ziel ist es, durch den Einsatz der DPU die Anzahl an Hardwaregeräten zu reduzieren und eine Mikrosegmentierung von Servern unabhängig von Sicherheitsagenten zu ermöglichen. Sie werden auf Server-Appliances ohnehin oft nicht unterstützt. Softwareseitig basiert der Switch auf einem Linux-Kernel mit einer Stateful Datenbank, wie es auch Arista bietet. Wir haben das Betriebssystem ArubaOS-CX (AOS-CX) in der Version 10.15.0005 getestet, wobei für einzelne Prüfungen auch die Version 10. 14.1020 zum Einsatz kam.

Zur Unterstützung von Multichassis-Link-Aggregation verfügte unser Switch über die Aruba Virtual Switching Extension (VSX). Dies bietet eine Serveranbindung mit multiplen Links für Redundanz- und Lastverteilungsgründe. Dadurch lassen sich einzelne Switches aktualisieren und neu starten, ohne dass es zu einer Down-time kommt. Besonders überzeugt hat uns die einfache Updatefunktion per Einzeiler in der Kommandozeile.

Stateful Firewalling gut gelöst

Eine zentrale Herausforderung besteht darin, wie zwei Hardware-Switches mit jeweils zwei DPUs das Stateful Firewalling umsetzen. Das Problem liegt in den asymmetrischen Datenflüssen, da alle DPUs den aktuellen Session-Status des jeweiligen Datenverkehrs benötigen. Hier hat die VSX-State-Sync-Technologie ihren Auftritt: Sie leitet die Pakete zunächst über den zweiten Switch, damit beide DPUs den Verbindungsstatus korrekt erfassen. Dies geschieht jedoch nur während des Verbindungsaufbaus (bei den ersten drei Paketen) sowie beim Verbindungsabbau (beim letzten FIN oder RST), um Verzögerungen zu minimieren. Bei statuslosen Verbindungen werden lediglich die ersten beiden Pakete "geloopt", was in unserem Test einwandfrei funktionierte.

Bei einer VSX-übergreifenden vMotion, also der Livemigration einer VM zwischen Hypervisoren mit aktivierten Stateful-Firewalling-Services, löst das vCenter einen Webhook zum PSM aus, das über einen Read-Only-User mit dem vCenter verbunden ist. Wichtig dabei: Sowohl auf dem Switch als auch auf dem ESXi-Host muss das LLDP-Protokoll aktiviert sein. Selbst die Livemigration gelang ohne eine negative Auswirkung durch den Einsatz der Stateful Services.

Das Management des Switches lässt sich klassisch über CLI (per Konsole oder SSH) als auch über ein Web-GUI oder ein REST-API erledigen. Zur Überwachung kommt SNMPv3 zum Einsatz. Für die Authentifizierung und Autorisierung des Managementzugriffs wiederum stehen TACACS+ und RADIUS bereit. Bei RADIUS war selbst die TLS-verschlüsselte RadSec-Erweiterung verfügbar. Neben Stateful Firewalling über die DPU unterstützt der Switch auch klassische, statuslose IPv4/IPv6-Access-Control-Lists.

VLANs en masse

Im Bereich der klassischen Switching-Funktionen auf Layer 2 verliert der CX 10000 auch bei bis zu 4018 VLANs nicht den Überblick und bietet die Möglichkeit zur VLAN-Übersetzung, falls erforderlich. Ungewöhnlich erscheint zunächst, dass im Trunk-Modus einer Schnittstelle standardmäßig keine VLANs zugelassen sind – ein Ansatz, der jedoch das Prinzip "Security by Default" widerspiegelt. Ein klarer Vorteil hingegen ist, dass beim Hinzufügen von VLANs kein Risiko besteht, bereits konfigurierte VLANs zu überschreiben. Bei anderen Herstellern ist hierfür oft ein zusätzliches "add"-Argument notwendig, um versehentliche Überschreibungen zu vermeiden.

Im Bereich Spanning Tree zeigt sich der CX 10000 äußerst flexibel: Er unterstützt sowohl moderne Varianten wie Rapid Spanning Tree nach 802.1w, Multiple Spanning Tree gemäß 802.1s und Rapid Per-VLAN Spanning Tree Plus (RPVST+), um die Interoperabilität mit Cisco-Catalyst-Switches sicherzustellen, als auch das ältere 802.1d Spanning Tree. Sollte der Switch in einem Service-Provider-Netzwerk zum Einsatz kommen, mag sich das BPDU-Tunneling als nützlich erweisen, um Spanning-Tree-Kontrollframes über das Providernetz hinweg weiterzuleiten. Für Monitoringzwecke bietet der CX 10000 bis zu vier Mirror-Gruppen für Port-Mirroring, die im Test einwandfrei funktionierten. Die MAC-Tabelle fasst bis zu 98.304 MAC-Adressen.

Für die Erweiterung eines Layer-2-Segments über ein Layer-3-Netz – etwa zur Rechenzentrumskopplung – unterstützte der Switch VXLAN (Virtual Extensible LAN). Dies konnte sowohl statisch als auch dynamisch über BGP-EVPN erfolgen. Die Replikation von Broadcast-, Unknown-Unicast- und Multicast-Datenverkehr konnte entweder Unicast-basiert per Head-End-Replikation oder über Multicast-Replikation erfolgen.

Für eine Erhöhung von Bandbreite und Verfügbarkeit sorgt die klassische Linkaggregation mittels LACP nach IEEE 802.1AX. Zudem steht eine LACP-Fallback-Funktion für Geräte bereit, die noch nicht für LACP konfiguriert sind – ideal beispielsweise für frisch aufgesetzte Server. Die Multi-Chassis-Linkaggregation über HPE VSX hatten wir zuvor bereits erwähnt. Zum Erkennen unidirektionaler Links und zur automatischen Einleitung einer Link-Down-Aktion kommt der UDLD-Mechanismus zum Einsatz, der in unserem Tests reibungslos funktionierte.

Umfassendes Layer-3-Routing

Im Bereich der Layer-3-Funktionen wartet der Switch mit einem umfassenden Spektrum an Routingprotokollen auf. Neben der Unterstützung statischer IPv4- und IPv6-Routen stehen für IPv4 OSPFv2, RIPv2 und BGP zur Verfügung, während im IPv6-Bereich OSPFv3, RIPng und BGP auf ihren Einsatz warten. IS-IS sowie MPLS hingegen sind nicht unterstützt, was jedoch primär in Providernetzwerken von Bedeutung ist.

Für Redundanz auf dem ersten Hop sorgte das standardkonforme Virtual Router Redundancy Protocol (VRRP). Innerhalb einer EVPN-Architektur waren zudem verteilte Anycast-Gateways auf den Leaf-Switches verfügbar, die eine ARP/ND-Suppression ermöglichten. Das hat unnötige Weiterleitungen von ARP- und Neighbor-Discovery-Anfragen und -Antworten innerhalb der Fabric reduziert. Das Inter-VLAN-Routing innerhalb der EVPN-Fabric wird durch das symmetrische Integrated Routing and Bridging (IRB) unterstützt, das sich im Test als zuverlässig erwies. Auch Funktionen wie PIM Sparse-Mode, IGMP-Snooping und IPv4-Multicast im Overlay sind mit an Bord.

Darüber hinaus unterstützt der Switch Subinterfaces, also mehrere 802.1Q-getaggte virtuelle Schnittstellen auf einer physischen, gerouteten Schnittstelle. Richtlinienbasiertes Routing (PBR) ließ sich im Test problemlos konfigurieren, ebenso wie Bidirectional Forward Detection (BFD), das insbesondere in Kombination mit BGP tadellos arbeitete. Auch hinsichtlich der Skalierbarkeit überzeugt der Switch: Er kommt mit bis zu 131.072 IPv4-Routen zurecht, im Fall von IPv6 immerhin bis maximal 32.732 Routen. Im Bereich Multicasting gilt ein einheitlicher Grenzwert von 8000 – sowohl für die maximale Anzahl der IGMP- und MLD-Gruppen als auch für die IPv4- und IPv6-Multicast-Routen.

Hinsichtlich Quality of Service (QoS) stehen verschiedene Mechanismen bereit. Strict Priority (SP) Queuing ermöglichte eine priorisierte Verarbeitung von Datenpaketen, wie sie typischerweise im Voice-over-IP-Umfeld Verwendung findet. Deficit Weighted Round Robin (DWRR) bietet eine gewichtete Verteilung der Warteschlangenressourcen.

Für Storage-Traffic unterstützt der Switch derweil Datacenter-Bridging-Technologien (DCB), darunter Priority Flow Control (PFC) mit sieben Prioritätsstufen pro Port sowie Enhanced Transmission Services (ETS). Darüber hinaus ist Flow Control Guard integriert, um eine übermäßige Ansammlung von Datenstaus zu vermeiden. Diese Funktion sorgt durch regelmäßiges Leeren dafür, dass Pakete nicht über längere Zeit im Puffer verbleiben.

Gelungenes Management

Im Test setzten wir den Aruba Fabric Composer (AFC) als Managementumgebung für Netzwerk- und Sicherheits-Overlays ein. Der AFC ermöglichte sowohl das Bereitstellen standardbasierter EVPN/VXLAN-Fabrics als auch traditioneller VSX-Implementierungen. Das on-premises GUI haben wir mithilfe eines OVA-Templates in Version 7.1.1 installiert. Bereits beim Import über das vCenter mussten wir IP-Adressen, Hostnamen, Domänennamen und das Admin-Kennwort angeben, anschließend war noch unser Lizenzschlüssel zu hinterlegen.

Zur Grundeinrichtung testeten wir die AFC-Wizards, beginnend mit der Konfiguration grundlegender Infrastrukturdienste wie NTP und DNS sowie der Einrichtung des VSX-Paars für MC-LAG. Über den Wizard-Reiter "Distributed Services" führten wir zudem die Anbindung an das PSM durch, wodurch wir AFC als zentralen Verwaltungspunkt nutzen konnten. All dies gelang völlig problemfrei.

Im Menü "Configurations / Integrations" besteht die Möglichkeit, das VMware vCenter zu integrieren. Besonders praktisch: Dadurch lassen sich VLANs auf dem Switch automatisch mit den entsprechenden Portgruppen auf dem verteilten vSwitch synchronisieren, was eine konsistente Konfiguration über alle Systeme hinweg sicherstellt. Auch Integrationen in Nutanix oder das SDN mit VMware NSX-T sind möglich.

In Bezug auf die Switch-Verwaltung agierte der AFC hauptsächlich als "Template Engine". Zwar erkannte er Konfigurationsanpassungen, die wir direkt über das CLI vorgenommen haben, jedoch meldete er keine Abweichungen von der ursprünglichen Zielkonfiguration (Config-Drift). Dadurch besteht das Risiko von Inkonsistenzen, was andere Lösungen besser handhaben. Immerhin wurden alle Änderungen zunächst vom Switch validiert, bevor sie in Kraft traten.

Flexible Sicherheitsrichtlinien

Für Stateful Services wie Firewalling, NAT und IPSec steht die GUI-Managementumgebung AMD Pensando Policy and Services Manager (PSM) als OVA-Datei zur Verfügung. Die Bereitstellung erfolgt durch einen Import in das vCenter und die Ausführung eines Python-Skripts mit wenigen Parametern wie IP-Adressen, Domänennamen und NTP-Servern, wodurch sich das PSM in unserem Fall einfach deployen ließ.

Damit wir das PSM nutzen konnten, mussten wir die Switchports mit bestimmten Rollen, den sogenannten Personas, versehen. Sie definieren entsprechend die DPU-Logik. Downlink-Ports erhielten die Persona "Access", während Uplinks mit "Uplink" kategorisiert wurden. Bei der "Access"-Persona wurde die DPU vor der Switching- und Routingentscheidung aktiv, während beim "Uplink"-Modus zuerst die Switching- und Routinglogik angewendet wurde und anschließend die DPU zum Einsatz kam.

AMD betrachtet die Richtlinien aus der Perspektive des produktiven Hosts beziehungsweise der virtuellen Maschine. Egress-Policies finden auf ausgehenden Datenverkehr der VM Anwendung, während Ingress-Policies den eingehenden Datenverkehr von der Switch-Ebene zur VM regeln. Fehlt eine Richtlinie, ist der gesamte Datenverkehr standardmäßig erlaubt.

Eine leere, jedoch mit einem VLAN verknüpfte Policy bedeutet hingegen eine vollständige Sperrung des Verkehrs. Besonders für Migrationsszenarien ist es vorteilhaft, dass sich der Datenverkehr im laufenden Betrieb unterbrechungsfrei vom ASIC des Switches auf die DPU umleiten lässt. Mithilfe des Befehlsshow dsm redirect konnten wir überprüfen, welche VLANs auf die DPU umgeleitet wurden und somit den dort hinterlegten Richtlinien unterlagen.

Darüber hinaus bietet das PSM eine Integration in VMware vCenter. Diese ermöglicht es, VMs anhand von Tags zu gruppieren, wobei sogar mehrere Tags pro VM auswertbar waren. Dadurch lassen sich Firewallregeln nicht mehr nur IP-basiert, sondern auch anhand von Tags definieren, was eine klare Trennung zwischen Firewall- und Virtualisierungs-Admins erlaubt.

Nach Änderungen an den Richtlinien war eine Speicherung erforderlich. Die DPU setzte diese erfreulicherweise unmittelbar um, sodass nach dem Speichern sofort eine Prüfung der Kommunikationsbeziehung durchgeführt werden konnte. Firewallregeln wurden ausschließlich über das PSM verwaltet, das auch eine API zur Verfügung stellte.

Eine besondere Einschränkung zeigte sich bei der Stateful Packet Inspection, die ausschließlich in Kombination mit VLANs funktionierte, jedoch nicht mit gerouteten Schnittstellen. Dies ließ sich jedoch durch die Nutzung eines ungetaggten Access-Interfaces innerhalb eines separaten VLANs umgehen.

Für Fehleranalysen oder die Ersteinrichtung bietet das PSM zudem eine sogenannte Service-Bypass-Funktion, die den Datenverkehr ohne weitere Prüfungen durch die DPU leitet. Dafür muss an Quelle und Ziel das Connection Tracking deaktiviert sein, sodass beide Seiten den Datenverkehr "durchschalten". Das Connection Tracking würde andernfalls jeden TCP-Flow blockieren, da im Normalfall der Status anhand der Kontrollpakete des initialen Dreiwege-Handshakes (SYN, SYN/ACK, ACK) sowie der Abschlusssequenz mit FIN- oder RST-Paketen überwacht wird.

Weiterhin lassen sich in den Richtlinien Einschränkungen für die maximale Anzahl an Verbindungen pro Sekunde sowie die maximale Anzahl aktiver Sessions definieren. AMD sieht hierdurch die Möglichkeit einer grundlegenden DDoS-Abwehr gegeben, wobei dies als eher grobe Lösung erscheint. Auch das Verhalten bei TCP-Fragmenten ist konfigurierbar, sodass diese entweder weitergeleitet oder verworfen werden.

VLAN-Konfiguration ohne Stolpersteine

Unsere Testumgebung setzte sich aus zwei HPE-CX-10000-Switches zusammen. Für die Integrationstests standen zudem vier VMware-vSphere-Hosts als Hypervisor bereit, auf denen ein vCenter sowie ein DNS-Server liefen. Unser erstes Testszenario begann mit der Einrichtung einer Layer-2-Firewall zwischen zwei virtuellen Linux-Maschinen auf unterschiedlichen Hosts. Die DPU sollte die ausgehende Kommunikation zwischen zwei Linux-VMs steuern. Dafür setzten wir testweise auf beiden Maschinen Webservices auf, um die Kommunikationsfreigaben und

-einschränkungen zwischen den Webservern gezielt zu regulieren und anschließend zu überprüfen.

Die beiden Test-Switches waren in einem VSX-Verbund konfiguriert und über eine Multichassis-LAG mit den vier ESXi-Hosts verbunden. Wir richteten mehrere VLANs mit zugehörigen VLAN-Interfaces (SVI) auf dem Switch sowie die entsprechenden VLANs auf den ESXi-Hosts ein. Zusätzlich mussten wir die VLANs im PSM hinzugefügen. Den beiden Test-VMs wiesen wir im vCenter den Tag "OS-Type=Linux" zu, woraufhin sie dank der vCenter-Integration sofort im Web-GUI des PSM erschienen.

Anschließend erstellten wir im PSM klassische IP-basierte Regelwerke innerhalb einer Egress-Policy und wiesen diese einem Test-VLAN zu. Die Konfiguration und Aktivierung verliefen reibungslos und ohne Unterbrechung des produktiven Datenverkehrs. Danach testeten wir Firewallregeln, die auf den im vCenter gesetzten Tags basierten. Auch diese wurden problemlos und ohne spürbare Verzögerung angewandt. Entfernten wir den Tag von einer VM, griffen die Regeln nicht mehr, und nach dem erneuten Hinzufügen wurden sie sofort wieder aktiv. Zusätzlich überprüften wir die Firewall-Logs im PSM, die der Switch korrekt speicherte. Optional bestand die Möglichkeit, diese per Syslog zu exportieren.

Das zweite Testszenario konzentrierte sich auf das Einrichten einer Layer-2-Firewall zwischen virtuellen Linux-Maschinen, die sich auf demselben Host befanden. Die beiden Test-Switches waren erneut in einem VSX-Verbund konfiguriert und über eine Multichassis-LAG mit den vier ESXi-Hosts verbunden. Die besondere Herausforderung bestand darin, den integrierten Switch im Hypervisor daran zu hindern, den Datenverkehr direkt zwischen den VMs weiterzuleiten. Stattdessen sollte der Datenverkehr für die Firewallinspektion an den Switch ausgeleitet werden.

Um dies zu realisieren, waren sowohl Anpassungen am CX-10000-Switch als auch Änderungen an den virtuellen verteilten Switches (vDS) im vCenter erforderlich. Konkret kam das Konzept der Private VLANs (PVLAN) zum Einsatz, wodurch sich die virtuellen Maschinen in isolierten privaten Netzwerken auf den ESXi-Hosts befanden. Damit der Datenverkehr über den Switch und somit über die DPU zur Stateful Packet Inspection geleitet wurde, aktivierten wir auf dem VLAN-Gateway des Switches das Proxy-ARP-Feature über den CLI-Befehlip local-proxy-arp. Auch dieser Testlauf mit Private VLANs verlief erfolgreich und funktionierte wie erwartet. Wir hatten im Labor lediglich ein temporäres Problem mit einer Netzwerkkarte im ESXi-Host, das wir durch einen Austausch beheben konnten.

Routing für Fortgeschrittene

Nun ging es an die Königsklasse im Routing und Switching: EVPN mit VXLAN. Dies kombinierten wir zudem noch mit dem vorherig benannten PVLAN-Szenario im Intra-VLAN Traffic auf dem gleichen Host, als auch mit symmetrischem Integrated Routing and Bridging (IRB) und einem Distributed Anycast Gateway (VLAN-Gateway auf den Leafs) mit ARP-Suppression.

Die EVPN-Routen-Typen 2 (MAC/IP Advertisement Route) und 3 (Inclusive Multicast Route) tauschten die Switches dabei problemfrei aus und auch die Weiterleitung des Datenverkehrs gelang. Für BUM-Traffic (Broadcast, Unknown Unicast und Multicast) nutzten wir die sogenannte Headend-Replikation über Unicasts zwischen den Virtual Tunnel Endpoints (VTEPs). HPE teilte uns mit, dass im aktuellen Release sogar Multicast-Replikation möglich wäre, wie es Cisco im Standarddesign einsetzt.

Firewallregeln für Inter-VLAN-Traffic wendeten die DPUs auch in diesem Szenario korrekt an. Bei Intra-VLAN-Traffic mit Private-VLANs stießen wir auf einen Fehler in der AOS-CX-Version 10.14.1020 auf den Switches, den wir mittels eines Updates auf das Release 10.15.0005 aus der Welt schafften.

Sichere Übertragung zwischen Rechenzentren

Wie bereits erwähnt, beherrscht der Switch auch IPSec-Verschlüsselung, um beispielsweise eine performante Rechenzentrumskopplung oder eine ebensolche in die Public Cloud einzurichten. Dabei war es zunächst wichtig, dass wir die Switches über die Kommandozeile in der Rolle Spine oder L3-Core konfigurierten. In der Leaf- oder L3AGG-Rolle ließ sich jedoch keine IPSec-Richtlinie zuweisen. Das lag daran, dass der Administrator die IPSec-Richtlinie im PSM auf VRF-Ebene und nicht auf VLAN-Ebene aufsetzt und sowohl die Rollen Leaf als auch L3AGG nur VLAN-Richtlinien unterstützen. IPSec soll in Zukunft auch im Leaf-Modus möglich sein. Die Switches unterstützen IKEv2 im Tunnel-Modus mit wahlweiser Pre-Shared-Key- oder Zertifikatsauthentifizierung.

Wir testeten eine fiktive Rechenzentrumskopplung über IPSec zwischen den beiden Switches. Dazu bedurfte es sowohl Konfigurationsbestandteile im PSM als auch auf der Kommandozeile der Switches. Eine vereinheitlichte Konfiguration auf einer Ebene ist nach Rücksprache mit AMD und HPE nicht möglich. Im PSM konfigurierten wir zwei IPSec-Richtlinien mit Referenz auf entsprechend auf der CLI anzulegende Tunnel-Schnittstellen. In dieser Richtlinie definierten wir den jeweiligen Zielswitch, die Authentifizierungsparameter, Ciphers, Laufzeiten und den Initiator der Verbindung. Im Anschluss verknüpften wir diese Richtlinie erfolgreich mit dem benötigten VRF. Nach unserer Einschätzung würde dem Switch auch eine Integration von MACsec gut zu Gesicht stehen, beispielsweise für performante Rechenzentrumskopplungen.

Der CX 10000 unterstützt im Übrigen NAT. Dies bedarf, wie auch die Stateful Packet Inspection, der Nutzung von VLANs und VLAN-Interfaces (SVIs). Geroutete Ports bleiben leider außen vor. Die Switches bieten sowohl Source-, als auch Destination-NAT an, wobei die Konfiguration im Gegensatz zu IPSec vollständig im PSM stattfindet.

Lizenzen und Support

Der CX 10000 erfordert zwingend eine sogenannte CX-Advanced-Lizenz zur Erweiterung der CX-Foundational-Netzwerkfunktionen um das Stateful-Firewalling, Telemetrie und die integrierte Nutzung von Containern. Für den Einsatz von NAT und IPSec-Verschlüsselung bräuchte es zusätzlich noch eine Premiumlizenz. Der Support kommt entsprechend dem gewählten Lizenzlevel (Advanced oder Premium) und den erforderlichen Support- und Reaktionszeiten (Foundational Care und Pro Care) jährlich als Kosten hinzu.

Das GUI-basierende Fabric-Management der Switches braucht zudem noch eine weitere Lizenz. Dabei müssen sich Kunden jedoch entscheiden, ob sie das dargestellte On-Premises-Management über den Aruba Fabric Composer oder ein Cloudmanagement über Aruba Central bevorzugen und die entsprechenden Subscriptions wählen. Das PSM steht mit dem Kauf des Switches kostenfrei zur Verfügung.

Fazit

Für mittlere und große Organisationen, die eine performante Layer-4-Firewall im Ost-/West-Datenverkehr im Rechenzentrum suchen, scheint der Switch nahezu perfekt geeignet. Dies gilt für alle getesteten Szenarien zur Mikrosegmentierung auf Layer 2 auf gleichem Host, Layer 2 auf unterschiedlichen Hosts, wie auch zwischen unterschiedlichen Subnetzen.

Für den aufgerufenen Preis erscheint das Gerät speziell mit seinen Durchsatzraten in den genannten Einsatzszenarien spannend. Alle getesteten Leistungsmerkmale funktionierten mit dem aktuellen Release 10.15 ohne Schwierigkeiten. Für einige Anwendungsfälle ist jedoch klassisches Stateful Firewalling nicht ausreichend. Ein IDS/IPS wäre wünschenswert, obgleich dies viel Performance kosten dürfte.

Produkt	1HE-Netzwerk-Switch mit Stateful Firewall.
Hersteller	HPE Aruba Networking in Kooperation mit AMD https://www.hpe.com
Preis	Für die Variante CX10000-48Y6C beträgt der Preis 43.000 Euro. Ein Rackmount Kit kostet 500 Euro, während die Lizenz für IPSec und NAT bei 11.700 Euro liegt.
Systemvoraussetzungen	- Management: ArubaOS-CX ab Version 10.13.1000, CLI, Web-GUI, REST-API. - Virtualisierungsumgebung: VMware vCenter (für PSM-Integration), ESXi ab Version 6.5. - Software-Tools: Aruba Fabric Composer (AFC) ab Version 7.0.1, Pensando PSM ab 1.80.1-T. - Netzwerkinfrastruktur: VLAN-fähige Umgebung mit VXLAN/EVPN-Unterstützung empfohlen. - Weitere Anforderungen: Aktiviertes LLDP auf ESXi-Hosts, RADIUS/TACACS+ für Authentifizierung (optional).
Technische Daten	https://www.it-administrator.de/downloads/datenblaetter

Produkt	1HE-Netzwerk-Switch mit Stateful Firewall.
Hersteller	HPE Aruba Networking in Kooperation mit AMD https://www.hpe.com
Preis	Für die Variante CX10000-48Y6C beträgt der Preis 43.000 Euro. Ein Rackmount Kit kostet 500 Euro, während die Lizenz für IPSec und NAT bei 11.700 Euro liegt.
Systemvoraussetzungen	- Management: ArubaOS-CX ab Version 10.13.1000, CLI, Web-GUI, REST-API. - Virtualisierungsumgebung: VMware vCenter (für PSM-Integration), ESXi ab Version 6.5. - Software-Tools: Aruba Fabric Composer (AFC) ab Version 7.0.1, Pensando PSM ab 1.80.1-T. - Netzwerkinfrastruktur: VLAN-fähige Umgebung mit VXLAN/EVPN-Unterstützung empfohlen. - Weitere Anforderungen: Aktiviertes LLDP auf ESXi-Hosts, RADIUS/TACACS+ für Authentifizierung (optional).
Technische Daten	https://www.it-administrator.de/downloads/datenblaetter

Durchsatz Stateful Packet Inspection	10
Verwaltbarkeit DPU-Features	8
Integration in Hypervisor	9
EVPN-/VXLAN-Features	8
Eignung für Mikrosegmentierung	9
Die Details unserer Testmethodik finden Sie unter https://www.it-administrator.de/testmethodik/

HPE Aruba Networking CX 10000

Einmal durchsieben

Viel Leistung auf einer Höheneinheit

Viel Leistung auf einer Höheneinheit

Stateful Firewalling gut gelöst

VLANs en masse

Umfassendes Layer-3-Routing

Gelungenes Management

Flexible Sicherheitsrichtlinien

VLAN-Konfiguration ohne Stolpersteine

Routing für Fortgeschrittene

Sichere Übertragung zwischen Rechenzentren

Lizenzen und Support

Fazit