Révision rapide : Automatisation et programmabilité – CCNA

Ce que vous devez vraiment savoir

L'automatisation et la programmabilité sont devenues une partie importante du CCNA parce que les réseaux modernes ne sont pas gérés uniquement par configuration manuelle en CLI. De plus en plus souvent, on utilise des contrôleurs, des API, des templates, des outils d'automatisation, des formats structurés et des modèles programmables.

Pour CCNA, vous n'avez pas besoin de devenir développeur logiciel avancé, mais vous devez comprendre les concepts fondamentaux : ce que sont les API, comment fonctionne REST, pourquoi JSON et YAML sont utilisés, ce que signifie SDN, quelles sont les différences entre northbound et southbound API et pourquoi des outils comme Ansible ou Cisco DNA Center aident à gérer les réseaux.

Le point central est celui-ci : l'automatisation sert à rendre le réseau plus cohérent, scalable, rapide à gérer et moins dépendant des configurations manuelles répétitives.

Concepts clés

• Automation : utilisation d'outils ou de scripts pour exécuter des tâches répétitives sans intervention manuelle continue.
• Programmability : capacité de contrôler des dispositifs ou services via du code, des API ou des modèles structurés.
• API : interface qui permet à différents systèmes de communiquer.
• REST API : API basée sur des requêtes HTTP et des ressources.
• JSON : format de données structuré très utilisé dans les API.
• YAML : format lisible souvent utilisé dans les fichiers de configuration et d'automatisation.
• SDN : modèle qui sépare le control plane et le data plane.
• Controller-based networking : réseau géré par un contrôleur central.
• Northbound API : API entre contrôleur et applications supérieures.
• Southbound API : API ou protocole entre contrôleur et dispositifs réseau.
• Cisco DNA Center : plateforme Cisco pour gestion, automatisation et assurance.
• Ansible : outil d'automatisation basé sur des playbooks.
• NETCONF : protocole pour configurer des dispositifs réseau de manière programmable.
• RESTCONF : protocole qui expose les données de configuration via une approche REST.

Différences à ne pas confondre

Concept	Signification principale
API	Interface entre systèmes
REST	Style API basé sur HTTP
JSON	Format de données structuré
YAML	Format lisible pour configurations
SDN	Séparation contrôle/données
Contrôleur	Gestion centralisée du réseau
Northbound API	Contrôleur vers applications
Southbound API	Contrôleur vers dispositifs
Ansible	Automatisation via playbooks
NETCONF	Configuration réseau programmable
RESTCONF	Configuration via modèle REST

Pourquoi l'automatisation réseau est nécessaire

La configuration manuelle dispositif par dispositif peut fonctionner dans de petits réseaux, mais elle devient difficile lorsque le réseau grandit.

Problèmes de la gestion manuelle :

• erreurs humaines ;
• configurations incohérentes ;
• délais longs ;
• troubleshooting plus complexe ;
• difficulté à documenter les changements ;
• difficulté à répéter des procédures identiques ;
• faible scalabilité.

L'automatisation aide à :

• appliquer des configurations cohérentes ;
• réduire les erreurs ;
• accélérer les tâches répétitives ;
• standardiser les procédures ;
• mieux documenter ;
• déployer des changements sur de nombreux dispositifs ;
• intégrer réseau, sécurité et systèmes IT.

Pour CCNA, vous devez retenir que l'automatisation ne signifie pas éliminer le networking traditionnel, mais le gérer plus efficacement.

API

Une API, Application Programming Interface, est une manière standard par laquelle un logiciel peut communiquer avec un autre logiciel.

Dans le networking, une API peut permettre de :

• lire des informations depuis un dispositif ;
• envoyer des configurations ;
• consulter des statistiques ;
• créer des objets ;
• modifier des policies ;
• interroger un contrôleur ;
• intégrer le réseau avec des outils externes.

Exemple conceptuel : au lieu d'entrer sur chaque switch via CLI pour vérifier l'état des interfaces, un système peut interroger une API et collecter automatiquement les données.

