Das Aufzeichnen und Analysieren von Datenflüssen in Rechenzentren stellt Admins oft vor Herausforderungen, vor allen Dingen aufgrund hoher Datenraten und großer Datenmengen. So wird die Fehlersuche zur Suche nach der Nadel im Heuhaufen. Wir haben uns das Allegro Network Multimeter angeschaut, um dessen Eignung für den Einsatz im Rechenzentrum zur Datenanalyse zu prüfen. Dieses Produkt besticht durch eine große Schnittstellen- und Modellvielfalt und die vom Hersteller versprochene hohe Performance der Analyse durch die In-Memory-Datenbank. Mitbewerber sind beispielsweise das in IT-Administrator 08/2022 [1] getestete Profitap IOTA, das jedoch nur maximal zwei 10-GBit/s-Schnittstellen bereitstellt.

Wir untersuchten im Test die unterschiedlichen Aufzeichnungsvarianten des Geräts sowie die Analysemöglichkeiten für verschiedene Protokolle wie STP und TCP sowie DNS, SMB, HTTP, SIP, RTP und TLS. Die Einbindung in das Datennetzwerk fand dabei sowohl inline zwischen Server und Managed Switch als auch via Sink-Modus an einem SPAN-Port des Managed Switches sowie über einen TAP statt.

In seiner Grundarchitektur baut das Network Multimeter auf unterschiedlichen Open-Source-Projekten auf. Dies fängt beim zugrundeliegenden Betriebssystem mit Debian Linux an. Einen guten Überblick über die eingesetzten Projekte konnten wir uns im "Über"-Bereich verschaffen, da dort alle eingesetzten Projekte mit Lizenz aufgeführt sind. Der Einsatz von Open Source ist an dieser Stelle sehr zu begrüßen, da auch sensible Daten im Netzwerk mitgeschnitten werden können.

Zur Verbesserung der Performance und des Datenschutzes legte das System die Metadaten im Standard lediglich in einer In-Memory-Datenbank ab, was sich bei Abfragen über die GUI als sehr positiv darstellte, da selbst komplexere Abfragen sehr schnell verarbeitet wurden. Die In-Memory-Datenbank ist jedoch Fluch und Segen zugleich, da die aufgezeichneten Metadaten bei einem Neustart verlorengehen. Ein Stromausfall führt zu gleichem Ergebnis. Eine weitere Performanceverbesserung brachte das Open-Source-Projekt Dataplane Development Kit (DPDK) mit, da durch dieses ein direkter Durchgriff von der Applikation auf die Netzwerkkarten erfolgen konnte. Dies ist standardmäßig aktiv.

Für Langzeitanalysen gab es in unserem Test jedoch ebenfalls eine Lösung, ohne Angst vor einem Stromausfall haben zu müssen: Einen sogenannten Paketringspeicher. Bei diesem sicherte die Appliance die aufgezeichneten Pakete auf der integrierten SSD und somit nichtflüchtig. Die Daten standen also auch nach einem Neustart bereit. Über Paketringspeicher-Längenfilter ließen sich datenschutzfreundlich sogar Aufzeichnungsfilter anlegen, wie beispielsweise nur bestimmte IP-Adressen oder bei Telefonie über SIP sogar nur Anrufe bestimmter Rufnummern. Aber auch die Option zum Beschneiden auf bestimmte Paketlängen kann interessant sein, um nur Zugriff auf Daten aus Headern, aber nicht im Payload zu haben. Dies reduzierte gleichzeitig auch die abzuspeichernde Datenmenge. So konnten wir problemlos gezielte Langzeitanalysen einrichten.

Es ist dabei jedoch zu beachten, dass der Paketringspeicher hardwareseitig passend dimensioniert werden muss. Wie der Namensbestandteil "Ringspeicher" vermuten lässt, überschrieb das Network Multimeter nämlich ab 90 bis 95 Prozent der maximalen Speicherkapazität die ältesten Daten. Dies kann insbesondere bei unterschiedlichen Traffic-Mustern im Rechenzentrum kritisch sein, beispielsweise wenn zwischenzeitlich große Backups laufen. Hier schafften jedoch eingerichtete Längenfilter Abhilfe.

