Damien/Notebook
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Fix(image missing)

Browse Source 
- Removing English
- Start new post
This commit is contained in:
darnodo
2025-05-10 15:55:23 +02:00
parent 8c71a2fad9
commit 02d7410a66
29 changed files with 264 additions and 1205 deletions
Download Patch File Download Diff File Expand all files Collapse all files

16
content/netlab/_index.md
View File

@@ -1,16 +0,0 @@
---
title: "Netlab"
cascade:
type: docs
---
<!-- markdownlint-disable MD033 MD034-->
{{< hextra/hero-subtitle >}}
Deep Dive using NetLab
{{< /hextra/hero-subtitle >}}
{{< cards >}}
{{< card link="/Notebook/netlab/netlab/" title="What is a Netlab" subtitle="What and Why we use NetLab" icon="science" >}}
{{< card link="/Notebook/netlab/first_lab/" title="My First Lab" subtitle="How to deploy an NetLab using DevPod" icon="docker" >}}
{{< /cards >}}

2
content/netlab/first_lab/_index.fr.md
View File

@@ -1,7 +1,7 @@
---
title: "Mon Premier Lab"
date: 2025-02-14T12:00:00+02:00
weight: 1
weight: 2
cascade:
type: docs
---

214
content/netlab/first_lab/_index.md
View File

