Building a Carrier‑Grade Yaesu IMRS Backbone on 44Net: A Replicable Playbook from VK

April 9, 2026

Below is a guest contribution from Phil Kern VK5PK, a 44Net user. If you’re a 44Net user and are interested in submitting a guest contribution, please reach out to comms@ardc.net.

Summary

Australian clubs and KernWi‑Fi, a local ISP, partnered to engineer a carrier‑grade IP fabric for Yaesu Internet-linked Multi-site Repeater System (IMRS) (DR‑2X) linking— using 44Net— with audited (Border Gateway Protocol) BGP announcements, reverse Domain Name System (rDNS) hygiene, and simple operational guardrails that clubs can replicate. The backbone centers on a managed core (Kern DC) with Open Shortest Path First (OSPF) at the edges, strict Virtual Local Area Network (VLAN) separation for deterministic voice paths, and public visibility of the 44.30.65.0/24 route originated by AS137399. Early results indicate predictable audio and easy onboarding for new repeaters, all of which has led to national coverage in Wireless Institute of Australia (WIA) News and other international ham media outlets.

This work demonstrates that deterministic digital-voice transport is achievable when IMRS is operated over a purpose-built IP fabric with stable addressing, authenticated routing, and strict traffic isolation. By publishing transparent, reproducible architecture— complete with BGP origin hygiene, OSPF convergence behaviour, and VLAN segmented QoS domains— it provides a reference implementation that clubs can clone or extend, accelerating the adoption of carrier style design patterns within amateur infrastructure.

This post shares the architecture, the ‘why 44Net,’ the controls that keep it stable, and a step‑by‑step on‑ramp using the 44Net Portal and 44Net Connect.

What is 44Net and why 44Net for linked repeaters?

44Net offers licensed hams, at no cost, globally routable, static IPv4 space for experimentation and learning— no CGNAT, no address churn, and a community committed to open, non‑commercial use. That’s ideal for multi‑site repeater linking, where stable addressing, transparent routing, and teachable network discipline matter as much as RF coverage.

ARDC’s recent investments, specifically 44Net Portal 2.0 and 44Net Connect, also make it simpler for clubs to get started with their needed requests, such as for addresses, WireGuard tunnels, and even BGP for advanced users, lowering the barrier to a real IP backbone for amateur infrastructure.

Project overview: VK Yaesu IMRS on a managed 44Net backbone

Many clubs in our region were operating DR-2X repeaters behind CGNAT or dynamic IP services, leading to unpredictable User Datagram Protocol (UDP) behaviour, rekeying events, and link failures whenever ISPs changed addressing. IMRS traffic was often mixed with general user data on flat networks, producing jitter and contention that degraded digital audio. There was also no common routing design— some sites used static routes, others used ad‑hoc VPNs— making fault isolation difficult and preventing deterministic convergence during outages. Finally, sysops lacked a transparent, inspectable model that explained why failures occurred or how to reproduce a stable topology.

To address these pain points, in late 2025, Australian operators and clubs engaged KernWi‑Fi to design and operate a carrier‑grade backbone for Yaesu’s IMRS. The goals were reliability, security, and a model that club sysops could inspect, learn from, and replicate. This project consolidates those pain points into a single, audited, repeatable architecture that clubs can study, verify, and replicate. We published the initial technical write‑up on 26 Dec 2025, and national coverage followed.

The architecture (at a glance)

Design mantra: Treat community radio infrastructure with enterprise discipline, and reliability follows.

  • Core: A managed data‑centre hub (Kern DC) terminates site tunnels, runs policy, and originates the public route for the 44Net services in scope.
  • Edge “Kern Nodes”: At each repeater site, a hardened edge device handles Wide Area Network (WAN), OSPF adjacency, and segmentation.
  • Routing: OSPF for dynamic east‑west convergence between sites and the core; BGP at the core for external advertisement of project 44Net space.
  • Segmentation: Two primary planes: (1) IMRS Voice VLAN— time‑critical UDP only; (2) Public IP Layer 3 (L3) tunnel VLAN— monitoring & management; this segmentation keeps digital audio deterministic even if the broader Internet is noisy.
Core‑edge topology (KernWi-Fi - AUS Repeater Net)

Figure 1: Core‑edge topology (KernWi-Fi – AUS Repeater Net)..

Why the hard line on segmentation?

IMRS depends on clean, low‑jitter UDP audio. We enforce ‘voice is sacred’ by isolating it from management traffic at both Layer 2 (L2) and L3, and by allow‑listing only the IMRS UDP port 21110 end‑to‑end. Yaesu’s IMRS documentation confirms the default port; we also set device passwords via the Yaesu tool so clubs can maintain a simple, auditable security posture.