Für einen Versand des Geräts mit sensiblen Daten konnten wir auch eine AES-256-Verschlüsselung des Datenträgers für den Paketringspeicher mit individuellem Kennwort einrichten. Zusätzlich bestand die Option, externe USB-Festplatten einzubinden, falls das initiale Sizing nicht mehr den aktuellen Bedürfnissen genügt. Auch dort war die zuvor genannte Verschlüsselung möglich. Die Einbindung gelang im Test sehr einfach.

Die Inhalte des Paketringspeichers ließen sich mit Unterbrechung des "Live-Modus" auch retrospektiv auswerten, beispielsweise wenn Aufzeichnung und Auswertung an unterschiedlichen Orten stattfinden. Die Unterbrechung führte zu einem Verlust aller Statistiken und Weiterleitung von Paketen. Dies erweist sich in der retrospektiven Analyse eines Fehlers jedoch als sehr hilfreich. So muss die Analyse nicht im für den Analysten klima- und geräuschtechnisch anstrengenden Rechenzentrum erfolgen.

Im Fall einer bestehenden Netzwerkaufzeichnung in Form einer PCAP-Datei konnten wir auch diese retrospektiv analysieren. Dies ist beispielsweise bei der Bereitstellung von Wireshark- oder tshark-Mittschnitten durch IT-Kollegen oder Dienstleister sinnvoll. Das Network Multimeter kann in diesem Fall die Daten statistisch aufbereiten und die schnellen Filter standen auch in diesem Fall zur Verfügung.

Um Daten aufzuzeichnen und zu analysieren, mussten wir zunächst entscheiden, wie wir das Network Multimeter in unsere Laborumgebung integrieren. Dazu standen unterschiedliche Integrationsmodi bereit: Bridge, Sink und Endpoint. Der gewählte Modus lässt sich auch während des Betriebs umschalten. Der Bridge-Modus verband zwei physische Netzwerkports zu einer transparenten Brücke. Es befand sich also aktiv In-Band im Traffic-Pfad und stellt somit auch einen möglichen Fehlerpunkt dar. Somit muss beim Einsatz im Rechenzentrum auch die redundante Ausstattung etwa bei Netzteilen Beachtung finden. Bei einem 200er- und 1000er-Modell kam es in unserem Test nämlich im Fall eines Stromausfalls bei den Onboard-Ports im Bridge-Modus zu einer Unterbrechung des Datenverkehrs.

Ab dem 1000er-Modell besteht die Option, eine zusätzlich zu erwerbende Bypass-Karte zu nutzen, die bei Stromausfall ein Failover bietet und somit die gebridgten Ports durchschaltet. Der Hersteller gab an, dass die meisten Kunden in einem solchen Fall TAPs einsetzen, die den Traffic an das Network Multimeter ausleiten und selbst die Durchschaltung durchführen. Bei den kleineren Modellen der 200er- und 500er-Serie waren im Bridge-Modus die horizontalen Portpaare und bei den größeren Modellen der 1000er- und 3000er-Serie die vertikalen Portpaare verknüpft.

