Michiel Piscaer

Homelab

I am setting up an IPv6-only homelab with Forgejo, OpenTofu + Terragrunt, MikroTik switches, and BIRD3 OSPFv3 routing. A Forgejo runner operates inside the homelab and configures the network using Infrastructure-as-Code. The entire IoC configuration is publicly available on Codeberg. homelab

#IPv6 #Homelab #Forgejo #OpenSource #MikroTik #OSPF #OpenTofu #Terragrunt #BIRD #Automation


Getting Started with Forgejo

I set up a Forgejo runner inside my homelab network so the runner can configure the switches and nodes directly. In theory, this isn’t strictly necessary because everything runs on IPv6 without NAT; with proper firewall rules, internet-originating traffic could reach the homelab as well.

My configuration is public on Codeberg:
Repository: myOpenstackCluster (https://codeberg.org/mpiscaer/myOpenstackCluster)

Why Codeberg?

  • 🇪🇺Based in Europe
  • 🫶Non-profit
  • 🌐Full IPv6 support

I followed the official installation guide: https://forgejo.org/docs/next/admin/actions/runner-installation/

Because this runner is IPv6-only, I made a few adjustments.

  1. Forgejo Configuration

In config.yml, I enabled:

enable_ipv6: true

2. Docker Configuration

{
  "ipv6": true,
  "experimental": true,
  "ip6tables": true,
  "fixed-cidr-v6": "fd00:d0ca:1::/64",
  "default-address-pools": [
    { "base": "172.17.0.0/16", "size": 24 },
    { "base": "fd00:d0ca:2::/104", "size": 112 }
  ],
  "registry-mirrors": [
    "https://registry.ipv6.docker.com"
  ]
}

This configuration:

  • Enables IPv6 networking
  • Provides an IPv6 address pool for containers
  • Uses Docker Hub’s IPv6 registry mirror

Network layout

My homelab currently consists of three switches and three compute nodes.

network diagram

Switch Configuration

Now that the Forgejo runner is operational, I can continue setting up the network. The long-term goal is to use BGP unnumbered, but that requires more preparation. For now, I’m starting with an IPv6-only OSPF setup, which avoids assigning global IPv6 addresses to every link and keeps early configuration simpler.

The plan is to use OpenTofu with Terragrunt to manage switch configuration as Infrastructure as Code.

Before Terragrunt can manage the switches, I need a minimal bootstrap configuration:

  • Create a user
  • Create TLS certificates
  • Enable HTTPS and the API

Now that the runner is running I can continue with the network setup. The goal of the Lab is to have a Unnumbered bgp setup. Currently for now it is to complex/new. So we start with a IPv6 only OSPF setup, the advantages is that you don't need to setup a IPv6 global adress range on every interface, this makes the setup easier. For now it is harder to figure out how it all works.

We will use OpenTofu and Terragrunt to configure the switches.

We start the setup with some basic setup so that the IoC(Intrastructure as Code) can connect to it.

We will enable the following:

  • Create a user
  • Create a certificate for the TLS
  • Enable the TLS webserver
  1. Create the user

    /user/add group=full comment="The user for the Forgejo Runner" name=forgejorunner password="MyS3cr3tP4ss"
    
  2. Enable the API and HTTPS Using this guide: https://www.shellhacks.com/mikrotik-enabling-https-for-webfig-api/

This generates certificates and enables the API over TLS. Terragrunt will later replace this configuration.

  1. Create the CA

    [admin@MikroTik] > /certificate add name=root-ca-template \
                                     common-name=root-ca \
                                     days-valid=99999 \
                                     key-size=2048 \
                                     key-usage=crl-sign,key-cert-sign
    [admin@MikroTik] > /certificate sign root-ca-template name=root-ca
    
  2. Create the MikroTik certificate

    [admin@MikroTik] > /certificate add name=mikrotik-ssl-template \
                                    common-name=mikrotik-ssl \
                                    days-valid=99999 \
                                    key-size=2048
    [admin@MikroTik] > /certificate sign mikrotik-ssl-template name=mikrotik-ssl ca=root-ca
    
  3. Mark the Mikrotik certificate trusted

    [admin@MikroTik] > /certificate set [find name=mikrotik-ssl] trusted=yes
    
  4. Assign the certificate to www-ssl and api-ssl

    [admin@MikroTik] > /ip service set www-ssl certificate=mikrotik-ssl disabled=no
    [admin@MikroTik] > /ip service set api-ssl certificate=mikrotik-ssl disabled=no
    

Terragrunt

OpenTofu (a Terraform fork) will manage the MikroTik configuration.
I found a useful example here:

https://github.com/mirceanton/mikrotik-terraform.git

I adapted parts of it: * router-base module * MikroTik provider code * Additional modules for IPv6 addressing, OSPF setup, and SSH key configuration


🖥️node setup

For now, the three nodes are configured manually. Eventually they will be managed through Ansible and integrated into the overall IaC workflow.

The nodes receive their IPv6 addresses via Router Advertisements. Using Netplan, I configured a static IPv6 address on each loopback interface. This loopback address will be propagated via OSPF.

BIRD3 Installation and Configuration

To install BIRD3, I followed the instructions from: https://pkg.labs.nic.cz/doc/?project=bird.

  1. Download the repository key

    sudo wget -O /usr/share/keyrings/cznic-labs-pkg.gpg https://pkg.labs.nic.cz/gpg
    
  2. Add the APT repository

    echo "deb [signed-by=/usr/share/keyrings/cznic-labs-pkg.gpg] https://pkg.labs.nic.cz/bird3 jammy main" | sudo tee /etc/apt/sources.list.d/cznic-labs-bird3.list
    
  3. Install BIRD3

    sudo apt-get update && sudo apt-get install bird3
    
  4. Make the bird configuration

    # =========================================================
    # GLOBAL SETTINGS
    # =========================================================
    #
    router id 172.17.40.12;
    #
    # =========================================================
    # KERNEL ROUTING
    # =========================================================
    protocol kernel {
    persist;
    learn;
    ipv6 {
    import all;     # Accept routes from kernel
    export all;     # Install BIRD-learned routes into kernel
    };
    }
    #
    # =========================================================
    # DEVICE PROTOCOL
    # =========================================================
    protocol device {
    scan time 5;
    }
    #
    # =========================================================
    # DIRECT (CONNECTED) ROUTES
    # =========================================================
    protocol direct {
    ipv6;
    interface "lo", "enP4p65s0", "enP2p33s0";
    }
    #
    # =========================================================
    # OSPFv3 (IPv6)
    # =========================================================
    protocol ospf v3 ospf6 {
    ipv6 {
    import all;
    export where source = RTS_DEVICE;  # Only advertise connected routes
    };
    area 0 {
    # Uplink / LAN interfaces
    interface "enP4p65s0" {
      hello 10;
      retransmit 5;
      cost 10;
    };
    interface "enP2p33s0" {
      hello 10;
      retransmit 5;
      cost 10;
    };
    };
    }
    

Just received my new ArmSoM Sige7 and started testing the provided Ubuntu 22.04 image and Rockchip loader. Flashed the board, set up the system, and ran initial CPU stress tests. Power usage looks great: ~7.5W under full load and ~2.5W idle, with temps staying cool and the fan barely audible. Promising start for this RK3588-based board!

#ArmSoM #Sige7 #RK3588 #SingleBoardComputer #SBC #Linux #Ubuntu #Homelab #ARM #TechNotes #SelfHosting

ArmSoM Sige7 — First Impressions & Setup Notes

Today, I received my ArmSoM Sige7 single-board computer, and I couldn’t wait to dive into setting it up and testing its performance. This post details my first impressions, the setup process, and the results of some early benchmarking.

Unboxing & Setup

The ArmSoM Sige7 came with a few essential files, available for download from ArmSoM's manual page. These files included the Ubuntu 22.04 preinstalled server image and the Rockchip firmware loader. Here’s what I downloaded:

  • ubuntu-22.04-preinstalled-server-arm64-armsom-sige7.img
  • rk3588_spl_loader_v1.15.113.bin

Preparing the Image

Before flashing the image onto the device, I decided to mount it locally on my computer to set the root password and make a few changes. Here’s how I did it:

losetup -f -P ubuntu-22.04-preinstalled-server-arm64-armsom-sige7.img
losetup -l
mount /dev/loop23p2 /mnt/armsom/

After saving the changes, I unmounted the image and prepared to load the firmware and flash the image to the MMC.

Flashing the Image

To flash the OS image, I used rkdeveloptool, a tool for working with Rockchip-based devices. Here’s the process:

snap install --edge rkdeveloptool
snap connect rkdeveloptool:raw-usb
rkdeveloptool db rk3588_spl_loader_v1.15.113.bin
rkdeveloptool wl 0 ubuntu-22.04-preinstalled-server-arm64-armsom-sige7.img

Once the flashing process was complete, the board was ready to boot into Ubuntu!

CPU Stress Test & Power Usage

I ran a quick CPU stress test to evaluate the board's performance under load. Here’s what I found:

  • Power Usage:

    • ** Idle:** 2.5W
    • Under Load (CPU stress test): 7.5W
  • Temperature:

    • Idle: 46°C
    • Max Load: 55°C

During the stress test, the fan remained completely silent, which suggests that the cooling solution is effective at handling the heat dissipation at this load.

Stress Test Output

Here’s the output from the stress test, using the stress-ng tool:

michiel@node1:~$ stress-ng --cpu 8 --timeout 60s --metrics-brief --timeout 60s
stress-ng: info:  [2477] setting to a 60 second run per stressor
stress-ng: info:  [2477] dispatching hogs: 8 cpu
stress-ng: info:  [2477] successful run completed in 60.13s (1 min, 0.13 secs)
stress-ng: info:  [2477] stressor       bogo ops real time  usr time  sys time   bogo ops/s     bogo ops/s
stress-ng: info:  [2477]                           (secs)    (secs)    (secs)   (real time) (usr+sys time)
stress-ng: info:  [2477] cpu               66276     60.03    479.56      0.00      1104.12         138.20

What's Next: GPU & NPU Testing

While the initial setup and CPU stress test have been promising, there’s a lot more to explore with the ArmSoM Sige7, especially the GPU and NPU.

The RK3588 chip includes a powerful Mali-G610 GPU and a dedicated NPU for AI and machine learning tasks. These features open up exciting possibilities for high-performance graphics rendering, AI inference, and edge computing applications.

In the coming weeks, I’ll be diving deeper into these capabilities:

GPU Testing: I plan to run graphics benchmarks, 3D rendering tests, and maybe even some gaming or multimedia applications to explore how well the Mali-G610 performs.

NPU Testing: I'll also look at utilizing the NPU for AI workloads, such as neural network inference or image processing. This could be a great way to speed up machine learning tasks on the edge.

Stay tuned as I continue to push the limits of this board — I’m excited to see how these advanced features perform under real-world conditions!

Conclusion

My first impressions of the ArmSoM Sige7 are very positive. The flashing process was straightforward, and the board is running smoothly with minimal power consumption. The temperature and noise levels are also impressive — even under load, the fan remains silent, and the temperature stays well within safe limits.

I’m excited to explore this board further, especially in the context of self-hosting and homelab setups. Stay tuned for more detailed posts as I continue to test and explore the possibilities with this device.

Tags: #ArmSoM #Sige7 #RK3588 #GPU #NPU #MaliG610 #AI #MachineLearning #EdgeComputing #SingleBoardComputer #SBC #Linux #Ubuntu #TechReview #Graphics #Homelab

TL;DR: I back up my homelab using Snapper snapshots, an external dual-bay dock, weekly disk rotation, encryption, and a Hue lamp that shows the backup status.


How I do my backup

On my homelab server, I’ve got a bunch of LXC containers running on a Btrfs filesystem. Snapper takes care of making hourly snapshots for me.

I wrote a little backup script that sends those snapshots to an ACT Dual Bay Docking Station—basically an external dock that can hold two hard drives.

Once a week, I swap out the disks and store the one I remove outside the house, just in case. Everything is encrypted, of course.

For fun (and convenience), the backup status gets sent to OpenHAB, which changes a Hue lamp in the living room so I can see at a glance whether everything’s working.

#homelab #backup #btrfs #lxc #snapper #openhab #selfhosted #linux #infosec

Summary: I’m building a low-power ARM homelab running Kubernetes on an IPv6-only routed network. I’ll experiment with Open-Xchange, OpenStack, VXLAN, and AI frameworks like PyTorch and TensorFlow.

#homelab #arm #kubernetes #openstack #openxchange #ipv6 #bgp #ospf #vxlan #mikrotik


I’m planning to build a low-power ARM-based homelab that can optionally run Android. The main environment will be a Kubernetes (k8s) cluster operating on an IPv6-only backend network. The underlay network will be fully routed using OSPF or BGP, providing redundancy without relying on LACP.

Later, I plan to deploy Open-Xchange on the Kubernetes cluster, followed by OpenStack-Helm. The provider network will also be routed through the underlay, likely using VXLAN as the overlay protocol. I also want to experiment with AI frameworks such as PyTorch and TensorFlow.


Hardware Overview

The switching layer will be based on two MikroTik desktop switches, forming the core of the redundant network.

Candidate Switch

A switch I’m considering is the MikroTik CRS310-8G+2S+IN, offering:

  • 8 × 2.5GbE ports
  • 2 × SFP+ ports
  • Routing capabilities
  • Support for OSPF and BGP

The primary requirements are having enough ports for all nodes and ensuring sufficient routing capacity for the underlay network.


Compute Nodes

I’ve evaluated two potential ARM-based node options:

Below is a summary of both.


Armsom Sige7-Pro Max

  • CPU: 4 × Cortex-A76 @ 2.4GHz + 4 × Cortex-A55 @ 1.8GHz (8nm)
  • RAM: 32GB
  • GPU: Mali-G610
  • NPU: 6 TOPS
  • AI Support: PyTorch and TensorFlow (limited SBC-class acceleration)

Cost: – $252 (~€210) for the SBC – Additional cost for cooling, power supply, and storage – Approx. €900 total for a three-node setup


MiniS Forum MS-R1

  • CPU: CIX CP8180 (12 cores / 12 threads @ 2.6GHz)
  • TDP: 28W
  • NPU: 28.8 TOPS (45 TOPS total AI capacity)
  • Memory & Storage: 32GB RAM, 1TB SSD included

Cost: – €659 (or €599 during the Black Friday deal) – Approx. €1.977,- for three nodes


Conclusion

The Armsom Sige7-Pro Max is significantly more affordable and offers decent performance for its size, but it is still a single-board computer and noticeably slower overall.

The MiniS Forum MS-R1, on the other hand, provides much stronger CPU performance, better storage capability, and more powerful AI acceleration—but at a much higher price.

In summary:

  • Armsom Sige7-Pro Max:

    • ✔ Budget-friendly
    • ✔ Low power
    • ✘ Limited performance
  • MiniS Forum MS-R1:

    • ✔ Strong performance
    • ✔ Ready-to-use hardware
    • ✘ Considerably more expensive

#homelab #arm #kubernetes #openstack #openxchange #ipv6 #bgp #machinelearning #tensorflow #pytorch