Hextra theme (#1)
* Adapt theme * Update Contents to match with new theme * chore: few updates * adapt HomePage * Add icons and french version * fix fr homepage * Fix Netlab view * Fix Netlab articles * devpod post * French version of DevPod * my_first_lab
This commit is contained in:
D. Arnodo
5
content/netlab/_index.fr.md
Normal file
5
content/netlab/_index.fr.md
Normal file
@@ -0,0 +1,5 @@
|
||||
---
|
||||
linkTitle: "Netlab"
|
||||
cascade:
|
||||
type: docs
|
||||
---
|
||||
16
content/netlab/_index.md
Normal file
16
content/netlab/_index.md
Normal file
@@ -0,0 +1,16 @@
|
||||
---
|
||||
title: "Netlab"
|
||||
cascade:
|
||||
type: docs
|
||||
---
|
||||
|
||||
<!-- markdownlint-disable MD033 MD034-->
|
||||
|
||||
{{< hextra/hero-subtitle >}}
|
||||
Deep Dive using NetLab
|
||||
{{< /hextra/hero-subtitle >}}
|
||||
|
||||
{{< cards >}}
|
||||
{{< card link="/netlab/netlab/" title="What is a Netlab" subtitle="What and Why we use NetLab" icon="science" >}}
|
||||
{{< card link="/netlab/first_lab/" title="My First Lab" subtitle="How to deploy an NetLab using DevPod" icon="docker" >}}
|
||||
{{< /cards >}}
|
||||
BIN
content/netlab/first_lab/Graph_view.png
Normal file
BIN
content/netlab/first_lab/Graph_view.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 70 KiB |
1
content/netlab/first_lab/VXLAN.svg
Normal file
1
content/netlab/first_lab/VXLAN.svg
Normal file
File diff suppressed because one or more lines are too long
|
After Width: | Height: | Size: 30 KiB |
217
content/netlab/first_lab/_index.fr.md
Normal file
217
content/netlab/first_lab/_index.fr.md
Normal file
@@ -0,0 +1,217 @@
|
||||
---
|
||||
title: "Mon Premier Lab"
|
||||
date: 2025-02-14T12:00:00+02:00
|
||||
weight: 1
|
||||
cascade:
|
||||
type: docs
|
||||
---
|
||||
|
||||
## Introduction 📚
|
||||
|
||||
Dans cet article, nous allons explorer comment installer notre tout premier netlab Containerlab en utilisant **DevPod**.
|
||||
Nous nous concentrerons sur l'utilisation d'un fournisseur cloud, en l'occurrence **AWS**, pour héberger notre projet.
|
||||
Pourquoi le **Cloud** ? Parce que les labs réseau peuvent consommer énormément de ressources, et nous avons besoin de pouvoir les déployer, les arrêter et les détruire rapidement, tant pour la performance que pour l'efficacité financière. 💡💰
|
||||
|
||||
Nous y parviendrons en combinant :
|
||||
|
||||
- **DevPod**
|
||||
- **DevContainer**
|
||||
- **Containerlab**
|
||||
|
||||
De plus, nous utiliserons une topologie simple que vous pouvez retrouver sur mon [dépôt GitHub](https://github.com/darnodo/VXLAN-EVPN). Notre objectif principal est de déployer ce lab sur AWS avec DevPod.
|
||||
Allons-y, c'est parti ! 🚀😊
|
||||
|
||||
## Prérequis 🔧
|
||||
|
||||
Avant de commencer, quelques étapes importantes sont à réaliser :
|
||||
|
||||
1. **Autorisation de l'environnement AWS** :
|
||||
Assurez-vous que DevPod est autorisé à accéder à votre environnement AWS. Pour un guide détaillé sur la configuration de DevPod avec AWS, consultez mon article sur ce [sujet](/documentation/devpod). 🔑
|
||||
|
||||
2. **Topologie Containerlab** :
|
||||
Nous avons besoin d'un fichier de topologie compréhensible par Containerlab. Dans notre cas, nous créons une topologie VXLAN simple. 🗺️
|
||||
|
||||
## Topologie Containerlab 🔄
|
||||
|
||||
Notre lab simulera une topologie VXLAN comprenant :
|
||||
|
||||
- **1 switch Spine**
|
||||
- **2 switches Leaf**
|
||||
- **2 nœuds Host**
|
||||
|
||||
Le diagramme suivant illustre la topologie VXLAN :
|
||||
|
||||
|
||||
|
||||
Voici le fichier de topologie Containerlab (`lab_vxlan.yml`) utilisé pour cette 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"]
|
||||
```
|
||||
|
||||
### Décryptage de la Topologie 🧐
|
||||
|
||||
1. **Nom et Structure** :
|
||||
- `name: vxlan-evpn-irb` – C'est le nom du lab.
|
||||
- La topologie se divise en **nodes** (périphériques) et **links** (connexions entre les périphériques).
|
||||
|
||||
2. **Nodes** :
|
||||
- **Couche Spine** :
|
||||
- `spine1` : Un switch Arista cEOS containerisé utilisant l'image version `4.32.0.1F`.
|
||||
- **IP de gestion** : `172.20.20.101`
|
||||
- **Couche Leaf** :
|
||||
- `leaf1` et `leaf2` : Des switches Arista cEOS utilisant la même version d'image.
|
||||
- **IPs de gestion** : `172.20.20.11` et `172.20.20.12`
|
||||
- **Couche Host** :
|
||||
- `host1` et `host2` : Des conteneurs Linux exécutant Alpine Linux.
|
||||
- Ils incluent des configurations personnalisées pour les interfaces réseau montées depuis l'hôte.
|
||||
- **IPs de gestion** : `172.20.20.21` et `172.20.20.22`
|
||||
|
||||
3. **Links** :
|
||||
- **De Spine à Leaf** :
|
||||
- `spine1:eth1` ↔ `leaf1:eth1`
|
||||
- `spine1:eth2` ↔ `leaf2:eth1`
|
||||
- **De Leaf à Host** :
|
||||
- `leaf1:eth2` ↔ `host1:eth1`
|
||||
- `leaf2:eth2` ↔ `host2:eth1`
|
||||
|
||||
Cette topologie représente une architecture spine-leaf typique, courante dans les datacenters pour permettre une connectivité en couche 2 et en couche 3 avec des configurations VXLAN EVPN. 🔗💻
|
||||
|
||||
## Déployer le Lab 🛠️
|
||||
|
||||
Nous allons déployer le lab avec **DevPod** de deux manières :
|
||||
|
||||
### 1. En Utilisant le Dépôt 📥
|
||||
|
||||
1. **Valider la configuration du fournisseur AWS** :
|
||||
Assurez-vous que votre fournisseur AWS est correctement configuré. Plus de détails [ici](/documentation/devpod). ✅
|
||||
|
||||
2. **Créer un Workspace** :
|
||||
- Rendez-vous dans l'onglet **Workspace** et cliquez sur **Create Workspace**.
|
||||
- Indiquez la **source du Workspace** : utilisez le [dépôt GitHub](https://github.com/darnodo/VXLAN-EVPN).
|
||||
- Sélectionnez **AWS** comme fournisseur.
|
||||
- Choisissez votre IDE par défaut.
|
||||
- Enfin, cliquez sur **Create Workspace**.
|
||||
|
||||
|
||||
|
||||
### 2. En Utilisant un Dossier Local 🗂️
|
||||
|
||||
Si vous préférez utiliser votre dépôt local :
|
||||
|
||||
- La seule différence se trouve dans la **source du Workspace**.
|
||||
- Il vous suffit de le pointer vers votre dépôt local.
|
||||
|
||||
|
||||
|
||||
## Démarrer le Lab 🎬
|
||||
|
||||
> [!WARNING] Images cEOS
|
||||
> Le lab utilise l'**image cEOS v4.32.0.1F**.
|
||||
> Pour télécharger cette image, rendez-vous sur la [page de téléchargement Arista](https://www.arista.com/en/support/software-download). ⚠️
|
||||
|
||||
1. **Importer l'image cEOS** :
|
||||
Enregistrez l'image cEOS dans votre dossier `network_images` en la glissant-déposant dans VSCode.
|
||||
Importez l'image en utilisant la commande suivante :
|
||||
|
||||
```bash
|
||||
docker import network_images/cEOS64-lab-4.32.0.1F.tar.xz ceos:4.32.0.1F
|
||||
```
|
||||
|
||||
2. **Déployer le Lab** :
|
||||
Déployez le lab en utilisant Containerlab :
|
||||
|
||||
```bash
|
||||
sudo containerlab deploy -t lab_vxlan.yml
|
||||
```
|
||||
|
||||
Suivez les instructions du CLI pour configurer vos périphériques. Pour des étapes de configuration détaillées, consultez [ce guide](https://github.com/darnodo/VXLAN-EVPN/tree/main/documentation/eos_configuration). 🔧🖥️
|
||||
|
||||
3. **Visualiser l'Architecture** :
|
||||
Vérifiez la topologie déployée grâce à la vue graphique de Containerlab :
|
||||
|
||||
```bash
|
||||
containerlab graph -t lab_vxlan.yml
|
||||
```
|
||||
|
||||
Les ports (par exemple, le port 50080 mentionné dans le `devcontainer.json`) sont redirigés. Accédez à la vue graphique via [localhost](http://localhost:50080).
|
||||
|
||||
|
||||
|
||||
## Utiliser EdgeShark 🦈
|
||||
|
||||
EdgeShark est un outil web qui permet de capturer des paquets depuis votre environnement de lab. Il redirige les captures du lab vers Wireshark exécuté localement. 📡🔍
|
||||
|
||||
Pour plus d'informations, consultez le [guide de démarrage d'EdgeShark](https://edgeshark.siemens.io/#/getting-started?id=optional-capture-plugin).
|
||||
|
||||
### Configuration d'EdgeShark dans le DevContainer 🐳
|
||||
|
||||
Dans la configuration du **DevContainer**, la commande `postCreateCommand` suivante a été ajoutée :
|
||||
|
||||
```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
|
||||
```
|
||||
|
||||
Cette commande télécharge un fichier Docker Compose pour faciliter l'utilisation d'EdgeShark. 🚀
|
||||
|
||||
### Lancer EdgeShark ⚡
|
||||
|
||||
Pour démarrer EdgeShark, exécutez :
|
||||
|
||||
```bash
|
||||
cd /opt/edgeshark
|
||||
DOCKER_DEFAULT_PLATFORM= docker compose up -d
|
||||
```
|
||||
|
||||
Accédez à EdgeShark via [localhost:5001](http://localhost:5001).
|
||||
|
||||
- **Vue d'EdgeShark** :
|
||||
|
||||
|
||||
- **Intégration avec Wireshark** :
|
||||
En cliquant sur l'icône Wireshark dans EdgeShark, vous pouvez lancer Wireshark localement.
|
||||
|
||||
|
||||
|
||||
## Conclusion 🎉
|
||||
|
||||
Dans cet article, nous avons parcouru les étapes pour déployer un lab VXLAN EVPN en utilisant Containerlab, DevPod et AWS. Nous avons abordé les points clés suivants :
|
||||
|
||||
- **Mise en place des prérequis** pour AWS et Containerlab. 🔑
|
||||
- **Création d'un fichier de topologie détaillé** pour une architecture spine-leaf. 🗺️
|
||||
- **Déploiement du lab** en utilisant à la fois un dépôt GitHub et un dossier local. 📥🗂️
|
||||
- **Démarrage du lab** avec Docker et Containerlab. 🚀🐳
|
||||
- **Utilisation d'EdgeShark** pour capturer des paquets et intégrer Wireshark pour une analyse approfondie. 🦈🔍
|
||||
|
||||
En suivant ces étapes, vous pourrez déployer et gérer facilement un environnement de lab réseau évolutif dans le cloud. Bon networking et profitez bien de vos aventures en lab ! 😄🎊
|
||||
214
content/netlab/first_lab/_index.md
Normal file
214
content/netlab/first_lab/_index.md
Normal file
@@ -0,0 +1,214 @@
|
||||
---
|
||||
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](/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:
|
||||
|
||||
|
||||
|
||||
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](/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**.
|
||||
|
||||
|
||||
|
||||
### 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.
|
||||
|
||||
|
||||
|
||||
## 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).
|
||||
|
||||
|
||||
|
||||
## 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**:
|
||||
|
||||
|
||||
- **Wireshark Integration**:
|
||||
Using the Wireshark icon in EdgeShark, you can launch Wireshark locally.
|
||||
|
||||
|
||||
|
||||
## 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! 😄🎊
|
||||
BIN
content/netlab/first_lab/devpod_configuration.png
Normal file
BIN
content/netlab/first_lab/devpod_configuration.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 201 KiB |
BIN
content/netlab/first_lab/devpod_configuration_local.png
Normal file
BIN
content/netlab/first_lab/devpod_configuration_local.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 244 KiB |
BIN
content/netlab/first_lab/edge_wireshark.png
Normal file
BIN
content/netlab/first_lab/edge_wireshark.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 252 KiB |
BIN
content/netlab/first_lab/edgeshark.png
Normal file
BIN
content/netlab/first_lab/edgeshark.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 137 KiB |
BIN
content/netlab/first_lab/edgeshark_interface.png
Normal file
BIN
content/netlab/first_lab/edgeshark_interface.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 24 KiB |
67
content/netlab/netlab.fr.md
Normal file
67
content/netlab/netlab.fr.md
Normal file
@@ -0,0 +1,67 @@
|
||||
---
|
||||
title: "Présentation des NetLabs"
|
||||
cascade:
|
||||
type: docs
|
||||
---
|
||||
|
||||
## Introduction
|
||||
|
||||
📡 Dans un monde où les réseaux informatiques jouent un rôle croissant dans notre vie quotidienne, la compréhension des principes et de la logique qui les animent devient de plus en plus essentielle.
|
||||
|
||||
Les laboratoires réseau virtuels (en anglais "NetLab" ou "Virtual Network Lab") constituent une approche idéale pour enseigner ces concepts, nous permettant de simuler des environnements réseaux complexes et d'expérimenter sans risques.
|
||||
|
||||
Je souhaite partager avec vous le fonctionnement de mes "NetLabs", qui seront régulièrement liés à des articles documentaires (dans la catégorie : **documentation**). Ils nous permettront de pratiquer, de constater ou bien de comprendre le fonctionnement de concepts expliqués théoriquement avant.
|
||||
|
||||
Dans le cadre des NetLab, ceux-ci seront principalement déployés via l'outil ContainerLab. Pour les architectures plus complexes, nous utiliserons GNS3.
|
||||
|
||||
## Qu'est-ce que ContainerLab ? 🛠️
|
||||
|
||||
ContainerLab est un outil open-source puissant qui permet la création de laboratoires réseau virtuels complets. Grâce à son utilisation, on peut simuler une multitude d'architectures réseaux complexes, avec des équipements tels que les routeurs, commutateurs, serveurs et autres appareils réseau.
|
||||
|
||||
Cette plateforme offre une grande flexibilité dans la conception des exercices, permettant l'abordage de différents sujets tels que l'apprentissage de protocoles réseau, de sécurité ou encore de configurations d'équipements. Les utilisateurs peuvent ainsi se concentrer sur l'analyse et la résolution de problèmes sans s'inquiéter des détails techniques sous-jacents.
|
||||
|
||||
L'installation de ContainerLab ne sera pas présentée ici, mais toutes les informations sont présentes sur le site officiel [ici](https://containerlab.dev/install/).
|
||||
|
||||
## Qu'est-ce que GNS3 ? 💻
|
||||
|
||||
GNS3, ou Graphical Network Simulator-3, est un logiciel open-source utilisé principalement pour la **simulation** et l'**émulation** de réseaux informatiques. Il permet aux ingénieurs réseaux, aux étudiants et aux professionnels de concevoir, tester et dépanner des réseaux complexes dans un environnement virtuel avant de les déployer dans le monde réel. GNS3 est particulièrement apprécié pour sa capacité à intégrer divers matériels et logiciels réseau, tels que les routeurs et commutateurs Cisco, ainsi que des machines virtuelles pour créer des topologies réseau réalistes.
|
||||
|
||||
Comme précédemment, l'installation de GNS3 ne sera pas évoquée, pour plus d'information, la documentation est présente [ici](https://docs.gns3.com/docs/).
|
||||
|
||||
## GNS3 vs ContainerLab ⚔️
|
||||
|
||||
GNS3 et ContainerLab sont deux outils puissants pour la simulation et l'émulation de réseaux, mais ils diffèrent dans leur approche, leurs fonctionnalités et leurs cas d'utilisation principaux. Voici un rapide comparatif entre les deux :
|
||||
|
||||
### GNS3
|
||||
|
||||
**Avantages :**
|
||||
|
||||
1. **Interface Graphique Intuitive :** GNS3 offre une interface graphique conviviale permet aux utilisateurs de glisser-déposer des composants pour créer des topologies réseau.
|
||||
2. **Support Multivendor :** Il supporte une large gamme de matériels et logiciels réseau, y compris les routeurs et commutateurs Cisco, ainsi que des machines virtuelles.
|
||||
3. **Flexibilité :** GNS3 peut être utilisé sur Windows, macOS et Linux, et il intègre bien d'autres outils comme Wireshark pour l'analyse de trafic.
|
||||
4. **Communauté Active :** Une grande communauté d'utilisateurs et de développeurs offre un vaste support et une multitude de ressources en ligne.
|
||||
|
||||
**Inconvénients :**
|
||||
|
||||
1. **Ressources Systèmes :** GNS3 peut être gourmand en ressources, surtout lorsqu'il émule des dispositifs complexes ou de grandes topologies.
|
||||
2. **Complexité de Configuration :** La configuration initiale peut être complexe, surtout pour les nouveaux utilisateurs.
|
||||
|
||||
### ContainerLab
|
||||
|
||||
**Avantages :**
|
||||
|
||||
1. **Légèreté et Performance :** ContainerLab utilise des conteneurs pour émuler les dispositifs réseau, ce qui le rend plus léger et performant que les solutions basées sur des machines virtuelles.
|
||||
2. **Automatisation et DevOps :** Il s'intègre bien avec les outils DevOps et d'automatisation comme Ansible, facilitant ainsi le déploiement automatisé et la gestion de réseaux.
|
||||
3. **Configuration Simplifiée :** Les topologies sont définies via des fichiers YAML, rendant la configuration plus simple et scriptable.
|
||||
4. **Support de Technologies Modernes :** Il supporte des technologies modernes comme Docker et Kubernetes, offrant ainsi une plus grande flexibilité pour les environnements cloud-native.
|
||||
|
||||
**Inconvénients :**
|
||||
|
||||
1. **Moins de Support Multivendor :** Bien que ContainerLab supporte plusieurs types de conteneurs réseau, il peut ne pas avoir le même niveau de support multivendor que GNS3.
|
||||
2. **Courbe d'Apprentissage :** Pour ceux qui ne sont pas familiers avec les concepts de conteneurisation, la courbe d'apprentissage peut être plus raide.
|
||||
|
||||
## Conclusion 📊
|
||||
|
||||
**GNS3** est idéal pour ceux qui recherchent une interface graphique intuitive et un large support de dispositifs réseau, particulièrement utile pour les étudiants et les ingénieurs réseau traditionnels. **ContainerLab**, en revanche, est plus adapté aux environnements modernes et aux pratiques DevOps, offrant une solution légère et scriptable pour la simulation de réseaux.
|
||||
|
||||
Le choix entre GNS3 et ContainerLab dépend donc principalement des besoins spécifiques de l'utilisateur en termes de flexibilité, performance, et intégration avec d'autres outils et technologies.
|
||||
67
content/netlab/netlab.md
Normal file
67
content/netlab/netlab.md
Normal file
@@ -0,0 +1,67 @@
|
||||
---
|
||||
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.
|
||||
Reference in New Issue
Block a user