Netzwerk-Emulatoren – Ihre virtuelle Laborumgebung zum Testen und Lernen

Testaufbau in Hardware?

Der Aufbau einer realen Testumgebung, also einer Umgebung mit physischen Switches, Routern, Firewalls oder anderen Netzkomponenten ist aufwendig und kostenintensiv. Da wären zum einen die Kosten für die Beschaffung dieser Komponenten, zum anderen benötigen diese viel Platz und natürlich Energie. Darüber hinaus entwickelt sich Netzwerkhardware rasant weiter. Der Router oder Switch, der für den Aufbau des Testlabors beschafft wurde, unterstützt nach einiger Zeit möglicherweise nicht mehr alle Features, die für einen aktuellen Test benötigt werden, eine neue Software-Version lässt sich nicht mehr installieren, oder es sind zu wenig Komponenten für den Testaufbau oder die Anzahl der Mitarbeiter vorhanden. Infolgedessen wird die einst beschaffte Netzwerkhardware schnell nutzlos und verstaubt im IT-Lager. An dieser Stelle können Software-basierte Netzwerk-Emulatoren ihre Vorteile ausspielen. Schließlich werden alle wesentlichen Funktionen, die auf einer Netzkomponente zur Verfügung stehen, durch die Software, die auf ihnen läuft, bestimmt. Darüber hinaus sind viele Netzkomponenten ohnehin als sogenannte virtuelle Appliances verfügbar, sei es zusätzlich zu einer Hardware-basierten Komponente oder mehr und mehr auch eben ausschließlich.

Was sind Netzwerk-Emulatoren?

Im Kontext dieses Artikels verstehen wir unter einem Netzwerk-Emulator eine Software-Umgebung, mit deren Hilfe Netzwerkkomponenten in einer beliebigen Topologie untereinander verbunden und wie ihre physischen Gegenstücke konfiguriert und schließlich betrieben werden können. Letztendlich transportieren Netzwerk-Emulatoren auch Datenpakete analog zur Funktionsweise von tatsächlichen Komponenten; sie verfügen also über eine sogenannte Dataplane. Ein Netzwerk-Emulator stellt folglich die Hardware der Netzkomponente und das zugehörige Betriebssystem nach. Gerade das Vorhandensein einer Dataplane grenzt die Netzwerk-Emulatoren von einem Netzwerk-Simulator ab. Eine emulierte Netzkomponente transportiert Datenpakete gemäß der innerhalb der Konfiguration gesetzten Regeln. Sie lässt sich mit einem externen Netzwerk verbinden und, wenn auch mit Einschränkungen hinsichtlich der Leistung, nutzen. Ein typisches Beispiel wäre etwa ein WLAN-Controller, der in einer emulierten Umgebung läuft und Access Points verwaltet, die über ein externes Netzwerk angeschlossen sind. Dementgegen werden bei einem Simulator Netzkomponenten innerhalb einer vollständig geschlossenen Umgebung simuliert. Es gibt keine Verbindung zur Außenwelt, eine tatsächliche Dataplane existiert nur insofern, dass Datenpakete simuliert werden. Nichtsdestotrotz eignen sich Netzwerk-Simulatoren ebenso für das Erlernen von Netzwerk-Konfiguration und deren Funktion. Da Netzwerk-Simulatoren immer nur ausgewählte Funktionen bzw. Gerätetypen der Hersteller abbilden, begnügen sie sich im Vergleich zu Emulatoren mit deutlich weniger Hardware-Ressourcen. Ein prominentes Beispiel für einen solchen Netzwerk-Simulator ist der Packet Tracer von Cisco Systems [1]. Produktbeispiele für Netzwerk-Emulatoren, auf welche wir später noch im Detail eingehen werden, sind GNS3 [2], EVE-NG [3] oder, als kommerzielle Variante, das Cisco Modeling Labs [4], dem Nachfolgeprodukt des Virtual Internet Routing Lab (VIRL).

Wie funktionieren Netzwerk-Emulatoren?

