{"id":20140600,"url":"https://github.com/goffinet/ansible-ccna-lab","last_synced_at":"2025-06-16T06:03:52.245Z","repository":{"id":40479520,"uuid":"150723986","full_name":"goffinet/ansible-ccna-lab","owner":"goffinet","description":"CCNA Labs ported on Ansible - for education purpose only - IOSv and IOSvL2 support only","archived":false,"fork":false,"pushed_at":"2024-10-25T17:48:33.000Z","size":2916,"stargazers_count":30,"open_issues_count":1,"forks_count":11,"subscribers_count":3,"default_branch":"master","last_synced_at":"2025-04-09T18:55:04.754Z","etag":null,"topics":["ansible","ccna","ccnp","cisco","gns3","gns3-server","ios","iosv","iosvl2","roles-ansible"],"latest_commit_sha":null,"homepage":"","language":"Python","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"mit","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/goffinet.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":"LICENSE","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null}},"created_at":"2018-09-28T10:25:55.000Z","updated_at":"2025-03-30T19:35:28.000Z","dependencies_parsed_at":"2024-03-02T14:07:01.725Z","dependency_job_id":null,"html_url":"https://github.com/goffinet/ansible-ccna-lab","commit_stats":null,"previous_names":[],"tags_count":2,"template":false,"template_full_name":null,"purl":"pkg:github/goffinet/ansible-ccna-lab","repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/goffinet%2Fansible-ccna-lab","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/goffinet%2Fansible-ccna-lab/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/goffinet%2Fansible-ccna-lab/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/goffinet%2Fansible-ccna-lab/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/goffinet","download_url":"https://codeload.github.com/goffinet/ansible-ccna-lab/tar.gz/refs/heads/master","sbom_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/goffinet%2Fansible-ccna-lab/sbom","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":260109458,"owners_count":22960025,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["ansible","ccna","ccnp","cisco","gns3","gns3-server","ios","iosv","iosvl2","roles-ansible"],"created_at":"2024-11-13T21:52:45.759Z","updated_at":"2025-06-16T06:03:52.216Z","avatar_url":"https://github.com/goffinet.png","language":"Python","funding_links":[],"categories":[],"sub_categories":[],"readme":"# Ansible CCNA Labs\n\n- [Ansible CCNA Labs](#ansible-ccna-labs)\n\t- [1. Description du projet](#1-description-du-projet)\n\t- [2. La gestion du réseau avec Ansible](#2-la-gestion-du-rseau-avec-ansible)\n\t- [3. La mise en place du lab sur GNS3](#3-la-mise-en-place-du-lab-sur-gns3)\n\t\t- [3.1. Setup du lab GNS3 avec Ansible](#31-setup-du-lab-gns3-avec-ansible)\n\t\t- [3.2. Configuration de la station de contrôle](#32-configuration-de-la-station-de-contrle)\n\t\t- [3.3. Préparation des images Cisco IOSv pour GNS3](#33-prparation-des-images-cisco-iosv-pour-gns3)\n\t\t\t- [3.3.1. Les Routeurs IOSv](#331-les-routeurs-iosv)\n\t\t\t- [3.3.2. Commutateurs IOSv](#332-commutateurs-iosv)\n\t\t- [3.4. Récupérer le dépôt des livres de jeu Ansible](#34-rcuprer-le-dpt-des-livres-de-jeu-ansible)\n\t\t- [3.5. Prise de connaissance des paramètres de configuration de Ansible](#35-prise-de-connaissance-des-paramtres-de-configuration-de-ansible)\n\t- [4. Les topologies CCNA](#4-les-topologies-ccna)\n\t\t- [4.1. Topologie CCNA Gateway](#41-topologie-ccna-gateway)\n\t\t- [4.2. Topologie CCNA Bipod](#42-topologie-ccna-bipod)\n\t\t- [4.3. Topologie CCNA Tripod](#43-topologie-ccna-tripod)\n\t\t\t- [4.3.1. Topologie logique](#431-topologie-logique)\n\t\t\t- [4.3.2. Brève description](#432-brve-description)\n\t\t- [4.4. Topologie variante Router on a Stick](#44-topologie-variante-router-on-a-stick)\n\t\t- [4.5. Topologie CCNA Switchblock](#45-topologie-ccna-switchblock)\n\t\t\t- [4.5.1. Topologie avec redondance de passerelle HSRP](#451-topologie-avec-redondance-de-passerelle-hsrp)\n\t\t\t- [4.5.2. VLANs](#452-vlans)\n\t\t\t- [4.5.3. Ports Etherchannel et Trunk VLANs](#453-ports-etherchannel-et-trunk-vlans)\n\t\t\t- [4.5.4. Spanning-Tree](#454-spanning-tree)\n\t\t\t- [4.5.5. Plan d'adressage](#455-plan-dadressage)\n\t\t\t- [4.5.6. HSRP](#456-hsrp)\n\t\t\t- [4.5.7. Ressources requises](#457-ressources-requises)\n\t\t\t- [4.5.8. Explication](#458-explication)\n\t\t- [4.6. Toplogie CCNA Tripod et Switchblock](#46-toplogie-ccna-tripod-et-switchblock)\n\t\t- [4.7. Topologie Ansible Networking Workshop](#47-topologie-ansible-networking_workshop)\n\t- [5. L'utilisation des livres de jeu](#5-lutilisation-des-livres-de-jeu)\n\t\t- [5.1. Inventaire et variables d'inventaire du livre de jeu ccna.yml](#51-inventaire-et-variables-dinventaire-du-livre-de-jeu-ccnayml)\n\t\t- [5.2. Livres de jeu](#52-livres-de-jeu)\n\t\t- [5.3. Les rôles invoqués](#53-les-rles-invoqus)\n\t\t- [5.4. Diagnostic de base](#54-diagnostic-de-base)\n\t\t- [5.5. Remettre à zéro les configurations](#55-remettre-zro-les-configurations)\n\t- [6. Notes](#6-notes)\n\t\t- [6.1. Comment rendre une tâche ios_config idempotente ?](#61-comment-rendre-une-tche-iosconfig-idempotente-)\n\t\t- [6.2. Phase I : roles ios_config](#62-phase-i-roles-iosconfig)\n\t\t\t- [6.2.1. Objectifs](#621-objectifs)\n\t\t\t- [6.2.2. Rôles à améliorer](#622-rles-amliorer)\n\t\t\t- [6.2.3. Rôles à créer](#623-rles-crer)\n\t\t- [6.3. Phase II : immutabilité](#63-phase-ii-immutabilit)\n\t\t- [6.4. Phase III : Reporting et documentation](#64-phase-iii-reporting-et-documentation)\n\n![Ansible Lint](https://github.com/goffinet/ansible-ccna-lab/workflows/Ansible%20Lint/badge.svg)\n\n## 1. Description du projet\n\nOn trouvera ici des livres de jeu Ansible inspirés des topologies et des sujets du Cisco CCNA (et plus) pour GNS3 (Cisco IOSv). Sa documentation devrait bientôt être disponible sur [https://goffinet.github.io/ansible-ccna-lab/](https://goffinet.github.io/ansible-ccna-lab/). Le projet permet de créer des topologies avec GNS3, de les approvisionner et ensuite, de les gérer avec Ansible avec pour seul véritable objet du code reproductible et manipulable à l'envi.\n\nLeur but est **uniquement pédagogique** visant à lier les compétences de gestion du réseau du CCNA/CCNP avec un outil IaC (\"Infrastructure as Code\") de gestion des configurations (\"Configuration Management\") comme Ansible et un gestionnaire de source (\"Source Control Management\") comme Git/Github. Le projet tente de répondre à la question suivante : Comment porter les labs de formation d'infrastructure IT (Cisco) sous forme de code ?\n\nIl s'agit aussi pour le formateur et pour les stagiaires d'avoir sous la main un outil souple pour créer et gérer des scénarios de labs qui demandent une préconfiguration ou des changements de configuration (afin de créer des erreurs à corriger manuellement par exemple, développer des projets plus complexes, observer des situations, compléter des configurations, mettre en place des modifications, etc.).\n\nDans les points suivants nous détaillerons :\n\n- La gestion du réseau avec Ansible\n- La mise en place du lab sous GNS3\n- Les topologies\n- L'utilisation des livres de jeu\n- Des notes et un roadmap du projet\n\n## 2. La gestion du réseau avec Ansible\n\nPour la gestion des noeuds Cisco, le projet est basé sur trois éléments :\n\n1. des livres de jeu (qui peuvent en appeler d'autres) sont nommés selon la **topologie** ; ils définissent la \"logique\" de la configuration ;\n2. ces livres de jeu configurent des hôtes d'inventaire (les noeuds à gérer) avec des **tâches** organisées en **rôles** ;\n3. les paramètres de la topologie sont configurés en tant que **variables d'inventaire selon un certain modèle de données**. Celui-ci est totalement aribitraire. Si nous invitons les utilisateurs à modifier les valeurs du modèle de données, nous le prévenons que la modification du _nom des variables_ peut avoir des conséquences sur l'exécution des tâches.\n\nLes topologies sont organisées de la manière suivante :\n\n```yaml\nccna:\n  tripod:\n    gateway:\n    bipod:\n    router_on_a_stick:\n  switchblock:\n```\n\nUne topologie intitulée \"ccna\" est composée de deux topologies distinctes \"tripod\" et \"switchblock\". La topologie \"tripod\" trouve trois variantes amoindries : \"gateway\", \"bipod\", et \"router_on_a_stick\".\n\nChaque topologie est liée à un inventaire.\n\nExpliqué rapidement :\n\n* Le livre de jeu `ccna.yml` (qui appelle les livres de jeu `tripod.yml` et `switchblock.yml`) utilise l'inventaire par défaut \"ccna\".\n* On trouve d'autres inventaires adaptés **aux livres de jeu du même nom** dans le dossier `inventories/`. Il est alors nécessaire de les désigner explicitement lors du lancement du livre de jeu.\n* Un livre le jeu _devrait_ appeler un inventaire du même nom, par exemple : `ansible-playbook -i inventories/tripod/hosts tripod.yml`.\n* On peut contrôler les tâches avec des _tags_ (définis sur les rôles) : `ansible-playbook ccna.yml --list-tags`.\n* L'exécution des tâches est conditionnée par le modèle de donnée (variables d'inventaire), principalement fondé sur une liste de paramètres d'interface. On notera que d'autres approches sont possibles.\n* Un rôle étant un ensemble de tâches abstraites, leur exécution est conditionnée par :\n    * une variable `ansible_network_os == 'ios'`, dans la perspective d'intégrer le projet à d'autres solutions ;\n    * la définition d'une variable de telle sorte que l'absence de paramètre évite l'exécution des tâches (\"Skipped\").\n* Le protocole de routage est contrôlé à partir du livre de jeu avec les variables `ipv4.routing` et `ipv6.routing`. Il est conseillé d'en activer un seul pour une topologie. Des cas de \"route redistribution\" devraient être envisagés.\n* Les livres de jeu exécutent les rôles dans un ordre logique ~~mais chacun trouve des dépendances de rôles définis~~.\n\n## 3. La mise en place du lab sur GNS3\n\nLa mise en place du lab se réalise sur le serveur GNS3 lui-même ou sur une station qui a accès au serveur, car il s'agit d'abord de discuter avec l'API de GNS3 pour monter la topologie. Pour installer GNS3 avec Ansible, on fera référence à un autre projet : [ansible-install-gns3-server](https://github.com/goffinet/ansible-install-gns3-server). Il correspond à quelques étapes :\n\n* Créer un projet GNS3 avec des périphériques interconnectés.\n* Placer une station de contrôle avec Ansible et y connecter les périphériques à gérer.\n* Préparer les images des noeuds Cisco pour une gestion avec Ansible à partir de la station de contrôle.\n\nToutes ces tâches font l'objet du livre de jeu `lab_setup.yml` et de scripts d'installation (station de contrôle).\n\n### 3.1. Setup du lab GNS3 avec Ansible\n\nUn livre de jeu intitulé [`lab_setup.yml`](https://github.com/goffinet/ansible-ccna-lab/blob/master/playbooks/lab_setup.yml) monte automatiquement les topologies qui sont présentées plus bas sur un serveur GNS3. Il exploite [gns3fy](https://davidban77.github.io/gns3fy/), la collection Ansible [davidban77.gns3](https://galaxy.ansible.com/davidban77/gns3) et l'exemple [Collection of Ansible + GNS3 project examples](https://github.com/davidban77/demo-ansible-gns3) de [David Flores (aka: netpanda)](https://davidban77.hashnode.dev/). Les variables qui définissent les périphériques et leurs connexions sont situées dans le dossier [`playbooks/vars/`](https://github.com/goffinet/ansible-ccna-lab/blob/master/playbooks/vars/). Des dépendances python doivent être installées (voir fichier [requirements.txt](https://github.com/goffinet/ansible-ccna-lab/blob/master/requirements.txt)).\n\n\u003c!--\n[^gns3fyissue96]\n\n[^gns3fyissue96]: [https://github.com/davidban77/gns3fy/pull/96](https://github.com/davidban77/gns3fy/pull/96)\n\n\n```bash\ncurl -s https://raw.githubusercontent.com/brownhami/gns3fy/4c651f233513c4544bd9c5fe4a2e1552717e802d/gns3fy/gns3fy.py \u003e $(find / -name gns3fy.py)\n```\n--\u003e\n\nOn peut installer les dépendances de la manière suivante :\n\n```bash\ndnf -y install telnet || apt update \u0026\u0026 apt -y install telnet\ndnf -y install python3-pip || apt update \u0026\u0026 apt -y install python3-pip\npip3 install pip --upgrade\npip3 install ansible\npip3 install netaddr\npip3 install pexpect\npip3 install gns3fy\nansible-galaxy collection install ansible.netcommon\n```\n\nLe livre de jeu crée une topologie CCNA (par défaut) sur un serveur GNS3, configure la gestion des routeurs et des commutateurs, duplique une seule fois (par défaut) le projet de base et supprime ce dernier. Les projets dupliqués sont nommés selon cette nomenclature `date-topologie-numero` : `2020-05-23-ccna-1`.\n\n```bash\ngit clone https://github.com/goffinet/ansible-ccna-lab\ncd ansible-ccna-lab/playbooks\nansible-playbook lab_setup.yml\n```\nou utiliser l'image docker `ghcr.io/goffinet/docker-gns3fy:main`:\n```bash\ngit clone https://github.com/goffinet/ansible-ccna-lab\ndocker run -it -v ./ansible-ccna-lab:/opt -w /opt/playbooks \\\nghcr.io/goffinet/docker-gns3fy:main \\\nbash -c \"ansible-playbook lab_setup.yml\"\n```\n\ndocker run -it -v ./ansible-ccna-lab:/opt -w /opt/playbooks ghcr.io/goffinet/docker-gns3fy:main bash -c \"\n\nOn peut choisir la topologie de base en précisant l'inventaire :\n\n```bash\nansible-playbook lab_setup.yml -i inventories/ccna/hosts\n```\n\nOn aussi préciser le nombre de topologies à dupliquer et le nom de base de chacun des projets créés, ici 3 avec le nom \"testlab\" :\n\n```bash\nansible-playbook lab_setup.yml -i inventories/tripod/hosts -e \"dest_name=testlab count=3\"\n```\n\nLes différentes étapes du livre de jeu peuvent être controllées avec des \"tags\" Ansible :\n\n- `create`\n- `start`\n- `provision`\n- `duplicate`\n- `remove`\n\n\u003c!--\n\nNote : Pour les utilisateurs de la topologie GNS3 fournie en classe, sur certains voire sur tous les périphériques Cisco, il sera peut-être nécessaire de regénérer les clés RSA :\n\n```shell\nenable\nconfigure terminal\ncrypto key generate rsa modulus 2048\nexit\nwr\n\n```\n\n--\u003e\n\n### 3.2. Configuration de la station de contrôle\n\nLa station a besoin d'être configurée manuellement si elle ne fait pas partie de l'inventaire.\n\nLa station de contrôle connecte tous les périphériques en SSH. Le logiciel Ansible y est fraîchement installé (avec la libraire python `netaddr`) avec `pip` ou à partir de dépôts officiels de Ansible.\n\nLa station de contrôle offre un service DHCP avec enregistrement dynamique des noms d'hôte dans un serveur DNS local (dnsmasq). Un serveur Rsyslog écoute sur les ports TCP514 et UDP514.\n\nOn trouve des scripts de préparation d'une station de contrôle Centos et Ubuntu dans le dossier [tests/](https://github.com/goffinet/ansible-ccna-lab/blob/master/tests/). L'interface `eth0` contrôle les périphériques et l'interface `eth1` donne accès à l'Internet.\n\nOn peut rapidement installer un contrôleur sous Centos :\n\n```bash\ncurl -s https://raw.githubusercontent.com/goffinet/ansible-ccna-lab/master/tests/centos-controller.sh -o setup.sh\nbash -x ./setup.sh\n```\n\nSi la version open source de Ansible Tower (Ansible AWX) vous intéresse, vous pouvez l'installer via ce script (4Go RAM et 2 vcpus) sur un station Ubuntu :\n\n```bash\ncurl -s https://raw.githubusercontent.com/goffinet/ansible-ccna-lab/master/tests/ubuntu-controller.sh -o setup.sh\nbash -x ./setup.sh\n```\n\nEt puis :\n\n```bash\ncurl -s https://raw.githubusercontent.com/goffinet/ansible-ccna-lab/master/tests/awx-setup.sh -o awx-setup.sh\nbash -x ./awx-setup.sh\n```\n\n### 3.3. Préparation des images Cisco IOSv pour GNS3\n\n\u003eSi vous avez utilisé le livre de jeu [`lab_setup.yml`](https://github.com/goffinet/ansible-ccna-lab/blob/master/playbooks/lab_setup.yml), cette étape est purement informative.\n\nLes livres de jeu sont testés avec [GNS3 Server](https://cisco.goffinet.org/ccna/cisco-ios-cli/installer-et-configurer-gns3/) et Qemu/KVM sous Linux.\n\nIl y a trois types de périphériques utilisés dans les topologies.\n\n| Périphériques | Images Qemu/KVM | Commentaire |\n| --- | --- | --- |\n| Routeur Cisco IOSv | `vios-adventerprisek9-m.vmdk.SPA.156-2.T` ou `vios-adventerprisek9-m.vmdk.SPA.157-3.M3` avec `IOSv_startup_config.img`  | [VIRL](https://learningnetworkstore.cisco.com/virtual-internet-routing-lab-virl/cisco-personal-edition-pe-20-nodes-virl-20) |\n| Commutateur Cisco IOSv L2/L3  | `vios_l2-adventerprisek9-m.03.2017.qcow2` ou `vios_l2-adventerprisek9-m.SSA.high_iron_20180619.qcow2`  |  [VIRL](https://learningnetworkstore.cisco.com/virtual-internet-routing-lab-virl/cisco-personal-edition-pe-20-nodes-virl-20) |\n| Poste de travail L2 à L7, Station de contrôle  | [`centos8-stream.qcow2`](http://get.goffinet.org/kvm/centos8-stream.qcow2)  |  Le [fichier d'appliance GNS3](http://get.goffinet.org/gns3a/centos8-stream.gns3a) ou Docker ou VPCS |\n\nLes livres de jeu peuvent vérifier la nature du périphérique utilisé de type Cisco et de type routeur ou commutateur à partir de variables d'inventaire.\n\nIl sera nécessaire d'activer SSH sur les périphériques à des fins de gestion par Ansible. On trouvera un modèle jinja2 dans le fichier [`playbooks/templates/iosv_default_config.j2`](ttps://github.com/goffinet/ansible-ccna-lab/blob/master/playbooks/templates/iosv_default_config.j2).\n\n#### 3.3.1. Les Routeurs IOSv\n\nOn utilise des images IOSv `vios-adventerprisek9-m.vmdk.SPA.156-2.T` pour les routeurs L3 avec 8 interfaces GigabitEthernet.\n\nL'interface `GigabitEthernet0/7` sert de console de contrôle TCP/IP et ne participe pas au routage.\n\nSSH est activé de la manière suivante, sur R1 par exemple :\n\n```shell\nhostname R1\nint GigabitEthernet0/7\n ip address dhcp\n no shutdown\n no cdp enable\nip domain-name lan\nusername root privilege 15 password testtest\ncrypto key generate rsa modulus 2048\nip ssh version 2\nip scp server enable\nline vty 0 4\n login local\n transport input ssh\nend\nwr\n\n```\n\n#### 3.3.2. Commutateurs IOSv\n\nOn utilise des images IOSv-L2 `vios_l2-adventerprisek9-m.03.2017.qcow2` pour les commutateurs multicouches.\n\nL'interface `GigabitEthernet3/3` sert de console de contrôle TCP/IP et ne participe pas au routage.\n\nSSH est activé de la manière suivante, sur AS1 par exemple :\n\n```shell\nhostname AS1\nint GigabitEthernet3/3\n no switchport\n ip address dhcp\n no shutdown\n no cdp enable\nip domain-name lan\nusername root privilege 15 password testtest\ncrypto key generate rsa modulus 2048\nip ssh version 2\nip scp server enable\nline vty 0 4\n login local\n transport input ssh\nend\nwr\n\n```\n\n### 3.4. Récupérer le dépôt des livres de jeu Ansible\n\nIl est nécessaire de cloner le dépot sur la machine de contrôle fraîchement configurée.\n\n```bash\ngit clone https://github.com/goffinet/ansible-ccna-lab\ncd ansible-ccna-lab/playbooks\n```\n\nLes livres de jeu sont disponibles dans le dossier `ansible-ccna-lab/playbooks` et se lancent à partir de ce dossier. On peut aussi les utiliser comme \"collection\" Ansible : voir [Using collections in a Playbook](https://docs.ansible.com/ansible/devel/user_guide/collections_using.html#using-collections-in-a-playbook).\n\nOn y trouve l'arborescence suivante :\n\n```\nansible-ccna-lab/playbooks/\n├── ansible.cfg  --\u003e fichier de configuration par défaut\n├── bipod.yml    --\u003e livre de jeu de la topologie bipod\n├── ccna.yml     --\u003e livre de jeu de la topologie ccna\n├── configs/     --\u003e dossier par défaut des fichiers de configuration\n├── demos/       --\u003e livres de jeu de démo / test\n├── files/       --\u003e fichiers statiques spécifiques à utiliser avec les livres de jeu\n├── gateway.yml            --\u003e livre de jeu de la topologie gateway\n├── inventories/           --\u003e dossier d'inventaires\n├── lab_setup.yml          --\u003e livre de jeu qui déploie une topologie sur GNS3\n├── library                --\u003e script utilisé par le livre de jeu lab_setup.yml\n├── networking_workshop.yml   --\u003e livre de jeu de la topologie networking_workshop\n├── restore_config.yml     --\u003e restaure des configurations par défaut\n├── roles/ -\u003e ../roles     --\u003e dossier des rôles utilisés par les livres de jeu\n├── router_on_a_stick.yml  --\u003e livre de jeu de la topologie router_on_a_stick\n├── switchblock.yml        --\u003e livre de jeu de la topologie switchblock\n├── tasks/       --\u003e tâches spécifiques à utiliser avec les livres de jeu\n├── templates/   --\u003e modèles spécifiques à utiliser avec les livres de jeu\n├── tripod.yml   --\u003e livre de jeu de la topologie tripod\n└── vars         --\u003e variables spécifiques à utiliser dans un livre de jeu\n```\n\nModèle de collection basé sur [https://github.com/bcoca/collection](https://github.com/bcoca/collection).\n\n### 3.5. Prise de connaissance des paramètres de configuration de Ansible\n\nLe fichier de configuration `ansible.cfg` dans le dossier `ansible-ccna-lab/playbooks` configure par défaut le comportement de Ansible :\n\n```ini\n[defaults]\ninventory = ./inventories/ccna/hosts\nroles_path = ~/.ansible/roles:./roles\nhost_key_checking = False\nretry_files_enabled = False\nlog_path = ./ansible.log\n#forks = 20\nstrategy = linear\n#gathering = explicit\ncallback_whitelist = profile_tasks\n#display_ok_hosts = no\n#display_skipped_hosts = no\n#[callback_profile_tasks]\n#task_output_limit = 100\n```\n\nLa section `[defaults]` définit différentes variables comportementales du logiciel Ansible utiles à nos exécutions en comparaison aux paramètres par défaut :\n\n- `inventory` : désigne l'emplacement de l'inventaire par défaut ici `./inventories/ccna/hosts`.\n- `roles_path` : désigne les emplacements par défaut des rôles.\n- `host_key_checking` : active ou non la vérification des clés SSH, ici désactivée.\n- `retry_files_enabled` active ou non la génération de fichier \"[retry](https://docs.ansible.com/ansible/latest/reference_appendices/config.html#retry-files-enabled)\".\n- `log_path` : désigne l'emplacement et le nom du fichier de log.\n- `forks` : désigne le nombre d'hôtes à controller en paralèlle (5 par défaut).\n- `strategy` : désigne la stratégie \"linear\" lance chaque tâche sur tous les hôtes concernés par un jeu avant de commencer la tâche suivante alors que la stratégie \"free\" permet à chaque hôte d'exécuter le jeu jusqu'à la fin aussi vite que possible.\n- `gathering` : collecte (\"implicit\", par défaut) ou non (\"explicit\") les facts. Ici désactivé par défaut.\n- `callback_whitelist` : affiche ou non des paramètres de temps (voir la section `[callback_profile_tasks]`).\n- `display_ok_hosts` : active ou non l'affichage des tâches dont le statut est \"OK\" (utile pour vérifier l'idempotence).\n- `display_skipped_hosts` : active ou non l'affichage des tâches dont le statut est \"Skipped\" (utile pour vérifier l'idempotence).\n\n## 4. Les topologies CCNA\n\nLes topologies réseau développées sont décrites dans différents inventaires et se configurent avec un livre de jeu du même nom :\n\n- \"gateway\" : un seul routeur connecte l'Internet et offre des services au LAN comme DHCP et RDNSS\n- \"bipod\" : topologie d'interconnexion de deux LANs distants\n- \"tripod\" : topologie de base maillée à trois routeurs avec un accès à l'Internet\n- \"router_on_a_stick\" : topologie d'apprentissage des VLANs\n- \"switchblock\" : topologie de commutateurs de couche Access et Distribution\n- \"ccna\" : topologies \"tripod\" et \"switchblock\" connectées entre elles\n- \"networking_workshop\"\n\n### 4.1. Topologie CCNA Gateway\n\nUn seul routeur Cisco qui connecte l'Internet et qui offre des services au LAN comme DHCP et RDNSS.\n\n![](docs/assets/images/gateway_lab.png)\n\nRéférences :\n\n* [Lab passerelle Internet](https://cisco.goffinet.org/ccna/services-infrastructure/lab-passerelle-internet/)\n\n![Topologie CCNA Gateway](https://www.lucidchart.com/publicSegments/view/d8a42bbc-5192-48b9-a630-2e968dcf6f43/image.png)\n\nDiagramme : Topologie CCNA Gateway\n\n### 4.2. Topologie CCNA Bipod\n\nConnexion point-à-point entre R1 et R2.\n\n![Topologie Bipod](https://www.lucidchart.com/publicSegments/view/46f2b887-0e06-40e6-b45c-b07f449adf08/image.png)\n\nRéférences :\n\n* [Lab routage statique simple](https://cisco.goffinet.org/ccna/routage/lab-routage-statique-simple/)\n* [Lab routage RIPv2 simple](https://cisco.goffinet.org/ccnp/rip/lab-ripv2-simple/)\n* [Lab Routage OSPF simple](https://cisco.goffinet.org/ccna/ospf/lab-routage-ospf-simple/)\n* [Lab de routage et services IPv4/IPv6](https://cisco.goffinet.org/ccna/services-infrastructure/lab-routage-et-services-ipv4-ipv6/)\n\nDiagramme : Topologie CCNA Bipod\n\n![](docs/assets/images/bipod_lab.png)\n\n### 4.3. Topologie CCNA Tripod\n\nCette topologie maillée à trois routeurs peut être désignée par \"tripod\". Elle est la couche \"Core\" de la topologie CCNA complète.\n\n![](docs/assets/images/tripod_lab.png)\n\n#### 4.3.1. Topologie logique\n\n![Topologie CCNA Tripod](https://www.lucidchart.com/publicSegments/view/3328e715-30bf-48a8-a48d-1ff276420520/image.png)\n\n#### 4.3.2. Brève description\n\nTrois périphériques IOSv interconnectés entre eux :\n\n* R1\n* R2\n* R3\n\n| Routeur | Interface | Adresse IPv4 | Adresses IPv6 | Description |\n| --- | --- | --- | --- | --- |\n| R1 | G0/0 | `192.168.1.1/24` | `FE80::1`, `FD00:FD00:FD00:1::1/64` | LAN de R1 |\n| R1 | G0/2 | `192.168.225.1/24` | `FE80::1` | Connexion vers R2 |\n| R1 | G0/3 | `192.168.226.1/24` | `FE80::1` | Connexion vers R3 |\n| R2 | G0/0 | `192.168.33.1/24` | `FE80::2`, `FD00:FD00:FD00:2::1/64` | LAN de R2 |\n| R2 | G0/1 | `192.168.225.2/24` | `FE80::2` | Connexion vers R1 |\n| R2 | G0/3 | `192.168.227.1/24` | `FE80::2` | Connexion vers R3 |\n| R3 | G0/0 | `192.168.65.1/24` | `FE80::3`, `FD00:FD00:FD00:3::1/64` | LAN de R3 |\n| R3 | G0/1 | `192.168.226.2/24` | `FE80::3` | Connexion vers R1 |\n| R3 | G0/2 | `192.168.227.2/24` | `FE80::3` | Connexion vers R2 |\n\n* On activera un service DHCP sur chaque réseau local (`GigabitEthernet0/0`).\n* Le routeur R1 connecte l'Internet. Le service NAT est activé.\n\nOn activera les protocoles de routage IPv4 et IPv6 :\n\n* [RIPv2](https://cisco.goffinet.org/categories/rip)\n* [OSPFv2 et/ou OSPFv3](https://cisco.goffinet.org/categories/ospf)\n* [EIGRP pour IPv4 et/ou IPv6](https://cisco.goffinet.org/categories/eigrp) avec des exemples de variance\n\nRéférences :\n\n* [Lab routage RIPv2 VLSM](https://cisco.goffinet.org/ccnp/rip/lab-ripv2-vlsm/)\n* [Lab Routage EIGRP](https://cisco.goffinet.org/ccnp/eigrp/lab-routage-eigrp/)\n* [Lab Routage OSPF Multi-Area](https://cisco.goffinet.org/ccna/ospf/lab-ospf-multi-area/)\n\n### 4.4. Topologie variante Router on a Stick\n\nVariante de la topologie Tripod en utilisant un Trunk Vlan entre R1 et SW0 ainsi qu'entre SW0 et SW1.\n\n![Topologie variante Router on a Stick](https://www.lucidchart.com/publicSegments/view/9414c7ca-8f9a-4306-8908-a1e1c44009e2/image.png)\n\nDiagramme : Topologie variante Router on a Stick\n\n![](docs/assets/images/router_on_a_stick_lab.png)\n\nRéférences :\n\n* [Lab VLAN de base](https://cisco.goffinet.org/ccna/vlans/lab-vlan-base-cisco-ios/)\n\n### 4.5. Topologie CCNA Switchblock\n\nCette seconde topologie \"switchblock\" met en oeuvre des _commutateurs_. Cette topologie est plus complexe et se connecte à la topologie \"tripod\". Elle met en oeuvre les couches \"distribution\" et \"access\".\n\n![](docs/assets/images/switchblock_lab.png)\n\nRéférences :\n\n* [Technologies VLANs](https://cisco.goffinet.org/ccna/vlans/)\n* [Redondance de liens](https://cisco.goffinet.org/ccna/redondance-de-liens/)\n* [Disponibilité dans le LAN](https://cisco.goffinet.org/ccna/disponibilite-lan/)\n\n#### 4.5.1. Topologie avec redondance de passerelle HSRP\n\n![Topologie avec redondance de passerelle HSRP](https://www.lucidchart.com/publicSegments/view/84f170f5-af2b-44c1-8f6d-d169399dbba2/image.png)\n\n#### 4.5.2. VLANs\n\n| VLAN | Ports Access (AS1 et AS2) | plage d'adresse | Passerelle par défaut |\n| --- | --- | --- | --- |\n| VLAN 10 | `g2/0` | `172.16.10.0/24` | **`172.16.10.254`** |\n| VLAN 20 | `g2/1` | `172.16.20.0/24` | **`172.16.10.254`** |\n| VLAN 30 | `g2/2` | `172.16.30.0/24` | **`172.16.10.254`** |\n| VLAN 40 | `g2/3` | `172.16.40.0/24` | **`172.16.10.254`** |\n| VLAN 99 | VLAN natif | Management\n\n#### 4.5.3. Ports Etherchannel et Trunk VLANs\n\n| PortChannel | ports physiques | Commutateurs |\n| --- | --- | ---\n| po1 | `g0/0`,`g1/0` | AS1 - DS1 |\n| po2 | `g0/1`,`g1/1` | AS1 - DS2 |\n| po3 | `g0/2`,`g1/2` | DS1 - DS2 |\n| po4 | `g0/0`,`g1/0` | AS2 - DS2 |\n| po5 | `g0/1`,`g1/1` | AS2 - DS1 |\n\n#### 4.5.4. Spanning-Tree\n\n| VLANs | DS1 | DS2 |\n| --- | --- | --- |\n| VLANs 1,10,30,99 | `root primary` | `root secondary` |\n| VLANs 20,40 | `root secondary` | `root primary` |\n\n#### 4.5.5. Plan d'adressage\n\n| Commutateur | Interface | Adresse IPv4 | Adresse(s) IPv6 |\n| --- | --- | --- | --- |\n| DS1 | VLAN10 | `172.16.10.252/24` | `FD00:1AB:10::1/64` |\n| DS1 | VLAN20 | `172.16.20.252/24` | `FD00:1AB:20::1/64` |\n| DS1 | VLAN30 | `172.16.30.252/24` | `FD00:1AB:30::1/64` |\n| DS1 | VLAN40 | `172.16.40.252/24` | `FD00:1AB:40::1/64` |\n| DS2 | VLAN10 | `172.16.10.253/24` | `FD00:1AB:10::2/64` |\n| DS2 | VLAN20 | `172.16.20.253/24` | `FD00:1AB:20::2/64` |\n| DS2 | VLAN30 | `172.16.30.253/24` | `FD00:1AB:30::2/64` |\n| DS2 | VLAN40 | `172.16.40.253/24` | `FD00:1AB:40::2/64` |\n\n#### 4.5.6. HSRP\n\n| Commutateur | Interface | Adresse IPv4 virtuelle | Adresse IPv6 virtuelle | Group | Priorité |\n| --- | --- | --- | --- | --- | --- |\n| DS1 | VLAN10 | `172.16.10.254/24` | `FE80::d:1/64` | 10/16 | 150, prempt |\n| DS1 | VLAN20 | `172.16.20.254/24` | `FE80::d:1/64` | 20/26 | default |\n| DS1 | VLAN30 | `172.16.30.254/24` | `FE80::d:1/64` | 30/36 | 150, prempt |\n| DS1 | VLAN40 | `172.16.40.254/24` | `FE80::d:1/64` | 40/46 | default |\n| DS2 | VLAN10 | `172.16.10.254/24` | `FE80::d:2/64` | 10/16 | default |\n| DS2 | VLAN20 | `172.16.20.254/24` | `FE80::d:2/64` | 20/26 | 150, prempt |\n| DS2 | VLAN30 | `172.16.30.254/24` | `FE80::d:2/64` | 30/36 | default |\n| DS2 | VLAN40 | `172.16.40.254/24` | `FE80::d:2/64` | 40/46 | 150, prempt |\n\n#### 4.5.7. Ressources requises\n\n*\t4 commutateurs (vios_l2 Software (vios_l2-ADVENTERPRISEK9-M), Experimental Version 15.2(20170321:233949))\n*\t8 PCs (Centos 7 KVM ou Ubuntu Docker)\n*\t(Câbles de console pour configurer les périphériques Cisco IOS via les ports de console)\n*\tCâbles Ethernet conformément à la topologie\n\n#### 4.5.8. Explication\n\nDans l'exercice de laboratoire \"Lab répartition de charge avec Rapid Spanning-Tree\", nous avons appris à déployer Rapid Spanning-Tree entre la couche Distribution et la couche Access. Il manque manifestement une sûreté au niveau de la passerelle par défaut que constitue le commutateur de Distribution. Afin d'éviter ce point unique de rupture, on apprendra à configurer et vérifier HSRP. Dans cette topologie une passerelle devient routeur \"Active\" pour certains VLANs et reste en HSRP \"Standby\" pour d'autres VLANs et inversément.\n\nOn trouvera plus bas les fichiers de configuration qui déploient la solution  VLANs, Trunking, Etherchannel, Rapid Spanning-Tree, SVI IPv4 et IPv6 et DHCP. Par rapport à l'exercice de laboratoire \"Lab répartition de charge avec Rapid Spanning-Tree\", tout reste identique sauf le paramètre de passerelle.\n\n### 4.6. Toplogie CCNA Tripod et Switchblock\n\nCette topologie interconnecte les topologies \"tripod\" et \"switchblock\".\n\n![](https://www.lucidchart.com/publicSegments/view/aacc6247-aa9a-44b2-a1ba-43ccb81deab7/image.png)\n\nAvec le contrôleur :\n\n![](docs/assets/images/ccna_lab_control.png)\n\n### 4.7. Topologie Ansible Networking Workshop\n\nCette topologie s'utilise dans le cadre de l'exercice [ANSIBLE RÉSEAU](https://iac.goffinet.org/ansible-network/) avec le projet [Ansible Networking Workshop Files](https://github.com/goffinet/networking_workshop).\n\n\u003c!--\n\n![Ansible Networking Workshop](https://github.com/network-automation/linklight/raw/master/images/network_diagram.png)\n\n--\u003e\n\n![](docs/assets/images/networking_workshop_lab.png)\n\n## 5. L'utilisation des livres de jeu\n\nSe rendre dans le dossier des livres de jeu `ansible-ccna-lab/playbooks/` :\n\n```bash\ncd\ngit clone https://github.com/goffinet/ansible-ccna-lab\ncd ansible-ccna-lab/playbooks\n```\n\n### 5.1. Inventaire et variables d'inventaire du livre de jeu ccna.yml\n\nL'inventaire par défaut est défini comme suit (fichier `inventories/ccna/hosts`) et correspond à la topologie ccna (tripod + switchblock) :\n\n```ini\n[all:vars]\n#method=modules # modules or templating not yet implemented\n\n[core]\nR1\nR2\nR3\n\n[distribution]\nDS1\nDS2\n\n[access]\nAS1\nAS2\n\n[blocks:children]\ndistribution\naccess\n\n[routers:children]\ncore\n\n[switches:children]\nblocks\n\n[cisco:children]\ncore\nblocks\n\n[core:vars]\nmgmt_interface=GigabitEthernet0/7\nimage_style=iosv_l3\n\n[blocks:vars]\nmgmt_interface=GigabitEthernet3/3\nimage_style=iosv_l2\n\n[cisco:vars]\nansible_user=root\nansible_ssh_pass=testtest\nansible_port=22\nansible_connection=network_cli\nansible_network_os=ios\n\n```\n\nLa variable `ansible_network_os=ios` conditionne l'exécution des rôles du livre de jeu.\n\nLes configurations sont définies en YAML dans les fichiers de variables d'inventaire (fichier au nom du groupe dans le dossier `inventories/ccna/group_vars` et fichier au nom de l'hôte dans le dossier `inventories/ccna/host_vars`).\n\n```\ninventories/ccna\n├── group_vars\n│   ├── all       --\u003e protocoles de routage ipv4/ipv6\n│   ├── blocks    --\u003e variables vlans, switchports et stp mode\n│   └── core      --\u003e variables routage, rdnss\n├── hosts         --\u003e fichier d'inventaire, avec des variables génériques\n└── host_vars     --\u003e variables propres à chaque périphérique\n    ├── AS1\n    ├── AS2\n    ├── DS1\n    ├── DS2\n    ├── R1\n    ├── R2\n    └── R3\n```\n\n### 5.2. Livres de jeu\n\nLes livres de jeu (`playbooks/`) font appel à des rôles qui trouvent la valeur des variables dans l'inventaire.\n\n\nLe playbook `tripod.yml` configure la topologie tripod :\n\n```bash\nansible-playbook tripod.yml -v\n```\n\nLe playbook `blocks.yml` configure la topologie switchblock :\n\n```bash\nansible-playbook switchblock.yml -v\n```\n\nLe playbook `ccna.yml` configure l'ensemble :\n\n```bash\nansible-playbook ccna.yml -v\n```\n\n### 5.3. Les rôles invoqués\n\nLes livres de jeu reprennent les rôles conçus, comme par exemple dans le livre de jeu `bipod.yaml` :\n\n```yaml\n---\n# bipod.yml\n- hosts: core\n  gather_facts: False\n  roles:\n    - role: ios_common\n    - role: ios_interface\n    - role: ios_ipv4\n    - role: ios_ipv6\n    - role: ios_ipv4_routing\n    - role: ios_ipv6_routing\n    - role: ios_static_routing\n    - role: ios_rip\n      when: '\"rip\" in ipv4.routing'\n    - role: ios_recursive_dns_server\n    - role: ios_dhcp_server\n    - role: ios_nat44\n    - role: ios_write\n```\n\nCes rôles trouvent leur place dans le dossier `roles` du projet :\n\n```\nroles/\n├── ios_common/\n├── ios_dhcp_server/\n├── ios_disable_dynamic_ipv4_routing/\n├── ios_eigrp4/\n├── ios_eigrp6/\n├── ios_etherchannel/\n├── ios_fhrp/\n├── ios_interface\n├── ios_ipv4/\n├── ios_ipv4_routing/\n├── ios_ipv6/\n├── ios_ipv6_routing/\n├── ios_nat44/\n├── ios_no_ipv4_routing\n├── ios_ospfv2/\n├── ios_ospfv3/\n├── ios_recursive_dns_server/\n├── ios_rip/\n├── ios_spanningtree/\n├── ios_static_routing/\n├── ios_vlans/\n└── ios_write/\n```\n\n### 5.4. Diagnostic de base\n\n_à améliorer_\n\n\u003c!--\n\nDiagnostic du routage sur R1 :\n\n```bash\nansible R1 -m ios_command -a \"commands='show ip route'\"\n```\n\nDiagnostic à partir des routeurs Core :\n\n```bash\nansible core -m ios_command -a \"commands='traceroute 192.168.1.1 source GigabitEthernet0/0 probe 1 numeric'\"\n```\n\n```bash\nansible core -m ios_command -a \"commands='traceroute 172.16.10.1 source GigabitEthernet0/0 probe 1 numeric'\"\n```\n\n--\u003e\n\n### 5.5. Remettre à zéro les configurations\n\nLe livre de jeu [playbooks/restore_config.yml](https://github.com/goffinet/ansible-ccna-lab/blob/master/playbooks/restore_config.yml) restaure des configurations vierges sur les hôtes d'inventaire Cisco.\n\n## 6. Notes\n\n### 6.1. Comment rendre une tâche ios_config idempotente ?\n\n\u003e \"Être idempotent permet à une tâche définie d'être exécutée une seule fois ou des centaines de fois sans créer un effet contraire sur le système cible, ne provoquant un changement à une seule reprise. En d'autres mots, si un changement est nécessaire pour obtenir le système dans un état désiré, alors le changement est réalisé ; par contre si le périphérique est déjà dans l'état désiré, aucun changement n'intervient. Ce comportement est différent des pratiques de scripts personnalisés et de copier/coller de lignes de commandes. Quand on exécute les mêmes commandes ou scripts sur un même système de manière répétée, le taux d'erreur est souvent élevé.\"\n\u003e\n\u003e Extrait de: Jason Edelman. « Network Automation with Ansible. », O’Reilly Media, 2016.\n\nAttention, Ansible autorise l'idempotence, mais selon le module utilisé, il faudra le manipuler pour atteindre cette exigence de conception.\n\n1/ La section [\"Why do the config modules always return true\" de la \"Ansible Network FAQ\"](https://docs.ansible.com/ansible/latest/network/user_guide/faq.html#why-do-the-config-modules-always-return-changed-true-with-abbreviated-commands) explique ceci :\n\nLes modules `*_config` d'Ansible Network comparent le texte des commandes que vous spécifiez dans les lignes au texte de la configuration. Si vous utilisez `shut` dans la section `lines` de la tâche, et que la configuration indique `shutdown`, le module retourne `changed=true` même si la configuration est déjà correcte. La tâche mettra à jour la configuration à chaque fois qu'elle s'exécutera.\n\nLes commandes utilisées avec Ansible pourraient ne pas être les mêmes commandes que celles trouvées dans la `running_config` : alors, les contrôles entre les lignes ne correspondent pas exactement, même s'ils produisent la même sortie.\n\n2/ Il y a aussi la façon dont le module compare les lignes mises à jour avec la `running_config`. Par défaut, le module vérifie chaque ligne, mais il y a d'autres options. La [documentation](https://docs.ansible.com/ansible/latest/modules/ios_config_module.html) dit ceci à propos de l'argument `match` du module :\n\nInstruit le module sur la façon d'effectuer la correspondance du jeu de commandes avec la configuration actuelle (running-config) du périphérique. Si l'argument `match` est valorisé par `line`, les commandes sont mises en correspondance ligne par ligne (défaut). Si l'argument `match` est valorisé par `strict`, les lignes de commande sont mises en correspondance par rapport à la position. Si l'argument `match` est valorisé par `exact`, les lignes de commande doivent être de même nature. Enfin, si l'argument `match` est valorisé par `none`, le module ne tentera pas de comparer la configuration source avec la \"running-config\" du périphérique distant.\n\n3/ L'option `after` contrôle l'application des changements aux interfaces :\n\nL'ensemble des commandes ordonnées à ajouter à la fin de la pile de commandes si un changement doit être fait. Comme avec l'option `before`, cela permet au concepteur du livre de jeu d'ajouter un ensemble de commandes à exécuter après l'ensemble de commandes.\n\nCombinée avec l'option `before`, on applique des commandes avant et après que les changements soient faits. Par exemple, on peut définir une réinitialisation en cinq minutes pour éviter une déconnexion à cause d'un problème de configuration, ou écrire les changements dans la ROM (bien que l'on puisse le faire avec l'option `save_when`).\u003csup\u003e1\u003c/sup\u003e\n\n\u003csup\u003e1\u003c/sup\u003e Texte original de [guzmonne](https://stackoverflow.com/users/1930817/guzmonne) en réponse à la question stackoverflow [How can I make my ios_config task idempotent?](https://stackoverflow.com/questions/57279642/how-can-i-make-my-ios-config-task-idempotent).\n\nAussi, l'argument `defaults` qu'il sera nécessaire d'activer avec la valeur `yes` spécifie s'il faut ou non collecter toutes les valeurs par défaut lors de l'exécution de la configuration du périphérique distant. Lorsqu'il est activé, le module obtient la configuration actuelle en lançant la commande `show running-config all`. En effet, des commandes comme `no shutdown` ou encore `ipv6 enable` ou encore `ipv4 routing` et beaucoup n'apparaissent pas avec la commande `show running-config`.\n\n### 6.2. Phase I : roles ios_config\n\n#### 6.2.1. Objectifs\n\n- [x] Tendre vers des rôles **idempotents** avec des [modules standards](https://docs.ansible.com/ansible/latest/modules/list_of_network_modules.html#ios).\n- [x] Usage du filtre jinja2 [ipaddr](https://docs.ansible.com/ansible/latest/user_guide/playbooks_filters_ipaddr.html#playbooks-filters-ipaddr), voir [playbooks/ipaddr.yml](https://github.com/goffinet/ansible-ccna-lab/blob/master/playbooks/demos/ipaddr.yml).\n- [x] Structure en \"collection\" Ansible. [Using collections in a Playbook](https://docs.ansible.com/ansible/devel/user_guide/collections_using.html#using-collections-in-a-playbook).\n- [x] Définir des paramètres par défaut.\n- [ ] Revoir les conditions, les boucles, les tags\n- [ ] Dépendances des livres de jeu (parser, gns3fy)\n\n#### 6.2.2. Rôles à améliorer\n\n* [ ] nat sur les interfaces\n* [ ] contrôle d'IPv6\n* [ ] dhcp-relay\n* [ ] ~~**fhrp4**~~ + delay\n* [ ] ~~**fhrp6**~~ + delay\n* [ ] ~~eigrp4/6~~ / ~~ospfv2/v3~~ authentication\n\n#### 6.2.3. Rôles à créer\n\n* [ ] **cdp** / **lldp**\n* [ ] **syslog**\n* [ ] **ntp** (+ auth)\n* [ ] **snmpv2c** / **snmpv3**\n* [ ] **zbf**\n* [ ] IPv6 Addresses Management :\n    * [ ] ra-config fine tuning\n    * [ ] dhcpv6 stateless\n    * [ ] dhcpv6 stateful\n* [ ] gre ipv4 / gre ipv6\n* [ ] **security hardening**\n* [ ] IPv6 default route poisoning benefits to `FD00::/8` as best route ?\n* [ ] ~~dependencies~~ ? handlers ?\n* [ ] ppp / chap / pap / pppoe\n* [ ] bgp / vrf / ip-mpls\n* [ ] dhcp snooping\n* [ ] dai\n\n### 6.3. Phase II : immutabilité\n\n_tasks by jinja2 templating_, \"boilerplate config\"\n\nRôles \"immutables\" qui agissent sur un modèle de fichier de configuration basé sur des choix d'infrastructure (des variables) et qui sera poussé sur les périphériques par la procédure `config replace flash:XXX force`.\n\n### 6.4. Phase III : Reporting et documentation\n\n* Reporting ([role ansible-network.cisco_ios](https://galaxy.ansible.com/ansible-network/cisco_ios)) :\n  * Documentation de la topologie (classique, énoncé) sur base des facts (parsing) et\n  * Surveillance des interfaces et des services\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fgoffinet%2Fansible-ccna-lab","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fgoffinet%2Fansible-ccna-lab","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fgoffinet%2Fansible-ccna-lab/lists"}