Building Networks with GNS3

Design and configure 3 network topology in GNS3 featuring VXLAN and BGP EVPN, using Docker containers as machines.

Introduction

This documentation demonstrates how to design and implement various network topologies using VXLAN and BGP EVPN technologies. Prior knowledge required includes: VLANs, VXLAN fundamentals, Autonomous Systems (AS), routing protocols including iBGP, eBGP, and OSPF, underlay/overlay network architecture concepts, and understanding of data plane versus control plane separation in modern networking.

https://datatracker.ietf.org/doc/html/rfc7348

Installation of requirements

prerequisites

Ubuntu ISO: https://ubuntu.com/download/desktop

VMware: https://www.vmware.com/products/desktop-hypervisor/workstation-and-fusion

GNOME: sudo apt install gnome-session-flashback (optional)

GNS3: https://docs.gns3.com/docs/getting-started/installation/linux/

Wireshark set up + permissions:

sudo apt update
sudo apt install wireshark
sudo usermod -aG wireshark $USER

sudo chgrp vmmon /usr/bin/dumpcap
sudo chmod 750 /usr/bin/dumpcap
sudo setcap 'CAP_NET_RAW+eip CAP_NET_ADMIN+eip' /usr/bin/dumpcap

Setting up VXLAN & BGP EVPN network topologies

GNS3 configuration with Docker

In this first section, we will instantiate a router that includes all the necessary protocols through a partially automated configuration, using FRR (Free Range Routing) as the routing software suite. We will be responsible for logically connecting these devices within GNS3, ensuring proper network topology setup and communication between nodes.

FRR allows us to implement dynamic routing protocols such as BGP, OSPF, and others, and is widely used in both lab environments and production networks for its flexibility and robustness.

We will also deploy a lightweight Alpine Linux-based host to simulate an endpoint in the network. This host will be used for basic connectivity testing and to validate the VXLAN and BGP EVPN setup.

host & router template

To do this, you can use the following scripts. Once the images are built, you can use them in GNS3 as Docker container templates and display them as shown in the image above.

Edit → Preferences → Docker → Docker Containers.

Make sure to select 2 adapters for the host and 8 for the routers.

Makefile

DOCKERFILE_ROUTER := router/Dockerfile.router
DOCKERFILE_HOST := host/Dockerfile.host

TAG_ROUTER := "aschiffe_r1"
TAG_HOST := "aschiffe_h1"

all: build run

build:
	docker build -t $(TAG_ROUTER) -f $(DOCKERFILE_ROUTER) .
	docker build -t $(TAG_HOST) -f $(DOCKERFILE_HOST) .

prune:
	docker system prune --all

.PHONY: all build run prune

Dockerfile.host

FROM alpine:latest
LABEL node_type="host"
RUN apk add --no-cache bash

Dockerfile.router

FROM frrouting/frr
LABEL node_type="router"
RUN sed -i -e 's/^bgpd=no/bgpd=yes/' \
           -e 's/^ospfd=no/ospfd=yes/' \
           -e 's/^isisd=no/isisd=yes/' /etc/frr/daemons
RUN echo "service integrated-vtysh-config" > /etc/frr/vtysh.conf && \
    echo "hostname frr" >> /etc/frr/vtysh.conf

You will be able to drag and drop them onto the logical diagram, start them, and check the running processes in the console using ps aux. Make sure to select the correct symbol for each machine.

You should see something like this:

host auxiliary console

router auxiliary console

We can observe interesting processes on the router's auxiliary console. These include the FRR daemons: bgpd, ospfd, and isisd, which are routing protocol daemon; the Zebra daemon, which manages the routing table in the UNIX kernel; and static, a daemon that handles the installation and deletion of static routes.

Discovering a VXLAN

In this section, we set up a VXLAN (Virtual Extensible LAN) network topology. VXLAN is a tunneling technology that allows the creation of extended virtual local area networks (VLANs) over existing IP infrastructures. VXLAN encapsulates Layer 2 Ethernet frames within Layer 3 UDP packets, creating an overlay network that tunnels L2 traffic over an L3 underlay infrastructure, enabling scalable multi-tenant isolation across data centers by adding a 24-bit VXLAN Network Identifier (VNI) header.

Concerning the discovery, VXLAN relies on the data plane (flood & learn approach). This means discovery is reactive, depending on user-generated traffic that triggers ARP/ND requests.

VXLAN packet