REST API

REST est un style très répandu pour concevoir des API.

Les REST API utilisent normalement HTTP et des opérations comme :

• GET : lire des informations ;
• POST : créer une nouvelle ressource ;
• PUT : mettre à jour ou remplacer une ressource ;
• PATCH : modifier partiellement une ressource ;
• DELETE : supprimer une ressource.

Pour CCNA, vous devez surtout reconnaître le sens général des méthodes HTTP.

Exemple :

• GET peut être utilisé pour lire l'état d'un dispositif ;
• POST peut être utilisé pour créer un objet ;
• PUT peut être utilisé pour mettre à jour une configuration ;
• DELETE peut être utilisé pour supprimer une ressource.

Codes HTTP

Les API REST renvoient souvent des codes de statut HTTP.

Quelques codes courants :

Code	Signification
200	OK, requête réussie
201	Created, ressource créée
400	Bad Request, requête incorrecte
401	Unauthorized, authentification manquante ou incorrecte
403	Forbidden, accès non autorisé
404	Not Found, ressource non trouvée
500	Server Error, erreur côté serveur

Dans les quiz CCNA, il peut apparaître que le code 200 indique un succès, tandis que 404 indique une ressource non trouvée.

JSON

JSON, JavaScript Object Notation, est un format de données structuré très utilisé dans les API.

Il est composé de paires clé-valeur.

Exemple conceptuel :

• hostname : Router1 ;
• interface : GigabitEthernet0/1 ;
• status : up.

JSON est très utilisé parce qu'il est lisible, léger et facile à traiter par les applications et les scripts.

Pour CCNA, vous devez reconnaître que JSON utilise souvent des accolades, des paires clé-valeur et des structures imbriquées.

YAML

YAML est un format lisible souvent utilisé pour les configurations, l'automatisation et les playbooks.

Il est courant dans des outils comme Ansible.

YAML utilise l'indentation pour représenter la structure des données. Cela le rend lisible, mais exige de faire attention aux espaces.

Pour CCNA, vous devez savoir que YAML est souvent choisi pour les fichiers de configuration et d'automatisation parce qu'il est plus lisible pour les humains que d'autres formats.

JSON vs YAML

JSON et YAML peuvent représenter des données structurées, mais ils sont souvent utilisés dans des contextes légèrement différents.

Format	Usage typique
JSON	API, échange de données entre systèmes
YAML	Configurations, playbooks, automatisation

JSON est très courant dans les réponses API. YAML est très courant dans les fichiers écrits par les opérateurs ou les outils d'automatisation.

SDN

SDN signifie Software-Defined Networking.

Le concept principal est de séparer :

• control plane : décide où le trafic doit aller ;
• data plane : transmet concrètement le trafic.

Dans les réseaux traditionnels, chaque dispositif prend de nombreuses décisions localement. Dans un modèle SDN ou controller-based, un contrôleur peut avoir une vision plus centralisée du réseau et distribuer des policies ou configurations.

Pour CCNA, vous devez comprendre que SDN ne signifie pas que les routeurs et switches n'existent plus. Cela signifie que le contrôle et la gestion peuvent être plus centralisés et programmables.

Control plane et data plane

Le control plane concerne les décisions et la logique.

Exemples :

• calcul des routes ;
• informations de routage ;
• décisions de forwarding ;
• policies ;
• contrôle de la topologie.

Le data plane concerne le transfert effectif du trafic.

Exemples :

• forwarding des paquets ;
• switching des trames ;
• application pratique des décisions de forwarding.

Différence simple :

• control plane = décide ;
• data plane = transmet.

Controller-based networking

Dans un réseau controller-based, un contrôleur central gère les dispositifs, policies, configurations et informations opérationnelles.

Le contrôleur peut :

• distribuer des configurations ;
• appliquer des policies ;
• collecter des données ;
• surveiller l'état du réseau ;
• automatiser des activités ;
• fournir des API ;
• simplifier le provisioning et le troubleshooting.