Nahezu alle verbreiteten Lösungen setzen Virtualisierung zur Emulation der Netzwerkkomponenten ein. Hierbei unterscheiden sich zwar die eingesetzten Virtualisierungsmethoden, das Grundprinzip ist jedoch meist gleich und vergleichsweise einfach: Der Emulations-Host bietet die Grundfunktionen zur Vernetzung auf ihm gehosteter virtueller Maschinen. Zusätzlich werden Schnittstellen zur Einrichtung der Verbindungen und Netze wie beispielsweise eine Web-GUI verfügbar gemacht. Der Emulations-Host wird in vielen Fällen selber als virtuelle Maschine bereitgestellt, sodass die emulierten Endgeräte geschachtelt als VM in der VM betrieben werden (Nested Virtualization). Abbildung 1 zeigt hierzu den Grundaufbau mit insgesamt drei emulierten Komponenten, EM-VM-1 bis EM-VM-3, welche als virtuelle Maschinen in der Emulator-VM zur Verfügung gestellt werden. Diese wiederrum ist ebenfalls (meist) eine virtuelle Maschine. Hierdurch können alle bekannten Vorteile einer VM-Bereitstellung genutzt werden. Der Emulator ist skalierbar, portabel und kann sehr einfach in bestehende Virtualisierungsumgebungen integriert werden.

Der Einsatz von Nested Virtualization bietet natürlich nicht nur Vorteile. Die geschachtelte Virtualisierung bringt eine reduzierte Performance der VMs mit sich. In Labor-Umgebungen ist dies jedoch meist zu vernachlässigen. Sollte die geringe Performance zum Problem werden, kann ein Emulator Abhilfe schaffen, der direkt auf der Hardware installiert wird. Im weiteren Verlauf werden wir noch kurz auf die eingesetzten Virtualisierungstechniken eingehen.

Netzwerk-Emulation mit einfachsten Mitteln

Für Netzwerk-Emulation braucht man im einfachsten Fall keine spezielle Emulator-Plattform. Die Emulations-Umgebung stellt grundsätzlich ein oder mehrere virtuelle Netze zur Verfügung, die von den virtuellen Maschinen genutzt werden. In allen heute etablierten Virtualisierungssystemen sind virtuelle Netze Standard und werden überall genutzt. Für einen selbst gebauten Netzwerk-Emulator benötigt man nur einen PC bzw. Server, einen Hypervisor und die Betriebssysteme im entsprechenden Format. Über die VM-Einstellungen lassen sich nun die verschiedenen virtuellen Netze verbinden. Man kann z.B. verschiedene LAN-Segmente bilden, die jeweils einem VLAN oder Subnetz entsprechen. Zwei VMs im gleichen Segment können untereinander kommunizieren. Wir müssen also den VMs nur eine bestimmte Anzahl an Netzwerkkarten hinzufügen und diese entsprechend einem gemeinsamen LAN-Segment zuordnen oder mit einem physischen Netz per Bridge-Adapter verbinden. Was bei 2-3 VMs noch ohne größere Probleme möglich ist, wird bei größeren Aufbauten schnell zum Problem: Es gibt keine Darstellung, wo welche VM angebunden ist. Jedes Mal müssen zur Verifizierung die Optionen aufgerufen werden. Nach kürzester Zeit verliert auch ein erfahrener Nutzer den Überblick, Strukturen werden unübersichtlich und einfachste Fehler in der Verbindung sorgen für aufwendige Fehlersuche.

Vorteile der virtuellen Umgebung

An dieser Stelle setzen Netzwerk-Emulatoren an und ermöglichen eine graphische Übersicht über die Verbindungen zwischen den Komponenten. Zudem können Notizen und einfache Zeichnungen eingefügt werden, sodass die Visualisierung hier schnell an Netzwerk-Dokumentationen und Übersichtszeichnungen erinnert. Der Nutzer kann im weitesten Sinne seine Netzwerk-Zeichnungen nachstellen und mit emulierten Komponenten den Live-Betrieb simulieren.

Im Folgenden wollen wir nun die bekanntesten und verbreitetsten Netzwerk-Emulatoren vorstellen und deren Merkmale und Vorteile beschreiben, bevor wir über mögliche Betriebsmodelle sprechen und einen Blick unter die Motorhaube der Emulatoren werfen.

GNS3