@@ -1,214 +0,0 @@
---
title: "My First Lab"
date: 2025-02-14T12:00:00+02:00
weight: 1
cascade:
type: docs
---
## Introduction 📚
In this article, we’ll explore how to install our very first Containerlab netlab using **DevPod**. We'll focus on leveraging a cloud provider—specifically **AWS**—to host our project. Why **Cloud**? Because network labs can consume a huge amount of resources, and we need the ability to deploy, stop, and destroy them quickly for both performance and financial efficiency. 💡💰
We'll achieve this using a combination of:
- **DevPod**
- **DevContainer**
- **Containerlab**
Additionally, we will use a small topology, which you can find on my [GitHub repository](https://github.com/darnodo/VXLAN-EVPN). Our main objective is to deploy this lab on AWS using DevPod. Let's dive in and get started! 🚀😊
## Prerequisites 🔧
Before we get started, there are a couple of important steps to complete:
1. **AWS Environment Authorization**:
Ensure that DevPod is authorized to access your AWS environment. For a detailed guide on configuring DevPod with AWS, please refer to my post on this [topic](/Notebook/documentation/devpod). 🔑
2. **Containerlab Topology**:
We need a topology file that Containerlab can understand. In our case, we're building a simple VXLAN topology. 🗺️
## Containerlab Topology 🔄
Our lab will simulate a VXLAN topology with:
- **1 Spine switch**
- **2 Leaf switches**
- **2 Host nodes**
The following diagram illustrates the VXLAN topology:
![VXLAN Topology](VXLAN.svg#center)
Below is the Containerlab topology file (`lab_vxlan.yml`) used for this setup:
```yaml
name: vxlan-evpn-irb
topology:
nodes:
spine1:
kind: ceos
image: ceos:4.32.0.1F
mgmt-ipv4: 172.20.20.101
leaf1:
kind: ceos
image: ceos:4.32.0.1F
mgmt-ipv4: 172.20.20.11
leaf2:
kind: ceos
image: ceos:4.32.0.1F
mgmt-ipv4: 172.20.20.12
host1:
kind: linux
image: alpine:latest
binds:
- hosts/h1_interfaces:/etc/network/interfaces
mgmt-ipv4: 172.20.20.21
host2:
kind: linux
image: alpine:latest
binds:
- hosts/h2_interfaces:/etc/network/interfaces
mgmt-ipv4: 172.20.20.22
links:
- endpoints: ["spine1:eth1", "leaf1:eth1"]
- endpoints: ["spine1:eth2", "leaf2:eth1"]
- endpoints: ["leaf1:eth2", "host1:eth1"]
- endpoints: ["leaf2:eth2", "host2:eth1"]
```
### Breaking Down the Topology 🧐
1. **Name and Structure**:
- `name: vxlan-evpn-irb` – This is the lab's name.
- The topology is divided into **nodes** (devices) and **links** (connections between devices).
2. **Nodes**:
- **Spine Layer**:
- `spine1`: A containerized Arista cEOS switch using image version `4.32.0.1F`.
- **Management IP**: `172.20.20.101`
- **Leaf Layer**:
- `leaf1` and `leaf2`: Arista cEOS switches with the same image version.
- **Management IPs**: `172.20.20.11` and `172.20.20.12`
- **Host Layer**:
- `host1` and `host2`: Linux containers running Alpine Linux.
- They include custom network interface configurations mounted from the host.
- **Management IPs**: `172.20.20.21` and `172.20.20.22`
3. **Links**:
- **Spine to Leaf**:
- `spine1:eth1` ↔ `leaf1:eth1`
- `spine1:eth2` ↔ `leaf2:eth1`
- **Leaf to Host**:
- `leaf1:eth2` ↔ `host1:eth1`
- `leaf2:eth2` ↔ `host2:eth1`
This topology represents a typical spine-leaf architecture, common in data center networks to enable both Layer 2 and Layer 3 connectivity with VXLAN EVPN configurations. 🔗💻
## Deploy the Lab 🛠️
We will deploy the lab using **DevPod** in two ways:
### 1. Using the Repository 📥
1. **Validate AWS Provider Configuration**:
Ensure that your AWS provider is correctly configured. More details can be found [here](/Notebook/documentation/devpod). ✅
2. **Create a Workspace**:
- Navigate to the **Workspace** tab and click on **Create Workspace**.
- Enter the **Workspace source**: use the [GitHub repository](https://github.com/darnodo/VXLAN-EVPN).
- Select **AWS** as the provider.
- Choose your default IDE.
- Finally, click on **Create Workspace**.
![DevPod Configuration](devpod_configuration.png#center)
### 2. Using a Local Folder 🗂️
If you prefer to use your local repository:
- The only difference is in the **Workspace source**.
- Simply point it to your local repository.
![DevPod Configuration - Local](devpod_configuration_local.png#center)
## Starting the Lab 🎬
> [!WARNING] cEOS Images
> The lab uses **cEOS image v4.32.0.1F**.
> To download this image, visit the [Arista download webpage](https://www.arista.com/en/support/software-download). ⚠️
1. **Import the cEOS Image**:
Save the cEOS image in your `network_images` folder by dragging and dropping it into VSCode.
Import the image using the following command:
```bash
docker import network_images/cEOS64-lab-4.32.0.1F.tar.xz ceos:4.32.0.1F
```
2. **Deploy the Lab**:
Deploy the lab using Containerlab:
```bash
sudo containerlab deploy -t lab_vxlan.yml
```
Follow the CLI prompts to configure your devices. For detailed configuration steps, refer to [this guide](https://github.com/darnodo/VXLAN-EVPN/tree/main/documentation/eos_configuration). 🔧🖥️
3. **Visualize the Architecture**:
Validate the deployed topology using Containerlab’s graph view:
```bash
containerlab graph -t lab_vxlan.yml
```
Ports (e.g., port 50080 as mentioned in the `devcontainer.json`) are forwarded. Access the graph view via [localhost](http://localhost:50080).
![Graph View](Graph_view.png#center)
## Using EdgeShark 🦈
EdgeShark is a web UI tool that helps capture packets from your lab environment. It tunnels captures from the lab to Wireshark running locally. 📡🔍
For more details, check out [EdgeShark’s Getting Started Guide](https://edgeshark.siemens.io/#/getting-started?id=optional-capture-plugin).
### EdgeShark Setup in the DevContainer 🐳
In the **DevContainer** configuration, the following `postCreateCommand` has been added:
```bash
sudo mkdir -p /opt/edgeshark && sudo curl -sL https://github.com/siemens/edgeshark/raw/main/deployments/wget/docker-compose.yaml -o /opt/edgeshark/docker-compose.yaml
```
This command downloads a Docker Compose file to facilitate the use of EdgeShark. 🚀
### Running EdgeShark ⚡
To start EdgeShark, execute:
```bash
cd /opt/edgeshark
DOCKER_DEFAULT_PLATFORM= docker compose up -d
```
Access EdgeShark via [localhost:5001](http://localhost:5001).
- **EdgeShark View**:
![Edgeshark View](edgeshark.png#center)
- **Wireshark Integration**:
Using the Wireshark icon in EdgeShark, you can launch Wireshark locally.
![Edgeshark Interface](edgeshark_interface.png#center)
![Edgeshark and Wireshark](edge_wireshark.png#center)
## Conclusion 🎉
In this article, we walked through the steps to deploy a VXLAN EVPN lab using Containerlab, DevPod, and AWS. We covered the following key points:
- **Setting up prerequisites** for AWS and Containerlab. 🔑
- **Creating a detailed topology** file for a spine-leaf network. 🗺️
- **Deploying the lab** using both repository and local methods. 📥🗂️
- **Starting the lab** with Docker and Containerlab. 🚀🐳
- **Using EdgeShark** to capture packets and integrate with Wireshark for detailed analysis. 🦈🔍
By following these steps, you can easily deploy and manage a scalable network lab environment in the cloud. Happy networking and enjoy your lab adventures! 😄🎊

1
content/netlab/netlab.fr.md
View File

@@ -1,5 +1,6 @@
---
title: "Présentation des NetLabs"
weight: 1
cascade:
type: docs
---

67
content/netlab/netlab.md
View File

@@ -1,67 +0,0 @@
---
title: "What is a Netlab"
cascade:
type: docs
---
## Introduction
📡 In a world where computer networks play an increasingly significant role in our daily lives, understanding the principles and logic that drive them becomes more and more essential.
Virtual Network Labs (commonly referred to as "NetLab" or "Virtual Network Lab") are an ideal approach for teaching these concepts, allowing us to simulate complex network environments and experiment without risks.
I would like to share with you how my "NetLabs" work, which will be regularly linked to documentary articles (in the category: **documentation**). They will allow us to practice, observe, or understand the operation of concepts explained theoretically beforehand.
In the context of NetLabs, they will primarily be deployed via the ContainerLab tool. For more complex architectures, we will use GNS3.
## What is ContainerLab? 🛠️
ContainerLab is a powerful open-source tool that enables the creation of complete virtual network labs. By using it, one can simulate a multitude of complex network architectures, with equipment such as routers, switches, servers, and other network devices.
This platform offers great flexibility in designing exercises, allowing the exploration of various topics such as learning network protocols, security, or configuring equipment. Users can thus focus on analysis and problem-solving without worrying about the underlying technical details.
The installation of ContainerLab will not be presented here, but all information is available on the official website [here](https://containerlab.dev/install/).
## What is GNS3? 💻
GNS3, or Graphical Network Simulator-3, is an open-source software primarily used for the **simulation** and **emulation** of computer networks. It allows network engineers, students, and professionals to design, test, and troubleshoot complex networks in a virtual environment before deploying them in the real world. GNS3 is particularly appreciated for its ability to integrate various network hardware and software, such as Cisco routers and switches, as well as virtual machines to create realistic network topologies.
As previously mentioned, the installation of GNS3 will not be discussed here. For more information, the documentation is available [here](https://docs.gns3.com/docs/).
## GNS3 vs ContainerLab ⚔️
GNS3 and ContainerLab are two powerful tools for network simulation and emulation, but they differ in their approach, features, and primary use cases. Here is a quick comparison between the two:
### GNS3
**Advantages:**
1. **Intuitive Graphical Interface:** GNS3 offers a user-friendly graphical interface that allows users to drag and drop components to create network topologies.
2. **Multivendor Support:** It supports a wide range of network hardware and software, including Cisco routers and switches, as well as virtual machines.
3. **Flexibility:** GNS3 can be used on Windows, macOS, and Linux, and it integrates well with other tools like Wireshark for traffic analysis.
4. **Active Community:** A large community of users and developers provides extensive support and a wealth of online resources.
**Disadvantages:**
1. **System Resources:** GNS3 can be resource-intensive, especially when emulating complex devices or large topologies.
2. **Configuration Complexity:** The initial setup can be complex, particularly for new users.
### ContainerLab
**Advantages:**
1. **Lightweight and Performance:** ContainerLab uses containers to emulate network devices, making it more lightweight and performant than solutions based on virtual machines.
2. **Automation and DevOps:** It integrates well with DevOps and automation tools like Ansible, facilitating automated deployment and network management.
3. **Simplified Configuration:** Topologies are defined via YAML files, making the configuration simpler and scriptable.
4. **Support for Modern Technologies:** It supports modern technologies like Docker and Kubernetes, offering greater flexibility for cloud-native environments.
**Disadvantages:**
1. **Less Multivendor Support:** Although ContainerLab supports several types of network containers, it may not have the same level of multivendor support as GNS3.
2. **Learning Curve:** For those unfamiliar with containerization concepts, the learning curve can be steeper.
## Conclusion 📊
**GNS3** is ideal for those looking for an intuitive graphical interface and broad support for network devices, particularly useful for students and traditional network engineers. **ContainerLab**, on the other hand, is more suited to modern environments and DevOps practices, offering a lightweight and scriptable solution for network simulation.
The choice between GNS3 and ContainerLab thus primarily depends on the specific needs of the user in terms of flexibility, performance, and integration with other tools and technologies.

4
content/netlab/vxlan_automation/Site Standard.drawio.svg Normal file
View File

File diff suppressed because one or more lines are too long
Side by Side

After

Width:  |  Height:  |  Size: 93 KiB

228
content/netlab/vxlan_automation/_index.fr.md Normal file
View File

@@ -0,0 +1,228 @@
---
title: Automatisation VXLAN avec Netbox
draft: true
date: 2025-04-02T20:00:00+02:00
weight: 3
cascade:
type: docs
---
## Introduction 📚
Dans cet article, nous allons explorer comment automatiser le déploiement d'une infrastructure VXLAN en nous appuyant sur **Netbox** comme source unique de vérité (*Source of Truth*) et sa fonctionnalité de **"Render Config"**.
L'idée principale de ce projet est de simplifier la gestion des configurations réseau en limitant le recours à des outils d'orchestration externes, qui peuvent parfois complexifier la gestion des inventaires. Nous allons démontrer comment Netbox peut générer automatiquement les configurations de nos équipements réseau à partir de modèles Jinja2, à condition de respecter un principe fondamental : **la standardisation de notre infrastructure.** 💡
Pour illustrer cette approche, nous allons prendre l'exemple d'un site fictif, **"Paris"**, conçu selon des règles de standardisation claires et précises. Cette normalisation nous permettra de :
1. **Modéliser** l'ensemble de l'infrastructure du site "Paris" dans Netbox (bâtiments, clients, fabric).
2. **Générer** les configurations des équipements réseau en se basant sur les informations centralisées dans Netbox.
3. **Valider** le bon fonctionnement de cette infrastructure automatisée à l'aide d'un environnement de laboratoire **NetLab** sous ContainerLab.
À travers cet exemple concret, nous mettrons en lumière que la standardisation n'est pas une contrainte, mais plutôt le **socle indispensable** pour une automatisation réussie et une gestion réseau simplifiée et efficace.
Alors, prêt à découvrir comment la standardisation ouvre la voie à une automatisation intelligente de votre réseau VXLAN avec Netbox ? C'est parti ! 🚀😊
> [!NOTE] **CookBook**
> L'ensemble des actions décrites dans cet article sont expliqués [ici](https://github.com/darnodo/projet-vxlan-automation/blob/dev/documentation/CookBook.md#-apply-templates)
> Cette article nous fournira pas un guide étape par étape, mais fournira le lien vers le Cookbook qui lui, le fourni.
## Le Concept du Site Standardisé ⚙️
L'automatisation efficace d'une infrastructure réseau repose sur une base solide de standardisation. Pour illustrer ce principe, nous avons défini un modèle de **site standard**, caractérisé par une structure et des règles de connectivité précises. Notre site "Paris" sera une instance concrète de ce modèle standardisé.
### Structure Type d'un Site Standard 🏢
Un site standard est défini par les éléments suivants :
* **Une Salle Serveur Centrale :** Unique au sein du site, elle héberge les deux spines de la fabric (Spine 1 et Spine 2), constituant le cœur de l'infrastructure réseau.
* **Un à Cinq Bâtiments Plain-Pied :** Chaque bâtiment est dédié à l'hébergement d'un seul client (bien que des clients puissent être répartis sur plusieurs bâtiments). Chaque bâtiment standard est équipé d'un switch d'accès pour la connectivité locale et d'un unique leaf pour la connexion à la fabric.
### Connectivité Standard des Leafs 🔗
Dans un site standard, la connexion des équipements leaf aux spines suit les règles suivantes :
* **Interface Eth1 du Leaf :** Systématiquement connectée à l'interface Eth1 du Spine 1.
* **Interface Eth2 du Leaf :** Systématiquement connectée à l'interface Eth2 du Spine 2.
* **Interface Eth3 du Leaf :** Systématiquement dédiée à la connexion au switch d'accès présent dans le même bâtiment.
![Site Standard](<Site Standard.drawio.svg>)
> [!NOTE] Simplification pour le POC
> Pour les besoins de ce Proof of Concept, nous avons opté pour une architecture simplifiée sans redondance avancée au niveau des connexions leaf-spine.
> L'objectif principal est de démontrer l'automatisation basée sur cette structure standardisée.
### Plan d'Adressage IP pour le Site "Paris" 🌐
Pour notre site "Paris", nous allons utiliser les conteneurs de préfixes Netbox suivants, qui s'inscrivent dans notre stratégie d'adressage globale :
* **Location :**
* Région : Europe
* Ville : Paris
* **Conteneurs de Préfixes :**
* **UnderlayContainer (Paris) :**
* CIDR : `172.16.0.0/16`
* Description : "Préfixe conteneur pour le réseau Underlay du site de Paris"
* **LoopbackContainer (Paris) :**
* CIDR : `192.168.100.0/24`
* Description : "Préfixe conteneur pour les adresses Loopback des équipements du site de Paris"
* **CustomersContainer (Paris) :**
* CIDR : `10.0.0.0/8`
* Description : "Préfixe conteneur pour l'adressage des clients du site de Paris"
Ces conteneurs de préfixes sont spécifiques au site de "Paris" et seront utilisés par nos scripts d'automatisation pour attribuer les adresses IP aux différents équipements et clients de ce site, en respectant la structure standard que nous avons définie.
## Le Site "Paris" : Une Instance de Notre Modèle Standardisé 📍
Notre site "Paris" suit scrupuleusement la structure et les règles définies dans notre modèle de site standard. Il comprendra donc une salle serveur avec les deux spines et pourra accueillir jusqu'à cinq bâtiments plain-pied, chacun équipé d'un leaf et d'un switch d'accès, connectés selon les conventions établies. L'adressage IP de "Paris" sera issu des conteneurs de préfixes standard que nous avons définis.
Cette standardisation est la clé qui nous permettra d'automatiser la création et la configuration de l'infrastructure de notre site "Paris" à l'aide des scripts que nous allons présenter ensuite.
## Environment de test
Le POC se jouera sur ContainerLab, il est donc necessaire de se reférencer à [cette article](../../documentation/devpod) afin de facilement reproduire l'installation et les outils.
Nous utiliserons :
* ContainerLab
* Arista cEOS pour la partie Switch/routeur
* Netbox
* Plugin : netbox_topology_views
Pour plus de détails, [voici la documentationation d'installation](https://github.com/darnodo/projet-vxlan-automation/blob/dev/documentation/INSTALLATION.md)
## Scripting : L'Automatisation en Action ! ⚙️
Maintenant, on entre dans le vif du sujet : comment on utilise des scripts pour automatiser la création de notre fabric VXLAN en s'appuyant sur Netbox. On va voir deux scripts principaux qui font le gros du boulot !
### Étape 1 : On Prépare Netbox avec `import.py` 🛠️
Avant de construire notre réseau, il faut préparer notre "Source of Truth", Netbox. Le script [`import.py`](https://github.com/darnodo/projet-vxlan-automation/blob/dev/documentation/CookBook.md#-populate-netbox) est là pour ça ! Il va injecter dans Netbox les infos de base de notre site "Paris" et les modèles de nos équipements.
**Les Ingrédients du Script :**
* **[`Devices/devices_model.yml`](https://github.com/darnodo/projet-vxlan-automation/blob/dev/utilities/Devices/devices_model.yml) :** La carte d'identité de nos équipements (spines, leafs, access cEOS) avec leurs caractéristiques (nombre d'interfaces, types, etc.).
* **[`IPAM/subnet.yml`](https://github.com/darnodo/projet-vxlan-automation/blob/dev/utilities/IPAM/subnets.yml) :** Les infos de notre site "Paris" (région Europe, ville Paris) et les plans de nos blocs d'adresses IP (pour l'underlay, les loopbacks et nos clients).
**Ce Que Fait le Script :**
* Il lit le fichier `devices_model.yml` et crée les modèles d'équipements correspondants dans Netbox. C'est comme enregistrer les types de matériel qu'on va utiliser.
* Il lit le fichier `IPAM/subnet.yml` et crée :
* La région "Europe" et le site "Paris".
* Les gros blocs d'adresses IP qu'on va utiliser pour notre réseau à Paris (nos "conteneurs de préfixes").
**Comment on Lance la Machine :**
On ouvre notre terminal et on tape la commande :
```bash
uv run import.py http://localhost:8080 YOUR_TOKEN Devices/devices_model.yml IPAM/subnet.yml
```
Remplace bien `http://localhost:8080` par l'adresse de ton Netbox et `YOUR_TOKEN` par ton jeton d'API Netbox ! Une fois lancé, ce script met en place les fondations de notre automatisation.
> [!TIP]
> Lien vers le Cookbook [ici](https://github.com/darnodo/projet-vxlan-automation/blob/dev/documentation/CookBook.md#-populate-netbox)
### Étape 2 : On Monte la Fabric VXLAN avec `Create_Fabric/main.py` 🚀
Maintenant que Netbox est prêt, on passe à la construction de notre réseau avec le script `Create_Fabric/main.py`. Ce script va créer tous les équipements, les connecter et leur attribuer des adresses IP, le tout en suivant notre modèle standardisé pour le site "Paris".
**Les Étapes du Script :**
1. **Vérification des Prêts ? ✅** Le script commence par vérifier si tout ce dont il a besoin existe dans Netbox (les rôles des équipements, les rôles IP, les types d'équipements). On ne veut pas commencer à construire sur des bases instables !
2. **Choix du Terrain : "Paris" Évidemment ! 🇫🇷** Le script nous demande sur quel site on travaille. On sélectionne "Paris", notre site standard. Son petit nom "PA" va servir de base pour nommer nos équipements.
3. **On Sort les Spines (x2) 💪** Le script crée nos deux spines dans Netbox, en utilisant le bon modèle et le rôle "spine". Ils sont baptisés `padc_sp1_00` et `padc_sp2_00`.
4. **Les Paires Leaf/Access par Bâtiment 🏢➡️** Pour chaque bâtiment de "Paris" (jusqu'à 5), le script crée une "location" Netbox et y installe un leaf (par exemple `pa01_lf1_00`) et un switch d'accès (par exemple `pa01_sw1_00`).
5. **Câblage Automatique 🧶** Le script connecte virtuellement les équipements dans Netbox en suivant nos règles : `Eth1` du leaf vers `Eth*n*` du Spine 1, `Eth2` du leaf vers `Eth*n*` du Spine 2, et `Eth3` du leaf vers `Eth1` de l'access switch. Plus besoin de s'embrouiller avec les câbles !
6. **Distribution des IPs 🗺️** Le script pioche dans les blocs d'adresses IP de "Paris" et attribue automatiquement les IPs aux interfaces (des /31 pour les liens entre les équipements et des /32 pour les loopbacks).
7. **Attribution des ASNs 🏷️** Pour finir, le script donne un numéro d'AS à chaque spine et à chaque leaf pour le routage BGP. Ces numéros sont enregistrés dans un champ spécial "ASN" dans Netbox.
```bash
uv run Create_Fabric/main.py
NetBox URL: http://localhost:8080
NetBox API Token:
Number of buildings (1-5): 4
Spine device type slug: ceos
Leaf device type slug: ceos
Access switch device type slug: ceos
Existing Sites:
1. Paris (slug=paris)
Choose site number or 'new': 1
```
**Le Résultat ? 🎉** En lançant ce script, on se retrouve avec toute notre infrastructure VXLAN de "Paris" créée et connectée dans Netbox, prête à être configurée ! C'est l'automatisation à son meilleur, rendue possible par notre approche standardisée.
> [!NOTE] Netbox Plugin
> La configuration est facilement visualisable avec l'aide du plugin : [netbox_topology_views](https://github.com/netbox-community/netbox-topology-views)
![Topologie de Paris](fabric_topology.png)
> [!TIP]
> Lien vers le Cookbook [ici](https://github.com/darnodo/projet-vxlan-automation/blob/dev/documentation/CookBook.md#%EF%B8%8F-create-fabric)
### Étape 3 : On configure nos clients avec `Create_Fabric/add_customers.py` 🧑‍💻
A ce niveau, la fabric est fonctionnelle, mais aucun client n'est configuré, mais qu'est-ce que ça veut dire !! 🙋
## La Magie des Templates : Netbox et Jinja2 Entrent en Scène ✨
Maintenant qu'on a notre inventaire réseau au top dans Netbox, comment on dit à nos équipements comment se configurer ? C'est là qu'interviennent les **Render Config** et les **templates Jinja2** !
### Les Templates Jinja : Nos Recettes de Configuration 📝
1. **Les Render Config, Késako ? 🤔** Imagine Netbox comme un chef cuisinier qui a tous les ingrédients (nos équipements, leurs interfaces, leurs IPs, etc.). Les Render Config, c'est sa manière de transformer ces ingrédients en plats préparés, c'est-à-dire des fichiers de configuration pour nos équipements réseau.
2. **Jinja2 : Notre Langage de Recettes 🗣️** Pour écrire ces "recettes" de configuration, Netbox utilise un moteur super puissant appelé Jinja2. C'est un peu comme un langage de programmation simple qui nous permet de créer des modèles de configuration dynamiques. On peut y mettre des "trous" (des variables) qui seront remplis par les informations de nos équipements dans Netbox.
3. **Un Petit Coup d'Œil à une Recette 📜** Prenons un exemple de template Jinja2 pour un de nos leafs :
```jinja
hostname {{ device.name }}
{% if device.custom_fields.ASN %}
router bgp {{ device.custom_fields.ASN }}
router-id {{ device.primary_ip4.address.split('/')[0] }}
{% endif %}
interface Loopback0
ip address {{ device.primary_ip4.address }}
{% for interface in device.interfaces %}
interface {{ interface.name }}
description {{ interface.description }}
{% if interface.connected_interface %}
no shutdown
{% endif %}
{% endfor %}
```
Vous voyez les trucs entre doubles accolades `{{ ... }}` ? Ce sont nos variables ! Par exemple, `{{ device.name }}` sera remplacé par le nom de notre leaf, et `{{ interface.name }}` par le nom de chaque interface. On peut même faire des conditions (`{% if ... %}`) et des boucles (`{% for ... %}`) pour adapter la configuration.
4. **Comment Netbox Prépare le Plat 🍳** Quand on demande à Netbox de générer la configuration pour un équipement (disons, notre `pa01_lf1_00`), voici ce qu'il se passe :
* Il va chercher toutes les infos sur ce leaf : son nom, ses interfaces, ses IPs, ses connexions, son ASN, etc.
* Il prend le template Jinja2 qu'on a associé au rôle "leaf".
* Il remplit tous les "trous" (les variables Jinja2) du template avec les infos spécifiques de notre `pa01_lf1_00`.
* Et hop ! Il nous sort un fichier de configuration texte prêt à être utilisé.
> [!TIP]
> Lien vers le Cookbook [ici](https://github.com/darnodo/projet-vxlan-automation/blob/dev/documentation/CookBook.md#-apply-templates)
### De Netbox au Lab : On Regarde et On Fait à la Main pour l'Instant 🖥️➡️💻
Maintenant qu'on sait comment Netbox génère les configurations, voyons comment on les utilise dans notre lab Containerlab.
1. **On Jette un Œil à la Configuration dans Netbox 👀** Pour voir la configuration générée par Netbox pour un équipement, c'est simple :
* Dans l'interface de Netbox, on va dans **Devices**.
* On clique sur l'équipement qui nous intéresse (par exemple, un de nos leafs).
* Et là, on a un onglet magique : **Render Config** ! En cliquant dessus, on voit la configuration que Netbox a générée pour cet équipement en utilisant le template Jinja2 et ses propres données.
2. **La Touche Humaine dans Containerlab 🖐️** Pour l'instant, on n'a pas de script qui envoie automatiquement ces configurations à nos équipements cEOS dans Containerlab. Donc, on va faire à l'ancienne (mais c'est pour la démo !) :
* On se connecte à chaque équipement cEOS de notre lab via SSH (par exemple, en utilisant l'extension VSCode Containerlab comme on l'a vu dans le cookbook).
* On copie la configuration qu'on a visualisée dans Netbox (l'onglet **Render Config**).
* Et on la colle dans l'interface de ligne de commande de l'équipement cEOS (en mode configuration, bien sûr !).
3. **Et Après ? Les Perspectives d'Évolution 🚀** Bien sûr, cette étape de copier-coller, c'est pas le top de l'automatisation ! Mais c'est une première étape pour voir comment Netbox peut être notre cerveau central. Dans le futur, on pourrait imaginer des outils comme Ansible ou NAPALM qui se connecteraient à Netbox, récupéreraient ces configurations générées et les appliqueraient automatiquement à nos équipements. C'est une piste pour de prochaines aventures dans l'automatisation ! 😉

BIN
content/netlab/vxlan_automation/fabric_topology.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 105 KiB