← Tous les projets

Automatisation réseau : de l’intention aux équipements

CPE Lyon, cours WAN DevNet, 2026 En cours

Un réseau Cisco de 3 sites décrit comme des données (YAML, puis NetBox), validé en Python, rendu avec Jinja2 et déployé avec Netmiko, NAPALM et Nornir.

L’intention, c’est décrire ce que le réseau doit être sous forme de données. Le code la vérifie, la transforme en configurations Cisco et les déploie sur les équipements.

Les sujets, la maquette et les squelettes de code sont fournis par l’enseignant ; j’écris les données, les fonctions et les templates. Le code noté n’est pas publié.

En un coup d’œil

  • 3 sitesLyon, Marseille, Paris
  • 10 équipementsdans l’inventaire Nornir
  • 9 testspytest, tous réussis
  • ~12 sOSPF déployé sur 5 routeurs en parallèle

Le réseau

Réseau du projet d’automatisationDeux routeurs de cœur, CORE-1 et CORE-2, fournis par l’enseignant, font de l’OSPF area 0 avec trois sites. Lyon et Marseille ont chacun deux routeurs avec VRRP et un switch. Paris a un routeur et un switch. Chaque site utilise les VLANs 10 et 20 sur des trunks 802.1Q et un VLAN d’administration 99.CORE-1CORE-2fournis par l’enseignantOSPF area 0Lyon, siègeR1-LYONR2-LYONSwitchVLAN 10/20802.1QVRRPVLAN admin 99MarseilleR1-MARSR2-MARSSwitchVLAN 10/20802.1QVRRPVLAN admin 99Paris, agenceR1-PARSSwitchVLAN 10/20802.1QVLAN admin 99Réseau du projet d’automatisationDeux routeurs de cœur, CORE-1 et CORE-2, fournis par l’enseignant, font de l’OSPF area 0 avec trois sites. Lyon et Marseille ont chacun deux routeurs avec VRRP et un switch. Paris a un routeur et un switch. Chaque site utilise les VLANs 10 et 20 sur des trunks 802.1Q et un VLAN d’administration 99.CORE-1CORE-2fournis par l’enseignantOSPF area 0Lyon, siègeR1-LYONR2-LYONSwitchVLAN 10/20802.1QVRRPVLAN admin 99MarseilleR1-MARSR2-MARSSwitchVLAN 10/20802.1QVRRPVLAN admin 99Paris, agenceR1-PARSSwitchVLAN 10/20802.1QVLAN admin 99

Émulé dans GNS3, travail individuel. VRRP sur deux routeurs à Lyon et à Marseille, un seul routeur à Paris.

La chaîne

  1. 1IntentYAML, puis NetBox
  2. 2Validateyamllint, check_site, pytest
  3. 3RenderJinja2, 8 configs
  4. 4DeployNetmiko, NAPALM, Nornir
  5. 5ÉquipementsGNS3

Le projet suit le cadre du Network Automation Forum (NAF) : intention, exécuteur, puis observabilité.

Avancement

  1. TP-01 Décrire le réseau

    Lyon configuré à la main, les 3 sites décrits en YAML.

  2. TP-02 Valider et générer

    check_site() avec 4 contrôles, templates Jinja2, 8 configs.

  3. TP-03 Netmiko et NAPALMPartiel

    Déploiement par script, diff en dry-run, puis commit. Test de rollback NAPALM non vérifié.

  4. TP-04 Passer à l’échelle avec NornirPartiel

    Inventaire de 10 équipements, OSPF sur 5 routeurs en 12 s environ. Test de bascule OSPF non vérifié.

  5. TP-05 NetBox, source de vérité

    Mêmes données, mêmes configs, déploiement depuis NetBox.

  6. TP-06 Dérive, orchestration, CIÀ venir

    Sujet pas encore publié.

  7. TP-07 Épreuve finaleÀ venir

    Toute la chaîne. Pas commencé.

Un changement fait dans NetBox, pas dans un fichier

  1. 1Priorité VRRP de R2-LYON passée à 120 dans l’interface de NetBox
  2. 2Dry-run : le diff montre le changement
  3. 3Déploiement sur les équipements
  4. 4R2-LYON devient Master

Le YAML et NetBox donnent le même dictionnaire et des configs identiques (diff -r) : seule la source de vérité change, pas les templates.

Extraits

Intention : un routeur dans data/pars.yaml
  - hostname: R1-PARS
    platform: ios
    model: c7200
    loopback: 10.255.0.31/32
    lan_interface: GigabitEthernet0/0
    wan:
      - interface: Serial1/0
        ip: 10.0.0.22/30
        peer: CORE-1
      - interface: Serial1/1
        ip: 10.0.0.26/30
        peer: CORE-2
    ips:
      10: 172.16.50.254/24
      20: 172.16.60.254/24
Généré : config/R1-PARS.cfg (extrait, un seul routeur donc aucune ligne VRRP)
hostname R1-PARS
!
interface GigabitEthernet0/0.10
 encapsulation dot1Q 10
 ip address 172.16.50.254 255.255.255.0
 no shutdown
!
interface GigabitEthernet0/0.20
 encapsulation dot1Q 20
 ip address 172.16.60.254 255.255.255.0
 no shutdown
!

Problèmes rencontrés