The following diagram illustrates a VXLAN network topology using two routers acting as VTEPs (VXLAN Tunnel Endpoints). Each router connects to a host that belongs to the same virtual Layer 2 network (30.1.1.0/24), even though they are physically located on separate Layer 3 networks (10.1.1.0/24). Packet Flow (Reverse Clock Direction) :

VXLAN here creates a virtual Ethernet segment between hosts, even though they're connected through separate IP networks.

1. Host 2 sends an L2 frame destined to Host 1.

2. Router 2 (VTEP2) Encapsulates the L2 frame into a VXLAN packet, Adds UDP + IP headers (VXLAN overlay inside IP underlay), Sends it to Router 1 (VTEP1) over the underlay network.

3. The L2 switch just forwards this VXLAN packet from eth0 to eth1.

4. Router 1 (VTEP1) Decapsulates the packet to retrieve the original L2 frame, Sends it to Host 1 via the bridged interface.

5. Host 1 receives the frame and believes Host 2 is on the same Ethernet segment.

We start by configuring the hosts and assigning them IP addresses. to the host’s eth1 interface. Note, the MTU is reduced to 1450 as the VXLAN the and other headers adds 50 bytes.

host1.sh

#!/bin/bash
ip addr add 30.1.1.1/24 dev eth1
ip link set dev eth1 mtu 1450

host2.sh

#!/bin/bash
ip addr add 30.1.1.2/24 dev eth1
ip link set dev eth1 mtu 1450

The following scripts configure each router as a VXLAN Tunnel Endpoint (VTEP). The result is a working VXLAN setup that forwards L2 frames between hosts over a L3 network.

Key Steps:

1. Create a Linux bridge (br0) to bridge the VXLAN tunnel and host-side interface (eth1).

2. Configure underlay IP (10.1.1.1 or 10.1.1.2) on eth0.

3. Create VXLAN interface (vxlan10):

   • Static mode: sets the remote peer’s IP explicitly.

   • Dynamic mode: uses a multicast group (239.1.1.1) to discover peers.

4. Assign an overlay IP (20.1.1.X) to vxlan10 (not essential but can be useful for diagnostics or routing).

5. Bridge vxlan10 and eth1 using brctl, enabling L2 forwarding between the local host and the VXLAN tunnel.

6. Bring up the VXLAN interface.

router1.sh

#!/bin/bash
mode="$1"

ip link add br0 type bridge
ip link set dev br0 up

ip addr add 10.1.1.1/24 dev eth0
# ip addr show eth0

if [ "$1" = "static" ]; then
    ip link add name vxlan10 type vxlan id 10 dev eth0 remote 10.1.1.2 local 10.1.1.1 dstport 4789
elif [ "$1" = "dynamic" ]; then
    ip link add name vxlan10 type vxlan id 10 dev eth0 group 239.1.1.1 dstport 4789
else
    echo "Unknown mode: $1"
    exit 1
fi

ip addr add 20.1.1.1/24 dev vxlan10
# ip -d link show vxlan10

brctl addif br0 eth1
brctl addif br0 vxlan10
ip link set dev vxlan10 up

router2.sh

#!/bin/bash
mode="$1"

ip link add br0 type bridge
ip link set dev br0 up

ip addr add 10.1.1.2/24 dev eth0
# ip addr show eth0

if [ "$1" = "static" ]; then
    ip link add name vxlan10 type vxlan id 10 dev eth0 remote 10.1.1.1 local 10.1.1.2 dstport 4789
elif [ "$1" = "dynamic" ]; then
    ip link add name vxlan10 type vxlan id 10 dev eth0 group 239.1.1.1 dstport 4789
else
    echo "Unknown mode: $1"
    exit 1
fi

ip addr add 20.1.1.2/24 dev vxlan10
# ip -d link show vxlan10

brctl addif br0 eth1
brctl addif br0 vxlan10
ip link set dev vxlan10 up

This is the main deployment script that configures all containers (routers and hosts) based on their labels and names. You can launch it through the Makefile in static or dynamic mode.

config.sh

#!/bin/bash
mode="$1"

if [ "$#" -ne 1 ]; then
  echo "You should provide either 'static' or 'dynamic' mode"
  exit 1
fi

