🥇Automatisierung von Netzwerkdiensten oder wie man ein virtuelles Labor mit OpenDaylight, Postman und Vrnetlab einrichtet

In diesem Artikel erläutere ich, wie Sie OpenDaylight für die Arbeit mit Netzwerkgeräten einrichten und zeige, wie Sie mit Hilfe von Postman und einfachen RESTCONF Anfragen diese Geräte steuern können. Wir werden nicht mit Hardware arbeiten, sondern stattdessen kleine virtuelle Labore mit einem einzigen Router mithilfe von Vrnetlab auf Ubuntu 20.04 LTS.

Ich werde die detaillierte Konfiguration zunächst am Beispiel des Routers Juniper vMX 20.1R1.11, und dann vergleichen wir sie mit der Konfiguration von Cisco xRV9000 7.0.2.

Inhalt

Notwendige Kenntnisse
Teil 1: Wir diskutieren kurz OpenDaylight (im Folgenden ODL), Postman und Vrnetlab und warum wir diese benötigen
Teil 2: Beschreibung des virtuellen Labors
Teil 3: wir konfigurieren OpenDaylight
Teil 4: wir konfigurieren Vrnetlab
Teil 5: mit Hilfe von Postman verbinden wir den virtuellen Router (Juniper vMX) mit ODL
Teil 6: wir erhalten und ändern die Konfiguration des Routers mithilfe von Postman und ODL
Teil 7: wir fügen Cisco xRV9000 hinzu
Fazit
P.S.
Literaturliste

Notwendige Kenntnisse

Damit der Artikel nicht zu lang wird, habe ich einige technische Details ausgelassen (mit Verweisen auf Literatur, wo man darüber lesen kann).

Daher schlage ich Ihnen Themen vor, die es gut wären (aber nicht unbedingt) vor dem Lesen zu kennen:

Teil 1: ein wenig Theorie

Eine offene SDN-Plattform zur Verwaltung und Automatisierung verschiedener Netzwerke, unterstützt von Linux Foundation
Java im Inneren
Basierend auf dem Model-Driven Service Abstraction Level (MD-SAL)
Verwendet YANG-Modelle zur automatischen Erstellung von RESTCONF-APIs für Netzwerkgeräte

Das zentrale Modul zur Netzwerkverwaltung. Über dieses kommunizieren wir mit den angeschlossenen Geräten. Es wird über eine eigene API gesteuert.

Ausführlicheres über OpenDaylight finden Sie hier hier.

Ein Werkzeug zum Testen von APIs
Ein einfaches und benutzerfreundliches Interface

In unserem Fall interessiert es uns als Mittel zur Sendung von REST-Anfragen an die API von OpenDaylight. Natürlich kann man auch manuell Anfragen stellen, aber in Postman sieht alles sehr anschaulich aus und passt perfekt zu unseren Zielen.

Für diejenigen, die tiefer eintauchen möchten: Es gibt viele Lernmaterialien zu diesem Thema (zum Beispiel).

Ein Werkzeug zum Bereitstellen von virtuellen Routern in Docker
Unterstützt: Cisco XRv, Juniper vMX, Arista vEOS, Nokia VSR und andere.
Open Source

Ein sehr interessantes, aber wenig bekanntes Tool. In unserem Fall werden wir damit Juniper vMX und Cisco xRV9000 auf einer handelsüblichen Ubuntu 20.04 LTS-Installation starten.

Weitere Informationen hierzu finden Sie auf der Projektseite.

Teil 2: Laborarbeit

In diesem Tutorial werden wir das folgende System einrichten:

Wie es funktioniert

Juniper vMX wird in Docker einem Container (mithilfe von Vrnetlab) hochgefahren und fungiert als regulärer virtueller Router.
ODL ist mit dem Router verbunden und ermöglicht dessen Verwaltung.
Postman wird auf einer separaten Maschine ausgeführt, und über ihn senden wir Befehle ODL: zum Verbinden/Trennen des Routers, Ändern der Konfiguration usw.

Kommentar zur Systemeinheit

