All checks were successful
Build and Deploy Hugo / Deploy Hugo Website (pull_request) Successful in 24s
Remove emojis and em dash separators Simplify introductory sentences Standardize section headings
200 lines
6.7 KiB
Markdown
200 lines
6.7 KiB
Markdown
---
|
||
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 set up our very first Containerlab netlab using **DevPod**.
|
||
We'll use 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 deploy, stop, and destroy them quickly, both for performance and cost.
|
||
|
||
We'll achieve this by combining:
|
||
|
||
- **DevPod**
|
||
- **DevContainer**
|
||
- **Containerlab**
|
||
|
||
We'll use a simple topology that you can find on my [GitHub repository](https://github.com/darnodo/VXLAN-EVPN). Our goal is to deploy this lab on AWS with DevPod.
|
||
|
||
## Prerequisites
|
||
|
||
Before starting, a few things need to be in place:
|
||
|
||
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:
|
||
|
||

|
||
|
||
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 is 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**.
|
||
|
||

|
||
|
||
### 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, 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 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).
|
||
|
||

|
||
|
||
## 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:
|
||

|
||
|
||
- Integration with Wireshark: clicking the Wireshark icon in EdgeShark launches Wireshark locally.
|
||

|
||

|
||
|
||
## Conclusion
|
||
|
||
That covers the full setup: prerequisites, the VXLAN topology, deploying the lab with DevPod on AWS, and capturing traffic with EdgeShark and Wireshark. From here you have a working spine-leaf lab you can tear down and redeploy whenever you need it.
|