Der Sink-Modus bietet derweil die Möglichkeit, die Appliance am SPAN-Port eines Switches und optional an einem TAP zu betreiben. Die Nutzung des SPAN-Ports bietet sich für die Analyse im Rechenzentrum insbesondere an, wenn das Network Multimeter bei Bedarf im Troubleshooting integriert werden soll und nicht im Dauerbetrieb läuft. Es kommt somit nicht zum Ausfall des Produktivtraffics, sollte der Strom wegbleiben. Bei diesem Betriebsmodell muss der Admin jedoch beachten, dass er durch Spiegelung der Sende- und Empfangsseite eines Ports den SPAN-Zielport nicht überlastet. Dies kann beispielsweise passieren, wenn ein 10 GBit/s-Port mit Sende- und Empfangsseite, also mit bis zu 20 GBit/s auf einen 10 GBit/s-Zielport ausgeleitet wird. Dafür bestand in diesem Modus wie erwähnt kein Risiko für den Ausfall des Produktivtraffics bei Fehlern der Appliance. Beachten sollten Admins jedoch, dass einige Switches im SPAN-Modus bestimmte Kontrollpakete nicht spiegeln. Der Betrieb an TAPs bietet hingegen eine noch höhere Genauigkeit, da in diesem Fall keine Interpretation der Daten stattfindet.

Heutige Datacenter-Netzwerke setzen oft auf Layer-3-Architekturen, bei denen je Top-of-Rack-(ToR/Leaf)-Switch beziehungsweise Switch-Paar ein gesondertes Subnetz zum Einsatz kommt. Falls also die Appliance in einem anderen Rack mit anderem Subnetz angebunden wird, lässt sich der Endpoint-Modus verwenden. Lediglich eine IP-Konnektivität zwischen dem ToR-Switch und dem Network Multimeter muss vorhanden sein. Der Switch verpackte in unserem Test dazu die Pakete in einen ERSPAN/GRE-Tunnel mit der IP-Adresse des Network Multimeters als Ziel und die Allegro-Appliance entpackte diese entsprechend. Dazu mussten wir einzelne Schnittstellen dediziert für diesen Zweck definieren und eine IP-Adresse für den Tunnel-Endpunkt definieren. Die Leistungsmerkmale funktionierten dabei einwandfrei. Somit besteht auch die Möglichkeit, das Gerät an entfernten Standorten einzusetzen, was die Integration flexibler gestaltet.

Zeitstempel sind im Troubleshooting für eine präzise Korrelation unerlässlich. Neben dem klassischen NTP bot das Network Multimeter auch das PTP. Für statistische Auswertungen auf Drittsystemen erlaubte das Testsystem auch einen IPFIX-Export an einen entsprechenden Collector. Die separat zu aktivierende Deduplizierung ermöglichte bei parallelen Messungen an unterschiedlichen Punkten im Netzwerk gerade bei hohen Datenraten, wie Ost-West-Traffic, eine sinnvolle Ergänzung, um Daten nicht doppelt aufzuzeichnen.

Wir hatten sowohl das Allegro-Modell 1000 für den Rack-Einbau und bis zu 20 GBit/s Performance für die Analyse als auch die kleine Allegro 200 für die schnelle und portable Analyse mit bis zu 2 GBit/s im Test. Für Rechenzentren stehen jedoch auch Rack-Appliances mit vier Höheneinheiten und bis zu 150 GBit/s maximalem Durchsatz, sowie 576 TByte integriertem Ringpuffer (Allegro 5500) bereit. Für die Analyse in virtuellen Umgebungen oder der Cloud gibt es eine virtuelle Appliance. Unser Test fand mit der Softwareversion 3.6.2 statt. Inzwischen hat der Hersteller jedoch Version 4.0.3 herausgebracht. Die GUI der Geräte ist bei allen Appliance-Varianten gleich.

Das kleine 200er-Modell bringt nur zwei integrierte 1-GBit/s-Ports mit, wobei einer davon bereits für das Management reserviert ist. Falls also der Bridge-Modus oder eine Analyse von mehreren Ports nötig ist, kann dies nur über den mitgelieferten USB-zu-LAN-Adapter erfolgen. Die 1000er-Variante lieferte drei 1GBASE-T-und zwei 10GBASE-T- sowie einen Management-Port, einen Hardware-Management-Port (IP-KVM) und zwei SFP+-Einschübe für 10 GBit/s-LWL-SFP+-Module. Alternativ kann das Management auch über WLAN erfolgen. Dazu liefert Allegro Packets einen USB-WLAN-Adapter 802.11b/g/n (TP-Link TL-WN725N beziehungsweise Edimax EW-7811Un) mit.

