Skip to content

getting-started.md

Latest commit

 

History

History
81 lines (61 loc) · 2.83 KB

getting-started.md

File metadata and controls

81 lines (61 loc) · 2.83 KB
Raw

Run the local networking lab

The ContainerLab environment builds Galactic from this checkout and runs three Kind clusters connected through an SRv6 transit network. It is the repository's worked example for workload attachment, tenant routing, ingress and egress. Use a dedicated development host: deployment changes host sysctls and creates privileged containers and network links.

For a smaller build/test loop, start with development. This walkthrough follows the lab's checked-in tasks; it does not certify a production release or replace feature-specific acceptance tests.

Prerequisites

  • A Linux kernel supporting the lab's VRF, SRv6 and eBPF operations.
  • Docker with a reachable daemon and permission to run privileged containers.
  • ContainerLab, Kind, kubectl, jq and Task. See the lab prerequisites.
  • Go and clang for building the checkout, or the repository's development container.

The ContainerLab development container provides a Docker-out-of-Docker setup. Container networking still depends on the Docker host's kernel and privileges.

Build and deploy

From the repository root:

cd deploy/containerlab
task deploy

The task builds the images, creates the clusters, installs the networking components and applies the lab scenarios. Allow it to finish before running verification. If it fails, use the named failing task and the lab's layout to locate the affected component; repeating a destructive cleanup is not a diagnostic step.

Verify connectivity

From the same directory:

task verify:underlay
task verify:scenarios
task verify:gateway
task verify:gateway-ingress
task verify:nat-datapath

Each task must exit successfully. Together these check underlay reachability, VPC workload connectivity, gateway API readiness, real ingress traffic and a translated egress round trip. API readiness alone does not prove a working packet path.

Use the lab's verification reference for additional checks. Fault-injection and rollout tests can interrupt lab traffic; run the checks required by the feature you changed rather than treating every task as a harmless health probe.

Inspect or remove the lab

task inspect

The task reports the lab containers. The generated dfw.kubeconfig, iad.kubeconfig and sjc.kubeconfig files in the lab directory select its clusters explicitly when using kubectl.

When finished, from the lab directory:

task destroy

This removes the lab containers and Kind clusters. task clean also removes built images and lab artifacts. Use the lab task reference for rebuild and feature-specific workflows.