NetLab Switch is a personal experimental project exploring how a small switch
operating system can be designed, implemented, and validated on real
data-center class Ethernet hardware. The current lab target is built around
Intel FM10000/FM10840 switching silicon, the Linux fm10k host-interface
driver path, and a PE31625G24DIRA-based hardware platform.
The project is not presented as a commercial distribution or a general-purpose network operating system. It is a long-running engineering experiment focused on control-plane design, hardware abstraction, routing integration, forwarding validation, and reproducible release evidence.
- Switching silicon: Intel FM10000 family, with current profiles and validation centered on FM10840/RubyRapid-class hardware.
- Host interface: the Linux
fm10kdriver path, including local hardening and validation for control-plane and packet I/O behavior. - Board target: PE31625G24DIRA-based hardware, including platform profiles, split-speed bring-up work, and muxed optics/DOM validation paths.
- Validation model: hardware-dependent tests are treated as live gates and kept separate from public-safe source and documentation where needed.
- Switch OS foundations: configuration management, daemon supervision, IPC contracts, platform profiles, and operator CLI workflows.
- Hardware abstraction: typed forwarding plans, SDK ownership control, read-back verification, rollback paths, and capability-aware feature gates.
- Routing and forwarding: FRR-backed control-plane integration, FIB programming, neighbor handling, ECMP behavior, and route-scale validation.
- Hardware validation: VLAN, LAG, STP/MSTP, ACL, QoS, L3 route, replay, reconvergence, and traffic-soak experiments.
- Release discipline: pinned dependencies, frozen driver/runtime versions, reproducible build assumptions, manifests, and validation notes.
The work is split by lifecycle rather than kept in a single catch-all repository:
| Area | Purpose |
|---|---|
| Core platform | Switch OS source, daemon code, CLI, tests, docs, and public-safe checks. |
| Driver integration | Validated host-interface driver sources, patches, manifests, and gate scripts. |
| Runtime bundles | Runtime manifests, third-party notices, checksums, and rebuild notes. |
| Lab infrastructure | Private hardware topology, traffic-generator setup, runner configuration, and environment templates. |
| Release evidence | Version matrices, soak summaries, validation ledgers, and freeze records. |
Some repositories may remain private because they can include hardware-specific details, licensed vendor dependencies, or controlled lab validation evidence.
- Keep ownership explicit: hardware programming should pass through a defined owner boundary.
- Verify real state: configuration intent is not enough; hardware read-back and traffic behavior matter.
- Fail closed by default: unsupported or unvalidated hardware paths should remain unavailable until evidence exists.
- Prefer reproducibility: source, runtime artifacts, driver versions, and validation results should be pinned and traceable.
- Test on real hardware: simulations are useful, but forwarding behavior ultimately needs live traffic and long-running soak validation.
This is an active personal lab project. Public-facing material will be published gradually as repository hygiene, licensing boundaries, third-party notices, and hardware-dependent workflows are cleaned up for external reading.