Das 1000er-Testmodell verfügte über 64 GByte RAM (standardmäßig sind 16 GByte an Bord) und für die In-Memory-Verarbeitung über eine 2 TByte große NVMe-SSD (Seagate FireCuda 520). Das 200er-Modell verfügte über 2 GByte RAM für die In-Memory-Datenbank und keine integrierte HDD oder SSD für den Paketringspeicher. Diesen mussten wir per USB 3.0 anbinden. Unsere Test-HDD wurde sofort erkannt und die Einrichtung erfolgte geführt und problemlos inklusive AES256-Verschlüsselung. Beide Modelle kamen daneben mit einem externem Netzteil ohne Möglichkeit für Redundanz, was bei der Inline-Aufzeichnung kritisch sein kann. Größere Modelle bringen jedoch eine solche Funktion. Dafür verfügten die kleinen Varianten über eine wertige Tragetasche für den mobilen Einsatz.

Die GUI des Network Multimeters ist sehr übersichtlich gehalten und das Menü auf Basis des OSI-Modells aufgebaut. Das initiale Dashboard verschaffte uns im Test einen guten Überblick über die aktiven Netzwerkschnittstellen mit dem zum Einsatz kommenden Betriebsmodus (Sink oder Bridge) sowie die "Top Talker" anhand deren MAC- oder IP-Adresse sortiert nach ein- und ausgehender Richtung. Wir konnten auch eigene Dashboards mit den für uns relevanten Daten anhand vordefinierter Widgets mit Konfigurationsmöglichkeiten anlegen.

So vorbereitet, wendeten wir uns nun den Netzwerkanalysen im Rechenzentrum zu. Diese strukturierten wir gemäß Menübaum in Layer 2, 3, 4 und 7. Wir starteten in unserem Test im Menübereich "L2 – Ethernet". Dieser Bereich ermöglicht zunächst einfachere Statistiken bezüglich MAC-Adressen oder VLANs, übertragenen Datenmengen und PCAP-Aufzeichnungen und -Downloads, falls die entsprechende Berechtigung besteht und der Paketringspeicher zum Einsatz kommt. Dies bot uns die Möglichkeit, bei Überlastsituationen eine Auswertung des Traffics einzelner Clients durchzuführen. Auch die ARP-Statistiken zur Korrelation von IP- zu MAC-Adressen stellten sich als hilfreich heraus. Gerade bei geclusterten Diensten in Rechenzentren kommen in einigen Fällen HA-Mechanismen zum Einsatz, die auf ARP aufbauen. Sei es durch differierende ARP-Antworten oder Gratuitous-ARP-Nachrichten bei einem Schwenk zwischen aktiven und passiven Servern. Wir konnten dort sehr schnell die aktuelle Korrelation erkennen und entsprechend bei Problemen auch PCAP-Aufzeichnungen herunterladen und analysieren.

Auch eine Analyse des Spanning-Tree-Protokolls war möglich. So konnten wir die aktuelle Root-Bridge mit entsprechenden Prioritäten und Timings erkennen. Eine Spanning-Tree-Konvergenz führt kurzzeitig zu Datenverlusten und könnte entweder auf eine Fehlkonfiguration, einen fehlerhaften Link oder einen Angriff hinweisen, um Traffic auf einen Angreifer umzuleiten oder die Datenübertragung zu stören. Daher bot das Network Multimeter im Test einen Root-Bridge-Verlauf, anhand dessen wir Manipulationen mit geänderter Root-Bridge-MAC-Adresse erkennen konnten.