Juniper vMX und ODL benötigen für einen stabilen Betrieb relativ viele Ressourcen. Allein vMX fordert 6 GB RAM und 4 Kerne. Daher wurde beschlossen, alle "schwergewichtigen" Teile auf eine separate Maschine auszulagern (Hewlett Packard Enterprise MicroServer ProLiant Gen8, Ubuntu 20.04 LTS). Der Router funktioniert darauf zwar nicht blitzschnell, aber für kleine Experimente reicht die Leistung aus.

Teil 3: OpenDaylight einrichten

Die aktuelle Version von ODL zum Zeitpunkt des Schreibens ist Magnesium SR1

1) Installieren Sie Java OpenJDK 11 (für eine detailliertere Installation hierhin)

ubuntu:~$ sudo apt install default-jdk

2) Wir finden und laden die neueste Version herunter ODL hier herunter
3) Wir entpacken das heruntergeladene Archiv
4) Wir wechseln in das entstandene Verzeichnis
5) Wir starten ./bin/karaf

An dieser Stelle ODL sollte es starten und wir befinden uns in der Konsole (Für den externen Zugriff verwenden wir Port 8181, auf den wir später zurückkommen werden).

Als nächstes installieren wir ODL Features, die für die Arbeit mit Protokollen vorgesehen sind NETCONF und RESTCONF. Dazu führen wir in der Konsole aus: ODL opendaylight-user@root> feature:install odl-netconf-topology odl-restconf-all

Damit ist die einfachste Konfiguration

abgeschlossen. (Mehr dazu können Sie lesen ODL Teil 4: Konfigurieren von Vrnetlab hier).

Systemvorbereitung

Vor der Installation

müssen die benötigten Pakete installiert werden. Diese sind unter anderem Vrnetlab sshpass Docker, git, ubuntu:~$ sudo apt update ubuntu:~$ sudo apt -y install python3-bs4 sshpass make ubuntu:~$ sudo apt -y install git ubuntu:~$ sudo apt install -y apt-transport-https ca-certificates curl gnupg-agent software-properties-common ubuntu:~$ curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add - ubuntu:~$ sudo add-apt-repository "deb [arch=amd64] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable" ubuntu:~$ sudo apt update ubuntu:~$ sudo apt install -y docker-ce docker-ce-cli containerd.io:

ubuntu:~$ sudo apt update
ubuntu:~$ sudo apt -y install python3-bs4 sshpass make
ubuntu:~$ sudo apt -y install git
ubuntu:~$ sudo apt install -y 
    apt-transport-https ca-certificates 
    curl gnupg-agent software-properties-common
ubuntu:~$ curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add -
ubuntu:~$ sudo add-apt-repository 
   "deb [arch=amd64] https://download.docker.com/linux/ubuntu 
   $(lsb_release -cs) 
   stable"
ubuntu:~$ sudo apt update
ubuntu:~$ sudo apt install -y docker-ce docker-ce-cli containerd.io

Installation von Vrnetlab

Zur Installation Vrnetlab klonen wir das entsprechende Repository von Github:

ubuntu:~$ cd ~
ubuntu:~$ git clone https://github.com/plajjan/vrnetlab.git

Wir wechseln in das Verzeichnis vrnetlab:

ubuntu:~$ cd ~/vrnetlab

Hier finden Sie alle Skripte, die für den Start erforderlich sind. Beachten Sie, dass für jeden Routertyp ein entsprechendes Verzeichnis angelegt wurde:

ubuntu:~/vrnetlab$ ls
CODE_OF_CONDUCT.md  config-engine-lite        openwrt           vr-bgp
CONTRIBUTING.md     csr                       routeros          vr-xcon
LICENSE             git-lfs-repo.sh           sros              vrnetlab.sh
Makefile            makefile-install.include  topology-machine  vrp
README.md           makefile-sanity.include   veos              vsr1000
ci-builder-image    makefile.include          vmx               xrv
common              nxos                      vqfx              xrv9k

Erstellen des Router-Images

Jeder unterstützte Router Vrnetlab, hat sein eigenes, einzigartiges Konfigurationsverfahren. Im Fall von Juniper vMX müssen wir lediglich das .tgz-Archiv mit dem Router (downloadbar von der offiziellen Webseite) in das Verzeichnis vmx kopieren und den Befehl ausführen make:

