Network on Kitten Connect

KittUnderlay DN42 Gateway

Fri, 03 Apr 2026 00:00:00 +0000

The KittUnderlay DN42 Interconnection (WIP Draft)

Introduction

This project explores extending the existing KittUnderlay architecture to interconnect with DN42, a decentralized, community-driven networking environment. The goal is to reuse the established WireGuard-based underlay and iBGP design to integrate external routing domains in a clean and controlled manner.

Rather than building a separate edge stack, this approach treats DN42 as an extension point of the existing fabric—while still maintaining clear boundaries between internal and external routing.

Project Vision

KittUnderlay was originally designed as a secure and flexible internal routing foundation. This project builds on that by introducing external peering with DN42, enabling experimentation with real-world routing policies, decentralized interconnections, and community-driven networking practices.

The key idea is to integrate DN42 without disrupting the internal design principles. Internal loopbacks and infrastructure routes remain stable and predictable, while DN42 prefixes are handled through controlled import/export policies.

This creates a hybrid environment where internal services and external reachability coexist without unnecessary complexity.

Key Goals

Reuse KittUnderlay as the primary transport and routing foundation
Establish secure WireGuard-based peering with DN42 participants
Integrate DN42 routes into the existing iBGP topology
Maintain strict separation between internal and external routing domains
Apply filtering and policy control for route exchange
Enable safe experimentation with real-world BGP scenarios

Architecture Overview

KittUnderlay Core
The existing WireGuard mesh and iBGP topology remain unchanged as the foundation of the network.
DN42 Edge Peering
External peers are connected via WireGuard tunnels, forming eBGP sessions with DN42 participants.
Route Injection into iBGP
Accepted DN42 routes are injected into the internal iBGP fabric, allowing controlled propagation across nodes.
Loopback Stability
Internal loopback addresses continue to be advertised via iBGP without modification, ensuring consistent router reachability.
Policy and Filtering Layer
Prefix filtering, ASN validation, and route policies are enforced at the edge to prevent leaks and maintain routing hygiene.
Optional Route Reflectors
If already present in KittUnderlay, Route Reflectors handle the distribution of DN42-learned routes across the network.

Features (Planned & In Progress)

WireGuard-based DN42 peer provisioning
eBGP session templates for DN42 integration
Route filtering and prefix validation mechanisms
Controlled redistribution into iBGP
Monitoring of external route propagation
Support for multiple DN42 peers for redundancy
Clear separation of internal vs external routing tables

Current Status

The project is in an experimental phase. Initial DN42 peerings are being established and tested against the existing KittUnderlay topology. Focus areas include route filtering correctness, propagation behavior, and maintaining stability within the internal network.

Adjustments to policy design and topology layout are ongoing as real-world scenarios are evaluated.

Getting Started

Future documentation will cover:

Joining DN42 and obtaining required credentials
Establishing WireGuard tunnels with DN42 peers
Configuring eBGP sessions and policies
Importing DN42 routes into KittUnderlay
Validating route propagation across the iBGP fabric
Implementing safeguards against route leaks

The goal is to provide a safe and structured path to experimenting with external routing while leveraging an existing internal network design.

This project is not just about connecting to DN42—it’s about extending a controlled internal network into a decentralized ecosystem while preserving clarity, stability, and intent in routing design.

KittUnderlay MPLS and VRF Architecture

Wed, 26 Feb 2025 00:00:00 +0000

KittUnderlay MPLS and VRF Architecture (WIP Draft)

Introduction

While simpler approaches like VRF-Lite or Policy-Based Routing (PBR) could isolate traffic using a single routing table per session, they fall short when scaling with Route Reflectors. With RRs distributing routes to multiple clients, VRF-Lite/PBR lacks the label-based forwarding needed to maintain proper isolation across the fabric. MPLS provides the necessary separation—each VRF route carries its own label, ensuring traffic reaches the correct routing instance even when passing through intermediate RRs.

KittUnderlay selectively uses MPLS for VRF route distribution, enabling proper network segmentation and traffic isolation. This approach reserves MPLS specifically for VRF-associated routes, where label-based forwarding provides clear benefits.

MPLS in KittUnderlay

MPLS is reserved specifically for VRF-associated routes, where label-based forwarding provides clear benefits in segmentation and traffic isolation. Unlike traditional MPLS deployments that might label all routes, KittUnderlay applies MPLS only where it adds value.

Key Goals for MPLS/VRF

Apply MPLS only where it adds value (VRF segmentation)
Maintain clear separation of global and VRF routing planes
Enable proper isolation and label-based forwarding between different routing instances

VRF Routing with MPLS

MPLS is used exclusively for VRF routes, enabling proper isolation and label-based forwarding between different routing instances.

BGP Template Configuration

The BGP template enables MPLS label distribution for VRF routes while maintaining separation from the global routing table:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32


