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

Update documentation for clarity and consistency
All checks were successful
Build and Deploy Hugo / Deploy Hugo Website (pull_request) Successful in 24s
Details

Browse Source 
Remove emojis and em dash separators
Simplify introductory sentences
Standardize section headings
This commit is contained in:
Damien
2026-07-19 15:09:56 +02:00
parent 0edec585a7
commit 2d8830960b
22 changed files with 485 additions and 553 deletions
Download Patch File Download Diff File Expand all files Collapse all files

92
content/netlab/automatisation réseau/vxlan_automation/_index.en.md
View File

@@ -6,11 +6,11 @@ cascade:
type: docs
---
## Introduction 📚
## Introduction
In this article, we're going to explore how to automate the deployment of a VXLAN infrastructure by relying on **Netbox** as our single source of truth (*Source of Truth*) and its **"Render Config"** feature.
The main idea behind this project is to simplify network configuration management by limiting the use of external orchestration tools, which can sometimes make inventory management more complex. We're going to show how Netbox can automatically generate the configurations for our network devices from Jinja2 templates, provided we respect one fundamental principle: **standardizing our infrastructure.** 💡
The main idea behind this project is to simplify network configuration management by limiting the use of external orchestration tools, which can sometimes make inventory management more complex. We're going to show how Netbox can automatically generate the configurations for our network devices from Jinja2 templates, provided we respect one fundamental principle: **standardizing our infrastructure.**
To illustrate this approach, we'll use the example of a fictional site, **"Paris"**, designed according to clear and precise standardization rules. This standardization will allow us to:
@@ -18,17 +18,17 @@ To illustrate this approach, we'll use the example of a fictional site, **"Paris
2. **Generate** the network device configurations based on the information centralized in Netbox.
3. **Validate** the proper operation of this automated infrastructure using a **NetLab** lab environment running on ContainerLab.
Through this concrete example, we'll highlight the fact that standardization isn't a constraint, but rather the **essential foundation** for successful automation and simplified, efficient network management.
Through this concrete example, we'll show that standardization isn't a constraint, but the foundation for successful automation and simpler, more efficient network management.
> [!NOTE] **CookBook**
> All of the actions explained in this article are described [here](https://github.com/darnodo/projet-vxlan-automation/blob/dev/documentation/CookBook.md#-apply-templates).
> This article will **not** provide a step-by-step guide, but will provide links to the Cookbook, which does.
## The Concept of the Standardized Site ⚙️
## The concept of the standardized site
Effective automation of a network infrastructure relies on a solid foundation of standardization. To illustrate this principle, we've defined a **standard site** model, characterized by a precise structure and precise connectivity rules. Our "Paris" site will be a concrete instance of this standardized model.
### Typical Structure of a Standard Site 🏢
### Typical structure of a standard site
A standard site is defined by the following elements:
@@ -36,7 +36,7 @@ A standard site is defined by the following elements:
* **One to Five Single-Story Buildings:** Each building is dedicated to hosting a single customer (although the same customers can be spread across multiple buildings).
Each standard building is equipped with an access switch for local connectivity and a single leaf for connecting to the fabric.
### Standard Leaf Connectivity 🔗
### Standard leaf connectivity
In a standard site, the connection of leaf devices to the spines follows these rules:
@@ -50,7 +50,7 @@ In a standard site, the connection of leaf devices to the spines follows these r
> For the purposes of this **Proof of Concept**, we opted for a simplified architecture without advanced redundancy at the leaf-spine connection level.
> The main goal is to demonstrate automation based on this standardized structure.
### IP Addressing Plan for the "Paris" Site 🌐
### IP addressing plan for the "Paris" site
For our "Paris" site, we'll use the following Netbox prefix containers, which fit into our overall addressing strategy:
@@ -70,13 +70,13 @@ For our "Paris" site, we'll use the following Netbox prefix containers, which fi
These "Container" type prefixes are specific to the "Paris" site and will be used by our automation scripts to assign IP addresses to the various devices and customers at this site, in accordance with the standard structure we've defined.
## The "Paris" Site: An Instance of Our Standardized Model 📍
## The "Paris" site: an instance of our standardized model
Our "Paris" site strictly follows the structure and rules defined in our standard site model. It will therefore include a server room with the two spines and can host up to five single-story buildings, each equipped with a leaf and an access switch, connected according to the established conventions. The IP addressing for "Paris" will come from the standard prefix containers we've defined.
This standardization is the key that will allow us to automate the creation and configuration of our "Paris" site infrastructure using the scripts we're about to present.
## Test Environment
## Test environment
The POC will run on ContainerLab, so it's necessary to refer to [this article](../../documentation/devpod) to easily reproduce the installation and the tools.
@@ -89,11 +89,11 @@ We'll be using:
For more details, [here's the installation documentation](https://github.com/darnodo/projet-vxlan-automation/blob/dev/documentation/INSTALLATION.md)
## Scripting: Automation in Action! ⚙️
## Scripting: automation in action
Now we get to the heart of the matter: how we use scripts to automate the creation of our VXLAN fabric by relying on Netbox. We'll look at two main scripts that do most of the heavy lifting!
### Step 1: Preparing Netbox with `import.py` 🛠️
### Step 1: preparing Netbox with `import.py`
Before we build our network, we need to prepare our "Source of Truth," Netbox. The [`import.py`](https://github.com/darnodo/projet-vxlan-automation/blob/dev/documentation/CookBook.md#-populate-netbox) script is here for that! It will inject into Netbox the basic information for our "Paris" site and the models for our devices.
@@ -122,19 +122,19 @@ Make sure to replace `http://localhost:8080` with your Netbox address and `YOUR_
> [!TIP]
> Link to the Cookbook [here](https://github.com/darnodo/projet-vxlan-automation/blob/dev/documentation/CookBook.md#-populate-netbox)
### Step 2: Building the VXLAN Fabric with `Create_Fabric/main.py` 🚀
### Step 2: building the VXLAN fabric with `Create_Fabric/main.py`
Now that Netbox is ready, we move on to building our network with the `Create_Fabric/main.py` script. This script will create all the devices, connect them, and assign them IP addresses, all while following our standardized model for the "Paris" site.
**The Script's Steps:**
1. **Ready Check? ✅** The script starts by checking whether everything it needs already exists in Netbox (device roles, IP roles, device types). We don't want to start building on unstable foundations!
2. **Choosing the Site: "Paris" Of Course! 🇫🇷** The script asks us which site we're working on. We select "Paris," our standard site. Its short name "PA" will be used as the base for naming our devices.
3. **Bringing Out the Spines (x2) 💪** The script creates our two spines in Netbox, using the correct model and the "spine" role. They're named `padc_sp1_00` and `padc_sp2_00`.
4. **Leaf/Access Pairs per Building 🏢➡️** For each building in "Paris" (up to 5), the script creates a Netbox "location" and installs a leaf there (e.g. `pa01_lf1_00`) and an access switch (e.g. `pa01_sw1_00`).
5. **Automatic Cabling 🧶** The script virtually connects the devices in Netbox following our rules: `Eth1` of the leaf to `Eth*n*` of Spine 1, `Eth2` of the leaf to `Eth*n*` of Spine 2, and `Eth3` of the leaf to `Eth1` of the access switch. No more getting tangled up with cables!
6. **IP Distribution 🗺️** The script draws from the "Paris" IP address blocks and automatically assigns IPs to interfaces (/31s for the links between devices and /32s for loopbacks).
7. **ASN Assignment 🏷️** Finally, the script assigns an AS number to each spine and each leaf for BGP routing. These numbers are stored in a special "ASN" field in Netbox.
1. **Ready check.** The script starts by checking whether everything it needs already exists in Netbox (device roles, IP roles, device types). We don't want to start building on unstable foundations.
2. **Choosing the site: "Paris" of course.** The script asks us which site we're working on. We select "Paris," our standard site. Its short name "PA" will be used as the base for naming our devices.
3. **Bringing out the spines (x2).** The script creates our two spines in Netbox, using the correct model and the "spine" role. They're named `padc_sp1_00` and `padc_sp2_00`.
4. **Leaf/access pairs per building.** For each building in "Paris" (up to 5), the script creates a Netbox "location" and installs a leaf there (e.g. `pa01_lf1_00`) and an access switch (e.g. `pa01_sw1_00`).
5. **Automatic cabling.** The script virtually connects the devices in Netbox following our rules: `Eth1` of the leaf to `Eth*n*` of Spine 1, `Eth2` of the leaf to `Eth*n*` of Spine 2, and `Eth3` of the leaf to `Eth1` of the access switch. No more getting tangled up with cables.
6. **IP distribution.** The script draws from the "Paris" IP address blocks and automatically assigns IPs to interfaces (/31s for the links between devices and /32s for loopbacks).
7. **ASN assignment.** Finally, the script assigns an AS number to each spine and each leaf for BGP routing. These numbers are stored in a special "ASN" field in Netbox.
```bash
uv run Create_Fabric/main.py
@@ -150,7 +150,7 @@ Existing Sites:
Choose site number or 'new': 1
```
**The Result? 🎉** By running this script, we end up with our entire "Paris" VXLAN infrastructure created and connected in Netbox, ready to be configured!
**The result?** By running this script, we end up with our entire "Paris" VXLAN infrastructure created and connected in Netbox, ready to be configured.
> [!NOTE] Netbox Plugin
> The configuration can easily be visualized with the help of the plugin: [netbox_topology_views](https://github.com/netbox-community/netbox-topology-views)
@@ -160,13 +160,13 @@ Choose site number or 'new': 1
> [!TIP]
> Link to the Cookbook [here](https://github.com/darnodo/projet-vxlan-automation/blob/dev/documentation/CookBook.md#%EF%B8%8F-create-fabric)
### Step 3: Configuring Our Customers with `Create_Fabric/add_customers.py` 🧑‍💻
### Step 3: configuring our customers with `Create_Fabric/add_customers.py`
At this point, the fabric is functional, but no customer is configured yet. What does that mean? 🤔 It means that the *underlay* – the foundation of our network – is configured in Netbox, and it's possible to generate a configuration to deploy BGP and configure the ASes. However, the access switches and leafs aren't ready yet to host users or customer services. There's no information in Netbox that allows for that yet.
At this point, the fabric is functional, but no customer is configured yet. What does that mean? It means that the *underlay* – the foundation of our network – is configured in Netbox, and it's possible to generate a configuration to deploy BGP and configure the ASes. However, the access switches and leafs aren't ready yet to host users or customer services. There's no information in Netbox that allows for that yet.
In our standardized approach, each building is designed to host **one** "customer." A customer could be, for example, a specific team within the company or an external contractor. Each customer will be assigned a VLAN (and, in our VXLAN fabric, a corresponding VNI). 🏢➡️🧑‍💻
In our standardized approach, each building is designed to host **one** "customer." A customer could be, for example, a specific team within the company or an external contractor. Each customer will be assigned a VLAN (and, in our VXLAN fabric, a corresponding VNI).
To perform this customer configuration, we use a dedicated script: **Create_Fabric/add_customers.py**. It will guide us step by step, asking for the VLAN and VNI to assign, as well as the building or buildings where our customers are based. 📋 Here's an example of it running:
To perform this customer configuration, we use a dedicated script: **Create_Fabric/add_customers.py**. It will guide us step by step, asking for the VLAN and VNI to assign, as well as the building or buildings where our customers are based. Here's an example of it running:
```bash
❯ uv run Create_Fabric/add_customers.py
@@ -198,7 +198,7 @@ Available Locations:
Select locations (comma-separated indices): 1,3
```
Once this information is provided, the script takes care of automating several actions in Netbox ✨:
Once this information is provided, the script takes care of automating several actions in Netbox:
* Creation of the tenant (representing the customer).
* Assignment of buildings (locations) to the tenant.
@@ -206,22 +206,22 @@ Once this information is provided, the script takes care of automating several a
* Logical configuration of the associated VXLAN/VLAN elements.
* Assignment of specific interfaces on the access devices for this customer.
Once Netbox is properly populated with all this customer data 📊, it then becomes possible to extract the final, ready-to-use network configuration from it. ⚙️
Once Netbox is properly populated with all this customer data, it then becomes possible to extract the final, ready-to-use network configuration from it.
## The Magic of Templates: Netbox and Jinja2 Take the Stage ✨
## Generating configs with Netbox and Jinja2 templates
Now that we have our network inventory all set up in Netbox, how do we tell our devices how to configure themselves? That's where **Render Config** and **Jinja2 templates** come in!
> [!TIP] Templates
> The templates used are available [here](https://github.com/darnodo/projet-vxlan-automation/tree/dev/templates).
### Jinja Templates: Our Configuration Recipes 📝
### Jinja templates: our configuration recipes
1. **What Are Render Configs, Anyway? 🤔** Imagine Netbox as a chef who has all the ingredients (our devices, their interfaces, their IPs, etc.). Render Configs are its way of turning these ingredients into prepared dishes, meaning configuration files for our network devices.
1. **What are Render Configs, anyway?** Imagine Netbox as a chef who has all the ingredients (our devices, their interfaces, their IPs, etc.). Render Configs are its way of turning these ingredients into prepared dishes, meaning configuration files for our network devices.
2. **Jinja2: Our Recipe Language 🗣️** To write these configuration "recipes," Netbox uses a super powerful engine called Jinja2. It's a bit like a simple programming language that lets us create dynamic configuration templates. We can put "holes" (variables) in them that get filled in with the information from our devices in Netbox.
2. **Jinja2: our recipe language.** To write these configuration "recipes," Netbox uses a powerful engine called Jinja2, a bit like a simple programming language that lets us create dynamic configuration templates. We can put "holes" (variables) in them that get filled in with the information from our devices in Netbox.
3. **A Quick Look at a Recipe 📜** Let's take an example of a Jinja2 template for one of our leafs:
3. **A quick look at a recipe.** Let's take an example of a Jinja2 template for one of our leafs:
```jinja
hostname {{ device.name }}
@@ -242,7 +242,7 @@ Now that we have our network inventory all set up in Netbox, how do we tell our
See those things between double curly braces `{{ ... }}`? Those are our variables! For example, `{{ device.name }}` will be replaced with the name of our leaf, and `{{ interface.name }}` with the name of each interface. We can even add conditions (`{% if ... %}`) and loops (`{% for ... %}`) to adapt the configuration.
4. **How Netbox Prepares the Dish 🍳** When we ask Netbox to generate the configuration for a device (say, our `pa01_lf1_00`), here's what happens:
4. **How Netbox prepares the dish.** When we ask Netbox to generate the configuration for a device (say, our `pa01_lf1_00`), here's what happens:
* It looks up all the information about this leaf: its name, its interfaces, its IPs, its connections, its ASN, etc.
* It takes the Jinja2 template that we've associated with the "leaf" role.
@@ -252,11 +252,11 @@ Now that we have our network inventory all set up in Netbox, how do we tell our
> [!TIP]
> Link to the Cookbook [here](https://github.com/darnodo/projet-vxlan-automation/blob/dev/documentation/CookBook.md#-apply-templates)
### From Netbox to the Lab: Looking and Doing It by Hand for Now 🖥️➡️💻
### From Netbox to the lab: doing it by hand for now
Now that we know how Netbox generates the configurations, let's see how we use them in our Containerlab lab.
1. **Taking a Look at the Configuration in Netbox 👀** To view the configuration generated by Netbox for a device, it's simple:
1. **Taking a look at the configuration in Netbox.** To view the configuration generated by Netbox for a device, it's simple:
* In the Netbox interface, go to **Devices**.
* Click on the device you're interested in (for example, one of our leafs).
@@ -264,27 +264,27 @@ Now that we know how Netbox generates the configurations, let's see how we use t
![PA01 Leaf Configuration](<Render Config.en.png>)
2. **The Human Touch in Containerlab 🖐️** For now, we don't have a script that automatically pushes these configurations to our devices in Containerlab. So we're going to do it the old-fashioned way (but that's fine for a demo!):
2. **The human touch in Containerlab.** For now, we don't have a script that automatically pushes these configurations to our devices in Containerlab. So we're going to do it the old-fashioned way (fine for a demo):
* We connect to each cEOS device in our lab via SSH (for example, using the Containerlab VSCode extension as we saw in the [cookbook](https://github.com/darnodo/projet-vxlan-automation/blob/dev/documentation/CookBook.md#%EF%B8%8F-deploy-configuration)).
* We copy the configuration we viewed in Netbox (the **Render Config** tab).
* And we paste it into the cEOS device's command-line interface (in configuration mode, of course!).
3. **What's Next? Future Perspectives 🚀** Of course, this copy-paste step isn't the pinnacle of automation! But it's a first step toward seeing how Netbox can be our central brain. In the future, we could imagine tools like Ansible or NAPALM connecting to Netbox, retrieving these generated configurations, and automatically applying them to our devices. That's a path for future adventures in automation! 😉
3. **What's next?** This copy-paste step isn't the pinnacle of automation, but it's a first step toward seeing how Netbox can be our central brain. Down the line, tools like Ansible or NAPALM could connect to Netbox, retrieve these generated configurations, and apply them to our devices automatically.
## Validating Communication ✅
## Validating communication
### Ping ⚽
### Ping
In the cookbook, we chose to configure 2 customers each in 2 different buildings, which lets us run a **ping**. As a reminder:
1. 🟠 Orange:
1. Orange:
* Subnet: 10.0.0.0/24
* Hosts:
* PA1: 10.0.0.10
* PA3: 10.0.0.20
2. 🟣 Purple
2. Purple
* Subnet: 10.0.1.0/24
* Hosts:
* PA2: 10.0.1.10
@@ -305,7 +305,7 @@ PING 10.0.0.20 (10.0.0.20): 56 data bytes
...
```
### Packet Capture
### Packet capture
To go further, it's also possible to use Wireshark, which is available by default in the devcontainer, with the help of Edgeshark.
For more information, I'll point you to the article on [My First Lab](../../netlab/first_lab/#utiliser-edgeshark-)
@@ -316,11 +316,9 @@ And then, via VSCode, it's possible to launch Wireshark directly:
![Capture Wireshark](wireshark_eth2_leaf1.en.png)
## Conclusion ✨
## Conclusion
To sum up our journey, we've seen how Netbox becomes our best ally 🥇 for automating the VXLAN network.
The key is to start from **a standardized foundation** 📐 — that's what allows Netbox to generate our configurations almost entirely on its own, thanks to Jinja2 templates.
Netbox turns out to be a solid ally for automating the VXLAN network.
The key is starting from a standardized foundation: that's what lets Netbox generate our configurations almost entirely on its own, using Jinja2 templates.
Even though, for now, we're still doing a bit of copy-pasting 🖐️, the potential is huge! Having all our information centralized in Netbox is the first step toward truly simplifying our network management and opening the door to full automation. Standardization isn't a constraint, but a springboard toward greater efficiency. ✅
This is only the beginning! Think about what comes next: automatically deploying these configs, managing more complex networks... Automation is here, accessible, ready to save you precious time. 🚀💪
We're still copying and pasting the last step by hand, but centralizing all our information in Netbox is the first move toward simplifying network management and opening the door to full automation. Next up: deploying these configs automatically and handling more complex networks.