The development environment

In order to test and experiment with OpenPERouter, a containerlab and kind based environment is available.

To start it, run

make deploy

The topology of the environment is as follows:

With:

  • Two kind nodes connected to two leaves (leafkind1 and leafkind2), running OpenPERouter
  • A spine container
  • Two EVPN enabled leaves, leafA and leafB
  • An SRv6 enabled leaf, leafSRV6, with IS-IS and SRv6 capabilities
  • For each EVPN leaf, two hosts connected to two different VRFs (red and blue)
  • For the SRv6 leaf, two hosts (hostSRV6_red and hostSRV6_blue) connected to two different VRFs (red and blue)
  • One host connected to the default VRF of leafA

By default, the two VRFs are exposed as type 5 EVPN (VNI 100 and 200) from leafA and leafB, and as SRv6 L3VPN from leafSRV6, to the rest of the fabric.

The kubeconfig file required to interact with the cluster is created under bin/kubeconfig.

The leaves the kind cluster is connected to (leafkind1 and leafkind2) are configured with the following parameters:

IP: 192.168.11.2 ASN: 64512

and they are configured to accept BGP sessions from any peer coming from the network 192.168.11.0/24 with ASN 64514.

More details, including the IP addresses of all the nodes involved, can be found on the project readme.

Veth recreation #

The development environment faces a significant issue:

  • the nodes of the topology are containers
  • the interfaces that connect the various node are veth pairs
  • if the network namespace wrapping a veth (or any virtual interface) gets deleted, the veth gets deleted too
  • OpenPERouter works by moving one interface from the host (the kind node) to the pod running inside of it

Because of this, when the router pod wrapping the interface gets deleted (instead of returning to the host as it would happen with a real interface).

To emulate the behavior of a real system, there is a background program which checks for the deletion of the veths and recreates them.