Die Abkürzung GNS3 steht für Graphical Network Simulator-3. Es handelt sich sicherlich um einen der bekanntesten Netzwerk-Emulatoren, der unter der GNU GPL lizensiert ist. Die Software der drei Entwickler Jeremy Grossmann, Piotr Pękala und Dominik Ziajka erschien erstmalig im Jahr 2008. GNS3 nutzt unter anderem die Emulations-Software Dynamips, die zur Emulation von Cisco-Routern entwickelt wurde. Zentraler Bestandteil von GNS3 ist die GNS3-All-in-one-Software, die zunächst einmal aus einer GUI und aus einem auf dem lokalen Host laufenden GNS3-Server besteht und auf dem Client installiert werden muss. Auf dem lokalen GNS3-Server können Netzkomponenten direkt virtualisiert werden, es empfiehlt sich jedoch die Installation einer GNS3-VM, die entweder direkt auf demselben oder auf einem separaten Host betrieben werden kann. Ein wesentlicher Bestandteil ist die GUI von GNS3, die in der Regel auf dem lokalen Host läuft. Über die GUI können zunächst einmal alle essenziellen Einstellungen vorgenommen werden, beispielsweise die für den GNS3-Server: Hier erfolgt die Auswahl, ob der lokale GNS3-Server, die GNS3-VM oder sogar mehrere GNS3-Server auf unterschiedlichen Hosts verwendet werden sollen. Ebenso werden über die GNS3-GUI neue Netzkomponenten bzw. virtuelle Maschinen angelegt und integriert. Während der Installation einer neuen Komponente wird das Image über die GUI geladen und in den lokal laufenden GNS3-Server oder in die GNS3-VM übertragen.

Wichtigster Bestandteil der GUI ist der Arbeitsbereich, innerhalb dessen die eigentliche Testumgebung aufgebaut wird. Der Aufbau der Testumgebung erfolgt, vergleichbar mit einem Zeichenprogramm, indem die eine Komponente repräsentierenden Icons in den Arbeitsbereich gezogen und dort geeignet angeordnet werden.

Hinsichtlich der zu emulierenden Komponenten bringt GNS3 direkt „ab Werk“ einen Ethernet-Switch, einen Hub und einen einfachen Linux-PC (Virtual PC Simulator) mit. Letzterer ist ausgesprochen schlank gehalten und unterstützt Ping und DHCP. Der mit GNS3 mitgelieferte Switch verfügt lediglich über Basisfunktionen, wie die Einrichtung von Port-basierten VLANs und VLAN-Tagging gemäß IEEE802.1Q. Die Verbindung zu externen Netzen, etwa dem Internet, erfolgt über eine Cloud. Hinter einer Cloud verbirgt sich eine Netzwerk-Verbindung mit Bridging oder NAT, die vom Virtualisierungshost bzw. vom Host-Betriebssystem zur Verfügung gestellt wird.

Nach der Platzierung der Komponenten in die Arbeitsumgebung folgt das Anlegen der Verbindungen zwischen den einzelnen Komponenten, wobei die jeweils zu verwendenden Ports für eine Verbindung ausgewählt und später entsprechend angezeigt werden können. Die so entstehende Netzwerkzeichnung kann um weitere graphische Elemente wie zum Beispiel Beschriftungen, Rahmen oder Bitmaps ergänzt werden. Nachdem die Netzwerkumgebung auf diese Weise aufgebaut wurde, können die Komponenten über ein Kontextmenü konfiguriert werden. Beispielsweise ist es möglich, die Anzahl der Ethernet-Interfaces oder die Art der Konsole-Verbindung festzulegen. Zusätzlich werden die Komponenten über das Kontextmenü gestartet oder angehalten.

Der Zugriff auf die Komponenten erfolgt schließlich unter Zuhilfenahme der üblichen Werkzeuge wie telnet (putty), VNC oder Spice. Datenpakete, die im virtualisierten Netz zwischen den Komponenten transportiert werden, können mittels Protokollanalysator Wireshark aufgezeichnet und in Echtzeit dargestellt werden. Bei Bedarf werden die benötigten Programme gleich über den GNS3-Installer mit installiert und konfiguriert.

Die Mindestanforderungen von GNS3 an die Hardware sind relativ gering. Die Software begnügt sich mit zwei CPUs, 4 GByte RAM und mindestens 200 Mbyte Festplattenspeicher. Jedoch kann der Bedarf an Systemressourcen in Abhängigkeit von der Art und Anzahl der emulierten Systeme sehr schnell ansteigen. So empfiehlt der Hersteller für ein optimales System folgende Hardware: 8 oder mehr CPUs, 32 GByte RAM und 80 GByte SSD-Speicher.

EVE-NG

Im Gegensatz zum zuvor beschriebenen GNS3 bietet EVE-NG eine Emulations-Lösung ohne Client-Software, was die Nutzung vereinfacht.

Die Verwaltung der Projekte und Bedienung der Labs erfolgt ausschließlich über die HTML5-Web-GUI. An dieser Stelle hat man zudem die Wahl, die Verbindungen zu den Komponenten im Browser (telnet, rdp vnc per HTML5) oder alternativ mit externen Programmen wie PUTTY oder einem VNC-Viewer herzustellen. Wer sich Arbeit und Frustration bei der Einrichtung der externen Werkzeuge für den Zugriff auf die emulierten Komponenten sparen möchte, dem sei die Installation des Tools „Client Side“ angeraten. Der für Windows, MAC-OS und Linux erhältliche Installer lädt, installiert und konfiguriert die benötigten Hilfsprogramme automatisch.