Bursts, also kurze Lastspitzen unter einer Sekunde, können in Rechenzentrumsnetzen zu kurzfristigen Überlastungen führen, die in durchschnittlichen Schnittstellenauslastungen aber nicht erkennbar sind. Bei Echtzeitdiensten wie VoIP wirken sich solche Lastspitzen dennoch aus. Das Allegro Network Multimeter maß in Zeitblöcken von einer Millisekunde, es bestand aber auch die Option, die Intervallzeiten zu erhöhen. Wir konnten auf Schnittstellen oder auch auf MAC-Adressen auswerten sowie mit IP-Statistiken korrelieren, um die Quelle des Bursts im Zeitintervall auszuwerten. Dies brachte also eine ganz neue Sichtbarkeit in unser Testnetz.

Bewegen wir uns nun eine OSI-Schicht nach oben: Auch im Menüpunkt "L3 – IP" fanden sich relevante Punkte für die Netzwerkanalyse im Rechenzentrum. Neben klassischen Angaben zur übertragenen Datenmenge je IP-Adresse und Top-Talker sowie fragmentierten IP-Paketen fanden wir eine nicht ganz korrekte OSI-Korrelation: Die DNS-Analyse, die gemäß OSI-Modell zur Applikationsebene gehört. DNS stellt immer wieder eine Quelle für nicht funktionierende oder verzögerte Kommunikationsbeziehungen dar.

Wir konnten dabei die Anzahl der Anfragen, Antworten, Fehler oder unbeantworteten Anfragen erkennen. Aber auch Antwortzeiten waren analysierbar und nach Server sortierbar. So ließen sich Überlastungen leicht erkennen. Selbst die FQDNs zu fehlerhaften Antworten waren auswertbar, um falsch konfigurierte Clients oder Server auszumachen. Gleichzeitig bietet dies aber auch die Möglichkeit, Denial-of-Service-Angriffe auf DNS-Server zu erkennen.

Trotz seines Alters stellt noch immer das TCP-Protokoll das am häufigsten verwendete Übertragungsprotokoll dar. Die getesteten Appliances boten vielfältige TCP-Statistiken zur Analyse von Datenströmen. So werteten sie automatisiert die initiale Round-Trip-Time (iRTT) im TCP-Handshake aus und gaben diese mit Bewertungshilfe (exzellent, gut, normal, schlecht, problematisch) und zugehörigen FQDNs sowie TLS-Zertifikaten aus. Aber auch allgemeine Antwortzeiten aus den Bestätigungen (ACKs) von TCP-Segmenten standen zur Auswertung bereit.

Das Ganze kam zudem gepaart mit einfachen Filtermöglichkeiten, wie beispielsweise applikationsspezifischen Filtern für WebEx, Teams oder Datentraffic zu Cloudflare. Es reichte eine einfache Eingabe von "cloudflare" im Filter, um die zugehörigen Kommunikationsbeziehungen zu diesem CDN-Anbieter ans Licht zu bringen. Dies dürfte insbesondere bei Performanceanalysen in hybriden Cloudumgebungen hilfreich sein.

Zur Qualitätsanalyse boten sich auch die Statistiken zu Sendewiederholungen (Retransmissions) im Verhältnis zur gesamten übertragenen Datenmenge an. Gleiches gilt für die TCP-Flag-Statistiken, die je IP-Adresse beispielsweise aufzeigen, wie viele DUP ACKs oder RSTs versendet oder empfangen wurden. Massenhafte SYNs könnten auf Angriffe oder Fehler wie etwa fehlende Firewall-Freigaben hindeuten. Auch Zero Windows waren auswertbar – also empfangene TCP-Segmente, die jedoch nicht durch die Applikation verarbeitet werden konnten, etwa durch client- oder serverseitige Überlastung. Ein klassischer Fall von "Es war nicht das Netzwerk".

