Automatisation des services réseau ou comment créer un laboratoire virtuel à l'aide d'OpenDaylight, Postman et Vrnetlab

Dans cet article, je vais expliquer comment configurer OpenDaylight pour travailler avec du matériel réseau, et je montrerai également comment, avec Postman et des simples RESTCONF requêtes, cet équipement peut être géré. Nous ne travaillerons pas directement sur le matériel, mais à la place, nous allons déployer de petites laboratoires virtuels avec un seul routeur, à l'aide de Vrnetlab sur Ubuntu 20.04 LTS.

Je vais d'abord montrer la configuration détaillée à partir d'un exemple de routeur Juniper vMX 20.1R1.11, puis nous comparerons cela à la configuration de Cisco xRV9000 7.0.2.

Contenu

• Connaissances nécessaires
• Partie 1: nous discutons brièvement de OpenDaylight (ci-après ODL), Postman et Vrnetlab et pourquoi nous en aurons besoin
• Partie 2: description du laboratoire virtuel
• Partie 3: configuration de OpenDaylight
• Partie 4: configuration de Vrnetlab
• Partie 5: à l'aide de Postman nous connectons le routeur virtuel (Juniper vMX) à ODL
• Partie 6: nous obtenons et modifions la configuration du routeur à l'aide de Postman et ODL
• Partie 7: ajout de Cisco xRV9000
• Conclusion
• P.S.
• Bibliographie

Connaissances nécessaires

Pour éviter que l'article ne devienne trop long, j'ai omis certains détails techniques (avec des liens vers la littérature où vous pouvez en lire plus).

Par conséquent, je vous propose des sujets que vous devriez idéalement (mais pas nécessairement) connaître avant de lire :

• NETCONF, RESTCONF
• colonnes / JSON
• YANG
• Compréhension de base de Docker

Partie 1 : un peu de théorie

• Plateforme SDN ouverte pour la gestion et l'automatisation de divers réseaux, supportée par Linux Foundation
• Java à l'intérieur
• Basé sur le Modèle-Niveau d'Abstraction de Service Orienté Modèle (MD-SAL)
• Utilise les modèles YANG pour créer automatiquement l'API RESTCONF des dispositifs réseau

Module principal pour la gestion du réseau. C'est à travers lui que nous allons communiquer avec les appareils connectés. Géré via sa propre API.

Vous pouvez lire plus en détail sur OpenDaylight ici.

• Outil pour tester l'API
• Interface simple et conviviale

Dans notre cas, il nous intéresse en tant qu'outil pour envoyer des requêtes REST à l'API d'OpenDaylight. Bien sûr, il est aussi possible d'envoyer des requêtes manuellement, mais dans Postman, tout est très visuel et convient parfaitement à nos objectifs.

Pour ceux qui veulent approfondir : de nombreux matériaux d'apprentissage ont été écrits à ce sujet (par exemple).

• Outil pour déployer des routeurs virtuels dans Docker
• Supporte : Cisco XRv, Juniper vMX, Arista vEOS, Nokia VSR, etc.
• Open Source

Un outil très intéressant mais peu connu. Dans notre cas, nous allons utiliser cet outil pour lancer Juniper vMX et Cisco xRV9000 sur une Ubuntu 20.04 LTS classique.

Vous pouvez en lire plus à ce sujet sur page du projet.

Partie 2 : travaux pratiques

Dans le cadre de ce tutoriel, nous allons configurer le système suivant :

Comment cela fonctionne

• Juniper vMX est en cours d'élévation dans Docker dans un conteneur (avec les moyens Vrnetlab) et fonctionne comme un routeur virtuel classique.
• ODL connecté au routeur et permet de le gérer.
• Postman exécuté sur une machine séparée et par son intermédiaire nous envoyons des commandes ODL: pour connecter/déconnecter le routeur, modifier la configuration, etc.

Commentaire sur l’appareil du système

Juniper vMX et ODL nécessitent pas mal de ressources pour un fonctionnement stable. Un seul vMX demande 6 Go de mémoire vive et 4 cœurs. Par conséquent, il a été décidé d'externaliser tous les "lourds" sur une machine séparée (Heulett Packard Enterprise MicroServer ProLiant Gen8, Ubuntu 20.04 LTS). Le routeur, bien sûr, ne "vole" pas dessus, mais pour de petites expériences, la performance est suffisante.