Un contrôleur n'élimine pas la nécessité de connaître routing, switching, sécurité et wireless. Il les coordonne de manière plus centralisée.

Northbound API et southbound API

Ces deux concepts sont très importants.

Les northbound API sont les API entre le contrôleur et les applications supérieures, dashboards, orchestrateurs ou outils externes.

Les southbound API ou protocoles relient le contrôleur aux dispositifs réseau.

Différence simple :

• northbound = vers les applications et systèmes de gestion ;
• southbound = vers les routeurs, switches, access points et dispositifs.

Exemple :

• un dashboard utilise une northbound API pour demander des données au contrôleur ;
• le contrôleur utilise une southbound API ou un protocole pour configurer un dispositif.

Cisco DNA Center

Cisco DNA Center est une plateforme Cisco pour la gestion et l'automatisation du réseau.

Elle peut être utilisée pour :

• gestion centralisée ;
• inventaire des dispositifs ;
• automatisation des configurations ;
• policies ;
• assurance ;
• surveillance ;
• troubleshooting ;
• intégration via API.

Dans le contexte CCNA, il n'est pas nécessaire de connaître chaque fonction avancée, mais vous devez reconnaître Cisco DNA Center comme plateforme controller-based pour la gestion et l'automatisation réseau.

Ansible

Ansible est un outil d'automatisation très utilisé pour la configuration et la gestion.

Caractéristiques importantes :

• utilise des playbooks ;
• les playbooks sont souvent écrits en YAML ;
• peut automatiser des tâches répétitives ;
• peut configurer de nombreux dispositifs de manière cohérente ;
• utilise des modules ;
• est agentless dans de nombreux scénarios, c'est-à-dire qu'il ne nécessite pas d'agent installé sur le dispositif géré.

Exemple conceptuel : au lieu de configurer manuellement dix switches, un playbook Ansible peut appliquer une configuration standard à tous.

Playbook

Un playbook est un fichier qui décrit les tâches à exécuter.

Il peut inclure :

• dispositifs cibles ;
• variables ;
• tâches ;
• modules à utiliser ;
• configurations à appliquer ;
• vérifications.

Les playbooks aident à rendre les opérations répétables et documentées.

Pour CCNA, vous devez relier Ansible à YAML et au concept d'automatisation déclarative ou procédurale via des tâches.

NETCONF

NETCONF est un protocole utilisé pour installer, modifier, supprimer et lire les configurations des dispositifs réseau.

Il utilise souvent des modèles de données structurés comme YANG.

Concepts importants :

• gestion programmable ;
• configurations structurées ;
• lecture et modification de l'état ;
• approche plus contrôlée que le screen scraping de la CLI.

Pour CCNA, vous devez reconnaître NETCONF comme protocole de configuration et de gestion programmable des dispositifs.

RESTCONF

RESTCONF fournit une manière d'accéder aux données de configuration et d'état avec une approche similaire à REST.

Il utilise HTTP et peut représenter les données dans des formats comme JSON ou XML.

Différence simple :

• NETCONF est un protocole spécifique pour la gestion des configurations ;
• RESTCONF expose les données de configuration avec des principes REST.

Pour CCNA, vous devez savoir que RESTCONF est lié à la programmabilité, aux API et aux modèles de données.

YANG

YANG est un langage de modélisation des données utilisé pour décrire la configuration et l'état des dispositifs réseau.

YANG définit la structure des données que des protocoles comme NETCONF et RESTCONF peuvent utiliser.

Pour CCNA, il n'est pas nécessaire d'écrire des modèles YANG complexes, mais vous devez savoir que YANG décrit les données réseau de manière structurée.

Intent-based networking

L'intent-based networking signifie exprimer ce que l'on veut obtenir, en laissant au système la tâche de traduire cette intention en configurations et policies.

Exemple :

• intention : le département guest doit accéder uniquement à Internet ;
• système : applique les VLAN, ACL, policies et configurations nécessaires.

Le concept est important parce que de nombreuses plateformes modernes cherchent à déplacer la gestion depuis la configuration manuelle individuelle vers l'objectif souhaité.