Hinsichtlich der Systemvoraussetzungen gilt Ähnliches wie bei GNS3 oder CML. Je mehr Komponenten bzw. je mehr Komponenten unterschiedlicher Art gleichzeitig emuliert werden sollen, umso höher ist der Speicherbedarf. Als Hilfestellung für die Abschätzung des Ressourcen-Bedarfs bietet der Hersteller eine Excel-Tabelle:

Für sehr leistungshungrige Labore gibt es die Möglichkeit, EVE-NG in einem Cluster aus mehreren Servern zu betreiben.

Während bei GNS3 die Installation neuer Images komfortabel mithilfe eines Assistenten innerhalb der GUI erfolgt, muss für diesen Zweck bei EVE-NG auf die Kommandozeile der Host-VM, einem Ubuntu-Linux, zugegriffen werden. Dies gestaltet sich vergleichsweise umständlich, die einzelnen Arbeitsschritte sind jedoch sehr gut dokumentiert.

Es werden vorkonfigurierte Images zum Einspielen in einen vorhandenen Hypervisor oder ISO-Images zur Eigeninstallation angeboten. Wie gezeigt gehören zu den begrenzenden Faktoren die zur Verfügung stehenden Ressourcen, insbesondere die Arbeitsspeicher. Während man kleinere Laborumgebungen auch auf dem Laptop betreiben kann, benötigt man für größere Testumgebungen mehr Ressourcen.

Hier kann man auf die Import- und Export-Funktion zurückgreifen, um vorhandene Testumgebungen inklusive Konfigurationen zu exportieren und an anderer Stelle wieder zu importieren. So lassen sich einmal aufgebaute Grund-Infrastrukturen an verschiedenen Stellen einsetzen und auch externe Laboraufbauten, z.B. aus dem Internet oder von Kollegen, nutzen.

Neben der Vernetzung der virtuellen Komponenten untereinander besteht ebenfalls die Möglichkeit, das Labor per Bridge-Adapter mit der Außenwelt zu koppeln. Auf diese Art und Weise sind hybride Umgebungen ebenfalls möglich, die zu einem Teil aus virtuellen und zum anderen Teil aus physischen Komponenten bestehen.

Zu jedem Zeitpunkt kann eine Paketaufzeichnung auf einem Interface gestartet werden. Die Darstellung erfolgt entweder per HTML5-Konsole oder direkt im auf dem Client-PC installierten Wireshark.

Neben einer kostenlosen Community-Edition gibt es auch eine Professional-Version und eine Learning-Center-Version, die gegenüber der Basis-Version einige Vorteile bieten. So lässt sich unter anderem die Umgebung Multi-User-fähig einrichten, es werden bis zu 1024 Geräte pro Lab unterstützt und es können Docker-Container eingebunden werden. Mit der Learning-Center-Version lassen sich unterschiedliche Zugriffsrollen definieren.

Für diejenigen, die gute Beispiele suchen oder auch als gute Ausgangsbasis für eigene Labs bietet EVE-NG eine Bibliothek mit zahlreichen bereits vollständig aufgebauten Labs zum Download. Diese sind übersichtlich nach Themen sortiert. Beispielsweise finden sich dort Labs zu den Themen Datacenter mit VXLAN BGP EVPN, SDWAN, Multicast-Labs oder spezielle Hersteller-spezifische Labs.

Zusätzlich zur großen Community, die bei Problemen oder Einrichtung unterstützt, gibt es auch einen offiziellen Support auf der Website.

Cisco Modeling Labs

Cisco Modeling Labs (CML) ist das Nachfolgeprodukt des Virtual Internet Routing LAB. CML kann entweder auf einem Host („Bare Metal“) oder als virtuelle Maschine unter VMware installiert werden.  Die Mindestanforderungen an die Hardware sind 4 CPU-Kerne, 8 GByte RAM und 16 GByte Festplattenspeicher. In Abhängigkeit von der Anzahl und dem Typ der virtualisierten Komponenten kann gerade der Speicherbedarf, analog zu GNS3 oder EVE-NG, schnell ansteigen. Beispielsweise benötigt ein Cisco CSR1000v 3 GByte Speicher. Cisco weist jedoch darauf hin, dass CML die Virtualisierungshardware überbuchen kann, was dazu führt, dass in der Praxis weniger Gesamtspeicher benötigt wird als etwa die Summe der Speicherbedarfe aller Einzel-Komponenten. Das trifft insbesondere dann zu, wenn mehrere Nodes des gleichen Typs verwendet werden.