Partie 3 : configurons OpenDaylight

La version actuelle de l'ODL à l'heure de la rédaction de cet article est - Magnesium SR1

1) Installons Java OpenJDK 11 (pour une installation plus détaillée ici)

ubuntu:~$ sudo apt install default-jdk

2) Trouvons et téléchargeons la dernière version ODL d'ici
3) Décompressons l'archive téléchargée
4) Allons dans le répertoire obtenu
5) Lançons .\/bin\/karaf

À ce stade ODL devrait se lancer et nous serons dans la console (Pour un accès externe, le port 8181 est utilisé, que nous utiliserons plus tard).

Ensuite, installons les fonctionnalités ODL, destinées à travailler avec les protocoles NETCONF et RESTCONF. Pour cela, dans la console ODL nous exécutons :

opendaylight-user@root> feature:install odl-netconf-topology odl-restconf-all

À ce stade, la configuration la plus simple ODL est terminée. (Plus de détails peuvent être lus ici).

Partie 4 : configurons Vrnetlab

Préparation du système

Avant l'installation Vrnetlab il est nécessaire d'installer les paquets requis pour son fonctionnement. Tels que Docker, git, sshpass:

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 -
ubunt...    stable"
ubuntu:~$ sudo apt update
ubuntu:~$ sudo apt install -y docker-ce docker-ce-cli containerd.io

Installation de Vrnetlab

Pour l'installation Vrnetlab clonons le dépôt correspondant depuis github :

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

Allons dans le répertoire vrnetlab:

ubuntu:~$ cd ~\/vrnetlab

Ici, vous pouvez voir tous les scripts nécessaires au lancement. Remarquez qu'un répertoire correspondant a été créé pour chaque type de routeur :

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

Créons l'image du routeur

Chaque routeur supporté Vrnetlab, a sa propre procédure de configuration. Dans ce cas, Juniper vMX il nous suffit de placer l'archive .tgz contenant le routeur (vous pouvez la télécharger depuis le site officiel) dans le répertoire vmx et d'exécuter la commande make:

ubuntu:~$ cd ~\/vrnetlab\/vmx
ubuntu:~$ # Copiez l'archive .tgz du routeur dans ce répertoire
ubuntu:~$ sudo make

Construction de l'image vMX cela prendra environ 10-20 minutes. C'est le moment d'aller préparer un café!

Pourquoi cela prend-il si longtemps, demandez-vous?

Traduction la réponse de l'auteur à cette question :

"C'est lié au fait qu'au premier démarrage, le VCP (Control Plane) lit le fichier de configuration qui détermine s'il fonctionnera en tant que VRR VCP dans vMX. Auparavant, ce démarrage se faisait lors du lancement de Docker, mais cela signifiait que le VCP redémarrait toujours une fois avant que le routeur virtuel ne soit disponible, ce qui entraînait un long temps de chargement (environ 5 minutes). Maintenant, le premier démarrage du VCP se fait lors de la construction de l'image Docker, et puisque la construction Docker ne peut pas être exécutée avec l'option --privileged, cela signifie que qemu fonctionne sans l'accélération matérielle KVM et, par conséquent, la construction prend beaucoup de temps. Pendant ce processus, de nombreux journaux sont affichés, donc au moins vous pourrez voir ce qui se passe. Je pense que la longue construction n'est pas si terrible, car nous créons l'image une seule fois, mais la démarrons plusieurs fois."

Après, nous pourrons voir l'image de notre routeur dans Docker:

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

Lançons le conteneur vr-vmx

Nous lançons avec la commande :

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

Ensuite, nous pouvons voir les informations sur les conteneurs actifs :

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

Connectons-nous au routeur

L'adresse IP de l'interface réseau du routeur peut être obtenue avec la commande suivante :

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

Par défaut, Vrnetlab crée un utilisateur de routeur vrnetlab/VR-netlab9.
Connectons-nous avec ssh:

ubuntu:~$ ssh vrnetlab@172.17.0.2
L'authenticité de l'hôte '172.17.0.2 (172.17.0.2)' ne peut pas être établie.
L'empreinte de clé ECDSA est SHA256:g9Sfg/k5qGBTOX96WiCWyoJJO9FxjzXYspRoDPv+C0Y.
Êtes-vous sûr de vouloir continuer à vous connecter (oui/non/[empreinte])? oui
Avertissement : Ajout permanent de '172.17.0.2' (ECDSA) à la liste des hôtes connus.
Mot de passe:
--- JUNOS 20.1R1.11 Noyau 64 bits  JNPR-11.0-20200219.fb120e7_buil
vrnetlab> show version
Modèle: vmx
Junos: 20.1R1.11

Ceci termine la configuration du routeur.

Des recommandations d'installation pour les routeurs de divers fournisseurs sont disponibles sur le projet github dans les répertoires correspondants.

Partie 5 : Postman — connexion du routeur à OpenDaylight

Installation de Postman

Pour l'installation, il suffit de télécharger l'application d'ici.

Connexion du routeur à ODL

Créons PUT requête :

1. Chaine de requête :

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

2. Corps de la requête (onglet Body) :

   <node xmlns="urn:TBD:params:xml:ns:yang:network-topology">
   <node-id>jun01</node-id>
   <host xmlns="urn:opendaylight:netconf-node-topology">172.17.0.2</host>
   <port xmlns="urn:opendaylight:netconf-node-topology">22</port>
   <username xmlns="urn:opendaylight:netconf-node-topology">vrnetlab</username>
   <password xmlns="urn:opendaylight:netconf-node-topology">VR-netlab9</password>
   <tcp-only xmlns="urn:opendaylight:netconf-node-topology">false</tcp-only>
   <schema-cache-directory xmlns="urn:opendaylight:netconf-node-topology">jun01_cache</schema-cache-directory>
   </node>

3. Dans l'onglet Autorisation, il faut paramétrer Basic Auth et le nom d'utilisateur/mot de passe : admin/admin. Cela est nécessaire pour accéder à ODL :
   
4. Dans l'onglet En-têtes, il faut ajouter deux en-têtes :
   • Accept application/xml
   • Content-Type application/xml

Notre requête est formée. Nous l'envoyons. Si tout était correctement configuré, nous devrions recevoir le statut "201 Created" :

Que fait cette requête ?

Nous créons un node à l'intérieur ODL avec les paramètres de l'équipement routeur réel auquel nous voulons accéder.

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

Ce sont des espaces de noms internes colonnes (espace de nom XML) selon lesquels il crée le node. ODL Ensuite, le nom du routeur est

node-id , l'adresse du routeur estetc. host La ligne la plus intéressante — la dernière.

Schema-cache-directory crée un répertoire où tous les fichiers YANG Schema de l'équipement routeur connecté sont extraits. Ils peuvent être trouvés dans $ODL_ROOT/cache/jun01_cache Vérifions la connexion du routeur.

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

Créons GET requête :

1. Chaine de requête :

   et le nom d'utilisateur/mot de passe : admin/admin.

2. Dans l'onglet Autorisation, il faut paramétrer Basic Auth Nous l'envoyons. Nous devrions recevoir le statut "200 OK" et la liste de tous les appareils pris en charge.

Envoyons. Nous devrions obtenir le statut "200 OK" et la liste de tous les dispositifs pris en charge. de l'équipement routeur connecté sont extraits. Ils peuvent être trouvés dans:

Commentaire: Pour voir la dernière, dans mon cas, il a fallu attendre environ 10 minutes après l'exécution PUT, pendant que tout le schéma YANG se chargeait sur ODL. Avant cela, lors de l'exécution de cette GET demande, le message suivant sera affiché :

Suppression du routeur

Créons SUPPRIMER requête :

1. Chaine de requête :

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

2. Dans l'onglet Autorisation, il faut paramétrer Basic Auth Nous l'envoyons. Nous devrions recevoir le statut "200 OK" et la liste de tous les appareils pris en charge.

Partie 6 : Modifier la configuration du routeur

Obtenons la configuration

Créons GET requête :

1. Chaine de requête :

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

