To demonstrate basic BGP security practices in a network emulator in a way that emulates real-world conditions, researchers need to emulate an Internet Routing Registry (IRR) database server running software like IRRd and a network management workstation running software utilities like bgpq4. These tools enable the centralized registration of prefix information and the generation of prefix filter lists from that information. I was not able to find ready-to-use container images that support either of these functions, so I created them.

In this post, I walk through the process of building reusable container images that can be dropped into any network emulator that supports Docker containers, such as Containerlab, GNS3, or Kathará, etc. I also show how I published the containers in a public repository.

IRRd and bgpq4

IRRd (Internet Routing Registry daemon) version 4 is a widely used software program for maintaining and serving IRR data in the RPSL format. To experience IRRd, you can directly interact with the IRRd user interface at ntt.net, which is a tier-1 global IP backbone provider, and it also powers industry-standard registries like RADB.

Bgpq4 is a command-line tool used by network engineers to query an IRR server and generate BGP prefix-list configurations for most router platforms.

Design decisions

The will build the IRRd container on top of a lightweight Debian image will bundle PostgreSQL, Redis, and IRRd in a single “all-in-one” image. This is not the recommended pattern for production, but we want the IRRd to appear to be one “node” in a network emulation lab. And, we want to make it available as a single image, with no Docker Compose file required.

I will also build the bgpq4 container on top of a lightweight Debian image that will include bgpq4 and common network utilities. This container will act as a network management workstation.

Building the IRRd container image

The IRRd image requires four files: a Dockerfile, an entrypoint script, an IRRd configuration file, and a base RPSL data file. Create them, as described below, and place them all in a project directory (I used the drectory name irrd-lab).

$ mkdir irrd-lab
$ cd irrd-lab

The IRRd Dockerfile

The IRRd Dockerfile will build the Docker image that combines IRRd, PostgreSQL, and Redis into one container.

Create a Dockerfile named Dockerfile.irrd:

$ vi Dockerfile.irrd

Copy and paste the following text into the file:

# All-in-one IRRd lab container

FROM python:3.14-slim-trixie

ENV DEBIAN_FRONTEND=noninteractive 

