BSD Router Project 2.0 — modern, compact, and ready for production

BSD Router Project 2.0 — modern, compact, and ready for production

Table of contents:-

What changed in 2.0 and why it matters

What’s included: notable packages and their operational role

Installation and upgrade: practical notes

Official upgrade guide (concise, operator-focused)

How to enter FRR router mode (quick operational steps)

Operational tips and best practices

Brief conclusion

BSD Router Project 2.0 is a carefully reworked, production-oriented router distribution built on FreeBSD that focuses on reliability, routing features, and a small operational footprint. The 2.0 release moves BSDRP onto a newer FreeBSD base, modernises the build and image process, adds aarch64 support, and refreshes the package set to deliver current routing stacks and tools for ISP, datacentre and advanced home lab use.

What changed in 2.0 and why it matters

BSDRP 2.0 is not a routine patch release. It rethinks how images are produced and which workloads the distribution targets, with practical outcomes that matter immediately to operators.

• New FreeBSD base and ports snapshot: The distribution now tracks FreeBSD 16-main and a recent ports tree snapshot, which brings newer system libraries, kernel features, and improved hardware support compared with the previous BSDRP branches. That foundation reduces the friction of running modern networking stacks on contemporary hardware and enables access to recent security and performance improvements.

• Build system overhaul — poudriere-image replaces the old NanoBSD framework: Images are now produced with the official poudriere-based method rather than the legacy NanoBSD toolchain. This brings two tangible benefits: packages are built with the standard FreeBSD ports methodology, improving reproducibility and compatibility with upstream ports; and image generation now supports both BIOS and UEFI boot modes plus GPT partition layouts, making installation and multi-platform deployment far simpler. Note: migrating an existing MBR-based installation to GPT requires a full reinstall; the upgrade path does not perform an in-place MBR→GPT conversion.

• aarch64 support: 2.0 adds first-class aarch64 images, opening BSDRP to a wide range of ARM hardware used in small lab devices, edge appliances, single-board systems and modern server platforms.

• Routing stacks and tooling updates: Key routing packages are refreshed — Bird, FRR, and others — and FRR builds now include Lua scripting support. The distribution ships current versions of VPN and tunnelling tools (OpenVPN, StrongSwan), monitoring utilities and an expanded set of network-analysis tools, giving network engineers up-to-date operational tooling out of the box.

• New and removed packages: The release introduces packages such as VPP (fast userspace packet processing), flashrom and Mellanox device tools (mstflint). At the same time, older DHCP packages such as isc-dhcp44 and dhcprelya were removed in favour of dnsmasq for lightweight DHCP/DNS needs, reflecting a deliberate streamlining of recommended components.

Why this matters in plain terms: the new build process and updated package set mean BSDRP images are now closer to mainstream FreeBSD workflows. Operators benefit from better hardware compatibility, reproducible builds, and modern routing features — while the decision to require a reinstall for GPT/UEFI transition provides a safe, predictable migration path instead of risky automated disk surgery.

What’s included: notable packages and their operational role

BSDRP 2.0’s package choices reflect its role as a focused routing distribution. The list is long and comprehensive; here are the highlights and why you’d care:

• Routing daemons: Bird 2.17 and FRR 10.4.1 (with Lua enabled) provide BGP/OSPF/MPLS capabilities and scripting hooks for advanced automation and route policy. These versions bring protocol improvements, stability fixes and better integration with modern control-plane tooling.

• Fast and programmable dataplane: vpp (Vector Packet Processing) is included for high-performance forwarding needs where userspace dataplanes are required for throughput and programmability.

• Monitoring and diagnostics: updated iperf3, mtr, netperf and packet capture libraries (libpcap) give engineers accurate performance testing and visibility tools during deployment and troubleshooting.

• VPN and security: OpenVPN and StrongSwan versions are current, enabling robust site‑to‑site and road‑warrior VPN configurations; supplementary packages like wireguard-tools remain available for modern tunnel options.

• Hardware and firmware utilities: flashrom and mstflint help manage firmware and vendor tools for NICs (including Mellanox), useful for datacentre maintenance and recovery workflows.

• System polish: packages such as monit, lldpd, and cpu-microcode support make BSDRP fit smoothly into production management landscapes by addressing automation, discovery and microcode security updates.

The distribution’s long package list also includes common libraries and language runtimes such as Python 3.11, up-to-date compilers and runtime libraries. That ensures compatibility with automation, monitoring agents and custom scripts you may want to run directly on the router appliance.

Installation and upgrade: practical notes

High-level guidance and important caveats:

• Fresh installs vs upgrades: Because the image generation now supports dual BIOS/UEFI and GPT, those features require a fresh installation to take effect. If you are on an older MBR-based install and want GPT/UEFI, plan for a reinstall and schedule downtime accordingly.

• Minimum existing version to upgrade in-place: If you are upgrading rather than reinstalling, BSDRP 1.994 or later is required as a baseline for in-place upgrade paths; attempting an in-place upgrade from earlier versions is unsupported and likely to fail.

• Package and configuration compatibility: Although packages have been updated, most service configuration formats remain compatible. Nonetheless, operators should test configuration backups and validate services (BGP/OSPF sessions, DHCP leases, firewall rules) in a staging environment before rolling the release out to production.