ubuntu:~$ cd ~/vrnetlab/vmx
ubuntu:~$ # Kopieren Sie das .tgz-Archiv mit dem Router in dieses Verzeichnis
ubuntu:~$ sudo make

Der Build des Images vMX dauert etwa 10-20 Minuten. Genau die richtige Zeit, um einen Kaffee zu machen!

Warum dauert das so lange, fragen Sie sich?

Die Übersetzung der Antwort des Autors auf diese Frage:

"Dies liegt daran, dass beim ersten Start von VCP (Control Plane) die Konfigurationsdatei eingelesen wird, die festlegt, ob es als VRR VCP im vMX fungiert. Früher wurde dieser Start während des Docker-Starts ausgeführt, was bedeutete, dass VCP immer einmal neu gestartet wurde, bevor der virtuelle Router verfügbar war, was zu langen Bootzeiten (ca. 5 Minuten) führte. Jetzt erfolgt der erste Start von VCP während des Erstellens des Docker-Images, und da der Docker-Bau nicht mit dem --privileged-Parameter ausgeführt werden kann, bedeutet dies, dass qemu ohne KVM-Hardwarebeschleunigung läuft und die Erstellung daher sehr lange dauert. Während dieses Prozesses werden viele Protokolle ausgegeben, sodass Sie zumindest sehen können, was passiert. Ich denke, dass die lange Erstellung nicht so schlimm ist, weil wir das Image nur einmal erstellen und es dann oft starten."

Nachher kann das Image unseres Routers in Docker:

ubuntu:~$ sudo docker image list
REPOSITORY          TAG                 IMAGE ID            CREATED             SIZE
vrnetlab/vr-vmx     20.1R1.11           b1b2369b453c        vor 3 Wochen         4.43GB
debian              stretch             614bb74b620e        vor 7 Wochen         101MB

Wir starten den Container vr-vmx

Wir starten mit dem Befehl:

ubuntu:~$ sudo docker run -d --privileged --name jun01 b1b2369b453c

Als Nächstes können wir die Informationen über aktive Container abrufen:

ubuntu:~$ sudo docker container list
CONTAINER ID        IMAGE               COMMAND             CREATED             STATUS                     PORTS                                                 NAMES
120f882c8712        b1b2369b453c        "/launch.py"        vor 2 Minuten       2 Minuten aktiv (ungesund)   22/tcp, 830/tcp, 5000/tcp, 10000-10099/tcp, 161/udp   jun01

Wir verbinden uns mit dem Router

Die IP-Adresse des Netzwerkinterfaces des Routers kann mit folgendem Befehl abgerufen werden:

ubuntu:~$ sudo docker inspect --format '{{.NetworkSettings.IPAddress}}' jun01
172.17.0.2

Standardmäßig Vrnetlab wird ein Benutzer für den Router erstellt vrnetlab/VR-netlab9.
Die Verbindung erfolgt über ssh:

ubuntu:~$ ssh vrnetlab@172.17.0.2
Die Authentizität des Hosts '172.17.0.2 (172.17.0.2)' kann nicht überprüft werden.
ECDSA Schlüssel-Fingerprint ist SHA256:g9Sfg/k5qGBTOX96WiCWyoJJO9FxjzXYspRoDPv+C0Y.
Sind Sie sicher, dass Sie die Verbindung fortsetzen möchten (ja/nein/[Fingerabdruck])? ja
Warnung: '172.17.0.2' (ECDSA) wurde dauerhaft zur Liste der bekannten Hosts hinzugefügt.
Passwort:
--- JUNOS 20.1R1.11 Kernel 64-Bit  JNPR-11.0-20200219.fb120e7_build
vrnetlab> show version
Modell: vmx
Junos: 20.1R1.11

Damit ist die Konfiguration des Routers abgeschlossen.

Installationsempfehlungen für Router verschiedener Hersteller finden Sie auf dem Github-Projekt in den entsprechenden Verzeichnissen.

Teil 5: Postman — Router mit OpenDaylight verbinden

Postman installieren

Für die Installation genügt es, die Anwendung herunterzuladen hier herunter.

Router mit ODL verbinden

Lassen Sie uns eine PUT

Anforderung erstellen:

PUT http://10.132.1.202:8181/restconf/config/network-topology:network-topology/topology/topology-netconf/node/jun01