# Install PostgreSQL, Redis, and build dependencies for IRRd
RUN apt-get update && apt-get install -y --no-install-recommends \
        postgresql \
        redis-server \
        gnupg \
        iproute2 \
        net-tools \
        netcat-openbsd \
        procps \
        curl \
        gcc \
        libpq-dev \
        python3-dev \
        rustc \
        cargo \
        apache2-utils \
    && pip install --no-cache-dir irrd \
    && apt-get purge -y gcc python3-dev rustc cargo \
    && apt-get autoremove -y \
    && rm -rf /var/lib/apt/lists/*

# Create directories for IRRd
RUN mkdir -p /var/log/irrd /var/run/irrd /etc/irrd /var/lib/irrd/gnupg \
    && chmod 700 /var/lib/irrd/gnupg

# Make PostgreSQL binaries available on PATH
ENV PATH="/usr/lib/postgresql/17/bin:${PATH}"

# Copy configuration and entrypoint
COPY irrd.yaml /etc/irrd.yaml
RUN mkdir -p /etc/irrd/data
COPY lab-irr-base.rpsl /etc/irrd/data/lab-irr-base.rpsl
RUN ln -sf /etc/irrd/data/lab-irr-base.rpsl /etc/irrd/lab-irr-base.rpsl
COPY entrypoint.sh /entrypoint.sh
RUN chmod +x /entrypoint.sh

# (Optional) Bind-mount host directory with RPSL files to /etc/irrd/data
# VOLUME ["/etc/irrd/data"]

EXPOSE 43
EXPOSE 8080

HEALTHCHECK --interval=30s --timeout=5s --start-period=45s --retries=3 \
    CMD sh -ec "pg_isready -q && redis-cli ping | grep -q PONG && nc -z 127.0.0.1 43"

ENTRYPOINT ["/entrypoint.sh"]

Save the file.

The Dockerfile, above, starts from python:3.14-slim-trixie. The IRRd deployment documentation states that IRRd requires PostgreSQL and Redis so the Dockerfile installs PostgreSQL and Redis from Debian packages, then installs IRRd from PyPI. It also installs some helpful utilities. The Dockerfile then temporarily installs build dependencies gcc and rustc, and removes them after the IRRd build is completed to keep the image smaller.

The Dockerfile then creates directories for IRRd and adds the PostgreSQL application to the system path. It also copies the configuration files and startup script into the container.

The Dockerfile also includes a HEALTHCHECK instruction. Docker will periodically run it and flag the container unhealthy if it fails.

Every time the container starts, it initializes a new database and loads the base RPSL data so no persistent volumes are needed.

The entrypoint script

The entrypoint script is the startup script for the container. It starts each service in order, waits for dependencies, then runs IRRd in the foreground.

Because the database and Redis live in the same container, the script also bootstraps the irrd database, loads the base RPSL data and creates a Web UI admin account. Waiting for each dependency avoids race conditions during startup.

Create the entrypoint.sh script:

$ vi entrypoint.sh

Copy and paste the following text into the file:

#!/bin/bash
set -e

echo "=== IRRd Lab Container Starting ==="

if [ ! -x "/usr/lib/postgresql/17/bin/initdb" ]; then
    echo "ERROR: expected PostgreSQL binaries at /usr/lib/postgresql/17/bin, but initdb was not found or is not executable."
    exit 127
fi
mkdir -p /var/log/irrd
chown postgres:postgres /var/log/irrd

# ------------------------------------------------------------------
# Start PostgreSQL
# ------------------------------------------------------------------
echo "Starting PostgreSQL..."

# Initialize the database cluster if it doesn't exist yet
if [ ! -f "/var/lib/postgresql/data/PG_VERSION" ]; then
    install -d -o postgres -g postgres -m 0700 "/var/lib/postgresql/data"
    su - postgres -c "/usr/lib/postgresql/17/bin/initdb -D /var/lib/postgresql/data"
fi

# Tune PostgreSQL for minimal lab use
cat >> "/var/lib/postgresql/data/postgresql.conf" <<EOF
random_page_cost = 1.0
work_mem = 50MB
max_connections = 30
listen_addresses = 'localhost'
EOF

# Allow local connections without a password
cat > "/var/lib/postgresql/data/pg_hba.conf" <<EOF
local   all   all                 trust
host    all   all   127.0.0.1/32  trust
host    all   all   ::1/128       trust
EOF

su - postgres -c "/usr/lib/postgresql/17/bin/pg_ctl -D /var/lib/postgresql/data -l /var/log/irrd/postgresql.log start"

# Wait for PostgreSQL to be ready
echo "Waiting for PostgreSQL to accept connections..."
for i in $(seq 1 30); do
    if su - postgres -c "/usr/lib/postgresql/17/bin/pg_isready -q" 2>/dev/null; then
        break
    fi
    sleep 1
done

# Create the IRRd database and pgcrypto extension
echo "Creating IRRd database..."
su - postgres -c "/usr/lib/postgresql/17/bin/psql -tc \"SELECT 1 FROM pg_database WHERE datname='irrd'\" | grep -q 1" || \
    su - postgres -c "/usr/lib/postgresql/17/bin/createdb irrd"
su - postgres -c "/usr/lib/postgresql/17/bin/psql -d irrd -c 'CREATE EXTENSION IF NOT EXISTS pgcrypto;'"

# ------------------------------------------------------------------
# Start Redis (no persistence, low memory)
# ------------------------------------------------------------------
echo "Starting Redis..."
redis-server \
    --daemonize yes \
    --save "" \
    --appendonly no \
    --maxmemory 64mb \
    --logfile /var/log/irrd/redis.log

# Wait for Redis to be ready
for i in $(seq 1 15); do
    if redis-cli ping 2>/dev/null | grep -q PONG; then
        break
    fi
    sleep 1
done

# ------------------------------------------------------------------
# Build IRRd database tables
# ------------------------------------------------------------------
echo "Building IRRd database tables..."
irrd_database_upgrade --config /etc/irrd.yaml

# Load base RPSL data
irrd_load_database --config /etc/irrd.yaml --source LABRIR /etc/irrd/lab-irr-base.rpsl
echo "RPSL data loaded."


# ------------------------------------------------------------------
# Bootstrap a hard-coded Web UI admin user (because no e-mail available)
# ------------------------------------------------------------------
echo "Creating IRRd Web UI admin user: test@irrtest.com"
WEBUI_PASSWORD_HASH="$(htpasswd -bnBC 12 "" "mypassword" | tr -d ':\n')"

su - postgres -c "/usr/lib/postgresql/17/bin/psql -d irrd -v ON_ERROR_STOP=1 <<'SQL'
INSERT INTO auth_user (email, name, password, active, override)
VALUES ('test@irrtest.com', 'Lab Administrator', '$WEBUI_PASSWORD_HASH', true, true)
ON CONFLICT (email)
DO UPDATE SET
    name = EXCLUDED.name,
    password = EXCLUDED.password,
    active = EXCLUDED.active,
    override = EXCLUDED.override,
    updated = now();
SQL"

echo "Web UI user created/updated: test@irrtest.com (override=true)"

# ------------------------------------------------------------------
# Start IRRd in the foreground
# ------------------------------------------------------------------
echo "Starting IRRd..."
echo "=== IRRd Lab Container Ready ==="
exec irrd --config /etc/irrd.yaml --foreground

Save the file.

As you can see from the entrypoint.sh file, the server startup sequence is: PostgreSQL → Redis → Schema creation → RPSL data load → Web user creation → Run IRRd in foreground. The code comments explain each step.

Note: The IRRd deployment docs recommend creating a dedicated irrd database role with a password and explicit grants. But, to keep things simple in this lab container, the entrypoint script connects to the database as the postgres superuser without authentication. This is OK in a lab because our PostgreSQL database is local and disposable.

The IRRd configuration file

See the full IRRd configuration reference for all IRRd configuration options. A lab instance needs very few features so our IRRd file is very simple. The irrd.taml file below covers the basic database/Redis URLs, server listeners, authentication overrides and source definitions that are relevant to our simple setup.

Create the irrd.yaml file:

$ vi irrd.yaml

Copy and paste the following text to the irrd.yaml file:

irrd:
    database_url: 'postgresql://postgres@localhost/irrd'
    redis_url: 'redis://localhost'
    piddir: /var/run/irrd/
    user: postgres
    group: postgres

    server:
        http:
            interface: '0.0.0.0'
            port: 8080
            url: 'http://localhost:8080/'
            workers: 1
        whois:
            interface: '0.0.0.0'
            port: 43
            max_connections: 5

    auth:
        gnupg_keyring: /var/lib/irrd/gnupg/
        override_password: '$1$test$4PzmqjLUwdD2j1Otz/LSw.' # password: mypassword
        set_creation:
            COMMON:
                prefix_required: false
                autnum_authentication: disabled

    email:
        from: 'test@irrtest.com'
        footer: ''
        smtp: 'localhost'

    log:
        level: INFO

    rpki:
        roa_source: null
    
    compatibility:
        inetnum_search_disabled: true

    sources_default:
        - LABRIR

    sources:
        LABRIR:
            authoritative: true
            keep_journal: true
            authoritative_non_strict_mode_dangerous: true

Then, save the file.

The key IRRd settings are:

• Both server.http.interface and server.whois.interface bind to 0.0.0.0 so other lab nodes can reach the IRR server.
• server.whois.max_connections: 5 and server.http.workers: 1, to keep memory usage low (each WHOIS connection uses ~200 MB).
• rpki.roa_source: null disables RPKI integration. We don’t need it in this filtering lab, and I will cover RPKI in a future post.
• sources.LABRIR is configured as authoritative with authoritative_non_strict_mode_dangerous: true to relax RPSL validation for lab objects.
• auth.override_password is the MD5 hash of “mypassword”, used for bypassing authentication when loading data.

The base RPSL data file

IRRd needs at least a mntner (maintainer) object to function as an authoritative source. This file seeds the IRRd database with a maintainer and an administrative contact.

Create the lab-irr-base.rpsl file:

$ vi lab-irr-base.rpsl

Then, copy and paste the following text into the file:

mntner:         LAB-MNT
descr:          Lab maintainer for all objects; password is "mypassword"
admin-c:        LAB-ADMIN
upd-to:         test@irrtest.com
auth:           MD5-PW $1$test$4PzmqjLUwdD2j1Otz/LSw.
mnt-by:         LAB-MNT
source:         LABRIR

person:         Lab Administrator
address:        Lab Network
phone:          +1-555-0100
nic-hdl:        LAB-ADMIN
mnt-by:         LAB-MNT
source:         LABRIR

Ensure that there us a blank line at the end of the file. RPSL requires that every object end with a blank line, including the last object in the file.

Save the file.

In the file above, the objects use LAB-MNT as their maintainer with the MD5 hash of “mypassword”, matching the override password in irrd.yaml. The source: LABRIR value must exactly match the source name in the IRRd configuration. When you use the container in a lab, you will load additional route, aut-num, and as-set objects describing your lab’s routing policy.

Building the IRRd image

Build the Docker image:

$ docker build -t irrd-lab -f Dockerfile.irrd .

This may take several minutes because it compiles some of its dependencies.

Checking container health

After building it, test the container by checking its health. First, run the new image in a container tagged irrd-test:

$ docker run -d -p 8080:8080 --name irrd-test irrd-lab:latest

Run the command below to see the healthcheck status, which verifies PostgreSQL, Redis, and IRRd’s WHOIS listener are all running. If you used the same docker build command, above, the container name will be irrd-test:

$ docker inspect --format '{{json .State.Health}}' irrd-test

A brief starting state or a few failed probes during initialization is normal. Eventually, you should see output similar to teh folloing:

{"Status":"healthy","FailingStreak":0,"Log":[{"Start":"2026-03-22T10:40:52.405173463-04:00","End":"2026-03-22T10:40:52.460239963-04:00","ExitCode":1,"Output":""},{"Start":"2026-03-22T10:40:57.461480257-04:00","End":"2026-03-22T10:40:57.51754926-04:00","ExitCode":0,"Output":"Connection to 127.0.0.1 43 port [tcp/whois] succeeded!\n"},{"Start":"2026-03-22T10:41:27.518192933-04:00","End":"2026-03-22T10:41:27.617904019-04:00","ExitCode":0,"Output":"Connection to 127.0.0.1 43 port [tcp/whois] succeeded!\n"}]}

Test the IRRd server

To check that the IRRd server is running, access the server’s web UI in a web browser. Go to https://localhost:8080. You should see the IRRd page as shown below:

Try to login with userid: test@irrtest.com and password mypassword. If the login works, then the server is running properly.

Destroy the IRRd container

Later, we will test the IRRd container in a small network with the bgpq4 container. So, we need to stop and destroy the current container.

$ docker destroy irrd-test
$ docker rm irrd-test

Build the bgpq4 utility container image

The bgpq4 utility container image is a lightweight Debian image that provides bgpq4 and common network tools.

Create Dockerfile.bgpq4:

$ vi Dockerfile.bgpq4

Copy and paste the following text into the file:

# Linux container with bgpq4 and other utilities

FROM debian:trixie-slim

RUN apt-get update && \
    apt-get install -y --no-install-recommends \
        bgpq4 \
        curl \
        iproute2 \
        traceroute \
        net-tools \
        netbase \
        netcat-openbsd \
        iputils-ping \
        whois \
    && rm -rf /var/lib/apt/lists/*

CMD ["sleep", "infinity"]

Save the file.

The bgpq4 Dockerfile uses the sleep infinity command so the bgpq4 container stays running in a lab topology, just like a real network management workstation would.

Build the image:

$ cd irrd-lab
$ docker build -t bgpq4-utils -f Dockerfile.bgpq4 .

To test it properly, the bgpq4 container needs to be in a network and must be able to reach an IRRd server. We’ll set that up in the following section.

Testing the containers together

Verify the containers work together using plain Docker (no network emulator required).

Start the containers

Create a Docker network and start both containers:

$ docker network create irr-test-net
$ docker run -d -p 8080:8080 --name irrd-test --network irr-test-net irrd-lab
$ docker run -d --name bgpq4-test --network irr-test-net bgpq4-utils

Wait for the IRRd container to finish initializing (15–30 seconds). Then, verify it is healthy:

$ docker inspect --format '{{json .State.Health}}' irrd-test

Verify the WHOIS service

Query the IRRd server from the bgpq4 container:

$ docker exec bgpq4-test sh -c 'echo "-i origin AS100" | nc irrd-test 43'

This query returns no results because only the base RPSL data is loaded (no route objects) — the important thing is that the connection succeeds. Verify the maintainer object is present:

$ docker exec bgpq4-test sh -c 'echo "LAB-MNT" | nc irrd-test 43'

This should return the LAB-MNT maintainer object like the following output:

mntner:         LAB-MNT
descr:          Lab maintainer for all objects; password is "mypassword"
admin-c:        LAB-ADMIN
upd-to:         test@irrtest.com
auth:           MD5-PW DummyValue  # Filtered for security
mnt-by:         LAB-MNT
source:         LABRIR
last-modified:  2026-03-22T15:18:21Z

This shows that the IRRd container and the bgpq4 container can interoperate over a Docker network (a Linux bridge). I will show how these containers may be used in more complex networks in a future post.

Clean up the test

$ docker stop irrd-test bgpq4-test
$ docker rm irrd-test bgpq4-test
$ docker network rm irr-test-net

Publishing the images

Publish the images we created to a container registry so they will be easy to access and use. I show the procedure for Docker Hub below; the process is similar for GitHub Container Registry.

Tag and push to Docker Hub

Tag the images with a specific version.

Replace yourusername with your Docker Hub account name:

$ docker tag irrd-lab yourusername/irrd-lab:0.1
$ docker tag bgpq4-utils yourusername/bgpq4-utils:0.1

Push the tagged versions to Docker Hub:

$ docker login
$ docker push yourusername/irrd-lab:0.1
$ docker push yourusername/bgpq4-utils:0.1

Now, anyone can use these images in a network emulation lab by pulling them from Docker Hub.

Conclusion

I built two Docker container images for network labs: an all-in-one IRRd server (WHOIS on port 43, web UI on port 8080) and a lightweight bgpq4 utility container. Both are self-contained and disposable, and are compatible with any Docker-capable network emulator. In a future post, I will use them to demonstrate a complete BGP prefix filtering lab.

The post Building IRRd and bgpq4 Docker Containers for Network Labs appeared first on Open-Source Routing and Network Simulation.

I first reviewed Containerlab in 2021 when it was a promising but relatively new container-based network emulator. Five years later, Containerlab has matured into a polished, developer-friendly platform with a rich ecosystem of tools around it. In this post, I will revisit Containerlab and cover what has changed since my original review.

What is Containerlab?

Containerlab is an open-source, container-based network emulation platform that lets you build, run, and tear down realistic network topologies using simple, declarative YAML files. It uses lightweight containers and Linux networking to interconnect routers, switches, hosts, and tools into reproducible labs that behave like real networks. It also supports virtual machines, so it can run many commercial router images.

Containerlab integrates cleanly with automation tools such as Ansible, Nornir, and CI/CD pipelines, and emphasizes “lab-as-code” workflows. It is well suited for network automation development, validating designs and configuration changes, and learning about complex scenarios like BGP, EVPN, or data-center fabrics on a single workstation or server.

The project was originally developed by Nokia engineers and is hosted on GitHub. It has grown into one of the most widely-used open-source network lab platforms, with an active community on Discord and a dedicated documentation site.

What’s Changed Since 2021

Back in 2021, Containerlab was a command-line tool that required sudo for every operation. It required the user to create shell scripts to configure nodes at startup. Users also needed to be very familiar with Docker commands and Linux networking commands to get the most out of the tool.

Today, Containerlab offers rootless operation, declarative node configuration, a full-featured VSCode extension with a graphical topology editor, multiple graph export formats, integrated packet capture, and a thriving community lab catalog. This post will walk through the most significant improvements and show you how the Containerlab experience has changed over the past five years.

Here are the most important changes to Containerlab over the past five years that will affect your day-to-day experience.

MacOS and Windows Support

Containerlab now officially supports macOS (both ARM and Intel) and Windows via WSL2. In 2021, the tool was Linux-only. Linux remains the primary platform, but the ability to run labs on a Mac or Windows machine broadens Containerlab’s reach to more users.

Sudo-less Operation

In 2021, every Containerlab command required sudo.

Containerlab now supports sudo-less operation. The installer sets up a clab_admins Unix group and the installer provides instructions to add your username to the group. Users in this group can run all Containerlab commands without sudo.

Declarative Node Configuration with exec:

In my 2021 review, configuring lab nodes required either logging into each container and manually running commands after deployment or writing shell scripts to run configuration commands. For example, to assign an IP address to a PC, I had to run the following commands in the CLI or in a shell script.

$ sudo docker exec -it clab-frrlab-PC1 /bin/ash
# ip link set eth1 up
# ip addr add 192.168.11.2/24 dev eth1
# ip route add 192.168.0.0/16 via 192.168.11.1 dev eth1
# exit
$

Containerlab now supports an exec: key in the topology file that runs commands inside each container at startup. This means you can configure IP addresses, routes, and other settings declaratively, without separate scripts.

topology:
  nodes:
    PC1:
      kind: linux
      image: wbitt/network-multitool:3.22.2
      exec:
        - ip link set eth1 up
        - ip addr add 192.168.11.2/24 dev eth1
        - ip route add 192.168.0.0/16 via 192.168.11.1 dev eth1

This improves the “lab-as-code” workflow because the entire lab state, such as topology, wiring, and node configuration, lives in a single YAML file (plus any router configuration files you bind-mount).

Imperative Node Configuration with exec CLI command

The clab exec CLI command allows a user to execute a command inside one or more nodes in a lab emulation scenario. In 2021, users had to use the docker exec CLI command to run commands in lab nodes, and they still can if they want to.

The clab exec command is similar to docker exec, but it allows a user to run the same command across multiple lab nodes in the lab topology. Users can use command flags to specify the nodes upon which to execute the command, so it’s useful for running the same command on a group of nodes.

Bridge Node Type

Containerlab added the kind: bridge node type, which creates a Linux bridge that acts as a shared Ethernet segment. This is useful for simulating scenarios like Internet Exchange Points (IXPs) where multiple routers peer over a common LAN.

Integrated Link Impairment Commands

In 2021, users who wanted to cause impairments on network links had to use Linux IP networking commands. Today, Containerlab offers integrated CLI commands that enable users to emulate network link impairments.

The new clab tool netem CLI command enables users to set link speed, corruption, delay, jitter, and loss.

Lab Examples Shipped with the Install

When you install Containerlab, it copies a set of ready-made lab examples to /etc/containerlab/lab-examples/. More example labs available today, compared to 2021. These labs cover a variety of topologies and vendor combinations, from simple FRR labs to multi-vendor data center fabrics.

The lab examples make it easy to explore different network scenarios and often serve as a good starting point for writing your own topology files.

Expanded Device Support

The list of supported network operating systems has grown significantly since 2021. Containerlab now has first-class kind: support for dozens of platforms, including:

• Nokia: SR Linux, SR OS (SR-SIM and vSIM)
• Arista: cEOS, vEOS
• Cisco: XRd, XRv9k, XRv, CSR1000v, Nexus 9000v, 8000, c8000v, IOL, VIOS, ASAv, FTDv, SD-WAN, Catalyst 9000v
• Juniper: cRPD, vMX, vQFX, vSRX, vJunos, cJunos
• Others: Cumulus VX, SONiC, MikroTik RouterOS, VyOS, OpenWRT, Ostinato, and more

When a device has first-class kind: support, Containerlab handles vendor-specific startup requirements (interface naming, management network setup, license handling, etc.) automatically. This is a big improvement over the generic kind: linux approach, which requires users to handle those details themselves.

Open-Source Router Support

For open-source routers, Containerlab still operates the same way it did in 2021. Users of open-source routing software like FRR still have to manage some setup commands, themselves. Containerlab still provides the kind: linux node type, which enables users to run open-source routing stacks like FRR, BIRD, GoBGP, and OpenBGPD in any Linux container.

The good news is that the new exec: command in the topology file, makes it easier to set up and configure open-source routers based on Linux containers.

Improved Visualization Export

The clab graph CLI command has been improved and now supports multiple output formats: HTML, draw.io, Mermaid, Graphviz.

The Containerlab VSCode Extension

The most visible addition to the Containerlab ecosystem is the VSCode extension, which transforms VSCode into a full-featured Containerlab IDE. This extension was developed by the Containerlab community to complement Containerlab’s CLI workflow with a graphical interface.

The extension adds a Containerlab icon to the VSCode activity bar. Clicking it opens an explorer panel with three sections:

• Running labs: Shows all deployed labs on the system. You can expand each lab to see its containers, and expand containers to see their interfaces — including IP addresses, MAC addresses, and MTU values.
• Undeployed local labs: Discovers all *.clab.yml files in your workspace so you can deploy them with a click.
• Help & Feedback: Quick links to documentation and community resources.

Graphical Topology Editor

The standout feature of the Containerlab VSCode extension is a graphical topology creator and viewer built directly into VSCode. The graphical viewer lets you create topologies visually. The lab topology file updates in real-time as you make changes. Creating a split-screen view of the graphical editor alongside the YAML file is a powerful way to design topologies.

When a lab is running, it displays the live topology with deployed node status. You can right-click on nodes to SSH into them, open a container shell, or view container logs, all without leaving VSCode.

Deploy, Destroy, and Manage Labs from VSCode

The extension provides multiple ways to manage lab lifecycle without opening a terminal.

• Deploy/Destroy buttons: When a .clab.yml file is open, deploy and graph buttons appear in the editor title bar.
• Command palette: Press Ctrl+Shift+P and search for Containerlab commands (deploy, redeploy, destroy, graph)
• Context menus: Right-click on a lab nodes in the tree view in the side panel to access all operations

Integrated Packet Capture

In 2021, capturing packets required a multi-step process involving ip netns exec, tcpdump, and piping to Wireshark:

The VSCode extension now provides integrated packet capture. Wireshark runs in a container and streams its GUI directly into a VSCode tab via VNC. No local Wireshark installation is needed. You can start a capture by right-clicking any interface in the tree view and selecting “Start capture.” Capture files can be saved to disk from within the Wireshark session.

Draw.io Integration

The extension can generate draw.io diagrams from your topology. The diagram opens inside a Draw.io editor in VSCode where you can further edit it and save it as a file. This is useful for documentation and presentations.

Installing the Extension

To install the extension, open the Extensions tab in VSCode and search for “Containerlab”, or visit the Visual Studio Marketplace. The extension is free and open-source.

Other Ecosystem Improvements

Several other community contributions have improved the Containerlab experience.

Community Lab Catalog

The Containerlab community maintains a catalog of ready-made lab topologies at clabs.netdevops.me. These community-contributed labs cover a wide range of scenarios — from basic routing protocols to complex multi-vendor data center fabrics. You can deploy many of these labs directly from the catalog, which makes it easy to explore unfamiliar technologies without building a topology from scratch.

Clabernetes: Containerlab on Kubernetes

Clabernetes is a newer project that lets you run Containerlab topologies on Kubernetes clusters. This enables users to scale large labs across multiple nodes in a cluster and run labs in cloud environments. While this is beyond what most individual users need, it shows how far the Containerlab ecosystem has grown.

Install Containerlab

The Containerlab project offers multiple install methods. I chose to install Containerlab from its package repository.

Prerequisites

To install and run Containerlab, you need a Linux host — this can be bare metal, a virtual machine, or Windows Subsystem for Linux (WSL2). Ensure you have at least 4 cores or vCPUs and 8 GB of RAM. The exact resources you need depend on the lab you intend to run; small labs with a few FRR containers will run fine with less, but commercial router images can be more demanding.

Containerlab’s main dependency is Docker. Install Docker and verify it is running before you proceed:

$ sudo systemctl is-active docker

You should see the following output:

active

If Docker is not installed, refer to the Docker installation guide for your distribution.

After installing Docker, add your user to the docker group so you can run Docker commands without sudo:

$ sudo usermod -aG docker $USER
$ newgrp docker

Install Containerlab

The Containerlab project offers multiple install methods. I chose to install it from a package:

$ echo "deb [trusted=yes] https://netdevops.fury.site/apt/ /" | \
  sudo tee -a /etc/apt/sources.list.d/netdevops.list
$ sudo apt update
$ sudo apt install containerlab

After the installer finishes, add your username to the clab_admins group.

$ sudo usermod -aG clab_admins $USER
$ newgrp clab_admins

Restart your computer. Then, check the version to ensure the binary is on your path:

$ clab version

You should see the following output:

  ____ ___  _   _ _____  _    ___ _   _ _____ ____  _       _     
 / ___/ _ \| \ | |_   _|/ \  |_ _| \ | | ____|  _ \| | __ _| |__  
| |  | | | |  \| | | | / _ \  | ||  \| |  _| | |_) | |/ _` | '_ \ 
| |__| |_| | |\  | | |/ ___ \ | || |\  | |___|  _ <| | (_| | |_) |
 \____\___/|_| \_| |_/_/   \_\___|_| \_|_____|_| \_\_|\__,_|_.__/ 

    version: 0.73.0
     commit: 611350001
       date: 2026-02-08T13:22:45Z
     source: https://github.com/srl-labs/containerlab
 rel. notes: https://containerlab.dev/rn/0.73/

Install the VSCode extension (optional)

If you use VSCode, I recommend installing the Containerlab extension. Open the Extensions tab in VSCode, search for “Containerlab”, and install the extension published by SR Labs. You can also install it from the Visual Studio Marketplace.

Deploy and Test a Sample Lab

With Containerlab and Docker installed, let’s deploy a sample lab to verify that everything works. We will use the frr01 example lab that ships with Containerlab and run some tests.

Deploy the frr01 lab

When you installed Containerlab, it copied a set of ready-made lab examples to the directory /etc/containerlab/lab-examples/. The frr01 lab is a small topology with three FRR routers arranged in a triangle, each with a “PC” (a lightweight Linux container) attached to it.

Navigate to the lab directory and deploy:

$ cd /etc/containerlab/lab-examples/frr01
$ clab deploy

You will see output indicating that container images are being pulled (on the first run), containers started, links created, and configurations applied. When the deployment finishes, Containerlab prints a summary table:

╭────────────────────┬─────────────────────────────────┬─────────┬───────────────────╮
│        Name        │            Kind/Image           │  State  │   IPv4/6 Address  │
├────────────────────┼─────────────────────────────────┼─────────┼───────────────────┤
│ clab-frr01-PC1     │ linux                           │ running │ 172.20.20.5       │
│                    │ wbitt/network-multitool:3.22.1  │         │ 3fff:172:20:20::5 │
├────────────────────┼─────────────────────────────────┼─────────┼───────────────────┤
│ clab-frr01-PC2     │ linux                           │ running │ 172.20.20.6       │
│                    │ wbitt/network-multitool:3.22.1  │         │ 3fff:172:20:20::6 │
├────────────────────┼─────────────────────────────────┼─────────┼───────────────────┤
│ clab-frr01-PC3     │ linux                           │ running │ 172.20.20.4       │
│                    │ wbitt/network-multitool:3.22.1  │         │ 3fff:172:20:20::4 │
├────────────────────┼─────────────────────────────────┼─────────┼───────────────────┤
│ clab-frr01-router1 │ linux                           │ running │ 172.20.20.3       │
│                    │ quay.io/frrouting/frr:10.5.1    │         │ 3fff:172:20:20::3 │
├────────────────────┼─────────────────────────────────┼─────────┼───────────────────┤
│ clab-frr01-router2 │ linux                           │ running │ 172.20.20.2       │
│                    │ quay.io/frrouting/frr:10.5.1    │         │ 3fff:172:20:20::2 │
├────────────────────┼─────────────────────────────────┼─────────┼───────────────────┤
│ clab-frr01-router3 │ linux                           │ running │ 172.20.20.7       │
│                    │ quay.io/frrouting/frr:10.5.1    │         │ 3fff:172:20:20::7 │
╰────────────────────┴─────────────────────────────────┴─────────┴───────────────────╯

All six containers are running. The routers use the FRR image and the PCs use the wbitt/network-multitool image, a lightweight Alpine-based container with common network tools.

Test connectivity

The frr01 lab comes pre-configured with OSPF routing, so all PCs should be able to reach each other through the router mesh. Run a quick ping from PC1 to PC3 to verify:

$ clab exec --label clab-node-name=PC1 --cmd "ping -c 3 192.168.13.2"
20:42:55 INFO Executed command node=clab-frr01-PC1 command="ping -c 3 192.168.13.2"
  stdout=
  │ PING 192.168.13.2 (192.168.13.2) 56(84) bytes of data.
  │ 64 bytes from 192.168.13.2: icmp_seq=1 ttl=62 time=0.059 ms
  │ 64 bytes from 192.168.13.2: icmp_seq=2 ttl=62 time=0.045 ms
  │ 64 bytes from 192.168.13.2: icmp_seq=3 ttl=62 time=0.040 ms
  │ 
  │ --- 192.168.13.2 ping statistics ---
  │ 3 packets transmitted, 3 received, 0% packet loss, time 2061ms
  │ rtt min/avg/max/mdev = 0.040/0.048/0.059/0.008 ms

Note: We use clab exec to run the ping command because the FRR and multitool containers are based on Alpine Linux and do not include an SSH server. For containers that support SSH, Containerlab provides a built-in ssh command.

The pings succeed, which confirms that Containerlab deployed the containers, created the virtual links between them, and applied the routing configuration correctly.

Test OSPF Adjacencies

The clab exec CLI command can run commands on multiple nodes, and you can select the nodes using labels. For example, the frr01.clab.yml topology file organizes nodes into two groups: routers and hosts.

To show the OSPF neighbour status on all routers using one command, run the following:

$ clab exec --label clab-node-group=routers --cmd "vtysh -c 'show ip ospf neighbor'"
22:11:26 INFO Executed command node=clab-frr01-router1 command="vtysh -c show ip ospf neighbor"
  stdout=
  │ 
  │ Neighbor ID     Pri State           Up Time         Dead Time Address         Interface                        RXmtL RqstL DBsmL
  │ 10.10.10.2        1 Full/DR         1h29m27s          32.842s 192.168.1.2     eth1:192.168.1.1                     0     0     0
  │ 10.10.10.3        1 Full/DR         1h29m27s          32.842s 192.168.2.2     eth2:192.168.2.1                     0     0     0
  │ 

22:11:26 INFO Executed command node=clab-frr01-router2 command="vtysh -c show ip ospf neighbor"
  stdout=
  │ 
  │ Neighbor ID     Pri State           Up Time         Dead Time Address         Interface                        RXmtL RqstL DBsmL
  │ 10.10.10.1        1 Full/Backup     1h29m27s          32.932s 192.168.1.1     eth1:192.168.1.2                     0     0     0
  │ 10.10.10.3        1 Full/DR         1h29m22s          32.932s 192.168.3.2     eth2:192.168.3.1                     0     0     0
  │ 

22:11:26 INFO Executed command node=clab-frr01-router3 command="vtysh -c show ip ospf neighbor"
  stdout=
  │ 
  │ Neighbor ID     Pri State           Up Time         Dead Time Address         Interface                        RXmtL RqstL DBsmL
  │ 10.10.10.1        1 Full/Backup     1h29m27s          32.885s 192.168.2.1     eth1:192.168.2.2                     0     0     0
  │ 10.10.10.2        1 Full/Backup     1h29m22s          32.886s 192.168.3.1     eth2:192.168.3.2                     0     0     0
  │ 

Visualize the topology with containerlab graph

Now let’s try the improved graph command. While still in the frr01 lab directory, run:

$ clab graph

Containerlab starts a local web server on port 50080. Open your browser and navigate to http://localhost:50080. You will see an interactive topology diagram showing the six nodes and the links between them. The graph displays node names, link endpoints, and — because the lab is running — live data such as management IP addresses.

Press Ctrl+C in the terminal to stop the graph web server when you are done.

You can also export the topology to other formats without starting a web server. For example, generate a dot file for use in Graphviz:

$ clab graph --dot

Or generate a Mermaid diagram for use in Markdown documentation:

$ clab graph --mermaid

Visualize the topology in VSCode

If you installed the Containerlab VSCode extension, you can visualize the topology directly inside your editor.

Start VSCode and open the folder containing the lab topology file. The Containerlab extension will automatically detect a running lab.

TopoViewer

Double-click on the frr01.clab.yml topology file in VSCode. This opens the TopoViewer panel with an interactive diagram of the running lab. You can right-click on nodes to SSH into them or open a container shell.

Draw.io view

You can also use Draw.io, if you prefer.

In the Containerlab sidebar panel, right-click on the running lab and hover over Graph Lab (draw.io). Choose a layout mode (horizontal, vertical, or interactive) and a Draw.io diagram opens inside VSCode.

You can save the Draw.io graph as a file and import it into other programs that support that format.

Tear down the lab

When you are finished exploring, destroy the lab to clean up all containers and virtual links:

$ clab destroy

You should see output confirming that each container has been removed. At this point, you have confirmed that Containerlab, Docker networking, visualization tools, and your user permissions are all working correctly.

Perform more network emulation experiments

At this point, you have a running lab that you may use for learning or validation. You can add configurations to any node and experiment with IP networking functionality.

Some experiments you might try are:

• Verify the routing table from the PCs
• Watch OSPF routes on the routers
• Break a link and observe OSPF convergence
• Add delay, jitter, or loss to links and test the impact
• Capture packets on a link
• …and more

Conclusion

Five years after my original review, Containerlab has matured from a promising CLI tool into a polished, developer-friendly network lab platform with a rich ecosystem surrounding it.

The most visible change is the tooling that now surrounds Containerlab. The VSCode extension turns your editor into a full lab management environment. You can design topologies graphically with TopoViewer, deploy and destroy labs with keyboard shortcuts, and generate diagrams for documentation. Features like Wireshark integration, the community lab catalog at clabs.netdevops.me, and Clabernetes for Kubernetes deployment round out an ecosystem that did not exist five years ago.

If you have not tried Containerlab recently, or if you have never tried it at all, I encourage you to install it and deploy one of the bundled example labs.

The post Containerlab Network Emulator v0.73 Review appeared first on Open-Source Routing and Network Simulation.

Kathará is a container-based network emulator developed by researchers at Roma Tre University in Italy as a modern successor to the Netkit network emulator. Coincidentally, Roma Tre University is also the same organization that developed BGPlay, a tool used to investigate BGP incidents.

Kathará uses Docker containers to emulate network devices. This approach enables users to create complex network topologies comprised of dozens of routers on a modest laptop. Kathará uses simple text-based configuration files that are easy to version-control and share. It’s open source, actively maintained, and runs on Linux, Windows, and MacOS.

In this tutorial, I will use the Kathará network emulator to recreate one of the most famous BGP hijacking incidents in Internet history, the 2008 YouTube hijack. By building a small network topology and simulating a similar attack, we will learn both the fundamentals of Kathará and to gain hands-on experience with BGP security concepts.

Install Kathará

First, we will install the Kathará network emulator and test it by setting up a basic lab environment.

Install Docker

Kathará uses Docker as its container runtime. Install Docker on your Linux system using the official Docker installation guide.

After that, add your user to the docker group so you can run containers without sudo:

$ sudo usermod -aG docker $USER

Log out and log back in for the group change to take effect. Verify Docker is working:

$ docker run hello-world

You should see a message confirming Docker is installed correctly.

Install Kathará

The install instructions on the Kathará wiki are outdated[^1] and do not work in Ubuntu 24.04 because they use the deprecated apt-key command. You can skip the apt-key command. Instead, follow the Kathara instructions on the Launchpad platform to add the Kathará PPA to Ubuntu, then install Kathará.

I summarize the modified install commands, below:

$ sudo add-apt-repository ppa:katharaframework/kathara
$ sudo apt update
$ sudo apt install kathara

Verify the installation:

$ kathara --version

You should see output showing the Kathará version, which was 3.8.0 when I wrote this post.

Verify Your Setup

Run a the check command to proactively download the Kathará base container and the Kathará network plugin container, and validate that Kathará can communicate with Docker:

$ kathara check

With your environment ready, we can move on to configuring Kathará.

Set the Terminal Emulator

Run the kathara settings command and set the terminal emulator used by emulated devices to be the Gnome Terminal. Alternatively, you could install xterm, because it is the default used by Kathará.

$ kathara settings

In the menu that appears, select 5, for Choose terminal:

  ╔═════════════════════════════════════════════════════════════════════════╗
  ║                                                                         ║
  ║                            Kathara Settings                             ║
  ║                                                                         ║
  ╠═════════════════════════════════════════════════════════════════════════╣
  ║                                                                         ║
  ║                      Choose the option to change.                       ║
  ║                                                                         ║
  ╠═════════════════════════════════════════════════════════════════════════╣
  ║                                                                         ║
  ║    1 - Choose default manager                                           ║
  ║    2 - Choose default image                                             ║
  ║    3 - Automatically open terminals on startup                          ║
  ║    4 - Choose device shell to be used                                   ║
  ║    5 - Choose terminal emulator to be used                              ║
  ║    6 - Choose Kathara prefixes                                          ║
  ║    7 - Choose logging level to be used                                  ║
  ║    8 - Print Startup Logs on device startup                             ║
  ║    9 - Enable IPv6                                                      ║
  ║   10 - Choose Docker Network Plugin version                             ║
  ║   11 - Automatically mount /hosthome on startup                         ║
  ║   12 - Automatically mount /shared on startup                           ║
  ║   13 - Docker Image Update Policy                                       ║
  ║   14 - Enable Shared Collision Domains                                  ║
  ║   15 - Configure a remote Docker connection                             ║
  ║   16 - Exit                                                             ║
  ║                                                                         ║
  ║                                                                         ║
  ╚═════════════════════════════════════════════════════════════════════════╝
  >> 5

Then, choose 2, to select gnome-terminal:

  ╔═════════════════════════════════════════════════════════════════════════╗
  ║                                                                         ║
  ║                   Choose terminal emulator to be used                   ║
  ║                                                                         ║
  ║                         Current: /usr/bin/xterm                         ║
  ║                                                                         ║
  ╠═════════════════════════════════════════════════════════════════════════╣
  ║                                                                         ║
  ║     Terminal emulator application to be used for device terminals.      ║
  ║   **The application must be correctly installed in the host system!**   ║
  ║                      Default is `/usr/bin/xterm`.                       ║
  ║                                                                         ║
  ╠═════════════════════════════════════════════════════════════════════════╣
  ║                                                                         ║
  ║    1 - /usr/bin/xterm                                                   ║
  ║    2 - /usr/bin/gnome-terminal                                          ║
  ║    3 - TMUX                                                             ║
  ║    4 - Choose another terminal emulator                                 ║
  ║    5 - Return to Kathara Settings                                       ║
  ║                                                                         ║
  ║                                                                         ║
  ╚═════════════════════════════════════════════════════════════════════════╝
  >> 2

Then select 16 to Exit.

Pull the FRR Docker Image

We’ll use the kathara/frr Docker image, which includes FRRouting, an open-source routing suite that supports BGP, OSPF, and other protocols. Pull it now to save time later:

$ docker pull kathara/frr

Test a very simple lab

To verify that Kathará is working, and to get an initial view of how Kathara labs are created and nodes are configured, let’s create a minimal lab with two FRR routers connected to each other and test connectivity between them.

First, create a directory for your test lab:

$ mkdir -p ~/Kathara/kathara-test
$ cd ~/Kathara/kathara-test

Create the lab.conf file that defines two routers connected by a shared network segment:

$ cat > lab.conf << 'EOF'
LAB_NAME="Simple Two-Router Test"
r1[0]="link1"
r1[image]="kathara/frr"
r2[0]="link1"
r2[image]="kathara/frr"
EOF

Create startup scripts to assign IP addresses to each router:

$ cat > r1.startup << 'EOF'
ip addr add 10.0.0.1/24 dev eth0
ip link set eth0 up
EOF

$ cat > r2.startup << 'EOF'
ip addr add 10.0.0.2/24 dev eth0
ip link set eth0 up
EOF

The lab directory should now contain:

kathara-test/
├── lab.conf
├── r1.startup
└── r2.startup

Start the lab:

$ kathara lstart

Kathara reads the lab.conf file and the two startup files to set up and configure the lab. You should see output indicating both routers have started:

┌─────────────────────────────────────────────────────────────────────────────────────┐
│                              Starting Network Scenario                              │
└─────────────────────────────────────────────────────────────────────────────────────┘
┌─────────────────────────────────────────────────────────────────────────────────────┐
│ Name: Simple Two-Router Test                                                        │
└─────────────────────────────────────────────────────────────────────────────────────┘
[Deploying collision domains]   ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 1/1
[Deploying devices]   ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 2/2

And, you should see two new terminal windows. Each one is connected to one of the routers in the lab. By default, Kathara starts terminals with the Bash shell.

Inside the r1 container’s terminal window, ping r2’s IP address:

root@r1:/# ping -c2 10.0.0.2
PING 10.0.0.2 (10.0.0.2) 56(84) bytes of data.
64 bytes from 10.0.0.2: icmp_seq=1 ttl=64 time=0.995 ms
64 bytes from 10.0.0.2: icmp_seq=2 ttl=64 time=1.08 ms

--- 10.0.0.2 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 0.995/1.038/1.081/0.043 ms
root@r1:/# 

We demonstrated that a simple lab with two routers works as expected. Clean up the lab:

$ kathara lclean

This removes all containers and networks created for the lab.

┌─────────────────────────────────────────────────────────────────────────────────────┐
│                              Stopping Network Scenario                              │
└─────────────────────────────────────────────────────────────────────────────────────┘
[Deleting devices]   ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 2/2
[Deleting collision domains]   ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 1/1

With Kathará working correctly, we’re ready to build more complex topologies.

Understanding BGP Hijacks and Route Leaks

BGP hijacks and route leaks are among the most significant threats to Internet routing security. Understanding how these incidents occur helps network engineers implement proper safeguards. By recreating these scenarios in a safe, isolated lab environment, one can observe exactly how prefix hijacks propagate through a network and experiment with mitigation techniques without affecting real infrastructure.

Origin Hijack

An origin hijack occurs when an AS announces a prefix it doesn’t legitimately own. The hijacking AS claims to be the origin of the route, essentially saying “I own this IP address range” when it doesn’t.

For example, if AS400 legitimately owns the prefix 40.40.0.0/16, an origin hijack would occur if AS300 started announcing that same prefix as if it originated there. Routers receiving both announcements would choose between them based on BGP path selection rules. Depending on network topology, some parts of the Internet might start sending traffic for 40.40.0.0/16 toward AS300 instead of the legitimate owner, AS400.

More-Specific Prefix Hijack

More-specific prefix hijack is a variant of origin hijacking. Instead of announcing the same prefix as the victim, the attacker announces a more-specific, or longer, prefix that falls within the victim’s address space.

BGP routers always prefer more-specific routes. If AS400 announces 40.40.0.0/16 and an attacker announces 40.40.0.0/17 and 40.40.128.0/17, the attacker’s more-specific /17 routes will be preferred everywhere in the Internet, completely overriding the legitimate /16 announcement.

Route Leak

A route leak occurs when an AS violates the expected routing policies by redistributing routes in ways that break the traditional customer-provider-peer relationships on the Internet. Unlike origin hijacks or more-specific prefix hijacks, the origin AS information remains correct. The problem is that the route is propagated where it shouldn’t be.

Route leaks are almost always accidental and are usually caused by misconfiguration, but their effects can be severe. When a small customer AS suddenly appears to offer a shortcut to major networks, traffic can flood through infrastructure that was never designed to handle it.

The 2008 Pakistan YouTube Hijack

The incident we’ll recreate is the famous YouTube hijacking that occurred on February 24, 2008, when Pakistan Telecom (AS17557) accidentally blocked YouTube globally. This event has become a textbook example of how BGP vulnerabilities can have worldwide impact and is well-documented by RIPE NCC and other organizations.

The key players were:

• YouTube (AS36561): The victim, legitimately announcing prefix 208.65.152.0/22
• Pakistan Telecom (AS17557): The hijacker, who announced the more-specific prefix 208.65.153.0/24
• PCCW (AS3491): Pakistan Telecom’s upstream provider who propagated the hijack
• Various upstream providers: Who received and further propagated the bogus route

What Happened

The Pakistan government ordered local ISPs to block access to YouTube due to content the government deemed offensive. Pakistan Telecom attempted to comply by creating a blackhole route for a more specific prefix that was part of YouTube’s allocated IP address space. However, instead of keeping this route prefix internal to their own network, they accidentally announced it to the global Internet through their upstream provider PCCW (AS3491).

YouTube was announcing their address space as a /22 prefix (208.65.152.0/22), which covers IP addresses from 208.65.152.0 to 208.65.155.255. Pakistan Telecom announced a /24 prefix (208.65.153.0/24), which is a subset of YouTube’s range.

BGP’s “longest prefix match” rule means routers always prefer more-specific routes. A /24 prefix is more specific than a /22, so routers receiving both announcements would send traffic for 208.65.153.0/24 toward Pakistan Telecom where it was blackholed. This affected global YouTube traffic because PCCW propagated the announcement to their peers and transit providers, who propagated the more-specific prefixes worldwide.

YouTube responded to the attack by announcing even-more-specific prefixes 208.65.153.128/25 and 208.65.153.0/25. Routers that received these announcements would have preferred the more-specific prefix and sent the traffic to YouTube. Eventually, PCCW properly resolved the problem by filtering the offending route.

This incident represents a straightforward BGP hijack with no other complications like AS-path manipulation. It demonstrates both the attack and the mitigation so it is a good BGP security example to study in a lab.

Kathará BGP Lab Setup

When you start a lab, Kathará reads the lab configuration files in the lab folder, creates Docker containers for each device, and sets up virtual network interfaces to connect them. The Kathará man pages provide information about how to use the command line interface and the Kathará Lab man pages provide information about building lab configuration files.

The kathara/frr image we pulled earlier contains FRRouting, which enables us to create fully-featured routers capable of running BGP, OSPF, IS-IS, and other routing protocols. Kathará also provides base images for simple hosts, and you can use other Kathará device images or any other Docker image that suits your needs.

What We’ll Build

In our lab, we’ll create a simplified 4-AS topology that will help us emulate this incident:

                     +----------+
                     | upstream |
                     |  AS400   |
                     +----+-----+
                          |
                          | 10.0.3.0/24
                          |
                     +----+-----+
                     | transit  |
                     |  AS300   |
                     +----+-----+
                    /            \
       10.0.1.0/24 /              \ 10.0.2.0/24
                  /                \
           +-----+----+       +-----+-----+
           | youtube  |       | pakistan  |
           |  AS100   |       |  AS200    |
           +----------+       +-----------+
             (Victim)          (Hijacker)

In this topology:

• AS100 (YouTube) is the victim, legitimately announcing 100.100.0.0/22
• AS200 (Pakistan Telecom) is the hijacker, who will announce a more-specific 100.100.0.0/24
• AS300 (Transit/PCCW) is the transit provider connecting both ASes to the Internet
• AS400 (Upstream) represents upstream providers who observe the hijack propagation

We’ll first configure this topology during normal BGP operations where only AS100 announces its prefix. Then we’ll introduce the hijack by having AS200 announce a more-specific prefix, and observe how it overrides the legitimate route. Finally, we’ll demonstrate how AS100 can counter the hijack using even more-specific announcements.

Lab Structure

As you saw in our simple test, above, a Kathará lab is simply a directory containing configuration files that describe your network topology and configuration. The lab file and directory structure is straightforward. The lab.conf file is mandatory. Other files or folders are optional.

Lab Configuration File Syntax

The best way to learn the lab configuration file syntax is to look at the example labs provided by the Kathará team.

If you want to see all options that are available, the Kathará team provides man-pages documentation for the syntax of each lab configuration file. See the links below:

• lab.conf: mandatory configuration file syntax manual
• lab.dep: optional configuration file syntax manual
• lab.ext: optional configuration file syntax manual

Device Directories and Lab Structure

For each device in your lab, you will usually create a directory with the same name. Files in this directory are copied into the container’s filesystem when the lab starts. This is how you provide configuration files to your devices.

In this lab example, you will create a directory structure like the one shown below:

bgp-youtube-hijack/
├── lab.conf
├── youtube/
│   └── etc/
│       └── frr/
│           ├── daemons
│           └── frr.conf
├── youtube.startup
├── pakistan/
│   └── etc/
│       └── frr/
│           ├── daemons
│           └── frr.conf
├── pakistan.startup
├── transit/
│   └── etc/
│       └── frr/
│           ├── daemons
│           └── frr.conf
├── transit.startup
├── upstream/
│   └── etc/
│       └── frr/
│           ├── daemons
│           └── frr.conf
└── upstream.startup

The contents of youtube/etc/frr/ will appear at /etc/frr/ inside the youtube container. This allows you to pre-configure FRR’s routing daemons with the required BGP settings.

BGP Lab Config File

To emulate a small network in which we can “replay” the famous YouTube BGP Hijack incident, we create a lab.conf file that creates four routers connected as shown in the diagram above.

First, create the lab directory

$ mkdir -p ~/Kathara/bgp-youtube-hijack
$ cd ~/Kathara/bgp-youtube-hijack

Create the lab.conf file in your favorite editor and enter the following configuration information:

# ~/bgp-youtube-hijack/lab.conf

LAB_NAME="YouTube BGP Hijack 2008" 
LAB_DESCRIPTION="This lab recreates the famous February 24, 2008 incident where Pakistan Telecom (AS17557) hijacked YouTube's traffic by announcing a more-specific prefix within YouTube's allocated IP address space."
LAB_VERSION=1.0

# YouTube (Victim) - AS100
youtube[0]="link_youtube_transit"
youtube[image]="kathara/frr"

# Pakistan Telecom (Hijacker) - AS200
pakistan[0]="link_pakistan_transit"
pakistan[image]="kathara/frr"

# Transit/PCCW - AS300
transit[0]="link_youtube_transit"
transit[1]="link_pakistan_transit"
transit[2]="link_transit_upstream"
transit[image]="kathara/frr"

# Upstream Observer - AS400
upstream[0]="link_transit_upstream"
upstream[image]="kathara/frr"

The syntax follows a simple pattern: device[interface]="collision_domain", where “collision domain” is simply the name you assign a network segment. All devices with interfaces on the same network segment can communicate directly with each other.

The device[image] property specifies which Docker image to use for each device. In this example, we are using the kathara/frr image for all routers, but you could use different images like kathara/bird or vyos, if you wish.

IP Addressing Scheme

Before we configure the routers, we must first establish the IP addressing plan:

Loopback addresses

Each AS router will have one or two loopback addresses that are reachable within its advertised prefix. The loopback addresses and announced prefixes for this hijack scenario will be:

Notice that YouTube announces 100.100.0.0/22 while Pakistan will announce 100.100.0.0/24, which is a more-specific prefix within YouTube’s range, after we trigger the hijack.

FRR Daemons Configuration

Each router needs a daemons file to tell FRR which routing protocols to enable. Create the directory structure and daemons file for each device. The content is identical for all routers:

$ mkdir -p youtube/etc/frr
$ mkdir -p pakistan/etc/frr
$ mkdir -p transit/etc/frr
$ mkdir -p upstream/etc/frr

Create the daemons file for each router. Here’s the content, which is the same for all four:

For the YouTube router, create the daemons file. In this lab scenario, the /etc/frr/daemons file copied to each router will contain the following configuration:

# /etc/frr/daemons
zebra=yes
bgpd=yes
vtysh_enable=yes
zebra_options="  -A 127.0.0.1 -s 90000000"
bgpd_options="   -A 127.0.0.1"

Save this content to:

• youtube/etc/frr/daemons
• pakistan/etc/frr/daemons
• transit/etc/frr/daemons
• upstream/etc/frr/daemons

frr.conf Files

Each router is pre-configured with an frr.conf file.

YouTube Configuration (AS100) — The Victim

The following FRR configuration file sets up BGP with AS number 100, representing YouTube’s AS36561, peers with Transit at 10.0.1.2 (AS300), and announces the 100.100.0.0/16 prefix, representing YouTube’s 208.65.152.0/22.

Create youtube/etc/frr/frr.conf:

frr version 9.1
frr defaults traditional
hostname youtube
log syslog informational
no ipv6 forwarding
service integrated-vtysh-config
!
interface eth0
 ip address 10.0.1.1/24
 description Link to Transit
exit
!
interface lo
 ip address 100.100.0.1/32
 ip address 100.100.1.1/32
 description Loopbacks - within announced /22 prefix
exit
!
router bgp 100
 bgp router-id 100.100.0.1
 no bgp ebgp-requires-policy
 neighbor 10.0.1.2 remote-as 300
 neighbor 10.0.1.2 description Transit-PCCW
 address-family ipv4 unicast
  network 100.100.0.0/22
  neighbor 10.0.1.2 activate
 exit-address-family
exit
!
ip route 100.100.0.0/22 blackhole
!
end

This lab scenario, YouTube is the legitimate owner of the 100.100.0.0/22 prefix.

Pakistan Telecom Configuration (AS200) — The Hijacker

Initially, Pakistan Telecom will NOT announce the hijacked prefix. We’ll add that later to demonstrate the hijack. For now, it only announces its own legitimate prefix.

Create pakistan/etc/frr/frr.conf:

frr version 9.1
frr defaults traditional
hostname pakistan
log syslog informational
no ipv6 forwarding
service integrated-vtysh-config
!
interface eth0
 ip address 10.0.2.2/24
 description Link to Transit
exit
!
interface lo
 ip address 200.200.0.1/32
 description Loopback - within announced /16 prefix
exit
!
router bgp 200
 bgp router-id 200.200.0.1
 no bgp ebgp-requires-policy
 neighbor 10.0.2.1 remote-as 300
 neighbor 10.0.2.1 description Transit-PCCW
 address-family ipv4 unicast
  network 200.200.0.0/16
  neighbor 10.0.2.1 activate
 exit-address-family
exit
!
ip route 200.200.0.0/16 blackhole
!
end

Transit/PCCW Configuration (AS300)

Transit represents PCCW (AS3491), the provider that connected both YouTube and Pakistan Telecom and inadvertently propagated the hijack. It peers with all three other ASes and provides transit.

Create transit/etc/frr/frr.conf:

frr version 9.1
frr defaults traditional
hostname transit
log syslog informational
no ipv6 forwarding
service integrated-vtysh-config
!
interface eth0
 ip address 10.0.1.2/24
 description Link to YouTube
exit
!
interface eth1
 ip address 10.0.2.1/24
 description Link to Pakistan
exit
!
interface eth2
 ip address 10.0.3.1/24
 description Link to Upstream
exit
!
interface lo
 ip address 30.30.0.1/32
 description Loopback - within announced /16 prefix
exit
!
router bgp 300
 bgp router-id 30.30.0.1
 no bgp ebgp-requires-policy
 !
 neighbor 10.0.1.1 remote-as 100
 neighbor 10.0.1.1 description YouTube
 !
 neighbor 10.0.2.2 remote-as 200
 neighbor 10.0.2.2 description Pakistan-Telecom
 !
 neighbor 10.0.3.2 remote-as 400
 neighbor 10.0.3.2 description Upstream
 !
 address-family ipv4 unicast
  network 30.30.0.0/16
  neighbor 10.0.1.1 activate
  neighbor 10.0.2.2 activate
  neighbor 10.0.3.2 activate
 exit-address-family
exit
!
ip route 30.30.0.0/16 blackhole
!
end

Note that Transit has no outbound filtering—it simply propagates all routes it learns. This is the configuration weakness that allowed the real-world hijack to spread globally.

Upstream Configuration (AS400)

Upstream represents the broader Internet—a provider that will receive and observe routes from Transit. This is where we’ll see the hijack propagate.

Create upstream/etc/frr/frr.conf:

frr version 9.1
frr defaults traditional
hostname upstream
log syslog informational
no ipv6 forwarding
service integrated-vtysh-config
!
interface eth0
 ip address 10.0.3.2/24
 description Link to Transit
exit
!
interface lo
 ip address 40.40.0.1/32
 description Loopback - within announced /16 prefix
exit
!
router bgp 400
 bgp router-id 40.40.0.1
 no bgp ebgp-requires-policy
 neighbor 10.0.3.1 remote-as 300
 neighbor 10.0.3.1 description Transit-PCCW
 address-family ipv4 unicast
  network 40.40.0.0/16
  neighbor 10.0.3.1 activate
 exit-address-family
exit
!
ip route 40.40.0.0/16 blackhole
!
end

Startup Files

The <device>.startup file is a shell script that runs inside the container when it starts. This is where you configure network interfaces, start services, or run any initialization commands.

How Kathará Creates Ethernet Interfaces

Before each node’s startup script runs, Kathará creates network interfaces on each node based on the lab.conf file. So, to avoid conflicts or weird behaviour, we should not create interfaces in the device startup files or by copying network interface configuration files into the node container.

When the kathara lstart command is run, Kathará creates the Docker container for a node, creates virtual ethernet interfaces like eth0, eth1, etc. and attaches them to the container, connects each interface to the specified collision domain (virtual network bridge), and then runs the node’s startup script.

The interfaces exist and are in “DOWN” state when your startup script begins.

Interface Naming Convention

The Ethernet device numbering convention matches the numbers defines in the lab.conf file. For example, the Transit router’s interfaces would be mapped from teh configuration file to the container as follows:

• transit[0] = eth0
• transit[1] = eth1
• transit[2] = eth2

youtube.startup

Create the file youtube.startup and add the following startup commands:

#!/bin/bash

ip link set eth0 up

/etc/init.d/frr start

Save the file in the lab directory, ~/bgp-youtube-hijack/.

The startup file executes after the device directory contents are copied into the container, so you can reference any configuration files you’ve provided.

pakistan.startup

Create pakistan.startup:

#!/bin/bash

ip link set eth0 up

/etc/init.d/frr start

transit.startup

Create transit.startup:

#!/bin/bash

ip link set eth0 up
ip link set eth1 up
ip link set eth2 up

/etc/init.d/frr start

upstream.startup

Create upstream.startup:

#!/bin/bash

ip link set eth0 up

/etc/init.d/frr start

Ready to start

Now we have a Kathará lab directory that contains a lab.conf file, router startup files, and sub-directories containing the configuration files for each router. We are ready to use the Kathará command-line interface.

Kathará Command Line Interface

Kathará provides a simple set of commands to manage your labs. Here are the ones you’ll use most often:

Starting the Lab

To start a lab, navigate to the lab directory and run:

$ kathara lstart

Kathará reads lab.conf, creates the necessary containers and networks, and executes each device’s startup script. You’ll see output as each device comes online:

┌─────────────────────────────────────────────────────────────────────────────────────┐
│                              Starting Network Scenario                              │
└─────────────────────────────────────────────────────────────────────────────────────┘
[Deploying collision domains]   ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 3/3
[Deploying devices]   ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 4/4

You will also see four terminal windows appear. each one is connected to a different router in the lab.

Connecting to a Device

If you closed a router’s terminal window, you can open another terminal session on a running device. Open a terminal window and enter the command:

$ kathara connect router1

This drops you into a shell inside the router container where you can run commands, check routing tables, or configure the device interactively. To exit, type exit or press Ctrl+D.

Checking Lab Status

To see information about a running lab:

$ kathara linfo

This displays details about all running devices, their interfaces, and which collision domains they’re connected to.

┌──────────────────────┬──────────┬─────────────────────┬─────────┬────────────────────┬──────┬───────────┬─────────────────────┬─────────────┬───────────────────┬──────────────────────┐
│ NETWORK SCENARIO ID  │ NAME     │ USER                │ STATUS  │ IMAGE              │ PIDS │ CPU USAGE │ MEM USAGE           │ MEM PERCENT │ NET USAGE         │ INTERFACES           │
╞══════════════════════╪══════════╪═════════════════════╪═════════╪════════════════════╪══════╪═══════════╪═════════════════════╪═════════════╪═══════════════════╪══════════════════════╡
│ GBhCCLpizE6xM9yUZKj… │ pakistan │ blinklet-hlipcf4s0… │ running │ kathara/frr:latest │ 17   │ 0.02%     │ 22.77 MB / 62.55 GB │ 0.04 %      │ 1.77 KB / 1.66 KB │ 0:link_pakistan_tra… │
├──────────────────────┼──────────┼─────────────────────┼─────────┼────────────────────┼──────┼───────────┼─────────────────────┼─────────────┼───────────────────┼──────────────────────┤
│ GBhCCLpizE6xM9yUZKj… │ youtube  │ blinklet-hlipcf4s0… │ running │ kathara/frr:latest │ 17   │ 0.02%     │ 22.75 MB / 62.55 GB │ 0.04 %      │ 1.77 KB / 1.66 KB │ 0:link_youtube_tran… │
├──────────────────────┼──────────┼─────────────────────┼─────────┼────────────────────┼──────┼───────────┼─────────────────────┼─────────────┼───────────────────┼──────────────────────┤
│ GBhCCLpizE6xM9yUZKj… │ upstream │ blinklet-hlipcf4s0… │ running │ kathara/frr:latest │ 17   │ 0.03%     │ 22.81 MB / 62.55 GB │ 0.04 %      │ 1.77 KB / 1.66 KB │ 0:link_transit_upst… │
├──────────────────────┼──────────┼─────────────────────┼─────────┼────────────────────┼──────┼───────────┼─────────────────────┼─────────────┼───────────────────┼──────────────────────┤
│ GBhCCLpizE6xM9yUZKj… │ transit  │ blinklet-hlipcf4s0… │ running │ kathara/frr:latest │ 17   │ 0.02%     │ 24.87 MB / 62.55 GB │ 0.04 %      │ 5.25 KB / 5.04 KB │ 0:link_youtube_tran… │
│                      │          │                     │         │                    │      │           │                     │             │                   │ 1:link_pakistan_tra… │
│                      │          │                     │         │                    │      │           │                     │             │                   │ 2:link_transit_upst… │
└──────────────────────┴──────────┴─────────────────────┴─────────┴────────────────────┴──────┴───────────┴─────────────────────┴─────────────┴───────────────────┴──────────────────────┘

Stopping and Cleaning Up

When you’re done with a lab, clean up all containers and networks:

$ kathara lclean

This stops and removes all containers created for the lab. Always run this before starting a modified version of your lab to ensure you’re working with a fresh environment.

With these fundamentals covered, you now understand how Kathará structures labs and how to interact with them.

In the next sections, we’ll use the virtual routers that have been created and interconnected by Kathará, as described in the lab.cong file and the router configuration files, to explore how the 2008 YouTube Hijack occurred and how it was mitigated.

Discover the Normal BGP State

First, we will establish the “normal” state of the lab. On each router, verify that the BGP sessions are established and YouTube’s prefix is being announced correctly to “upstream” systems.

Check Upstream (Observer)

We’ll start with Upstream since this is where we’ll observe the hijack’s effect. Connect and check the BGP table on the router named upstream. A terminal window connected to upstream should already be open on your desktop. If not, use Kathará’s connect command:

$ kathara connect upstream

The, start the FRR CLI, vtysh, and check BGP status:

root@upstream:/# vtysh
upstream# show ip bgp summary

You should see output showing the BGP session with Transit (AS300) is established:

IPv4 Unicast Summary (VRF default):
BGP router identifier 40.40.40.1, local AS number 400 vrf-id 0
BGP table version 4
RIB entries 7, using 672 bytes of memory
Peers 1, using 20 KiB of memory

Neighbor        V         AS   MsgRcvd   MsgSent   TblVer  InQ OutQ  Up/Down State/PfxRcd   PfxSnt Desc
10.0.3.1        4        300        11        12        4    0    0 00:04:42            3        4 Transit-PCCW

Total number of neighbors 1

Check the BGP route table to see the routes:

upstream# show ip bgp

This is the crucial view. See below that:

• 100.100.0.0/22 is YouTube’s legitimate prefix, learned via AS path “300 100” (Transit → YouTube)
• 200.200.0.0/16 is Pakistan Telecom’s own prefix
• 30.30.0.0/16 is Transit’s prefix

BGP table version is 4, local router ID is 40.40.40.1, vrf id 0
Default local pref 100, local AS 400
Status codes:  s suppressed, d damped, h history, * valid, > best, = multipath,
               i internal, r RIB-failure, S Stale, R Removed
Nexthop codes: @NNN nexthop's vrf id, < announce-nh-self
Origin codes:  i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found

    Network          Next Hop            Metric LocPrf Weight Path
 *> 30.30.0.0/16     10.0.3.1                 0             0 300 i
 *> 40.40.0.0/16     0.0.0.0                  0         32768 i
 *> 100.100.0.0/22   10.0.3.1                               0 300 100 i
 *> 200.200.0.0/16   10.0.3.1                               0 300 200 i

Displayed  4 routes and 4 total paths

There is no more-specific /24 route for YouTube’s address space yet. This is the normal, pre-hijack state.

Check Transit

Verify Transit is properly peering with all neighbors. Use the terminal window connected to the transit router:

root@transit:/# vtysh
transit# show ip bgp summary

We see Transit BGP has three peers, as expected. Sessions are established with YouTube (AS100), Pakistan (AS200), and Upstream (AS400):

IPv4 Unicast Summary (VRF default):
BGP router identifier 30.30.30.1, local AS number 300 vrf-id 0
BGP table version 4
RIB entries 7, using 672 bytes of memory
Peers 3, using 60 KiB of memory

Neighbor        V         AS   MsgRcvd   MsgSent   TblVer  InQ OutQ  Up/Down State/PfxRcd   PfxSnt Desc
10.0.1.1        4        100        15        15        4    0    0 00:08:59            1        4 YouTube
10.0.2.2        4        200        15        15        4    0    0 00:08:59            1        4 Pakistan-Telecom
10.0.3.2        4        400        15        15        4    0    0 00:08:59            1        4 Upstream

Total number of neighbors 3

Check the BGP route table to see the routes:

upstream# show ip bgp

See below that Transit is receiving:

• 1 prefix from Upstream (AS400): its 40.40.0.0/16
• 1 prefix from YouTube (AS100): the 100.100.0.0/22
• 1 prefix from Pakistan (AS200): its legitimate 200.200.0.0/16

BGP table version is 4, local router ID is 30.30.30.1, vrf id 0
Default local pref 100, local AS 300
Status codes:  s suppressed, d damped, h history, * valid, > best, = multipath,
               i internal, r RIB-failure, S Stale, R Removed
Nexthop codes: @NNN nexthop's vrf id, < announce-nh-self
Origin codes:  i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found

    Network          Next Hop            Metric LocPrf Weight Path
 *> 30.30.0.0/16     0.0.0.0                  0         32768 i
 *> 40.40.0.0/16     10.0.3.2                 0             0 400 i
 *> 100.100.0.0/22   10.0.1.1                 0             0 100 i
 *> 200.200.0.0/16   10.0.2.2                 0             0 200 i

Displayed  4 routes and 4 total paths

Check YouTube

Verify YouTube is properly peering with all neighbors.

root@youtube:/# vtysh
youtube# show ip bgp summary

We see YouTube BGP has one BGP peer, as expected. It has established a BGP session with Transit (AS300):

IPv4 Unicast Summary (VRF default):
BGP router identifier 100.100.100.1, local AS number 100 vrf-id 0
BGP table version 4
RIB entries 7, using 672 bytes of memory
Peers 1, using 20 KiB of memory

Neighbor        V         AS   MsgRcvd   MsgSent   TblVer  InQ OutQ  Up/Down State/PfxRcd   PfxSnt Desc
10.0.1.2        4        300        40        41        4    0    0 00:33:25            3        4 Transit-PCCW

Total number of neighbors 1

Verify YouTube is announcing its prefix correctly:

root@youtube:/# vtysh
youtube# show ip bgp

As shown below, YouTube sees:

• Its own 100.100.0.0/22 (locally originated)
• Routes to other ASes via Transit

BGP table version is 4, local router ID is 100.100.100.1, vrf id 0
Default local pref 100, local AS 100
Status codes:  s suppressed, d damped, h history, * valid, > best, = multipath,
               i internal, r RIB-failure, S Stale, R Removed
Nexthop codes: @NNN nexthop's vrf id, < announce-nh-self
Origin codes:  i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*> 30.30.0.0/16     10.0.1.2                 0             0 300 i
*> 40.40.0.0/16     10.0.1.2                               0 300 400 i
*> 100.100.0.0/22   0.0.0.0                  0         32768 i
*> 200.200.0.0/16   10.0.1.2                               0 300 200 i

Displayed  4 routes and 4 total paths

Check Pakistan

Verify Pakistan is properly peering with all neighbors.

root@transit:/# vtysh
transit# show ip bgp summary

We see Pakistan BGP has established a BGP peering session with Transit:

IPv4 Unicast Summary (VRF default):
BGP router identifier 200.200.200.1, local AS number 200 vrf-id 0
BGP table version 4
RIB entries 7, using 672 bytes of memory
Peers 1, using 20 KiB of memory

Neighbor        V         AS   MsgRcvd   MsgSent   TblVer  InQ OutQ  Up/Down State/PfxRcd   PfxSnt Desc
10.0.2.1        4        300        35        36        4    0    0 00:28:18            3        4 Transit-PCCW

Total number of neighbors 1

Check the BGP route table to see the routes:

pakistan# show ip bgp

See below that Pakistan is receiving:

• 1 prefix from Transit (AS300): its 30.30.0.0/16
• 1 prefix from Upstream (AS400): its 40.40.0.0/16
• 1 prefix from YouTube (AS100): the 100.100.0.0/22

BGP table version is 4, local router ID is 200.200.200.1, vrf id 0
Default local pref 100, local AS 200
Status codes:  s suppressed, d damped, h history, * valid, > best, = multipath,
               i internal, r RIB-failure, S Stale, R Removed
Nexthop codes: @NNN nexthop's vrf id, < announce-nh-self
Origin codes:  i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found

    Network          Next Hop            Metric LocPrf Weight Path
 *> 30.30.0.0/16     10.0.2.1                 0             0 300 i
 *> 40.40.0.0/16     10.0.2.1                               0 300 400 i
 *> 100.100.0.0/22   10.0.2.1                               0 300 100 i
 *> 200.200.0.0/16   0.0.0.0                  0         32768 i

Displayed  4 routes and 4 total paths

Verifying Connectivity

Let’s test connectivity to YouTube’s address space. From Upstream’s loopback interface, ping YouTube’s loopback address 100.100.0.1:

root@upstream:/# ping -I 40.40.0.1 -c 3 100.100.0.1
PING 100.100.0.1 (100.100.0.1) from 40.40.0.1 : 56(84) bytes of data.
64 bytes from 100.100.0.1: icmp_seq=1 ttl=63 time=1.70 ms
64 bytes from 100.100.0.1: icmp_seq=2 ttl=63 time=2.06 ms
64 bytes from 100.100.0.1: icmp_seq=3 ttl=63 time=1.80 ms

--- 100.100.0.1 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2004ms
rtt min/avg/max/mdev = 1.704/1.853/2.058/0.149 ms

Traffic from Upstream, which represents traffic from Internet users in this lab example, reaches YouTube correctly. This is the normal, pre-hijack state.

Use the traceroute command to check the path that the traffic between Upstream and Youtube follows:

root@upstream:/# traceroute -s 40.40.0.1 100.100.0.1
traceroute to 100.100.0.1 (100.100.0.1), 30 hops max, 60 byte packets
 1  10.0.3.1 (10.0.3.1)  0.730 ms  1.239 ms  1.827 ms
 2  100.100.0.1 (100.100.0.1)  2.428 ms  3.025 ms  3.541 ms

At this point, we have a fully functional 4-AS BGP topology with normal routing:

In the next section, we’ll introduce Pakistan Telecom’s more-specific /24 hijack and observe how it overrides YouTube’s legitimate route.

Recreating the Prefix Hijack

Now we will introduce the more-specific prefix announcement that hijacks YouTube’s traffic, recreating the 2008 Pakistan incident. This demonstrates how BGP’s longest-prefix-match rule can be exploited, even unintentionally.

The Before State

Before making changes, let’s confirm YouTube’s route is the only one for the 100.100.x.x address space. In the Upstream terminal window:

root@upstream:/# vtysh
upstream# show ip bgp 100.100.0.1

When we query BGP for the specific IP 100.100.0.1, we see that it matches the /22 prefix owned by YouTube (AS100). The AS path “300 100” shows the route comes via Transit (AS300) from YouTube (AS100).

BGP routing table entry for 100.100.0.0/22, version 3
Paths: (1 available, best #1, table default)
  Advertised to non peer-group peers:
  10.0.3.1
  300 100
    10.0.3.1 from 10.0.3.1 (30.30.0.1)
      Origin IGP, valid, external, best (First path received)
      Last update: Sat Jan 31 16:31:16 2026

Starting the Hijack

Now we’ll simulate Pakistan Telecom announcing the more-specific prefix. In the Pakistan terminal window:

root@pakistan:/# vtysh
pakistan# configure terminal

First, we need to create a blackhole route for the prefix we’re about to announce, just like Pakistan Telecom did when trying to block YouTube:

pakistan(config)# ip route 100.100.0.0/24 blackhole

Now, add the more-specific prefix to BGP:

pakistan(config)# router bgp 200
pakistan(config-router)# address-family ipv4 unicast
pakistan(config-router-af)# network 100.100.0.0/24
pakistan(config-router-af)# exit
pakistan(config-router)# exit
pakistan(config)# exit

Verify the new route is in Pakistan’s BGP table:

pakistan# show ip bgp

In the output below, notice that there are two routes for YouTube’s address space:

• 100.100.0.0/22 is YouTube’s legitimate announcement (learned via Transit)
• 100.100.0.0/24 is Our hijacked announcement (locally originated)

BGP table version is 5, local router ID is 200.200.0.1, vrf id 0
Default local pref 100, local AS 200
Status codes:  s suppressed, d damped, h history, * valid, > best, = multipath,
               i internal, r RIB-failure, S Stale, R Removed
Nexthop codes: @NNN nexthop's vrf id, < announce-nh-self
Origin codes:  i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found

    Network          Next Hop            Metric LocPrf Weight Path
 *> 30.30.0.0/16     10.0.2.1                 0             0 300 i
 *> 40.40.0.0/16     10.0.2.1                               0 300 400 i
 *> 100.100.0.0/22   10.0.2.1                               0 300 100 i
 *> 100.100.0.0/24   0.0.0.0                  0         32768 i
 *> 200.200.0.0/16   0.0.0.0                  0         32768 i

Displayed  5 routes and 5 total paths

The hijack is now being advertised to Transit.

In our lab YouTube announces 100.100.0.0/22, which covers 100.100.0.0 – 100.100.3.255, and Pakistan is now announcing 100.100.0.0/24, which covers 100.100.0.0 – 100.100.0.255.

The /24 is more specific than the /22, so routers will prefer it for any traffic destined to addresses in the 100.100.0.0/24 range.

Observing the Hijack Propagation

Let’s see how the hijack propagates through the network. Go to the Transit terminal window and enter the following commands.

root@transit:/# vtysh
transit# show ip bgp

You can see that the more specific route has reached the Transit AS router.

BGP table version is 5, local router ID is 30.30.0.1, vrf id 0
Default local pref 100, local AS 300
Status codes:  s suppressed, d damped, h history, * valid, > best, = multipath,
               i internal, r RIB-failure, S Stale, R Removed
Nexthop codes: @NNN nexthop's vrf id, < announce-nh-self
Origin codes:  i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found

    Network          Next Hop            Metric LocPrf Weight Path
 *> 30.30.0.0/16     0.0.0.0                  0         32768 i
 *> 40.40.0.0/16     10.0.3.2                 0             0 400 i
 *> 100.100.0.0/22   10.0.1.1                 0             0 100 i
 *> 100.100.0.0/24   10.0.2.2                 0             0 200 i
 *> 200.200.0.0/16   10.0.2.2                 0             0 200 i

Displayed  5 routes and 5 total paths

It now has two routes covering YouTube’s address space:

• 100.100.0.0/22 from YouTube (AS100) via 10.0.1.1
• 100.100.0.0/24 from Pakistan (AS200) via 10.0.2.1

Transit will forward the hijacked route to its other neighbors, including Upstream.

Check Upstream, which is the observer that represents the broader Internet. Go to the Upstream terminal window and enter the following commands.

root@upstream:/# vtysh
upstream# show ip bgp

You can see that the more specific route has reached the Upstream AS router, from which we will assume it propagates to all other routers in the Internet.

BGP table version is 6, local router ID is 40.40.40.1, vrf id 0
Default local pref 100, local AS 400
Status codes:  s suppressed, d damped, h history, * valid, > best, = multipath,
               i internal, r RIB-failure, S Stale, R Removed
Nexthop codes: @NNN nexthop's vrf id, < announce-nh-self
Origin codes:  i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*> 30.30.0.0/16     10.0.3.1                 0             0 300 i
*> 40.40.0.0/16     0.0.0.0                  0         32768 i
*> 100.100.0.0/22   10.0.3.1                               0 300 100 i
*> 100.100.0.0/24   10.0.3.1                               0 300 200 i
*> 200.200.0.0/16   10.0.3.1                               0 300 200 i

Displayed  5 routes and 5 total paths

Notice the two routes:

• 100.100.0.0/22 with AS path “300 100” (Transit → YouTube), which is the legitimate route
• 100.100.0.0/24 with AS path “300 200” (Transit → Pakistan), which is the hijacked route

In the real incident, Pakistan Telecom was trying to block YouTube internally by creating a blackhole route. The problem was that this route was accidentally announced to their transit provider PCCW, who propagated it globally.

Understanding the Impact

Now let’s see what happens when Upstream tries to reach an IP address in the hijacked range:

upstream# show ip bgp 100.100.0.1

BGP routing table entry for 100.100.0.0/24, version 5
Paths: (1 available, best #1, table default)
  Advertised to non peer-group peers:
  10.0.3.1
  300 200
    10.0.3.1 from 10.0.3.1 (30.30.0.1)
      Origin IGP, valid, external, best (First path received)
      Last update: Sat Jan 31 17:38:36 2026

This is the hijack in action! When querying for IP 100.100.0.1:

• Before the hijack, this command matched the /22 route to YouTube and we saw that it originated from AS100 (Youtube)
• After the hijack, it matches the /24 route to Pakistan and we see it originates from AS200 (Pakistan)

The more-specific /24 prefix “wins” due to BGP’s longest-prefix-match rule. Traffic for 100.100.0.x is now being sent toward Pakistan instead of YouTube.

Let’s verify with a traceroute. Exit vtysh first:

upstream# exit

Try to ping the YouTube loopback address and see that you cannot reach YouTube at 100.100.0.1 from the Upstream router:

root@upstream:/# ping -I 40.40.0.1 -c 3 100.100.0.1
PING 100.100.0.1 (100.100.0.1) from 40.40.0.1 : 56(84) bytes of data.

--- 100.100.0.1 ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 2056ms

Next, trace the path to an address in the hijacked range:

root@upstream:/# traceroute -s 40.40.0.1 100.100.0.1
traceroute to 100.100.0.1 (100.100.0.1), 30 hops max, 60 byte packets
 1  10.0.3.1 (10.0.3.1)  1.592 ms  2.020 ms  2.429 ms
 2  * * *
 3  * * *

The traceroute shows:

• First hop: Transit (10.0.3.1)
• Second hop: Nothing shows because Pakistan is blackholing the traffic.

This is exactly what happened in 2008: YouTube traffic flowed toward Pakistan where it was dropped, causing a global YouTube outage.

Compare this to the other YouTube address 100.100.1.1, which is outside the hijacked /24 but still within YouTube’s /22:

root@upstream:/# traceroute -s 40.40.0.1 100.100.1.1
traceroute to 100.100.1.1 (100.100.1.1), 30 hops max, 60 byte packets
 1  10.0.3.1 (10.0.3.1)  0.895 ms  1.173 ms  1.573 ms
 2  100.100.1.1 (100.100.1.1)  1.762 ms  2.185 ms  2.586 ms

Traffic to 100.100.1.1 still reaches YouTube (via Transit) because that address is covered by the /22 but NOT by the hijacked /24.

YouTube’s Response

In the real incident, YouTube responded by announcing their own more-specific prefixes to compete with Pakistan’s hijack. Let’s simulate this defense.

Go to the YouTube terminal window and enter the following commands:

root@youtube:/# vtysh
youtube# configure terminal

YouTube will announce two /25 prefixes which are more specific than Pakistan’s /24 and which, together, cover the name address range as the /24 that Pakistan announced:

youtube(config)# ip route 100.100.0.0/25 blackhole
youtube(config)# ip route 100.100.0.128/25 blackhole
youtube(config)# router bgp 100
youtube(config-router)# address-family ipv4 unicast
youtube(config-router-af)# network 100.100.0.0/25
youtube(config-router-af)# network 100.100.0.128/25
youtube(config-router-af)# exit
youtube(config-router)# exit
youtube(config)# exit

Verify YouTube is now announcing the counter-attack routes:

youtube# show ip bgp

BGP table version is 7, local router ID is 100.100.0.1, vrf id 0
Default local pref 100, local AS 100
Status codes:  s suppressed, d damped, h history, * valid, > best, = multipath,
               i internal, r RIB-failure, S Stale, R Removed
Nexthop codes: @NNN nexthop's vrf id, < announce-nh-self
Origin codes:  i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found

    Network          Next Hop            Metric LocPrf Weight Path
 *> 30.30.0.0/16     10.0.1.2                 0             0 300 i
 *> 40.40.0.0/16     10.0.1.2                               0 300 400 i
 *> 100.100.0.0/22   0.0.0.0                  0         32768 i
 *> 100.100.0.0/24   10.0.1.2                               0 300 200 i
 *> 100.100.0.0/25   0.0.0.0                  0         32768 i
 *> 100.100.0.128/25 0.0.0.0                  0         32768 i
 *> 200.200.0.0/16   10.0.1.2                               0 300 200 i

Displayed  7 routes and 7 total paths

YouTube is now announcing /25s that will override Pakistan’s /24 prefix

Check Upstream to see the effect. Go to the Upstream terminal window and enter the following commands:

root@upstream:/# vtysh
upstream# show ip bgp

This will show there are three routes covering the 100.100.0.0/24 range:

• 100.100.0.0/24 from Pakistan (AS200)
• 100.100.0.0/25 from YouTube (AS100), which is more specific
• 100.100.0.128/25 from YouTube (AS100), which is more specific

BGP table version is 7, local router ID is 40.40.0.1, vrf id 0
Default local pref 100, local AS 400
Status codes:  s suppressed, d damped, h history, * valid, > best, = multipath,
               i internal, r RIB-failure, S Stale, R Removed
Nexthop codes: @NNN nexthop's vrf id, < announce-nh-self
Origin codes:  i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found

    Network          Next Hop            Metric LocPrf Weight Path
 *> 30.30.0.0/16     10.0.3.1                 0             0 300 i
 *> 40.40.0.0/16     0.0.0.0                  0         32768 i
 *> 100.100.0.0/22   10.0.3.1                               0 300 100 i
 *> 100.100.0.0/24   10.0.3.1                               0 300 200 i
 *> 100.100.0.0/25   10.0.3.1                               0 300 100 i
 *> 100.100.0.128/25 10.0.3.1                               0 300 100 i
 *> 200.200.0.0/16   10.0.3.1                               0 300 200 i

Displayed  7 routes and 7 total paths

Let’s verify Upstream traffic now goes to YouTube:

upstream# show ip bgp 100.100.0.1

This will show that the Upstream router now will send traffic addressed to 100.100.0.1 to YouTube (AS100) instead of to Pakistan (AS200).

upstream# show ip bgp 100.100.0.1
BGP routing table entry for 100.100.0.0/25, version 6
Paths: (1 available, best #1, table default)
  Advertised to non peer-group peers:
  10.0.3.1
  300 100
    10.0.3.1 from 10.0.3.1 (30.30.0.1)
      Origin IGP, valid, external, best (First path received)
      Last update: Sat Jan 31 19:41:08 2026

YouTube has reclaimed control. The /25 routes from YouTube (AS100) override Pakistan’s /24 route. Traffic for 100.100.0.1 now correctly flows to YouTube.

Cleanup

When you’re finished experimenting with the hijack scenario clean up the lab:

$ kathara lclean
┌──────────────────────────────────────────────────────────────────────────────┐
│                          Stopping Network Scenario                           │
└──────────────────────────────────────────────────────────────────────────────┘
[Deleting devices]   ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 4/4
[Deleting collision domains]   ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 3/3

Summary: The Attack and Defense

This exercise demonstrated the lifecycle of the Pakistan YouTube hijack.

The key lesson is that in the BGP “longest prefix match” game, the most specific route wins. However, while that was possible in 2008, that’s a game that attackers and defenders a less able to play in modern networks due to the use of modern BGP security practices.

Modern BGP Security Practices

Now that you’ve seen how a prefix hijack works, let’s discuss the techniques network operators use to prevent them. The Pakistan YouTube incident highlighted critical weaknesses in BGP that the industry has been working to address ever since.

Pakistan Telecom’s /24 BGP Hijack and YouTube’s emergency /25 de-aggregation response worked in 2008 because prefix filtering and origin validation were weak. Today, strict prefix-length filtering and the widespread use of RPKI mean that such more-specific announcements would often be rejected.

Prefix Filtering with Prefix Lists

The most fundamental protection against prefix hijacks is explicit prefix filtering. Transit providers can configure their routers to only accept announcements for prefixes the customer is authorized to announce. To accomplish this, they need to maintain a comprehensive list of valid customer prefixes.

Internet providers maintain prefix filter lists using tools like bgpq4 that automatically generate prefix lists from data stored in Internet Routing Registry (IRR) databases like RADB, RIPE, and ARIN.

RPKI and Route Origin Validation

Resource Public Key Infrastructure (RPKI) represents a fundamental shift in BGP security. Instead of relying on trusted databases or manual coordination, RPKI provides cryptographic proof of route authorization. RPKI would have prevented the Pakistan YouTube hijack, if RPKI had existed in 2008.

RPKI adoption has grown dramatically since the Pakistan YouTube incident. Major networks and tier-1 providers now validate routes and drop RPKI-invalid announcements.

BGPsec

BGPsec extends RPKI to provide path validation, cryptographically signing each AS hop in the path. While RPKI validates the origin AS, BGPsec validates the entire path, detecting route leaks and path manipulation attacks. However, BGPsec faces significant deployment challenges because every AS in the path must support BGPsec.

Conclusion

In this post, I’ve walked you through using Kathará to recreate the 2008 Pakistan YouTube BGP prefix hijack. We’ve learned how to use Kathará to gain hands-on experience with how prefix hijacks occur and propagate, and how to detect and counter them.

The beauty of network emulation, using tools like Kathará, is that you can experiment freely without risking production infrastructure. If you want to continue exploring BGP scenarios with Kathará, the project maintains an excellent collection of ready-to-use labs:

Further Reading

To get more information about BGP security, I recommend these resources:

• RIPE NCC Case Study: Pakistan YouTube Hijack: Detailed analysis of the 2008 YouTube incident with routing data
• NIST BGP Security Guidelines (SP 800-189): Comprehensive guidance on securing BGP infrastructure
• MANRS (Mutually Agreed Norms for Routing Security): Industry initiative promoting routing security best practices
• Cloudflare’s BGP Security Blog: Accessible explanations of BGP incidents and mitigations
• RPKI Documentation at ARIN, RIPE, or APNIC: Guides for creating and managing RPKI data

[^1] https://github.com/KatharaFramework/Kathara/wiki/Linux

The post Recreating a Real-World BGP Hijack with the Kathará Network Emulator appeared first on Open-Source Routing and Network Simulation.

In this annual update of my list of open-source network simulators and emulators, I check each project’s development activity, verify the well-maintained projects, identify new projects that deserve attention, and consider projects that may be fading away.

Top Projects

Two open-source network emulation projects stand out in 2026, due to their popularity, functionality, and development velocity.

Containerlab continues its impressive development pace, and seems to have cemented its position as a leading network emulation tool for developers. New features added in 2024 and 2025 include VM snapshot/restore functionality, expanded device support, a system for running labs on Kubernetes clusters, and improved container network configuration.

GNS3 continues steady development and remains a leading network emulation tool for engineers. While the 2.x release is still the default download, the GNS3 team released a 3.0 version that implemented major architectural changes in GNS3. GNS3 continues to be the most popular GUI-based open-source network emulator.

$ curl -s -o cnet-Linux-x86_64 https://teaching.csse.uwa.edu.au/units/CITS3002/cnet/downloads/cnet-Linux-x86_64

The post Open-source network simulators and emulators in 2026 appeared first on Open-Source Routing and Network Simulation.

In this post, I will review Cloonix v53 and walk through some hands-on exercises with the new features.

What’s New in Cloonix v53

The Cloonix network emulator has evolved significantly since I last wrote about it in 2017.

I list the major changes, since I last looked at Cloonix, below:

Container Support

One of the most significant additions is native container support, using crun. Cloonix feature support for containers is, however, limited. For example, one cannot save a container’s filesystem and containers do not support Spice connections so they can’t run a desktop environment.

Cloonix containers start faster and use fewer resources than KVM virtual machines, or even Docker containers, making them ideal for scenarios where you need many lightweight nodes. I imagine containers in Cloonix will be used to create many clients in a network simulation scenario.

Cloonix continues to support virtual machines using qemu-kvm, and you can mix containers and KVM VMs in the same Cloonix topology.

Rootless Installation Option

Cloonix v53 introduces a “cloonix-toy” installation that runs entirely in user space without requiring root privileges. This is particularly useful for quick evaluations without modifying the host system or for using Cloonix on systems where you don’t have administrator access.

The rootless “cloonix-toy” version uses a container to isolate Cloonix from the host system while still providing full functionality.

In this post, I cover the full installation. I’ll cover the rootless “cloonix-toy” version in a future post.

WiFi Emulation

Cloonix v53 adds WiFi emulation support on qemu-kvm virtual machines using vwifi. This allows you to create wireless network scenarios in Cloonix. WiFi emulation is an experimental feature in Cloonix v53.

Web Interface

Cloonix now includes a web interface built with noVNC that allows you to access the Cloonix GUI from a web browser. This is useful for remote access or when running Cloonix on a headless server.

Installing Cloonix

Before installing Cloonix, ensure your system meets the requirements. The following procedures were tested on my laptop running Ubuntu 24.04:

Hardware Virtualization

Cloonix uses KVM for virtual machines. Check that your CPU supports hardware virtualization:

$ egrep -c '(vmx|svm)' /proc/cpuinfo

If the result is greater than zero, your CPU supports virtualization. If not, you may need to enable it in your BIOS settings.

Install virtualization tools

Cloonix uses qemu-kvm and other virtualization tools that are not installed by default in the Ubuntu Desktop system. Install virtualization tools with the commands:

$ sudo apt update
$ sudo apt install -y qemu-kvm \
                      libvirt-daemon-system \
                      libvirt-clients \
                      bridge-utils \
                      virt-manager

Installing the virtualization tools should also set up your PC to support the virtualization features required by Cloonix. If virtualization is not enabled, read the Cloonix documentation to see the steps required to enable virtualization for your Linux PC.

Install the mac80211_hwsim kernel module

The mac80211_hwsim is used in WiFi simulation scenarios. Check that the mac80211_hwsim kernel module is installed:

$ lsmod | grep mac80211_hwsim

If it is not installed, install it with the command:

$ sudo modprobe mac80211_hwsim

Cloonix Full Installation (Recommended)

The full installation procedure is shown below:

$ cd
$ wget http://clownix.net/downloads/cloonix-53/cloonix-bundle-53.tar.gz
$ tar xvf cloonix-bundle-53.tar.gz
$ rm cloonix-bundle-53.tar.gz
$ cd cloonix-bundle-53
$ sudo ./install_cloonfs

This installs Cloonix to the following directories:

• /usr/bin/cloonix_* — User interface scripts
• /usr/libexec/cloonix — Binaries and libraries
• /var/lib/cloonix — Storage for VM images

Removing Cloonix from your system is easy; you just delete the directories that the Cloonix install script created. See the Cloonix documentation for more details about uninstalling Cloonix.

Guest filesystems

Before you can use Cloonix, you need to have filesystems installed in the /var/lib/cloonix/bulk directory.

Download guest filesystem images in KVM and container formats. Cloonix offers different systems in their website’s downloads page for Cloonix v53. I chose to use the images based on Debian 13 “Trixie”.

$ cd /var/lib/cloonix/bulk
$ wget http://clownix.net/downloads/cloonix-53/bulk/trixie.qcow2.gz
$ gunzip trixie.qcow2.gz
$ wget https://clownix.net/downloads/cloonix-53/bulk/trixie_gnome.qcow2.gz
$ gunzip trixie_gnome.qcow2.gz
$ wget http://clownix.net/downloads/cloonix-53/bulk/trixie.zip
$ wget http://clownix.net/downloads/cloonix-53/bulk/trixie.tar.gz
$ tar zxvf trixie.tar.gz
$ rm trixie.tar.gz

Cloonix filesystems are based on standard Linux distributions, with qemu-guest-agent and cloonix-agent pre-installed.

Fix AppArmor settings (Ubuntu)

I run Ubuntu 24.04 and ran into an AppArmor problem with Cloonix because Ubuntu restricts unprivileged user namespaces by default.

To see if you have the same problem, just run the help command:

$ cloonix_cli nemo help

You should see a help screen that displays a list of Cloonix commands. If nothing happens, you probably have a problem with AppArmor and Cloonix.

To verify if AppArmor is a problem, check the kernel ring buffer for “denied” appaarmor operations:

$ sudo dmesg | grep -i denied

If you see messages like the following, then you have the same problem I had:

[   54.172165] audit: type=1400 audit(1767126460.057:244): apparmor="DENIED" operation="capable" class="cap" profile="unprivileged_userns" pid=5282 comm="cloonix-hide-di" capability=21  capname="sys_admin"

The AppArmor issue with Cloonix on Ubuntu 24.04 relates to how Cloonix uses unprivileged user namespaces for container isolation. Starting with Ubuntu 23.10 and continuing in 24.04, Ubuntu added a new AppArmor restriction specifically targeting unprivileged user namespaces. This was a security hardening measure because unprivileged user namespaces have historically been a source of privilege escalation vulnerabilities.

To fix this, edit the /etc/sysctl.conf file:

$ sudo nano /etc/sysctl.conf

Add the following two lines to the end of the file:

kernel.unprivileged_userns_clone=1
kernel.apparmor_restrict_unprivileged_userns=0

Save the file. Then, apply the changes:

$ sudo sysctl -p

These settings reduce some security restrictions on your system. Unprivileged user namespaces can potentially be exploited in container escape or privilege escalation attacks. If you’re running Cloonix on a dedicated lab machine or VM, the security trade-off may be acceptable.

Your First Cloonix v53 Network

To test that the basics of Cloonix are working, let’s create a simple network with two virtual machines connected by a LAN.

Start Cloonix

Start the Cloonix server and GUI:

$ cloonix_net nemo

Remember, you always have to start the Cloonix server before anything else. The “nemo” tag is the name of the Cloonix server. The Cloonix server names and parameters were defined in the Cloonix configuration file, which is installed in your system in the file /usr/libexec/cloonix/cloonfs/etc/cloonix.cfg.

Then, you can start the Cloonix GUI or issue Cloonix CLI commands. In this exercise, let’s start the GUI:

$ cloonix_gui nemo

If you see an error message stating that something Failed to load module “canberra-gtk-module”, you can ignore it. It is warning about a module used to generate sound and I don’t feel like messing with the audio on my laptop.

Create Virtual Machines

Before creating VMs, configure the VM settings by right-clicking and selecting kvm_config.

The KVM config you set will be used to create the next virtual machine. If you need virtual mnachines with different configurations, set the config first, then start the virtual machine.

In this example, I will create two VMs with the same configurations, shown below:

• VM name: Leave as default or customize. I set it to “VM”.
• RAM: 4000 MB (adjust based on your system)
• CPU: 2
• eth: sss (three spyable interfaces that can interact with Wireshark)

The config window will look like the screenshot below:

Click OK to accept the configuration.

In the Cloonix GUI, right-click on the canvas to open the menu. Select the kvm radio button show the KVM options and select the filesystem trixie.qcow2 to start a new virtual machine.

A new VM will appear on the canvas. Repeat the process again to create a second VM.

Note: I noticed that if I changed the name to anything besides “Cloon”, Cloonix stops automatically numbering VMs (“Cloon1”, “Cloon2”, etc.). I had to open the KVM config panel before creating each new VM so I could give it a unique name.

Create a LAN

Right-click on the canvas and select lan to create a LAN.

A small circle representing the LAN switch will appear. It is labeled lan01.

Connect VMs to the LAN

Double-click on the LAN object lan01. It will turn purple, indicating it’s selected for connection. Then click on the eth1 port (the small circle labeled “1”) on the VM named VM. A line will connect the VM’s eth1 interface to the LAN.

Repeat the process. Double-click on the LAN. Click on VM2’s eth1 port.

Now both VMs are connected to the same LAN.

Configure IP Addresses

Double-click on VM to open a terminal window. Configure its network interface:

VM# ip addr add 10.0.0.1/24 dev eth1
VM# ip link set eth1 up

Double-click on VM2 and configure it:

VM2# ip addr add 10.0.0.2/24 dev eth1
VM2# ip link set eth1 up

Test Connectivity

From VM, ping VM2:

VM# ping -c 3 10.0.0.2

You should see output similar to the screenshot below:

Congratulations! You’ve created your first Cloonix v53 network.

You can close both terminal windows by typing exit in each.

SSH to VMs

The terminal windows that open up when you double-click the VM lack some terminal features, like copy-and-paste via keyboard shortcuts. For a better user experience, I suggest that you run Cloonix CLI commands to SSH into any node running on a Cloonix server.

For example, in my PC’s terminal application, I can type the Cloonix CLI command to SSH into VM2:

$ cloonix_ssh nemo VM2

This enables me to interact with VM2 in my PC’s terminal application.

Using Containers in Cloonix

To create a Cloonix node based on a container, you must first choose which container type you will use. The “zip” containers are very lightweight but, currently, do not have the option to install packages or save a persistent filesystem. The “cvm” containers are a bit heavier weight, but still lighter and faster than Docker containers, and they allow packages to be installed. In this example, I chose to use the “zip” container type.

Right-click on the Cloonix GUI canvas and click on the zip radio button to activate the container options for crun zip containers. Then, select zip config to configure the next container.

Configure the container. Choose a name for the node that will be created, the number of interfaces, etc.

Then, select the trixie.zip file system to create your container.

Now you have added a node based on a container to your topology. Cloonix shows you it’s a container by rendering it as a smaller circle on the canvas.

Connect the Container

Connect the container to the same LAN as your VMs:

1. Double-click on the existing LAN, lan01.
2. Click on the container Cnt1‘s eth1 port.

Now you should see all three nodes connected to the same LAN:

Access the Container

Double-click on the container to open a shell, or run the following command in your terminal app:

$ cloonix_ssh nemo Cnt1

Configure Cnt1‘s network:

# ip addr add 10.0.0.3/24 dev eth1
# ip link set eth1 up

You now have a mixed environment with both KVM VMs and containers on the same network. Test that the connection work with the command:

# ping -c 3 10.0.0.1

You should see output like:

PING 10.0.0.1 (10.0.0.1) 56(84) bytes of data.
64 bytes from 10.0.0.1: icmp_seq=1 ttl=64 time=0.508 ms
64 bytes from 10.0.0.1: icmp_seq=2 ttl=64 time=0.319 ms
64 bytes from 10.0.0.1: icmp_seq=3 ttl=64 time=0.827 ms

--- 10.0.0.1 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2046ms
rtt min/avg/max/mdev = 0.319/0.551/0.827/0.209 ms
Cnt1#

Exit the SSH session with the exit command.

Using Wireshark to Capture Traffic

Cloonix includes a customized version of Wireshark for packet capture and analysis.

Enable Packet Capture

In the Cloonix GUI, look at the eth1 port on one of your nodes. If it’s green, it’s “spyable” and you can capture packets on it.

Double-click on the green eth1 port on Cnt1. A Wireshark window will open and begin capturing packets.

Generate Traffic

From VM2‘s terminal, ping Cnt1:

VM2# ping -c 5 10.0.0.1

Watch the Wireshark window — you’ll see the ICMP echo request and reply packets.

Save the Capture

The customized Wireshark in Cloonix v53 is a simplified version. For full analysis capabilities, save the .pcap file and open it with a complete Wireshark installation on your host.

First, stop the capture. In Wireshark’s menu, go to Capture –> Stop. Then, save the .pcap file.
Go to File –> Save As and choose a location.

Adding Internet Access with NAT

Cloonix provides a variety of filesystems for use in the Cloonix network simulator. In version 53, these root filesystem only have the most basic software packages installed and will not support advanced network configuration.

To create a network simulation that runs real-world networking software, we need to install new software on the root filesystems we will use in Cloonix. In this example, we chose to start with the Debian Trixie filesystem and we will install some new packages on it as a demonstration.

Let’s connect our network to the Internet using Cloonix’s NAT component.

Create and connect NAT Object

To connect a Cloonix node to a NAT object so it can communicate with the host system and with the Internet, follow the steps below:

• Right-click on the Cloonix GUI canvas and select nat. A NAT object will appear.
• Right-click and select lan to create a new LAN (e.g., lan02).
• Double-click on the new LAN to select it
• Click on the NAT object to connect it
• Double-click on the LAN again
• Click on an unused port on VM1 (e.g., eth0)

You should see that the Cloonix canvas now looks similar to the screenshot below:

Configure the VM for NAT

On VM1, configure the interface connected to the NAT and request an IP address via DHCP. The Cloonix v53 documentation says to use the dhclient command but that utility is not installed in the root Trixie filesystem that comes with Cloonix. So, let’s set up DHCP manually on VM1.

Create a file named after the interface, e.g.:

VM1# nano /etc/network/interfaces.d/eth0

In the eth0 file, add the following lines:

auto eth0
iface eth0 inet dhcp

Save the file, then bring up the interface:

VM1# ifup eth0

The VM VM1 should successfully connect with the DHCP server running on the NAT and request an IP address. In my case, it was assigned the IP address, 172.17.0.10/24.

Test Internet Connectivity

Try to ping an external host:

VM# ping -c 3 google.com

If your host has Internet connectivity, the ping should succeed. In my case, pings failed but I still had Internet connectivity. The NAT object seems to be corrupting ICMP packets. Pinging the NAT interface at 172.17.0.2 will not work, and using Wireshark to check the packets on the eth1 interface shows that the ICMP replies from 172.17.0.2 have invalid checksums.

This is a minor issue, because the actual functionality that we need still works. I can download repository info from the Internet and, after installing it, I can use curl to get web page information from the Internet.

Get repository updates

I tried running the apt command to update the repository information but the Trixie root file system that comes with Cloonix has only a local mirror configured and, since I am not running a local Debian mirror, it does not work. I had to edit the /etc/apt/sources.list file and add in the Debian repos.

VM1# nano /etc/apt/sources.list

Delete the line that already exists in the file and add in the following line:

deb http://deb.debian.org/debian trixie main contrib non-free

Save the file, then update the repository:

VM1# apt clean
VM1# apt update

Install curl on the VM VM1:

VM1# apt install curl

Now, you can use curl to test other Internet connectivity, like downloading a web page:

VM1# curl https://www.example.com
<!doctype html><html lang="en"><head><title>Example Domain</title><meta name="viewport" content="width=device-width, initial-scale=1"><style>body{background:#eee;width:60vw;margin:15vh auto;font-family:system-ui,sans-serif}h1{font-size:1.5em}div{opacity:0.8}a:link,a:visited{color:#348}</style><body><div><h1>Example Domain</h1><p>This domain is for use in documentation examples without needing permission. Avoid use in operations.<p><a href="https://iana.org/domains/example">Learn more</a></div></body></html>

Configuring containers to connect to NAT

Containers can be connected to the NAT object, the same as VMs. However, in Cloonix v53, both the cvm and zip versions of the Trixie filesystem are designed to be extremely minimal. They do not support DHCP.

Manually set up an IP address and default route:

Cnt1# ip addr add 172.17.0.50/24 dev eth0
Cnt1# ip route add default via 172.17.0.2 dev eth0

Then, configure the nameserver. Edit the /etc/resolv.conf file:

Cnt1# vi /etc/resolv.conf

Replace the nameserver with:

nameserver 172.17.0.3

Save the file.

It is not possible to install packages on the zip-type containers. But, if you use the cvm-type containers, you can install packages. To enable the apt repository, edit the /etc/apt/sources.list file:

Cvm2# vi /etc/apt/sources.list

Delete the existing line, and replace it with:

deb http://deb.debian.org/debian trixie main contrib non-free

Using the Command-Line Interface

The cloonix_cli command allows you to automate topology creation with scripts. See the Cloonix documentation for CLI commands. You can do everything in the CLI that you can do in the GUI.

I’ll cover more about the Cloonix v53 CLI in a future post.

Stop Cloonix

When finished with a simulation, stop the Cloonix server:

$ cloonix_cli nemo kil

This terminates all VMs, containers, and cleans up resources.

Running a Demo Script

Cloonix includes demo scripts that create pre-configured network scenarios.

Demo scripts are available on the Cloonix web site. They make good examples of how to build a script that creates a customized simulation scenario.

Let’s get the demo scripts so we can use them to play with Cloonix:

$ cd
$ cd cloonix-bundle-53
$ mkdir demos
$ cd demos
$ wget https://clownix.net/downloads/cloonix-53/demos/eth_cvm.sh
$ wget https://clownix.net/downloads/cloonix-53/demos/eth_kvm.sh
$ wget https://clownix.net/downloads/cloonix-53/demos/eth_zip.sh
$ wget https://clownix.net/downloads/cloonix-53/demos/wpa_cvm.sh
$ wget https://clownix.net/downloads/cloonix-53/demos/wpa_kvm.sh
$ wget https://clownix.net/downloads/cloonix-53/demos/wpa_zip.sh
$ chmod +x *

To run a demo script, run the following commands:

$ cd
$ cd cloonix-bundle-53/demos
$ ./eth_kvm.sh

Conclusion

Cloonix v53 represents the continued evolution of the Cloonix network emulator. The addition of container support and WiFi emulation show the potential to significantly expands its capabilities, as these features are improved in future releases. The simplified installation process and improved user interface make Cloonix more accessible than ever.

Cloonix is actively developed and it continues to be a valuable tool in the network emulation landscape.

Links

• Cloonix Website
• Cloonix Documentation (v53)
• Cloonix on GitHub
• My Previous Cloonix Posts

The post Cloonix Network Emulator Updated to Version 53 appeared first on Open-Source Routing and Network Simulation.