template bgp kittunderlay {
 local port 1790;
 neighbor port 1790;
 rr client;
 path metric off;
 ipv4 mpls {
 extended next hop;
 next hop self;
 import keep filtered;
 import filter {
 if is_valid4_loopback() then {
 accept;
 } else reject;
 };
 export filter { if is_valid4_loopback() && source ~ [RTS_STATIC, RTS_DEVICE, RTS_BGP, RTS_OSPF] then accept; else reject; };
 import limit 1000 action block;
 };
 ipv6 mpls {
 next hop self;
 import keep filtered;
 import filter {
 if is_valid6_loopback() then {
 accept;
 } else reject;
 };
 export filter { if is_valid6_loopback() && source ~ [RTS_STATIC, RTS_DEVICE, RTS_BGP, RTS_OSPF] then accept; else reject; };
 import limit 1000 action block;
 };
 mpls {
 label policy aggregate;
 };
}

VRF-Specific BGP Sessions

Each VRF instance establishes BGP sessions with MPLS label distribution:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30


# <IFNAME>
# L: AS4242421945 | R: AS4242421945
protocol bgp <IFNAME> from kittunderlay {
 # disabled;
 local as 4242421945;
 neighbor fe80::xxxx as 4242421945;
 interface "<IFNAME>";
 direct;
 ipv4 mpls { # Inform MPLS labels in addition to loopback routes
 import filter {
 if ( is_valid4_loopback() ) then {
 # here use some additional functions to set MED / communities
 accept;
 }
 reject;
 };
 };
 ipv6 mpls { # Inform MPLS labels in addition to loopback routes
 import filter {
 if ( is_valid6_loopback() ) then {
 # here use some additional functions to set MED / communities
 accept;
 }
 reject;
 };
 };
 mpls {
 label policy aggregate;
 };
}

MPLS Label Handling

The label policy aggregate in the BGP template ensures efficient MPLS label allocation for VRF routes. This approach:

Reduces label consumption by aggregating when possible
Maintains proper forwarding state for VRF instances
Enables seamless traffic isolation between routing tables

Features

✅ Clear separation of global and VRF routing planes
✅ MPLS integration for VRF-specific traffic only
✅ NixOS friendly configurations

Getting Started

Planned documentation will include:

Enabling VRFs with MPLS-based forwarding
Understanding MPLS label distribution for VRF routes
Configuring VRF instances and route distinguishers
Verifying VRF isolation and forwarding behavior

MPLS in KittUnderlay is about applying the right level of complexity—using label-based forwarding only where it provides clear benefits for traffic segmentation.

Kitten Router OS

Sat, 15 Jun 2024 00:00:00 +0000

The Kitten Router OS (WIP Draft)

Introduction

RoutehOS is a work-in-progress routing operating system aimed at delivering a clean, intuitive, and accessible networking experience. Designed with beginners in mind, it provides both local and global web interfaces that simplify interaction with network infrastructure. The goal is to make networking feel less intimidating and more exploratory—turning first-time users into confident operators.

Project Vision

This project is currently in an early draft stage and continues to evolve. The core idea behind RoutehOS is to reduce the traditional complexity of routing and network management without stripping away essential functionality. Instead of overwhelming users with dense configurations and unfamiliar terminology, RoutehOS introduces a guided, structured approach to learning and managing networks.

By lowering technical barriers, it enables users to gradually build knowledge while actively working within a real networking environment. The system is intended not only as a tool, but also as a learning platform.

Key Goals

Simplify network configuration workflows
Provide an educational, beginner-first experience
Maintain flexibility for more advanced use cases over time
Offer a consistent interface for both local and remote management
Build a scalable foundation that can grow with user needs

Features (Planned & In Progress)

Intuitive, user-friendly web interface
Streamlined routing and network setup
Integration with existing network environments
Built-in security-focused design principles
Modular and scalable system architecture
Guided setup and contextual help for new users

Current Status

RoutehOS is an active work in progress. Features, design, and architecture are subject to change as the project develops. Feedback and iteration play a key role in shaping the system.

Getting Started

As development progresses, installation instructions and documentation will be made available. The aim is to provide a straightforward onboarding process through a guided web interface, allowing users to quickly deploy and experiment with the system.

RoutehOS is not just about managing networks—it’s about making networking approachable, practical, and engaging from day one.

KittUnderlay Routing Fabric

Thu, 21 Dec 2023 00:00:00 +0000

The KittUnderlay Routing Fabric (WIP Draft)

Introduction

KittUnderlay is a work-in-progress routing architecture designed to explore a secure, scalable, and structured foundation for internal network routing. Built on iBGP mesh with WireGuard-based transport, the underlay ensures reliable connectivity between all nodes while maintaining simplicity and clarity.

Project Vision

The underlay architecture demonstrates that complex routing designs can remain understandable when responsibilities are clearly separated. Instead of overloading the network with unnecessary abstractions, the architecture applies each technology where it makes the most sense. Loopback addresses are distributed using standard iBGP, ensuring simplicity and universal reachability.

Where beneficial, the system introduces controlled dynamism—such as latency-informed MED adjustments—to improve path selection without sacrificing predictability.

As the network scales, Route Reflectors are introduced to optimize control-plane efficiency while maintaining consistent route visibility.

Key Goals

Maintain a clean and deterministic iBGP control plane
Use WireGuard for secure and flexible node-to-node connectivity
Keep loopback routing simple and label-free
Enable scalable growth through Route Reflectors
Preserve clarity between underlay, overlay, and service layers