Zugriffe auf Fileserver finden meist über das Server-Message-Block-Protokoll (SMB) statt. Neben der ermittelten Anzahl von Shares, Clients und Servern, die SMB nutzen, gab das Network Multimeter auch Auskünfte zu erfolgreichen und fehlgeschlagenen SMB-Verbindungen und Trennungen mit Angabe des jeweiligen Servers und Shares. So lassen sich insbesondere bei Lastverteilungen, wie beispielsweise beim Distributed File System (DFS), problematische Server schnell erkennen, was einen echten Mehrwert darstellt. Aber auch für Sicherheitsprüfungen eignete sich das Testgerät. So konnten wir auf einfache Weise angebotene und verwendete SMB-Versionen sichtbar machen und feststellen, ob eine SMB-Verschlüsselung zum Einsatz kommt.

Bei der VoIP-Analyse mit zentral bereitgestellten SIP-Servern und auch Providerübergängen im Rechenzentrum überzeugten uns die Appliances vollends. Dabei fokussiert sich das Network Multimeter auf die heutzutage geläufige Kombination von SIP-Signalisierung und Sprachdatenübertragung über RTP. Dieses Protokoll ist anfällig für Packet Loss, Jitter und Delay und bedarf daher häufiger einer Betrachtung im Netzwerk. Das SIP-Dashboard gab einen ersten Überblick über Fehler wie Loss und Jitter.

Ein besonders interessantes Feature fanden wir im Bereich der SIP-Anrufe: Ohne Kenntnis der SIP-Header konnten wir über eine einfache Rufnummernsuche den zugehörigen Anruf auffinden. Nach einem Klick auf die Anrufdetails erhielten wir neben der Anrufdauer auch die verwendeten Codecs, Jitter und Paketverluste je Richtung angezeigt und hatten die Möglichkeit, uns die Signalisierung sowie die Sprachdaten herunterzuladen und anzuhören. Selbst im Audioformat konnten wir eine oder sogar beide Audiorichtungen anhören, um die Audioqualität unabhängig von Netzwerk-Qualitätsmetriken zu beurteilen.

Auch die Analysemöglichkeit der SIP-Antworttypen erwies sich als hilfreich. Bei vielen 500er-Messages (serverseitige Fehler) könnte dies auf Serverprobleme hindeuten. Viele 404-Fehler (nicht gefunden) deuten auf Falschwahlen oder eine fehlerhafte Nummernmanipulation auf einer TK-Anlage oder einem Session Border Controller hin. Das Ganze ließ sich sogar in Korrelation von Anfrage und Antwort darstellen, da einige Anfrage/Antwort-Kombinationen normal sind (etwa REGISTER und 401 oder INVITE und 407). Als sehr gut empfanden wir auch die Option, nach Rufnummern im Paketringspeicher filtern zu können, um nur relevante Anrufe für die Analyse abzulegen und so dem Datenschutz selbst im Troubleshooting gerecht zu werden. Wenn dann noch die SIP-Eventaufzeichnung aktiviert ist, können jegliche Signalisierungsnachrichten mit zugehöriger Anruf-ID abgelegt werden. So lassen sich Anomalien wie beispielsweise Fehler im Anrufaufbau oder -abbau erkennen.

Der überwiegende Teil heutiger Webtraffic-Übertragung findet TLS-verschlüsselt per HTTPS statt. Dabei bringt TLS einige Abhängigkeiten mit, etwa zu DNS, Zertifikaten/PKI und NTP. Neben Zielservern mit FQDNs und IP-Adressen mit zugehörigem Land bot das Network Multimeter auch die Möglichkeit, die Anzahlen von Requests anzuzeigen.

Spannender für das Troubleshooting wurde es jedoch im Bereich der SSL-Antwortzeiten. Über dieses Dashboard ließen sich Handshake-Zeiten auswerten. So konnten wir in unserem Test einen trägen Verbindungsaufbau zu einem Webserver troubleshooten. Über die GUI der Testgeräte erkannten wir, dass der TCP-Handshake noch mit normalen Round-Trip-Times ablief, also die Latenz im Netzwerk in Ordnung war. Jedoch lief der TLS-Handshake zum Webserver sehr langsam ab. Dies lag an einer überforderten CPU des Webservers in Verbindung mit RSA-4096-Bit-Zertifikaten. Dies erzeugte einen hohen Rechenaufwand auf Serverseite, dem die dieser nicht gewachsen war.