ProblèmeDiagnosticCorrection
Équipements injoignables après un redémarrage : les switchs émulés perdaient tous leurs VLANs, y compris le VLAN d’administration 99.Le fichier vlan.dat n’est jamais écrit dans la flash. Côté R2, une route dépendait d’une sonde IP SLA qui tombait avec le VLAN. Trouvé avec un ping depuis la VM, show ip interface brief, show interfaces trunk et show track.VLANs recréés à la main (administration de base, hors de la config générée), puis Nornir relancé seulement sur les hôtes en échec. Persistance des VLANs non résolue.
Un diff NAPALM jamais vide.Sur IOS, le mode merge compare du texte : vrrp preempt, no shutdown et priority 100 sont des valeurs par défaut absentes de la running-config, donc elles réapparaissent à chaque diff.Accepté : la configuration est idempotente dans son effet, pas dans le diff texte. Des templates qui n’écrivent pas les valeurs par défaut d’IOS sont à faire.
Une modification NetBox qui semblait invisible.Le dry-run ne montrait pas le changement attendu. Une lecture de l’API et du Changelog a montré qu’il n’avait jamais été enregistré.Modification refaite, puis vérifiée par l’API.

En cours / à venir

  • TP-06 : détecter les écarts entre l’intention et le réseau, orchestrer, et un pipeline CI GitHub Actions. Le sujet n’est pas encore publié.
  • TP-07 : l’épreuve finale, toute la chaîne. Pas commencé.
  • Pas vérifiés jusqu’au bout : le test de rollback NAPALM (TP-03, erreur volontaire sur la VIP VRRP) et le test de bascule OSPF quand le lien R1-LYON vers CORE-1 est coupé (TP-04).
  • À améliorer : la persistance des VLANs sur les switchs émulés, et des templates qui n’écrivent pas les valeurs par défaut d’IOS, pour obtenir un diff NAPALM vide.
Tous les détails

Contexte et principe

  • Cours WAN DevNet, CPE Lyon, 4IRC (2026). Travail individuel sur une maquette émulée dans GNS3. L’enseignant fournit les sujets, la maquette et des squelettes de code ; j’écris les fonctions demandées, les données et les templates, puis je les applique sur le réseau.
  • Le réseau est décrit sous forme de données, d’abord en YAML puis dans NetBox. Ces données sont validées en Python, puis transformées en configurations Cisco IOS par des templates Jinja2. Ces configurations sont déployées automatiquement avec Netmiko, NAPALM et Nornir. Le projet suit le cadre du Network Automation Forum : intention, exécuteur, puis observabilité.
  • Cette page décrit le travail. Elle ne contient pas le code des TP, qui sont notés.

Le réseau

  • 3 sites : CPE-LYON (siège), CPE-MARS (Marseille) et CPE-PARS (Paris, agence), reliés à un cœur de deux routeurs (CORE-1, CORE-2) fourni par l’enseignant.
  • Équipements : 5 routeurs de site (Cisco c7200), 3 switchs (c3725 avec module EtherSwitch) et des PC.
  • Protocoles : VLANs 10 et 20, trunks 802.1Q, routage inter-VLAN par sous-interfaces, VRRP (deux routeurs à Lyon et à Marseille), OSPF area 0 vers le cœur, et un réseau d’administration séparé (VLAN 99).

Outils

  • Python 3.12, PyYAML, Jinja2, yamllint, pytest, Netmiko, NAPALM, Nornir (nornir-netmiko, nornir-napalm, nornir-netbox), NetBox (Docker), pynetbox, requests, GNS3, Git et GitHub (deux remotes : upstream pour l’enseignant, origin pour mon dépôt privé).

TP-01 à TP-03

  • TP-01 : configuration manuelle du site de Lyon (VLAN, trunk, sous-interfaces dot1Q, VRRP), les 3 sites décrits en YAML, et load_yaml() et summarize() écrits par moi.
  • TP-02 : check_site() avec 4 contrôles (ids de VLAN uniques, passerelle dans son réseau, IP des routeurs dans le bon réseau, priorités VRRP différentes s’il y a deux routeurs), templates site_switch.j2 et site_router.j2 (VRRP seulement si le site a deux routeurs), fonctions de rendu produisant 8 fichiers de configuration. Les 6 tests de validation et les 3 tests de rendu passent. Configs de Marseille appliquées dans GNS3 : R1-MARS est Master VRRP, R2-MARS est Backup.
  • TP-03 : Netmiko (connect, show, deploy_file, backup) avec Paris déployé par script et sauvegardes de la configuration avant et après ; NAPALM (open_device, preview avec compare_config, apply avec diff, confirmation, puis commit ou abandon). Une description de VLAN ajoutée dans le YAML, puis dans le template, appliquée sur R1-MARS et R2-MARS après lecture du diff ; au 2ᵉ passage, elle n’apparaît plus dans le diff.

TP-04 et TP-05

  • TP-04 : inventaire Nornir de 10 équipements avec groupes par rôle et par site, identifiants lus dans un fichier .env ignoré par Git ; init_nornir(), site_routers() (5 routeurs, jamais le cœur), render_ospf() et deploy_ospf() avec un template ospf.j2. OSPF déployé en parallèle sur les 5 routeurs en 12 s environ ; R1-PARS a ses deux voisins (CORE-1 et CORE-2) en FULL.
  • TP-05 : NetBox avec Docker ; API REST avec curl puis requests, codes HTTP testés sans jeton ou avec un jeton invalide ; get_api() et get_or_create() importent les 3 sites de façon idempotente ; list_sites() et _vlans() relisent NetBox et donnent exactement le même dictionnaire que les YAML (--compare OK), et les configs générées sont identiques (diff -r) ; site_devices() et deploy_site() ont déployé le changement de priorité VRRP de R2-LYON fait dans NetBox.
M’écrireLinkedIn

Basé à Lyon, France

Dernière mise à jour

Télécharger le CV (en anglais)Contact