Architecture Overview

Full iBGP Mesh (Initial Phase)
Every node peers directly with their adjacent neighbors using Link-Local IPv6, allowing straightforward route propagation and easier troubleshooting during early stages.

graph LR
%% Center node
RR["Route Reflectors"]
%% Surrounding routers
R1["R1"]
R2["R2"]
R3["R3"]
%% iBGP (hub-and-spoke)
RR <-. "multiHop iBGP" .-> R1
RR <-. "multiHop iBGP" .-> R2
RR <-. "multiHop iBGP" .-> R3
%% Underlay (mesh between routers)
R1 <== "iBGP" ==> R2
R2 <== "iBGP" ==> R3
R3 <== "iBGP" ==> R1

WireGuard Underlay
All non-physical BGP sessions operate over WireGuard tunnels, providing encrypted transport independent of physical infrastructure. All tunnels configured with a unique peer where AllowedIPs = 0.0.0.0/0, ::0/0

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


[NetDev]
Kind=wireguard
Name=<IFNAME>

[WireGuard]
ListenPort=<ListenPort>
PrivateKeyFile=/run/secrets/wireguard_serverkey

[WireGuardPeer]
AllowedIPs=0.0.0.0/0
AllowedIPs=::/0
PersistentKeepalive=10
PublicKey=<PeerKey>

Loopback Announcements
Loopback interfaces are advertised via iBGP without MPLS labels. These addresses serve as stable router identifiers and core reachability endpoints across the fabric.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39


template bgp kittunderlay {
 local port 1790;
 neighbor port 1790;
 rr client;
 path metric off;
 ipv4 {
 extended next hop;
 next hop self;
 import keep filtered;
 import filter {
 if is_valid4_loopback() then {
 if defined( bgp_med ) then
 bgp_med = bgp_med + 2147483648;
 else {
 bgp_med = 2147483648;
 }
 accept;
 } else reject;
 };
 export filter { if is_valid4_loopback() && source ~ [RTS_STATIC, RTS_DEVICE, RTS_BGP, RTS_OSPF] then accept; else reject; };
 import limit 1000 action block;
 };
 ipv6 {
 next hop self;
 import keep filtered;
 import filter {
 if is_valid6_loopback() then {
 if defined( bgp_med ) then
 bgp_med = bgp_med + 2147483648;
 else {
 bgp_med = 2147483648;
 }
 accept;
 } else reject;
 };
 export filter { if is_valid6_loopback() && source ~ [RTS_STATIC, RTS_DEVICE, RTS_BGP, RTS_OSPF] then accept; else reject; };
 import limit 1000 action block;
 };
}

Route Reflectors (Scaling Phase)
As the topology expands, Route Reflectors reduce the number of iBGP sessions required while preserving full route distribution across the network.
Adaptive Path Selection (Latency-Aware MED) A lightweight Go-based service runs alongside each node, continuously measuring latency between BGP peers over the WireGuard underlay. Based on observed performance, it dynamically adjusts BGP MED (Multi-Exit Discriminator) values to influence path selection, allowing the fabric to react to changing network conditions without manual intervention.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35


# <IFNAME>
# L: AS4242421945 | R: AS4242421945
protocol bgp <IFNAME> from kittunderlay {
 # disabled;
 local as 4242421945; # localIP: ""
 neighbor fe80::xxxx as 4242421945;
 interface "<IFNAME>";
 direct;
 ipv4 {
 import filter {
 if ( is_valid4_loopback() ) then {
 if defined( bgp_med ) then
 bgp_med = bgp_med + autoMED_<IFNAME>;
 else {
 bgp_med = autoMED_<IFNAME>;
 }
 accept;
 }
 reject;
 };
 };
 ipv6 {
 import filter {
 if ( is_valid6_loopback() ) then {
 if defined( bgp_med ) then
 bgp_med = bgp_med + autoMED_<IFNAME>;
 else {
 bgp_med = autoMED_<IFNAME>;
 }
 accept;
 }
 reject;
 };
 };
}

Features

✅ Full iBGP mesh configuration templates
💭 Automated WireGuard tunnel deployment
✅ Route Reflector deployment models
⚒️ Observability and route inspection tooling
✅ NixOS friendly configurations
✅ Automated MED adjustment based on real-time network performance
💭 Policy controls to bound and stabilize dynamic routing decisions

(Planned 💭 - In Progress ⚒️ - Done ✅)

Current Status

KittUnderlay is actively under development. Current efforts focus on stabilizing the interaction between the WireGuard underlay and iBGP control plane. Also we need to find a way to have different routing views using VRFs / PBR.

Route Reflector behavior and scaling patterns are being tested in parallel.

Getting Started

Planned documentation will include:

Building a WireGuard full mesh underlay
Establishing iBGP sessions across all nodes
Advertising loopbacks without MPLS
Transitioning from full mesh to Route Reflector topology

The objective is to provide a progressive learning path—from simple full-mesh routing to a more scalable, production-like design.

KittUnderlay is about building a strong foundation and applying the right level of complexity in the right place, keeping the network both powerful and understandable.