2. Dans l'onglet Autorisation, il faut paramétrer Basic Auth Nous l'envoyons. Nous devrions recevoir le statut "200 OK" et la liste de tous les appareils pris en charge.

Envoyons. Nous devons obtenir le statut "200 OK" et la configuration du routeur :

Créons une configuration

À titre d'exemple, créons la configuration suivante et modifions-la :

protocols {
    bgp {
        disable;
        shutdown;
    }
}

Créons POST requête :

1. Chaine de requête :

   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

2. Corps de la requête (onglet Body) :

3. Dans l'onglet Autorisation, il faut paramétrer Basic Auth Nous l'envoyons. Nous devrions recevoir le statut "200 OK" et la liste de tous les appareils pris en charge.
4. Dans l'onglet En-têtes, il faut ajouter deux en-têtes :
   • Accept application/xml
   • Content-Type application/xml

Après l'envoi, nous devons obtenir le statut "204 No Content"

Pour vérifier que la configuration a été modifiée, on peut utiliser la demande précédente. Mais à titre d'exemple, nous en créerons une autre qui nous affichera uniquement les protocoles configurés sur le routeur.

Créons GET requête :

1. Chaine de requête :

   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

2. Dans l'onglet Autorisation, il faut paramétrer Basic Auth Nous l'envoyons. Nous devrions recevoir le statut "200 OK" et la liste de tous les appareils pris en charge.

Après l'exécution de la demande, nous verrons ceci :

Modifier la configuration

Modifions les informations sur le protocole BGP. Après nos actions, cela apparaîtra comme suit :

protocols {
    bgp {
        disable;
    }
}

Créons PUT requête :

1. Chaine de requête :

   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

2. Corps de la requête (onglet Body) :

3. Dans l'onglet Autorisation, il faut paramétrer Basic Auth Nous l'envoyons. Nous devrions recevoir le statut "200 OK" et la liste de tous les appareils pris en charge.
4. Dans l'onglet En-têtes, il faut ajouter deux en-têtes :
   • Accept application/xml
   • Content-Type application/xml

En utilisant la demande précédente, nous voyons les modifications : GET Supprimer la configuration

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

Créons SUPPRIMER requête :

1. Chaine de requête :

   Pour la demande avec des informations sur les protocoles, nous verrons ceci :

2. Dans l'onglet Autorisation, il faut paramétrer Basic Auth Nous l'envoyons. Nous devrions recevoir le statut "200 OK" et la liste de tous les appareils pris en charge.

Lors de l'appel GET Pour modifier la configuration, il n'est pas nécessaire d'envoyer le corps de la demande au format

La vulnérabilité a été confirmée dans de nombreuses images officielles Docker, y compris les images couchbase, elasticsearch, flink, solr, storm, etc.

. On peut le faire au format colonnesPour cela, par exemple, dans la demande JSON.

pour modifier la configuration, nous remplacerons le corps de la demande par : PUT { "junos-conf-protocols:protocols": { "bgp": { "description" : "Changé dans Postman" } } }

N'oubliez pas de changer les en-têtes sur l'onglet Headers à :

Accept application/json

• Content-Type application/json
• Après l'envoi, nous obtiendrons le résultat suivant (Voir la réponse en utilisant

Après l'envoi, nous obtiendrons le résultat suivant (Regardons la réponse en utilisant GET requête):

Partie 7 : ajout de Cisco xRV9000

Que savons-nous tous de Juniper, oui de Juniper ? Parlons de Cisco !
J'ai trouvé une version xRV9000 7.0.2 (une bête qui nécessite 8 Go de RAM et 4 cœurs. Elle n'est pas disponible librement, donc contactez Cisco) — nous allons l'exécuter.

Lancer un conteneur

Le processus de création d'un conteneur Docker n'est pratiquement pas différent de Juniper. De la même manière, nous plaçons le fichier .qcow2 avec le routeur dans le répertoire correspondant à son nom, (dans ce cas xrv9k) et exécutons la commande make docker-image.

Après quelques minutes, nous voyons que l'image a été créée :

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

Nous lançons le conteneur :

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

Après un certain temps, nous vérifions que le conteneur a démarré :