44Net hygiene: BGP, rDNS, and Internet Routing Registry (IRR) that others can trust

  • BGP origin: AS137399 (KernWi‑Fi) originates 44.30.65.0/24; public tools confirm visibility, upstreams, and RPKI status— great teaching material for club nights.
  • Reverse DNS: DNS pointer records (PTRs) point to the service gateway, aiding diagnostics and reinforcing amateur‑operated stewardship under 44Net policy.
  • Documentation: The full narrative and design rationale remain public so others can reuse and critique the approach.

Preliminary results

  • Reliability & determinism: Sites converge quickly on failures (OSPF), and voice remains clean thanks to segmentation and simple Access Control Lists (ACLs).
  • Education & adoption: Coverage by WIA and Amateur Radio Daily drove interest and volunteer learning around 44Net and routing. Multiple clubs contacted us requesting address allocations, 44Net Portal onboarding help, and example configs modelled on the published topology. These media pieces effectively served as technical primers, prompting sysops to explore 44Net routing, experiment with OSPF adjacency, and adopt stronger segmentation practices in their local repeater networks.

Our primary goal from the outset was to deliver IMRS over an IP fabric that behaves like a carrier network— predictable routing, strong isolation, and security you can audit.

The architecture, controls, and operational practices were designed to demonstrate that IMRS can run with the same determinism and fault tolerance expected in commercial networks. These preliminary results— clean audio under load, fast OSPF convergence, and growing adoption by clubs— are direct indicators that the design is meeting those goals in real deployments.

Replicate it in your club: a 44Net on‑ramp

Get on 44Net (addresses & tunnels)

Create/verify your account in the 44Net Portal, and request initial address space for your backbone and site edges. For fastest time‑to‑first‑packet, use 44Net Connect to stand up a WireGuard tunnel into an ARDC Point-of-Presence (PoP); graduate to BGP when ready.

Start with a minimal, repeatable topology

Stand up a core hub and one site first. Run OSPF between core and edge; create two VLANs— IMRS Voice and Mgmt/Monitoring— to mirror the ‘two‑plane’ practice.

Lock down IMRS the simple way

Allow only UDP/21110 between authorized IMRS endpoints; block everything else in the voice plane. Set IMRS passwords in the Yaesu tool and track changes.

Make it observable (and teachable)

Publish a read‑only Network Management System (NMS) view; log OSPF and tunnel events; create a PTR (rDNS) convention (e.g., gw.yourclub.44.in-addr.arpa). Announce your presence on the 44Net Groups.io list.

Document your BGP/IRR (when you’re ready)

If you originate 44Net space via BGP, publish route objects and verify RPKI where others can see them (bgp.tools / bgp.he.net). Use this as a training aid.

Please note that although ARDC does not issue RPKI ROAs for 44Net allocations, RPKI visibility for this project comes from our upstream providers. AS137399 announces 44.30.65.0/24 to transit networks that do participate in RPKI validation, so tools like bgp.tools and bgp.he.net display the prefix as “RPKI Valid” or “Partially Valid” based on those upstream ROAs— not on any ROA originating from ARDC. This approach lets operators verify path integrity, origin-AS consistency, and upstream validation behaviour in public routing tools, providing a practical training aid for club sysops learning how authenticated routing works.

Operational guardrails we recommend

  • Change windows & checklists for site work; preserve roll‑back plans.
  • Back up edge configs and the IMRS settings blob after each change.
  • Keep a spare pre‑flashed edge device to reduce Mean Time to Repair/Recover/Respond/Resolve (MTTR).
  • Drill failures: simulate upstream loss; measure OSPF reconvergence and user experience; log lessons learned.

What we’d like to do next

Blueprint packages: publish sanitized ACL/OSPF/VLAN templates the community can adapt; hands‑on workshops using 44Net Connect for a one‑hour build lab.

Call to action

If your club wants to explore a 44Net anchored IMRS backbone, start with the ARDC 44Net overview, the 44Net Portal for address requests, and the 44Net Connect dashboard for tunnels. We’re happy to share sanitized configurations, deployment templates, and compare notes with teams interested in replicating or extending this design. For technical enquiries, onboarding assistance, or collaboration, contact Phil Kern (VK5PK) at phil.kern@staff.kernwifi.com.au or via your preferred amateur radio call sign lookup service.

Recognition & media

Resources & references

About the author

Phil Kern (VK5PK) is the Director of KernWi‑Fi, a local ISP (AS137399) in South Australia, and a long‑time amateur operator who enjoys turning ‘carrier‑grade’ concepts into repeatable playbooks for clubs and volunteers. His recent work focuses on resilient amateur networks, including 44Net‑based backbones for voice and data services.