Anfragekörper (Reiter Body):

jun01
172.17.0.2
22
vrnetlab
VR-netlab9
false
jun01_cache

Im Reiter Authorization muss der Parameter eingestellt werden Basic Auth und Benutzername/Passwort: admin/admin. Dies ist erforderlich, um Zugriff auf ODL zu erhalten:
Im Reiter Headers müssen zwei Header hinzugefügt werden:
- Accept application/xml
- Content-Type application/xml

Unsere Anfrage ist formuliert. Senden wir sie ab. Wenn alles korrekt konfiguriert ist, sollten wir den Status "201 Created" zurückerhalten:

Was bewirkt diese Anfrage?

Wir erstellen einen Node innerhalb ODL mit den Parametern eines echten Routers, auf den wir zugreifen möchten.

xmlns="urn:TBD:params:xml:ns:yang:network-topology"
xmlns="urn:opendaylight:netconf-node-topology"

Dies sind interne Namensräume XML (XML-Namespace) für ODL nach denen der Node erstellt wird.

Das Routername ist entsprechend node-id, die Routeradresse ist host usw.

Die interessanteste Zeile ist die letzte. Schema-Cache-Verzeichnis erzeugt ein Verzeichnis, in das alle Dateien heruntergeladen werden YANG Schema des verbundenen Routers. Sie sind zu finden in $ODL_ROOT/cache/jun01_cache.

Überprüfen der Routerverbindung

Lassen Sie uns GET PUT

Anforderung erstellen:

GET http://10.132.1.202:8181/restconf/operational/network-topology:network-topology/topology/topology-netconf/

Im Reiter Authorization muss der Parameter eingestellt werden Basic Auth und Logininformationen: admin/admin.

Senden. Wir sollten den Status "200 OK" und eine Liste aller vom Gerät unterstützten YANG Schema:

Kommentar: Um das Letzte zu sehen, musste ich in meinem Fall etwa 10 Minuten warten, nachdem ich eine, bis alle YANG-Schemas exportiert sind. ODLBis zu diesem Zeitpunkt wird bei der Ausführung dieser GET Anfrage Folgendes ausgegeben:

Router löschen

Lassen Sie uns DELETE PUT

Anforderung erstellen:

DELETE http://10.132.1.202:8181/restconf/config/network-topology:network-topology/topology/topology-netconf/node/jun01

Im Reiter Authorization muss der Parameter eingestellt werden Basic Auth und Logininformationen: admin/admin.

Teil 6: Routerkonfiguration ändern

Konfiguration abrufen

Lassen Sie uns GET PUT

Anforderung erstellen:

GET http://10.132.1.202:8181/restconf/config/network-topology:network-topology/topology/topology-netconf/node/jun01/yang-ext:mount/

Im Reiter Authorization muss der Parameter eingestellt werden Basic Auth und Logininformationen: admin/admin.

Senden. Wir sollten den Status "200 OK" und die Routerkonfiguration erhalten:

Konfiguration erstellen

Als Beispiel erstellen wir die folgende Konfiguration und ändern sie:

protocols {
    bgp {
        disable;
        shutdown;
    }
}

Lassen Sie uns POST PUT

Anforderung erstellen:

POST http://10.132.1.202:8181/restconf/config/network-topology:network-topology/topology/topology-netconf/node/jun01/yang-ext:mount/junos-conf-root:configuration/junos-conf-protocols:protocols

Anfragekörper (Reiter Body):
Im Reiter Authorization muss der Parameter eingestellt werden Basic Auth und Logininformationen: admin/admin.
Im Reiter Headers müssen zwei Header hinzugefügt werden:
- Accept application/xml
- Content-Type application/xml

Nach dem Senden sollte der Status "204 No Content" erhalten werden.

Um zu überprüfen, ob die Konfiguration geändert wurde, kann die vorherige Anfrage verwendet werden. Zur besseren Veranschaulichung erstellen wir jedoch eine weitere Anfrage, die uns Informationen nur über die auf dem Router konfigurierten Protokolle ausgibt.

Lassen Sie uns GET PUT

Anforderung erstellen:

GET http://10.132.1.202:8181/restconf/config/network-topology:network-topology/topology/topology-netconf/node/jun01/yang-ext:mount/junos-conf-root:configuration/junos-conf-protocols:protocols

Im Reiter Authorization muss der Parameter eingestellt werden Basic Auth und Logininformationen: admin/admin.

Nach der Anfrage sehen wir Folgendes:

Konfiguration ändern

Wir werden die Informationen über das BGP-Protokoll ändern. Nach unseren Änderungen wird es wie folgt aussehen:

protocols {
    bgp {
        disable;
    }
}

Lassen Sie uns eine PUT

Anforderung erstellen:

PUT http://10.132.1.202:8181/restconf/config/network-topology:network-topology/topology/topology-netconf/node/jun01/yang-ext:mount/junos-conf-root:configuration/junos-conf-protocols:protocols

Anfragekörper (Reiter Body):
Im Reiter Authorization muss der Parameter eingestellt werden Basic Auth und Logininformationen: admin/admin.
Im Reiter Headers müssen zwei Header hinzugefügt werden:
- Accept application/xml
- Content-Type application/xml

Unter Verwendung der vorherigen GET Anfrage sehen wir die Änderungen:

Konfiguration entfernen

Lassen Sie uns DELETE PUT

Anforderung erstellen:

DELETE http://10.132.1.202:8181/restconf/config/network-topology:network-topology/topology/topology-netconf/node/jun01/yang-ext:mount/junos-conf-root:configuration/junos-conf-protocols:protocols

Im Reiter Authorization muss der Parameter eingestellt werden Basic Auth und Logininformationen: admin/admin.

Beim Aufruf GET der Abfrage mit Informationen zu Protokollen sehen wir Folgendes:

Zusatz:

Um die Konfiguration zu ändern, ist es nicht unbedingt notwendig, den Anfragebody im Format XMLzu senden. Dies kann auch im Format JSON.

geschafft werden, zum Beispiel in der Anfrage eine zur Änderung der Konfiguration ersetzen wir den Anfragebody durch:

{
    "junos-conf-protocols:protocols": {
        "bgp": {
            "beschreibung" : "In Postman geändert" 
        }
    }
}

Vergessen Sie nicht, auf der Registerkarte Headers die folgenden Header zu ändern auf:

Accept application/json
Content-Type application/json

Nach dem Senden erhalten wir folgendes Ergebnis (Antwort ansehen mit GET Request):

Teil 7: hinzugefügt Cisco xRV9000

Immer nur über Juniper reden? Lassen Sie uns über Cisco sprechen!
Ich habe einen xRV9000 der Version 7.0.2 gefunden (ein Monster, das 8Gb RAM und 4 Kerne benötigt. Es ist nicht öffentlich verfügbar, daher wenden Sie sich an Cisco) — den werden wir starten.

Starten des Containers

Der Prozess zur Erstellung eines Docker-Containers unterscheidet sich kaum von Juniper. Ebenso legen wir die .qcow2-Datei mit dem Router in das Verzeichnis, das seinem Namen entspricht, (in diesem Fall xrv9k) und führen den Befehl aus make docker-image.

Nach ein paar Minuten sehen wir, dass das Image erstellt wurde:

ubuntu:~$ sudo docker image ls
REPOSITORY          TAG                 IMAGE ID            CREATED             SIZE
vrnetlab/vr-xrv9k   7.0.2               54debc7973fc        vor 4 Stunden       1.7GB
vrnetlab/vr-vmx     20.1R1.11           b1b2369b453c        vor 4 Wochen        4.43GB
debian              stretch             614bb74b620e        vor 7 Wochen        101MB

Wir starten den Container:

ubuntu:~$ sudo docker run -d --privileged --name xrv01 54debc7973fc

Nach einer kurzen Zeit überprüfen wir, dass der Container gestartet ist:

ubuntu:~$ sudo docker ps
CONTAINER ID        IMAGE               COMMAND             CREATED             STATUS                 PORTS                                                      NAMES
058c5ecddae3        54debc7973fc        "/launch.py"        vor 4 Stunden       Hoch (gesund) seit 4 Stunden   22/tcp, 830/tcp, 5000-5003/tcp, 10000-10099/tcp, 161/udp   xrv01