Cisco bietet CML in den folgenden Lizenz-Stufen an:

Von Haus aus integriert CML die Cisco-eigenen Images für ASAv, CSR1000v, IOS-XRv, IOS-XRv 9000, IOSv, IOSvL2, NX-OS und NX-OS 9000. Hinzu kommen ein WAN-Emulator, Linux-Hosts (Ubuntu und Alpine) sowie der Cisco-eigene Paket-Generator TRex. CML unterstützt ebenfalls Komponenten anderer Hersteller, wie zum Beispiel von Fortinet, Arista, F5 und viele andere mehr. Eine entsprechende Liste bietet die CML-Community [5]. Für die Installation der Images können dort die sogenannten Node Definitions heruntergeladen werden. Dabei handelt es sich um in YAML geschriebene Dateien, die alle für die Installation benötigten Informationen enthalten. Das jeweilige Image selbst muss, wie bei allen anderen Emulatoren auch, unter Beachtung der Lizenzbestimmungen bei zugehörigen Herstellern bezogen werden.

Der Zugriff auf CML erfolgt über eine HTML5-Web-GUI. Das Arbeiten mit CML gestaltet sich vergleichbar zu GNS3 oder EVE-NG. Auch hier werden die Komponenten in eine graphische Arbeitsfläche gezogen und miteinander verbunden. Ebenso gibt es die Möglichkeit, ein LAB oder einzelne Komponenten mit externen Netzen zu verbinden. Hierzu wird ein sogenannter Connector Node verwendet, der entweder für Bridging oder für NAT konfiguriert werden kann. Auch eine Paketaufzeichnung darf bei CML nicht fehlen. Hierfür steht ein in die Oberfläche integriertes Packet-Capture-Werkzeug zur Verfügung, mit dessen Hilfe die über einen Link transportierten Datenpakete angezeigt werden. Alternativ kann eine Paketaufzeichnung im PCAP-Dateiformat heruntergeladen werden.

CML lässt sich in einer DEVNET Sandbox [6] testen. Cisco stellt hierfür ein vorbereitetes CML-Labor zur Verfügung, welches für einen Zeitraum von 4 Stunden reserviert werden kann. Der Zugriff auf das Demo-Lab erfolgt mittels VPN, was die Installation des Cisco-eigenen VPN-Client AnyConnect erforderlich macht.

On-Prem oder doch in die Cloud?

Klassisch würde man seine Umgebung auf eigenen Virtualisierungsservern oder auf dedizierter Hardware betreiben. Darüber hinaus lassen sich die meisten Lösungen auch in Public Clouds bereitstellen, wodurch Ressourcen einfacher skaliert und nach aktiver Benutzung der Umgebung auch wieder freigegeben werden können. Man zahlt also nur für die aktive Zeit im Lab und spart sich die Beschaffung und den dauerhaften Unterhalt in der eigenen Infrastruktur. Eine Bereitstellung in der Cloud kann sich auszahlen, wenn man die virtuelle Labor-Umgebung nur unregelmäßig nutzt oder zeitweise viele Ressourcen benötigt. Sobald die Virtualisierungsumgebung von mehreren Personen oder dem gesamten Team genutzt wird, sollte eine andere Bereitstellungsvariante in Erwägung gezogen werden. Neben dem Eigenbetrieb in der Cloud oder On-Prem gibt es auch die Möglichkeit, dedizierte, in der Cloud gehostete Umgebungen anzumieten, die durch Dienstleister bereitgestellt werden. Die Bereitstellung und Wartung werden vom Dienstleister übernommen, und die Umgebung ist dauerhaft aktiv. Ein Beispiel hierfür ist der Anbieter CloudMyLab [7], der unter anderem alle hier vorgestellten Produkte als Lab as a Service anbietet.

Erste Schritte hin zur eigenen Emulations-Umgebung

Sie fragen sich jetzt, wie man seine eigene Emulations-Lösung aufbauen sollte und welche die richtige für Sie persönlich oder Ihre IT-Abteilung ist? Das sind Fragen, die immer vom jeweiligen Nutzungsszenario abhängen. Wir haben die folgenden Tipps für Sie:

• Verschiedene Emulatoren ausprobieren und vergleichen.