• Architecture selection: Choose x86_64 or aarch64 images carefully based on your hardware. aarch64 support broadens hardware options but verify vendor drivers and firmware for your target platform.

These points summarise the operational decisions required when planning an upgrade or fresh deployment. 

Below you’ll find a step-by-step section that gives the official upgrade guidance and a practical method to enter FRR router mode.

Official upgrade guide (concise, operator-focused)

This is the official, recommended approach distilled from the project release notes and announcements:

1. Verify current version: Ensure your running BSDRP instance is 1.994 or later; if not, plan for a staged upgrade or fresh reinstall.

2. Backup everything: Export configuration files, routing configs, ZFS or UFS dataset snapshots and any custom scripts. Validate your backups offline and keep bootable rescue media ready.

3. Download the appropriate 2.0 image: Select the correct architecture (x86_64 or aarch64) and boot mode (BIOS/UEFI) for your hardware from the BSDRP downloads page.

4. For MBR→GPT or UEFI enablement: Plan a full reinstall. Boot the 2.0 installer media, repartition the target disk using GPT and install the image fresh; restore configurations from your backups after the install completes.

5. For in-place upgrades (same boot mode and partition scheme): Follow the project’s recommended in-place upgrade steps provided in the official upgrade documentation and release notes, ensuring the running system is at least version 1.994 and that you use the project-provided upgrade script or procedures.

6. Validate services: After upgrade/reinstall, check kernel messages, restart routing daemons and confirm BGP/OSPF neighbor relationships, NAT/DHCP behaviour, and management-plane access before declaring the node ready.

This compact set of steps represents the stable, low-risk path recommended by the project for moving to 2.0. It emphasises backup, image selection and the requirement to reinstall for GPT/UEFI migration.

How to enter FRR router mode (quick operational steps)

FRR is central to BSDRP’s routing capabilities. FRR stands for FRRouting (originally Free Range Routing), an open-source IP routing suite that implements routing protocols such as BGP, OSPF, IS-IS, RIP, PIM, and others for Unix-like systems. It runs as a routing daemon set, exchanges routing information with peers, makes routing decisions, and installs routes into the OS kernel for packet forwarding.

Use these steps to start and manage FRR in BSDRP 2.0:

1. Install or verify FRR is present: Confirm frr 10.4.1 (or the packaged version) is installed on your system; the BSDRP image includes it by default.

2. Enable the FRR service: On BSDRP, the routing services are controlled by rc.d scripts. Enable FRR at boot and start it immediately:

• Enable at boot: add the appropriate frr_enable flag in /etc/rc.conf (for example: frr_enable="YES").

• Start the service: run the rc.d start command for frr (for example: service frr start).

3. Enter the FRR CLI: Use vtysh to access the FRR integrated CLI, which aggregates Zebra, BGP, OSPF and other daemons into a single management shell:

• Start vtysh: run vtysh from the shell to enter the FRR CLI context.

• Configure protocols: use normal FRR commands (configure terminal, router bgp <asn>, neighbor <ip> remote-as <asn>, etc.) to declare BGP sessions and policies.

4. Persist and validate: Save configurations to the FRR config files (typically under /etc/frr/) and use show commands (show ip bgp summary, show running-config) to validate neighbor status and route tables.

These steps reflect standard FRR operational practices and align with the packaged FRR experience included in BSDRP 2.0.

Operational tips and best practices

• Test in a lab: Always validate BGP/OSPF policies and automation in a test environment before pushing changes to production.

• Use versioned configuration backups: Because package upgrades can change behaviour, maintain timestamped, versioned backups of /etc/ and FRR configuration so you can quickly roll back.

• Monitor proactively: Leverage the included monitoring tools (monit, lldpd, nagios plugins) to implement health checks that alert on routing flaps, interface failures or daemon crashes.

• Prefer standard packages: The move to poudriere-based builds means packages align with standard FreeBSD ports; prefer packaged versions to local builds for stability and reproducibility.

• Plan hardware firmware updates: Tools like mstflint and flashrom are included for firmware maintenance; schedule firmware updates in maintenance windows and keep NVMe/BIOS/firmware vendor guidance handy.

Brief conclusion

BSD Router Project 2.0 is a pragmatic, modern step forward that realigns the distribution with upstream FreeBSD processes, broadens hardware support through aarch64 and dual boot modes, and refreshes the routing and management toolset for today’s network demands. For operators the message is simple: plan for a reinstall if you need GPT/UEFI, test thoroughly, and you’ll gain a lean, well-maintained routing platform that fits both lab and production use cases.

Disclaimer: BSD Router Project, FreeBSD, FRR, Bird, VPP, and the other trade names referenced are the trademarks or registered trademarks of their respective owners and are acknowledged here for identification purposes only. This post takes a strong stance against endorsing malware, viruses, or any content that could harm digital systems. We also do not support or condone any form of exploiting open-source software in ways that are unlawful or unethical.

References (official sources used)

• BSD Router Project

• [Bsdrp-announce] BSD Router Project 2.0 available

• BSD Release: BSD Router Project 2.0 (DistroWatch.com News)

---

▲

Back to top