Avantages de l'automatisation

Les principaux avantages sont :

• réduction des erreurs manuelles ;
• plus grande vitesse ;
• configurations cohérentes ;
• scalabilité ;
• documentation implicite via fichiers et templates ;
• répétabilité ;
• intégration avec d'autres systèmes ;
• provisioning plus rapide ;
• troubleshooting plus efficace.

Dans un grand réseau, automatiser une modification réduit le risque d'avoir des dispositifs configurés différemment à cause d'une erreur humaine.

Risques de l'automatisation

L'automatisation n'est pas sans risques.

Risques courants :

• propager rapidement une erreur sur de nombreux dispositifs ;
• utiliser des templates incorrects ;
• ne pas tester les modifications ;
• mal gérer les identifiants ou tokens API ;
• absence de contrôle de version ;
• permissions excessives pour les outils d'automatisation ;
• documentation insuffisante ;
• absence de rollback.

C'est pourquoi automatisation et change management doivent fonctionner ensemble.

Version control

Le version control permet de tracer les modifications apportées aux fichiers, scripts, templates et configurations.

Avantages :

• savoir qui a modifié quoi ;
• revenir à des versions précédentes ;
• mieux collaborer ;
• documenter les changements ;
• réduire les erreurs ;
• soutenir les audits et le troubleshooting.

Git est un exemple courant de système de contrôle de version.

Dans le contexte CCNA, vous devez comprendre la valeur du version control même si vous n'avez pas besoin de devenir expert Git.

Troubleshooting automatisation et API

Lorsqu'une automatisation ne fonctionne pas, vous devez contrôler :

• identifiants ;
• tokens API ;
• permissions ;
• endpoint correct ;
• méthode HTTP correcte ;
• payload correct ;
• format JSON ou YAML valide ;
• connectivité vers contrôleur ou dispositif ;
• réponse HTTP ;
• logs de l'outil ;
• compatibilité du dispositif.

Exemple : si une API renvoie 401, le problème est probablement l'authentification. Si elle renvoie 404, la ressource ou endpoint peut ne pas exister.

Erreurs fréquentes dans les quiz

• Penser que l'automatisation remplace complètement les administrateurs réseau.
• Confondre JSON et YAML.
• Penser que YAML est utilisé uniquement pour les API.
• Confondre northbound et southbound API.
• Penser que SDN élimine les routeurs et switches.
• Confondre control plane et data plane.
• Penser que REST est un protocole de routage.
• Penser que GET modifie les configurations.
• Oublier que POST, PUT, PATCH et DELETE peuvent modifier des ressources.
• Confondre Ansible avec un protocole de routage.
• Penser que l'automatisation élimine la nécessité de test et de change management.
• Oublier qu'une erreur automatisée peut se propager très rapidement.

Mini scénario d'examen

Une équipe veut appliquer la même configuration de base à vingt switches. Le faire manuellement prend du temps et peut générer des erreurs différentes sur chaque dispositif. La solution la plus adaptée est d'utiliser un outil d'automatisation, comme Ansible, avec un playbook et des templates contrôlés.

Autre scénario : un dashboard doit lire des informations depuis un contrôleur réseau. La communication entre le dashboard et le contrôleur se fait via une northbound API.

Mini checklist avant le quiz

Avant de commencer le quiz, vous devriez savoir expliquer :

• ce que signifie automatisation réseau ;
• ce que signifie programmability ;
• ce que fait une API ;
• ce qui caractérise une REST API ;
• la différence entre GET, POST, PUT et DELETE ;
• ce qu'indiquent les codes HTTP comme 200, 401 et 404 ;
• ce que sont JSON et YAML ;
• la différence entre JSON et YAML ;
• ce que signifie SDN ;
• la différence entre control plane et data plane ;
• ce que sont northbound et southbound API ;
• à quoi sert Cisco DNA Center ;
• à quoi sert Ansible ;
• ce que sont NETCONF, RESTCONF et YANG ;
• pourquoi automatisation et change management doivent être liés.