Neben vielen Gemeinsamkeiten sind es vor allem die Unterschiede in Benutzung und Ausrichtung. Hier hilft es nur, die unterschiedlichen Lösungen zu testen, um Ihren Use Case abzudecken. Gegebenenfalls wird auch eine zweite Lösung benötigt, um Spezialfällen gerecht zu werden. Unserer Erfahrung nach gibt es nicht „die perfekte Lösung“, alle Plattformen haben ihre Vor- und Nachteile.

• Klein anfangen und bei Bedarf skalieren.

Wir empfehlen, erst im Kleinen, vielleicht am eigenen Rechner, oder in einer schwächeren VM zu testen. Dass die Projekte und oft auch die VMs exportiert werden können, vereinfacht die Handhabung. Für unregelmäßige Tests können ebenfalls externe Ressourcen wie die Cloud-Bereitstellung genutzt werden.

• Zentrale Lösungen bieten Vorteile.

Wenn neben Ihnen auch weitere Personen oder die ganze Abteilung eine Emulations-Umgebung nutzen will, ist es sinnvoll, eine zentrale Plattform für alle zu schaffen und Labs aktiv untereinander zu tauschen. So können neue Techniken oder Konfigurationen ebenso von mehreren Personen unter gleichen Bedingungen getestet und verifiziert werden.

• Verwaltung und Betrieb der Plattform muss sichergestellt werden.

Neben der initialen Inbetriebnahme muss die Lösung auch regelmäßig aktualisiert und gewartet werden, wenn die Emulations-Umgebung als feste Test- und Weiterbildungsressource angenommen und genutzt wird. Gleiches gilt für die Aktualität der genutzten Software-Images. Wir empfehlen im Vorhinein zu klären, wer bzw. welches Team sich um die Verwaltung der Umgebung kümmert.

• Aufbau innerhalb einer gesicherten, nicht produktiven, Umgebung.

Aus Sicherheitsgründen empfiehlt sich der Aufbau einer Testumgebung innerhalb einer sicheren bzw. isolierten Umgebung, die vom produktiven Netz des Unternehmens logisch oder physikalisch getrennt ist. Auf diese Weise erspart man sich ungewollte Seiteneffekte im produktiven Netz. Zudem benötigen die emulierten Komponenten und die Emulations-Software einen Internetzugang, etwa zum Aufspielen von Updates. Der Zugriff auf die Testumgebung kann beispielsweise mittels VPN oder eines Sprungservers abgesichert und kontrolliert werden.

Images und Virtualisierungstechniken

Zusätzlich zum Emulator sind die verwendeten VMs für den Aufbau essenziell. Für den Betrieb benötigt man die Betriebssystem-Images der Hersteller. Möchte man zum Beispiel eine Firewall emulieren, um eine spezielle Kunden-Konfiguration zu testen, benötigt man genau dieses virtuelle Image, im besten Fall in genau derselben Software-Version.

Glücklicherweise werden häufig die gängigsten Produkte verschiedener Hersteller unterstützt. Genauere Informationen zu den unterstützten Versionen sind in den jeweiligen Dokumentationen angegeben.

An dieser Stelle muss man allerdings darauf hinweisen, dass die Emulatoren „nur“ Virtualisierung, Vernetzung und Verwaltung der virtuellen Maschinen übernehmen.

Der Bezug der Images und deren Lizensierung ist meist dem Anwender überlassen. Für eine entsprechend große Lab-Umgebung ist dies nicht zu vernachlässigen, da hierdurch zudem noch zusätzliche Kosten entstehen können. Für die Verwendung im kleineren Rahmen werden jedoch oft auch Testversionen mit beschränktem Datendurchsatz und zur Verfügung stehender Performance angeboten. Wir empfehlen dies im Vorfeld je Hersteller und VM-Art zu prüfen.

Die virtuellen Images müssen in die Emulations-Umgebung importiert werden. Dies ist je nach Lösung unterschiedlich, jedoch meist gut dokumentiert. Herstellerunabhängige Emulations-Lösungen unterstützen die meist genutzte Virtualisierung mit QEMU/KVM, doch auch Dynamips oder IOL (IOS on Linux). Nach der Implementierung stehen die Systeme auf der Emulator-Oberfläche zur Verfügung und können mehrfach platziert und untereinander verbunden werden.

Wie eingangs erwähnt unterstützt GNS3 Dynamips die Emulation von mittlerweile in die Jahre gekommenen Cisco-Routern. Darüber hinaus können sogenannte IOU-Images verwendet werden. IOU steht für IOS on Unix, also von Cisco portierte Images, die zu x86-64-Hardware kompatibel sind und unter Unix/Linux laufen. Für die Verwendung der IOU-Images innerhalb von GNS3 wird entweder die GNS3-VM oder eine GNS3-Installation unter Linux benötigt.