Wir verbinden uns per SSH:

ubuntu@ubuntu:~$ ssh vrnetlab@172.17.0.2
Passwort:

RP/0/RP0/CPU0:ios#show version
Mon Jul  6 12:19:28.036 UTC
Cisco IOS XR Software, Version 7.0.2
Copyright (c) 2013-2020 by Cisco Systems, Inc.

Build Information:
 Built By     : ahoang
 Built On     : Fri Mar 13 22:27:54 PDT 2020
 Built Host   : iox-ucs-029
 Workspace    : /auto/srcarchive15/prod/7.0.2/xrv9k/ws
 Version      : 7.0.2
 Location     : /opt/cisco/XR/packages/
 Label        : 7.0.2

cisco IOS-XRv 9000 () Prozessor
Systembetriebszeit beträgt 3 Stunden 22 Minuten

Wir verbinden den Router mit OpenDaylight

Die Hinzufügung erfolgt ganz ähnlich wie beim vMX-Abbild. Es müssen nur die Namen geändert werden.
eine PUT

Nach einiger Zeit rufen wir GET eine Anfrage auf, um zu überprüfen, dass alles verbunden ist:

Konfiguration ändern

Wir werden die folgende Konfiguration einrichten:

!
router ospf LAB
 mpls ldp auto-config
!

Lassen Sie uns POST PUT

Anforderung erstellen:

POST http://10.132.1.202:8181/restconf/config/network-topology:network-topology/topology/topology-netconf/node/xrv01/yang-ext:mount/Cisco-IOS-XR-ipv4-ospf-cfg:ospf

Anfragekörper (Reiter Body):

{
    "processes": {
        "process": [
            {
                "process-name": "LAB",
                "default-vrf": {
                    "process-scope": {
                        "ldp-auto-config": [
                            null
                        ]
                    }
                }
            }
        ]
    }
}

Im Reiter Authorization muss der Parameter eingestellt werden Basic Auth und Logininformationen: admin/admin.
Im Reiter Headers müssen zwei Header hinzugefügt werden:
- Accept application/json
- Content-Type application/json

Nach der Ausführung sollte der Status "204 No Content" angezeigt werden.

Lass uns überprüfen, ob alles geklappt hat.
Dafür erstellen wir GET PUT

Anforderung erstellen:

GET http://10.132.1.202:8181/restconf/config/network-topology:network-topology/topology/topology-netconf/node/xrv01/yang-ext:mount/Cisco-IOS-XR-ipv4-ospf-cfg:ospf

Im Reiter Authorization muss der Parameter eingestellt werden Basic Auth und Logininformationen: admin/admin.

Nach der Ausführung sollten wir Folgendes sehen:

Um die Konfiguration zu löschen, verwenden wir DELETE:

Anforderung erstellen:

DELETE http://10.132.1.202:8181/restconf/config/network-topology:network-topology/topology/topology-netconf/node/xrv01/yang-ext:mount/Cisco-IOS-XR-ipv4-ospf-cfg:ospf

Im Reiter Authorization muss der Parameter eingestellt werden Basic Auth und Logininformationen: admin/admin.

Fazit

Wie Sie wahrscheinlich bemerkt haben, sind die Verbindungsverfahren für Cisco und Juniper zu OpenDaylight ähnlich – das eröffnet viele kreative Möglichkeiten. Von der Verwaltung der Konfigurationen aller Netzwerkkomponenten bis hin zur Erstellung eigener Netzwerkrichtlinien.
In diesem Tutorial habe ich einfache Beispiele aufgeführt, wie man mit Netzwerkhardware über OpenDaylight interagieren kann. Zweifellos können die Anfragen aus den gezeigten Beispielen deutlich komplexer gestaltet werden, und ganze Dienste können mit nur einem Klick eingerichtet werden – alles hängt nur von Ihrer Vorstellungskraft ab.

Die Fortsetzung folgt…

P.S.

Falls Sie bereits mit diesem Thema vertraut sind oder sich für ODL begeistert haben, empfehle ich, die Entwicklung von Anwendungen auf dem ODL-Controller in Betracht zu ziehen. Der Einstieg ist einfach. hier herunter.

Viel Erfolg bei Ihren Experimenten!