Damit Admins die ermittelten Handshake-Zeit nicht selbst bewerten müssen, hilft die von den Allegro-Entwicklern eingebaute Einschätzung als "exzellent", "gut", "normal", "schlecht" oder "problematisch". Für Sicherheitsanalysen bot sich die Auswertung der verwendeten TLS-Versionen und TLS-Cipher-Suites an. Aktuell sollte als Version nur noch TLS 1.2 oder 1.3 zum Einsatz kommen. Auch den Einsatz unsicherer Cipher Suites konnten wir im Test überprüfen. Dazu bot sich ein Abgleich mit den Empfehlungen des BSI (TR-02102-2) an. Immerhin gab es in unserem Testnetz keine Auffälligkeiten, in größeren Umgebungen könnte dies spannender sein. Bei eventuellen Zertifikatsfehlern bietet sich eine Analyse der jeweiligen Inhalte an. Dafür bot das Testgerät unter anderem die Auswertung der Gültigkeitszeiträume, der Aussteller und des Common Name.

Da das Gerät sensible Daten aufzeichnen und verarbeiten kann, brachte es selbstverständlich auch ein Rechte- und Rollenmodell mit. Neben der lokalen Verwaltung der Nutzer konnten wir auch TACACS+ und LDAP als externe Authentifizierungsebene verwenden. Dies funktionierte inklusive Gruppenzuweisungen im Test ohne Beanstandungen und auch die Dokumentation wurde im Vergleich zu früheren Versionen verbessert. Jedoch war leider nur für lokale Nutzer eine Zweifaktor-Authentifizierung möglich. Der Hersteller zeigte sich hier allerdings aufgeschlossen gegenüber einer zukünftigen Implementierung. Eine Einschränkung auf bestimmte IP-Quellnetze war jedoch nicht möglich. Dies müsste auf einer vorgelagerten Komponente, wie Router oder Switch, beispielsweise auf Basis einer Access Control List (ACL), geschehen.

Zu den vordefinierten Rollen konnten wir auch eigene festlegen sowie bestehende bearbeiten. Neben dem "admin" mit Vollzugriff gab es einen "user" mit reinem Lesezugriff und ohne Zugang zu PCAP-Aufzeichnungen. Letzteres ermöglichte wiederum die "capture"-Rolle. Datenschutzrechtlich interessante Features brachten die Rollen für die Vieraugen-Autorisierung. Dabei brauchte es getrennt nach PCAP-Aufzeichnung oder VoIP-Statistiken (SIP und RTP) der Autorisierung eines Nutzers der Rolle "admin" oder einen weiteren Nutzer mit "api-pcap-4-eyes-authorization" beziehungsweise "api-voip-4-eyes-authorization"-Rolle.

Firmware-Updates stellt der Hersteller in hoher Frequenz bereit. Diese sind jedoch nur mit aktivem Supportvertrag erhältlich. Das Lizenzmodell gestaltet sich einfach: Es gibt nur eine Lizenz für alle Leistungsmerkmale. Eine deutschsprachige Anleitung stellt Allegro Packets leider nicht bereit. Die Online-Dokumentation bietet zumindest die automatische Google-Übersetzung an.

Das Allegro Network Multimeter bietet vielfältige Möglichkeiten zur Aufzeichnung und Analyse von Datenströmen. Insbesondere die Geschwindigkeit der In-Memory-Datenbank bei der Filterung großer Datenmengen überzeugte uns im Test. Dies ist bei großen Datenmengen, wie sie in Rechenzentren anfallen, ein entscheidendes Kriterium. Vordefinierte Grafiken und Wertungen vereinfachen die Applikationsanalyse auch für weniger routinierte Netzwerkanalysten.