for container_id in $(docker ps -q); do
  node_type=$(docker inspect --format='{{ index .Config.Labels "node_type" }}' "$container_id")

  if [[ "$node_type" == "router" || "$node_type" == "host" ]]; then
    hostname=$(docker inspect --format='{{ .Config.Hostname }}' "$container_id")
    echo "Checking container $container_id with hostname '$hostname' and node_type '$node_type'"
    if [[ "$node_type" == "router" && "$hostname" =~ -1$ ]]; then
      echo "Container $container_id ($hostname): executing router-1 vxlan config"
      cat ./router/router1.sh | docker exec -i $container_id bash -s -- $mode
    elif [[ "$node_type" == "router" && "$hostname" =~ -2$ ]]; then
      echo "Container $container_id ($hostname): executing router-2 vxlan config"
      cat ./router/router2.sh | docker exec -i $container_id bash -s -- $mode
    elif [[ "$node_type" == "host" && "$hostname" =~ -1$ ]]; then
      echo "Container $container_id ($hostname): executing host-1 ip addr config"
      cat ./host/host1.sh | docker exec -i $container_id bash -s -- $mode
    elif [[ "$node_type" == "host" && "$hostname" =~ -2$ ]]; then
      echo "Container $container_id ($hostname): executing host-2 ip addr config"
      cat ./host/host2.sh | docker exec -i $container_id bash -s -- $mode
    else
      echo "Container $container_id ($hostname): hostname does not match -1 or -2 pattern"
    fi
  fi
done

Makefile

HOST_DIR := host/
ROUTER_DIR := router/

HOST1_CONFIG := $(HOST_DIR)/host1.sh
HOST2_CONFIG := $(HOST_DIR)/host2.sh

ROUTER1_CONFIG := $(ROUTER_DIR)/router1.sh
ROUTER2_CONFIG := $(ROUTER_DIR)/router2.sh

run_config:
	@read -p "vxlan mode: " vmode; \
	bash config.sh $$vmode

.PHONY: run_config

Once you have launched the container configurations that set up the VXLAN & set up the network, i suggest you sniff the interface between the router and the Layer 2 switch using Wireshark (trigger a ping request from h1 to h2).

pingP2.pcapng

We can observe several types of packets, including ICMPv6 Router Solicitations (RS) (type 133) sent by several network hosts in order to automatically discover any IPv6 routers present on the local link.

They use the Neighbour Discovery Protocol (NDP), which is the replacement for ARP.

Two key messages:

Router Solicitation (RS) → sent by a client to ask, “Is there an IPv6 router on this link?”

Router Advertisement (RA) → sent by a router to say, “Yes, I’m a router! Here’s the IPv6 prefix to use, my gateway, and so on.”

These messages are sent when an IPv6 network interface is initialised, or when it joins a new network (for example, when switching Wi-Fi or plugging in an Ethernet cable). They are sent to the multicast address ff02::2, which targets all routers on the local link.

However, since no Router Advertisement (RA) follows, it is likely that no active IPv6 router is present on the network.

ARP (Address Resolution Protocol) is used to translate an IPv4 address (e.g. 10.1.1.1) into a MAC address (e.g. 02:42:3c:43:5b:00). This process is essential for the network layer (IP) to be able to send packets over the data link layer (Ethernet).

For example:

When you ping 10.1.1.1, your operating system checks for its MAC address. If it is not already in the ARP cache, it sends an ARP request. When you try to reach the default gateway (router) 10.1.1.1, your PC also sends an ARP request to obtain its MAC address. Once the reply is received, it is stored in the ARP cache to avoid sending repeated requests.

Discovering BGP with EVPN

BGP (Border Gateway Protocol) is the routing protocol that interconnects Autonomous Systems (AS) - independent networks identified by unique AS numbers. While traditionally used for inter-domain routing on the internet, BGP has evolved with the EVPN (Ethernet VPN) extension to address modern data center needs.

In this section, we will deploy a BGP EVPN VXLAN solution in a Spine-Leaf architecture. 1 RR, 3 leafs, each associated with 1 host.

BGP EVPN (Ethernet VPN) is a control plane protocol that uses MP-BGP (Multi-Protocol BGP) to distribute MAC addresses, IP addresses, and other reachability information for overlay networks (typically VXLAN).

In this architecture, BGP manages the MAC <-> IP <-> VTEP mappings instead of discovering them via the data plane as in the previous section. Each VTEP dynamically advertises its local information into BGP, and other VTEPs learn these mappings through the Route Reflector (RR).

OSPF builds the physical IP network between all fabric devices (spines and leafs). It uses link-state routing where each device knows the complete topology and calculates optimal paths using Dijkstra's algorithm. Its role is limited to distributing each leaf's loopback addresses and establishing the basic IP connectivity that enables VXLAN tunnels to form.