Neben Dynamips und IOU nutzen GNS3 und EVE-NG die freie Virtualisierungssoftware QEMO [8] (Quick Emulator). QEMU ist in der Lage, die Hardware unterschiedlichster Prozessorarchitekturen zu emulieren, u.a. x86, x64, ARM, Alpha, Sparc32/64.  Mittels QEMU wird folglich die Emulation zahlreicher unterschiedlicher Systeme ermöglicht. Eine gute Übersicht bietet der Marketplace von GNS3 oder die Dokumentation von EVE-NG [9]. Hier findet man eine lange Liste der unterstützten Systeme bzw. Appliances. Für GNS3 kann zu jeder Appliance die für die Installation benötigte Konfigurationsdatei (*.gns3a) auf dem Marketplace heruntergeladen werden. Zudem sind dort Hinweise zur Installation hinterlegt. Das eigentliche Image für die Installation der Appliance muss beim jeweiligen Hersteller bzw. Herausgeber bezogen werden.

EVE-NG Professional sowie GNS3 ab Version 1.5 unterstützen auch Docker Container. Container nutzen Dienste, die vom Kernel des Host-Betriebssystems, also zum Beispiel von der GNS3-VM, bereitgestellt werden. Sie sind nicht auf den Kernel des Betriebssystems angewiesen, das in einer QEMU-VM installiert ist. Dies hat zur Folge, dass Container insgesamt weniger RAM- und CPU-Ressourcen pro Instanz verbrauchen und einen geringeren Speicherbedarf haben [10]. Nützliche Docker-Anwendungen sind beispielsweise Linux-Hosts, Ansible, Wireshark, Web-Browser wie Google Chrome oder Firefox oder der Paket-Generator und Network-Traffic-Generator Ostinato.

Kann ich jedes Image virtualisieren?

Betriebssystem-Images für Netzwerkhardware ist in den meisten Fällen spezifisch auf die jeweilig verwendeten ASICs und andere Hardware abgestimmt. Die meisten spezifischen Betriebssysteme lassen sich aus diesem Grund nicht einfach so virtualisieren. Wie bereits oben erwähnt benötigt man eine spezielle virtuelle Version, die oftmals auch für die virtuelle Verwendung z.B. in Public oder Private Clouds entwickelt wurden. Glücklicherweise bieten die meisten Hersteller ein entsprechendes Betriebssystem-Abbild an oder sehen den Bedarf an Netzwerk-Virtualisierung und bieten hierzu spezielle Images an.

Grenzen der Virtualisierung

Wenngleich Virtualisierung gegenüber einem physischen Lab viele Vorteile bietet, gibt es auch Grenzen, die je nach Anwendungsfall nicht zu vernachlässigen sind.

Da alle Betriebssysteme nur virtualisiert betrieben werden, sind viele auf Hardware basierende Funktionen nicht verfügbar. Als Beispiel können diverse Cluster-Technologien, wie Multi-Chassis-Link-Aggregation (MLAG) oder Stacking, sowie spezifische Funktionen, wie z.B. Software-Updates, genannt werden. Allerdings entwickeln sich die Emulatoren von Version zu Version weiter, sodass etwa bei GNS3 mittlerweile gängige Switching-Technologien wie Spanning Tree (MST, PVST), Link Aggregation (Etherchannel), Dynamic Trunking Protocol (DTP) oder Port Security unterstützt werden. Dies gilt allerdings nicht pauschal und ist immer vom Hersteller und Image abhängig und sollte daher unbedingt vorher geprüft werden.

Weiterhin lassen sich nicht immer alle Plattformen virtuell bereitstellen. Wird beispielsweise eine neue Hardware- und Software-Generation angeboten, wird diese mit hoher Wahrscheinlichkeit nicht unmittelbar virtuell zur Verfügung stehen.

Zudem gibt es oft kleinere, geringfügige Konfigurationsunterschiede zwischen Hardware-Plattform und virtualisierter Plattform. Hier sind insbesondere eingeschränkte Funktionen der Virtualisierung oder auch der verwendeten Hardware zu nennen. Beispiele sind Spezial-Funktionen, die nur in bestimmten Produkt-Reihen unterstützt werden. Gleiches gilt für das Nachvollziehen von Bugs und Fehlern in Kombinationen aus Betriebssystem und Hardware. Dies ist virtuell nur sehr begrenzt möglich, solange hinter dem Bug kein Konfigurationsfehler oder eine generelle Limitierung des Herstellers steht.

