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

Add bilingual French/English support with Hugo multilingual config

Browse Source 
Configure Hugo multilingual mode (fr default, en secondary) with
Hextra's language-switch menu entry, and translate all existing
content pages to English using Hugo's per-file language suffix
convention (.en.md alongside .fr.md).
This commit is contained in:
Damien
2026-07-18 09:48:18 +02:00
parent a4cffd8916
commit f49c0f45dd
20 changed files with 2706 additions and 2 deletions
Download Patch File Download Diff File Expand all files Collapse all files

16
content/netlab/_index.en.md Normal file
View File

@@ -0,0 +1,16 @@
---
title: "Netlab"
cascade:
type: docs
---
<!-- markdownlint-disable MD033 MD034-->
{{< hextra/hero-subtitle >}}
A deep dive into NetLabs
{{< /hextra/hero-subtitle >}}
{{< cards >}}
{{< card link="/en/netlab/netlab/" title="What is a Netlab?" subtitle="Why and how we use NetLab" icon="science" >}}
{{< card link="/en/netlab/first_lab/" title="My First NetLab" subtitle="How to deploy a NetLab using DevPod" icon="docker" >}}
{{< /cards >}}

13
content/netlab/automatisation réseau/_index.en.md Normal file
View File

@@ -0,0 +1,13 @@
---
title: "Network Automation"
sidebar:
open: true
cascade:
type: docs
---
<!-- markdownlint-disable MD033 MD034-->
{{< cards >}}
{{< card link="/en/netlab/automatisation-réseau/vxlan_automation/" title="VXLAN Automation with Netbox" subtitle="How to use Netbox to automate network configuration" icon="science" >}}
{{< /cards >}}

326
content/netlab/automatisation réseau/vxlan_automation/_index.en.md Normal file
View File