ubuntu:~$ sudo docker ps
CONTAINER ID        IMAGE               COMMAND             CREATED             STATUS                 PORTS                                                      NAMES
058c5ecddae3        54debc7973fc        "\/launch.py"        4 hours ago         Up 4 hours (healthy)   22\/tcp, 830\/tcp, 5000-5003\/tcp, 10000-10099\/tcp, 161\/udp   xrv01

Nous nous connectons via ssh :

ubuntu@ubuntu:~$ ssh vrnetlab@172.17.0.2
Mot de passe :

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 par Cisco Systems, Inc.

Informations de build :
 Construit par     : ahoang
 Construit le      : Ven Mar 13 22:27:54 PDT 2020
 Hôte de build    : iox-ucs-029
 Espace de travail : \/auto\/srcarchive15\/prod\/7.0.2\/xrv9k\/ws
 Version          : 7.0.2
 Emplacement       : \/opt\/cisco\/XR\/packages\/\n Label            : 7.0.2

cisco IOS-XRv 9000 () processeur
Le temps de fonctionnement du système est de 3 heures 22 minutes

Nous connectons le routeur à OpenDaylight

L'ajout se fait de manière totalement similaire à l'image vMX. Il suffit de changer les noms.
PUT requête :

Après un certain temps, nous invoquons GET la requête pour vérifier que tout est connecté :

Modifier la configuration

Nous allons configurer la configuration suivante :

!
routeur ospf LAB
 mpls ldp auto-config
!

Créons POST requête :

1. Chaine de requête :

   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

2. Corps de la requête (onglet Body) :

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

3. Dans l'onglet Autorisation, il faut paramétrer Basic Auth Nous l'envoyons. Nous devrions recevoir le statut "200 OK" et la liste de tous les appareils pris en charge.
4. Dans l'onglet En-têtes, il faut ajouter deux en-têtes :
   • Content-Type application/json
   • Après l'envoi, nous obtiendrons le résultat suivant (Voir la réponse en utilisant

Après son exécution, nous devrions obtenir le statut "204 No Content".

Vérifions ce que nous avons obtenu.
Pour cela, nous allons créer GET requête :

1. Chaine de requête :

   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

2. Dans l'onglet Autorisation, il faut paramétrer Basic Auth Nous l'envoyons. Nous devrions recevoir le statut "200 OK" et la liste de tous les appareils pris en charge.

Après exécution, nous devrions voir ce qui suit :

Pour supprimer la configuration, nous utilisons SUPPRIMER:

1. Chaine de requête :

   SUPPRIMER 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

2. Dans l'onglet Autorisation, il faut paramétrer Basic Auth Nous l'envoyons. Nous devrions recevoir le statut "200 OK" et la liste de tous les appareils pris en charge.

Conclusion

Comme vous avez pu le constater, les procédures de connexion de Cisco et Juniper à OpenDaylight ne diffèrent pas — cela ouvre un large champ de créativité. Cela va de la gestion des configurations de tous les composants du réseau à la création de vos propres politiques réseau.
Dans ce tutoriel, j'ai fourni des exemples simples de la manière d'interagir avec des équipements réseau à l'aide d'OpenDaylight. Il ne fait aucun doute que les requêtes des exemples présentés peuvent devenir beaucoup plus complexes et permettre de configurer des services entiers d'un simple clic — tout est limité uniquement par votre imagination.

À suivre...

P.S.

Si vous connaissez déjà tout cela ou, au contraire, si vous êtes tombé sous le charme d'ODL, je vous recommande de vous intéresser au développement d'applications sur le contrôleur ODL. Vous pouvez commencer ici. d'ici.

Je vous souhaite de bons essais !

Bibliographie

1. Vrnetlab : Émuler des réseaux avec KVM et Docker / Brian Linkletter
2. OpenDaylight Cookbook / Mathieu Lemay, Alexis de Talhouet, Et al.
3. Programmabilité Réseau avec YANG / Benoît Claise, Loe Clarke, Jan Lindblad
4. Apprendre XML, Deuxième Édition / Erik T. Ray
5. DevOps Efficace / Jennifer Davis, Ryn Daniels

Source : habr.com