Kann ein virtuelles Labor also eine physische Laborumgebung 1:1 ersetzen? Nein, allerdings überwiegen dennoch die Vorteile durch unkomplizierte Bereitstellung, schnelle Skalierung, umfassende Erreichbarkeit und geringere Kosten. In der Praxis kann eine hybride Testumgebung den Arbeits- und Deployment-Prozess beschleunigen und vereinfachen. Hierzu ein einfaches Beispiel:

Wir planen die Ausstattung eines neuen Kunden-Standorts mit aktiver Netzhardware. Die Hardware wird direkt zum Kunden geliefert. Für den Aufbau steht ein gewisser, begrenzter Zeitraum zur Verfügung. Nachdem das Feinkonzept festgelegt ist, kann die Konfiguration der Geräte vorbereitet und in der Emulations-Umgebung getestet werden. Hier fallen die ersten Fehler auf und können behoben werden, z.B. Syntaxfehler, fehlerhafte Konfiguration von Routing-Protokollen, Firewall-Features, die zusätzlich konfiguriert werden müssen, usw.  Nach Überarbeitung der vorbereiteten Konfigurationen können eine kleine Laborumgebung vor Ort aufgebaut und die plattform-spezifischen Konfigurationen getestet werden. Vermutlich werden hier noch einige Details auffallen und müssen korrigiert werden.

Durch das Testen der Grund-Konfiguration in der Virtualisierungsumgebung sind es jedoch weitaus weniger Fehler, und diese können schneller behoben werden. Der Rollout vor Ort wird beschleunigt, und die vergleichsweise teure und kritische Vor-Ort-Tätigkeit kann schneller erfolgen.

Disclaimer

Obwohl gängige Praxis, darf nicht jedes verfügbare Software-Image in einer Emulations-Umgebung ohne Weiteres genutzt werden. Davor haben die Hersteller ihre Lizenzbedingungen gesetzt, was in Anbetracht der Tatsache, dass die Hersteller und deren Programmierer ebenfalls Geld verdienen möchten, verständlich ist.

Vor dem Einsatz eines speziellen Images sind demnach die Lizenzbedingungen zu überprüfen. Möglicherweise gibt es für spezielle Komponenten eine sogenannte Evaluierungs-Lizenz oder eine spezielle Education-Lizenz, die entweder kostengünstig erworben werden kann oder für einen eingeschränkten Zeitraum kostenlos nutzbar ist. Man sei jedoch getröstet: Die Open-Source-Gemeinde liefert zahlreiche sehr gute Produkte, die entsprechend genutzt werden können. Open-Source-Entwickler freuen sich übrigens immer über einen Click auf den Donate-Link.

Fazit und Zusammenfassung

Egal, ob eine kostenlose oder eine kostenpflichtige Netzwerk-Emulations-Software verwendet werden soll, es kostet mindestens Zeit und Mühe, eine ordentlich nutzbare Umgebung auf die Beine zu stellen. Auch wir sind bei unseren Tests immer wieder auf Probleme gestoßen, sei es bei der Installation und Inbetriebnahme der Emulatoren oder beim Einbinden neuer Images.

Zum Glück gibt es im Internet eine große Community, sodass für das eine oder andere Problem immer eine schnelle Lösung gefunden werden konnte. Zusammengefasst können wir jedoch sagen, dass es die Mühe wert war, da wir Netzwerk-Emulatoren mittlerweile häufig zum Lernen, zum Testen oder sogar für Live-Demos in unseren Seminaren verwenden können. Obgleich wir innerhalb dieses Artikels bei diesem komplexen Thema nur an der Oberfläche kratzen konnten, hoffen wir dennoch, Ihr Interesse geweckt zu haben und dass Sie den Emulator vielleicht auch selber einmal ausprobieren. Wir helfen gerne weiter.

Verweise

[1] https://www.netacad.com/courses/packet-tracer; 08.08.2022

[2] https://www.gns3.com/ ; 08.08.2022

[3] https://www.eve-ng.net/; 08.08.2022

[4] https://developer.cisco.com/modeling-labs/ ; 08.08.2022

[5] https://github.com/CiscoDevNet/cml-community/tree/master/node-definitions

[6] https://devnetsandbox.cisco.com/RM/Topology ; 21.08.2022

[7] https://cloudmylab.com/#

[8] https://www.qemu.org/; 20.08.2022

[9] https://www.eve-ng.net/index.php/documentation/supported-images/

[10] https://docs.gns3.com/docs/emulators/docker-support-in-gns3; 20.08.2022