@@ -0,0 +1,326 @@
---
title: VXLAN Automation with Netbox
date: 2025-04-02T20:00:00+02:00
weight: 3
cascade:
type: docs
---
## 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.** 💡
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:
1. **Model** the entire "Paris" site infrastructure in Netbox (buildings, customers, fabric).
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.
> [!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 ⚙️
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 🏢
A standard site is defined by the following elements:
* **A Central Server Room:** Unique within the site, it hosts the fabric's two spines (Spine 1 and Spine 2), forming the core of the network infrastructure.
* **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 🔗
In a standard site, the connection of leaf devices to the spines follows these rules:
* **Leaf Eth1 Interface:** Always connected to the Spine 1 Eth1 interface.
* **Leaf Eth2 Interface:** Always connected to the Spine 2 Eth2 interface.
* **Leaf Eth3 Interface:** Always dedicated to connecting to the access switch present in the same building.
![Site Standard](<Site Standard.drawio.svg>)
> [!NOTE] Simplification for the POC
> 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 🌐
For our "Paris" site, we'll use the following Netbox prefix containers, which fit into our overall addressing strategy:
* **Location:**
* Region: Europe
* City: Paris
* **Prefix Containers:**
* **UnderlayContainer (Paris):**
* CIDR: `172.16.0.0/16`
* Description: "Container prefix for the Underlay network of the Paris site"
* **LoopbackContainer (Paris):**
* CIDR: `192.168.100.0/24`
* Description: "Container prefix for Loopback addresses of devices at the Paris site"
* **CustomersContainer (Paris):**
* CIDR: `10.0.0.0/8`
* Description: "Container prefix for customer addressing at the Paris site"
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 📍
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
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.
We'll be using:
* ContainerLab
* Arista cEOS for the switch/router part
* Netbox
* Plugin: netbox_topology_views
For more details, [here's the installation documentation](https://github.com/darnodo/projet-vxlan-automation/blob/dev/documentation/INSTALLATION.md)
## 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` 🛠️
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.
**The Script's Ingredients:**
* **[`Devices/devices_model.yml`](https://github.com/darnodo/projet-vxlan-automation/blob/dev/utilities/Devices/devices_model.yml):** The ID card for our devices (spines, leafs, access cEOS) with their characteristics (number of interfaces, types, etc.).
* **[`IPAM/subnet.yml`](https://github.com/darnodo/projet-vxlan-automation/blob/dev/utilities/IPAM/subnets.yml):** The information for our "Paris" site (Europe region, city of Paris) and the plans for our IP address blocks (for the underlay, loopbacks, and our customers).
**What the Script Does:**
* It reads the `devices_model.yml` file and creates the corresponding device types in Netbox. It's like registering the types of hardware we're going to use.
* It reads the `IPAM/subnet.yml` file and creates:
* The "Europe" region and the "Paris" site.
* The IP address blocks we'll use for our network in Paris (our "container prefixes").
**How to Fire Up the Machine:**
Open a terminal and type the command:
```bash
uv run import.py http://localhost:8080 YOUR_TOKEN Devices/devices_model.yml IPAM/subnet.yml
```
Make sure to replace `http://localhost:8080` with your Netbox address and `YOUR_TOKEN` with your Netbox API token! Once launched, this script lays the foundations of our automation.
> [!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` 🚀
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.
```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
```
**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)
![Topologie de Paris](fabric_topology.png)
> [!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` 🧑‍💻
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). 🏢➡️🧑‍💻
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
Enter NetBox URL: http://localhost:8080
Enter NetBox API Token: 4e58e40e6b19d7f6cc53ae5665ca7ddd00558e71
Enter Customer Name: Orange
Enter VLAN ID (1-4094): 10
Enter VNI ID: 10010
Available Locations:
0: PA1
1: PA2
2: PA3
3: PA4
Select locations (comma-separated indices): 0,2
❯ uv run Create_Fabric/add_customers.py
Enter NetBox URL: http://localhost:8080
Enter NetBox API Token: 4e58e40e6b19d7f6cc53ae5665ca7ddd00558e71
Enter Customer Name: Purple
Enter VLAN ID (1-4094): 10
Enter VNI ID: 10010
Available Locations:
0: PA1
1: PA2
2: PA3
3: PA4
Select locations (comma-separated indices): 1,3
```
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.
* Allocation of a /24 prefix for the customer's IP addressing.
* 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. ⚙️
## The Magic of Templates: Netbox and Jinja2 Take the Stage ✨
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 📝
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.
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 }}
{% 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 %}
```
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:
* 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.
* It fills in all the "holes" (the Jinja2 variables) in the template with the specific information for our `pa01_lf1_00`.
* And there you go! It produces a text configuration file ready to be used.
> [!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 🖥️➡️💻
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:
* In the Netbox interface, go to **Devices**.
* Click on the device you're interested in (for example, one of our leafs).
* And there we have a magic tab: **Render Config**! Clicking on it shows the configuration Netbox generated for this device using the Jinja2 template and its own data.
![PA01 Leaf Configuration](<Render Config.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!):
* 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! 😉
## Validating Communication ✅
### 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:
* Subnet: 10.0.0.0/24
* Hosts:
* PA1: 10.0.0.10
* PA3: 10.0.0.20
2. 🟣 Purple
* Subnet: 10.0.1.0/24
* Hosts:
* PA2: 10.0.1.10
* PA4: 10.0.1.20
A simple "ping" lets us validate connectivity between the 2 sites:
```bash
/ # ifconfig eth1
eth1 Link encap:Ethernet HWaddr AA:C1:AB:49:55:B6
inet addr:10.0.0.10 Bcast:0.0.0.0 Mask:255.255.255.0
...
/ # ping 10.0.0.20
PING 10.0.0.20 (10.0.0.20): 56 data bytes
64 bytes from 10.0.0.20: seq=0 ttl=64 time=15.378 ms
64 bytes from 10.0.0.20: seq=1 ttl=64 time=4.349 ms
...
```
### 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-)
And then, via VSCode, it's possible to launch Wireshark directly:
![Extension vscode](leaf1_capture_eth1.png)
![Capture Wireshark](wireshark_eth2_leaf1.png)
## 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.
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. 🚀💪

219
content/netlab/first_lab/_index.en.md Normal file
View File

@@ -0,0 +1,219 @@
---
title: "My First Lab"
date: 2025-02-14T12:00:00+02:00
weight: 2
sidebar:
open: true
cascade:
type: docs
---
## Introduction 📚
In this article, we're going to explore how to set up our very first Containerlab netlab using **DevPod**.
We'll focus on using a cloud provider, in this case **AWS**, to host our project.
Why the **Cloud**? Because network labs can consume a huge amount of resources, and we need to be able to deploy, stop, and destroy them quickly, both for performance and cost efficiency. 💡💰
We'll achieve this by combining:
- **DevPod**
- **DevContainer**
- **Containerlab**
In addition, we'll use a simple topology that you can find on my [GitHub repository](https://github.com/darnodo/VXLAN-EVPN). Our main goal is to deploy this lab on AWS with DevPod.
Let's get to it! 🚀😊
## Prerequisites 🔧
Before starting, a few important steps need to be taken:
1. **AWS Environment Authorization**:
Make sure DevPod is authorized to access your AWS environment. For a detailed guide on configuring DevPod with AWS, check out my article on this [topic](../../documentation/devpod/). 🔑
2. **Containerlab Topology**:
We need a topology file that Containerlab can understand. In our case, we'll create a simple VXLAN topology. 🗺️
## Containerlab Topology 🔄
Our lab will simulate a VXLAN topology consisting of:
- **1 Spine switch**
- **2 Leaf switches**
- **2 Host nodes**
The following diagram illustrates the VXLAN topology:
![VXLAN Topology](VXLAN.fr.svg#center)
Here's the Containerlab topology file (`lab_vxlan.yml`) used for this configuration:
```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 name of the lab.
- The topology is split 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 using 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 datacenters to enable Layer 2 and Layer 3 connectivity with VXLAN EVPN configurations. 🔗💻
## Deploying the Lab 🛠️
We'll deploy the lab with **DevPod** in two ways:
### 1. Using the Repository 📥
1. **Validate the AWS Provider Configuration**:
Make sure your AWS provider is properly configured. More details [here](../../documentation/devpod/). ✅
2. **Create a Workspace**:
- Go to the **Workspace** tab and click **Create Workspace**.
- Specify the **Workspace source**: use the [GitHub repository](https://github.com/darnodo/VXLAN-EVPN).
- Select **AWS** as the provider.
- Choose your default IDE.
- Finally, click **Create Workspace**.
![DevPod Configuration](devpod_configuration.fr.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.fr.png#center)
## Starting the Lab 🎬
> [!WARNING] cEOS Images
> The lab uses **cEOS image v4.32.0.1F**.
> To download this image, head over to the [Arista download page](https://www.arista.com/en/support/software-download). ⚠️
1. **Import the cEOS Image**:
Save the cEOS image into 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 instructions to configure your devices. For detailed configuration steps, check out [this guide](https://github.com/darnodo/VXLAN-EVPN/tree/main/documentation/eos_configuration). 🔧🖥️
3. **Visualize the Architecture**:
Check the deployed topology using Containerlab's graphical view:
```bash
containerlab graph -t lab_vxlan.yml
```
Ports (for example, port 50080 mentioned in `devcontainer.json`) are forwarded. Access the graphical view via [localhost](http://localhost:50080).
![Graph View](Graph_view.fr.png#center)
## Using EdgeShark 🦈
EdgeShark is a web tool that lets you capture packets from your lab environment. It forwards lab captures to Wireshark running locally. 📡🔍
For more information, check out the [EdgeShark getting started guide](https://edgeshark.siemens.io/#/getting-started?id=optional-capture-plugin).
### Configuring EdgeShark in the DevContainer 🐳
In the **DevContainer** configuration, the following `postCreateCommand` was 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 make it easier to use EdgeShark. 🚀
### Launching EdgeShark ⚡
To start EdgeShark, run:
```bash
cd /opt/edgeshark
DOCKER_DEFAULT_PLATFORM= docker compose up -d
```
Access EdgeShark via [localhost:5001](http://localhost:5001).
- **EdgeShark View**:
![EdgeShark View](edgeshark.fr.png#center)
- **Integration with Wireshark**:
By clicking the Wireshark icon in EdgeShark, you can launch Wireshark locally.
![EdgeShark Interface](edgeshark_interface.fr.png#center)
![EdgeShark and Wireshark](edge_wireshark.fr.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 the prerequisites** for AWS and Containerlab. 🔑
- **Creating a detailed topology file** for a spine-leaf architecture. 🗺️
- **Deploying the lab** using both a GitHub repository and a local folder. 📥🗂️
- **Starting the lab** with Docker and Containerlab. 🚀🐳
- **Using EdgeShark** to capture packets and integrate Wireshark for in-depth analysis. 🦈🔍
By following these steps, you'll be able to easily deploy and manage a scalable network lab environment in the cloud. Happy networking, and enjoy your lab adventures! 😄🎊

68
content/netlab/netlab.en.md Normal file
View File

@@ -0,0 +1,68 @@
---
title: "Introducing NetLabs"
weight: 1
cascade:
type: docs
---
## Introduction
📡 In a world where computer networks play an ever-growing role in our daily lives, understanding the principles and logic that drive them is becoming increasingly essential.
Virtual network labs (also known as "NetLab" or "Virtual Network Lab") are an ideal approach to teaching these concepts, allowing us to simulate complex network environments and experiment risk-free.
I want to share with you how my "NetLabs" work, which will regularly be linked to documentation articles (in the **documentation** category). They will let us practice, observe, or understand the workings of concepts explained theoretically beforehand.
As part of NetLab, these will mainly be deployed using the ContainerLab tool. For more complex architectures, we'll use GNS3.
## What is ContainerLab? 🛠️
ContainerLab is a powerful open-source tool that enables the creation of complete virtual network labs. With it, you 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, making it possible to cover various topics such as learning network protocols, security, or device configuration. Users can therefore focus on analyzing and solving problems without worrying about the underlying technical details.
Installing ContainerLab won't be covered here, but all the information is available on the official website [here](https://containerlab.dev/install/).
## What is GNS3? 💻
GNS3, or Graphical Network Simulator-3, is open-source software mainly 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 before, installing GNS3 won't be covered 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 main use cases. Here's a quick comparison between the two:
### GNS3
**Advantages:**
1. **Intuitive Graphical Interface:** GNS3 offers a user-friendly graphical interface that lets users drag and drop components to build 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.
**Drawbacks:**
1. **System Resources:** GNS3 can be resource-intensive, especially when emulating complex devices or large topologies.
2. **Configuration Complexity:** Initial setup can be complex, especially for new users.
### ContainerLab
**Advantages:**
1. **Lightweight and Performant:** ContainerLab uses containers to emulate network devices, making it lighter and more performant than VM-based solutions.
2. **Automation and DevOps:** It integrates well with DevOps and automation tools like Ansible, making automated deployment and network management easier.
3. **Simplified Configuration:** Topologies are defined via YAML files, making configuration simpler and scriptable.
4. **Support for Modern Technologies:** It supports modern technologies like Docker and Kubernetes, offering greater flexibility for cloud-native environments.
**Drawbacks:**
1. **Less Multivendor Support:** While 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 device support, particularly useful for students and traditional network engineers. **ContainerLab**, on the other hand, is better suited to modern environments and DevOps practices, offering a lightweight and scriptable solution for network simulation.
The choice between GNS3 and ContainerLab therefore mainly depends on the user's specific needs in terms of flexibility, performance, and integration with other tools and technologies.

13
content/netlab/sécurité/_index.en.md Normal file
View File

@@ -0,0 +1,13 @@
---
title: "Security"
sidebar:
open: true
cascade:
type: docs
---
<!-- markdownlint-disable MD033 MD034-->
{{< cards >}}
{{< card link="/en/netlab/sécurité/stepca/" title="Self-Hosted Certificate Manager" subtitle="Deploy a certificate authority and manage certificates" icon="document-check" >}}
{{< /cards >}}

312
content/netlab/sécurité/stepca.en.md Normal file
View File

@@ -0,0 +1,312 @@
---
title: "Self-Hosted Certificate Manager"
date: 2024-08-01T20:00:00+02:00
weight: 2
cascade:
type: docs
---
## 🔗 Sources
- [📖 Official Documentation](https://smallstep.com/docs/tutorials/)
- [🛠️ Step-CA as a systemd Service](https://angrysysadmins.tech/index.php/2022/09/grassyloki/step-ca-run-as-a-systemd-service/)
- [🔐 Certificate Management with OpenSSL](https://www.golinuxcloud.com/tutorial-pki-certificates-authority-ocsp/)
## 🤖 About Step-CA
Step-CA is a clever toolset developed by Smallstep, a company specializing in secure identity management and certificate automation. 🚀
Its mission? To simplify setting up and managing your own certificate authorities (CAs) with ease and security!
### Key Features
1. **Certificate Authority Management** 🔑
Easily configure and manage your own CAs. Create root and intermediate CAs, issue certificates, and handle revocations like a pro.
2. **Secure Key Management** 🛡️
Follows best practices for securely storing and managing keys, ensuring your cryptographic keys stay protected from unauthorized access.
3. **Automation and Scalability** ⚙️
Ideal for small to large-scale deployments. Take advantage of APIs and integrations that automate certificate issuance, renewal, and revocation for a smooth lifecycle.
4. **Enhanced Security** 🔒
Through the use of modern cryptographic algorithms and protocols, Step-CA supports industry-standard X.509 certificates, providing robust encryption and digital signatures.
5. **Infrastructure Integration** 🌐
Integrates seamlessly with your existing tools and systems. Supports various authentication methods such as username/password, MFA, and external identity providers.
6. **Auditability and Compliance** 📜
With comprehensive logging and auditing capabilities, you can track certificate activity and meet compliance requirements with ease.
7. **Developer-Friendly APIs** 👩‍💻👨‍💻
APIs and SDKs designed for developers make it easy to integrate certificate management into your applications and custom workflows.
**In short:** Step-CA by Smallstep is designed to make certificate authority management both fun and hassle-free. Thanks to its secure, scalable, and user-friendly features, you can easily manage your certificates' lifecycle while protecting your infrastructure!
## 🚀 Installation
### 🔧 Binary Installation
#### 1. Step CLI
```bash
wget https://dl.step.sm/gh-release/cli/docs-cli-install/v0.24.3/step-cli_0.24.3_amd64.deb
sudo dpkg -i step-cli_0.24.3_amd64.deb
```
#### 2. Step-CA
```bash
wget https://dl.step.sm/gh-release/certificates/docs-ca-install/v0.24.1/step-ca_0.24.1_amd64.deb
sudo dpkg -i step-ca_0.24.1_amd64.deb
```
#### 3. Creating a Dedicated User
```bash
adduser adminCA
```
#### Configuration
```bash
$ step ca init --password-file=password.txt
✔ Deployment type: Standalone
What would you like to name your new PKI?
✔ (e.g. Smallstep) : Lab
✔ (e.g. ca.example.com[,10.1.2.3,etc.]) : ca.lab.loc, localhost, 192.168.1.101
What IP and port will your new CA bind to? (:443 will bind to 0.0.0.0:443). 1.101
✔ (e.g. :443 or 127.0.0.1:443) : :443
What would you like to name the CA's first provisioner?
✔ (e.g. you@smallstep.com) : contact@lab.loc
Choose a password for your CA keys and the first provisioner.
✔ [leave empty and we will generate one] :
Generating root certificate... done! 🎉
Generating intermediate certificate... done! 🎊
✔ Root certificate: /home/adminCA/.step/certs/root_ca.crt
✔ Root private key: /home/adminCA/.step/secrets/root_ca_key
✔ Root fingerprint: 7d754397c6897aa87d21e33c64daad7be087dc6fe18bf04627848ae1c8e26a4f
✔ Intermediate certificate: /home/adminCA/.step/certs/intermediate_ca.crt
✔ Intermediate private key: /home/adminCA/.step/secrets/intermediate_ca_key
✔ Database folder: /home/adminCA/.step/db
✔ Default configuration: /home/adminCA/.step/config/defaults.json
✔ Certificate Authority configuration: /home/adminCA/.step/config/ca.json
Your PKI is ready to go. To generate certificates for individual services, see `step help ca`.
💌 **FEEDBACK**
The step utility is not instrumented for usage statistics. It does not contact a central server. Your feedback is, however, extremely valuable! Please consider writing to feedback@smallstep.com, joining GitHub Discussions, or joining us on Discord at [https://u.step.sm/discord](https://u.step.sm/discord).
```
Start Step-CA:
```bash
step-ca .step/config/ca.json
```
#### Enable ACME
```bash
$ step ca provisioner add acme --type ACME
✔ CA Configuration: /home/adminCA/.step/config/ca.json
Success! Your `step-ca` configuration has been updated. To pick up the new configuration, send a SIGHUP (kill -1 <pid>) or restart the step-ca process. 🎉
```
#### Running Step-CA as a systemd Service
Create a file:
```bash
vim /etc/systemd/system/step-ca.service
```
Paste in the following:
```config
[Unit]
Description=step-ca
After=syslog.target network.target
[Service]
User=adminCA
Group=adminCA
ExecStart=/bin/sh -c '/bin/step-ca /home/adminCA/.step/config/ca.json --password-file=/home/step/.step/pwd >> /var/log/step-ca/output.log 2>&1'
Type=simple
Restart=on-failure
RestartSec=10
[Install]
WantedBy=multi-user.target
```
Create the log directory:
```bash
mkdir -p /var/log/step-ca
chown -R adminCA:adminCA /var/log/step-ca
```
Reload the systemd daemon:
```bash
systemctl daemon-reload
systemctl start step-ca.service
```
### 🐳 Docker Installation
```bash
docker run -it -v step:/home/step \
-p 9000:9000 \
-e "DOCKER_STEPCA_INIT_NAME=Lab" \
-e "DOCKER_STEPCA_INIT_DNS_NAMES=caserver.lab.loc,localhost,192.168.1.101" \
-e "DOCKER_STEPCA_INIT_REMOTE_MANAGEMENT=true" \
-e "DOCKER_STEPCA_INIT_ACME=true" \
smallstep/step-ca
```
## 🔑 Accessing the CA from Another Client
> [!NOTE] Adjust the port based on your installation:
>
> - **Binary:** port **443**
> - **Docker:** port **9000**
Install the Step CLI:
```bash
wget https://dl.step.sm/gh-release/cli/docs-cli-install/v0.24.3/step-cli_0.24.3_amd64.deb
sudo dpkg -i step-cli_0.24.3_amd64.deb
```
Initialize your CA:
```bash
step ca bootstrap --ca-url https://caserver.lab.loc:$PORT/ --fingerprint 685059c30eb305db5272a7a199a2b5823624d55c732121ac65c06b0915d3c887
```
> [!TIP] To get the **fingerprint**, simply run:
>
> ```bash
> step certificate fingerprint $(step path)/certs/root_ca.crt
> ```
>
> For Docker, check the container logs.
Example output:
```bash
admin@User:~$ step ca bootstrap --ca-url https://caserver.lab.loc:$PORT --fingerprint 685059c30eb305db5272a7a199a2b5823624d55c732121ac65c06b0915d3c887
The root certificate has been saved in /home/admin/.step/certs/root_ca.crt.
The authority configuration has been saved in /home/admin/.step/config/defaults.json.
```
Install the certificate:
```bash
step certificate install $(step path)/certs/root_ca.crt
```
---
> [!TIP] **Installation on Debian:**
>
> - Copy the individual CRT files (PEM format) into `/usr/local/share/ca-certificates/`
> - The files must be owned by `root:root` with `644` permissions
> - Make sure the `ca-certificates` package is installed (if not, install it)
> - Then, run as root:
>
> ```bash
> # /usr/sbin/update-ca-certificates
> ```
>
> All certificates will be consolidated into: `/etc/ssl/certs/ca-certificates.crt`
---
### 📝 Obtaining a Certificate
```bash
admin@User:~$ step ca certificate nas.lab.loc srv.crt srv.key
✔ Provisioner: contact@lab.loc (JWK) [kid: chyGkrZqp-BGSHUZ8v3jsPipegt2JLcC7y6RPq4OOkU]
Please enter the password to decrypt the provisioner key:
✔ CA: https://caserver.lab.loc:443
✔ Certificate: srv.crt
✔ Private Key: srv.key
```
---
> [!TIP] To perform a health check:
>
> ```bash
> curl https://caserver.lab.loc:443/health -k
> ```
---
You may need to customize the `ca.json` file to increase the minimum certificate validity duration. Here's the directory structure:
```bash
.
|-- certs
| |-- intermediate_ca.crt
| `-- root_ca.crt
|-- config
| |-- ca.json
| `-- defaults.json
|-- db
| |-- 000000.vlog
| |-- 000020.sst
| |-- KEYREGISTRY
| |-- LOCK
| `-- MANIFEST
|-- secrets
| |-- intermediate_ca_key
| |-- password
| `-- root_ca_key
`-- templates
```
Example `ca.json` file:
```json
{
"root": "/home/step/certs/root_ca.crt",
"federatedRoots": null,
"crt": "/home/step/certs/intermediate_ca.crt",
"key": "/home/step/secrets/intermediate_ca_key",
"address": ":9000",
"insecureAddress": "",
"dnsNames": [
"caserver.lab.loc",
"caserver",
"localhost",
"192.168.1.200"
],
"logger": {
"format": "text"
},
"db": {
"type": "badgerv2",
"dataSource": "/home/step/db",
"badgerFileLoadingMode": ""
},
"authority": {
"enableAdmin": true,
"claims": {
"maxTLSCertDuration": "4380h"
}
},
"tls": {
"cipherSuites": [
"TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256",
"TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256"
],
"minVersion": 1.2,
"maxVersion": 1.3,
"renegotiation": false
}
}