Private ASN ranges: deploy global anycast routing

Four virtual machines across Düsseldorf, Marseille, and Toronto form the backbone of this specific anycast network. Deploying a functional global routing infrastructure demands more than simply announcing IP blocks; it requires rigorous adherence to RFC 7511 and precise BGP path control. Readers will examine the transition from shell-escaped files to a json-inspired format for managing IPAM v2 workflows efficiently. The discussion details the mechanics of WireGuard tunnels connecting OpenBSD routers to ensure durability when upstream sessions fail. We will also explore how specific netblocks like 2602:feda:b8e::/48 are subdivided for distinct functions such as LAN and RTBH labeling.

The narrative dispels the myth that global redundancy is trivial by highlighting the scarcity of providers willing to support small 1cpu instances with custom BGP sessions. By centralizing validation and using private ASNs, operators can maintain reliable IPv6 infrastructure without excessive overhead. This approach ensures that traffic flows correctly even when individual links encounter disruptions.

The Strategic Role of Private ASNs in Modern Anycast Architecture

Private ASN Ranges and IANA Reserved Blocks

IANA designates the 64512-65534 range within the 2-byte space specifically for private autonomous system use. This reserved block contains exactly 1,023 numbers intended for internal routing domains that do not require global visibility on the public internet. Operators deploying non-global solutions often apply these identifiers to manage internal routing policies without consuming scarce public resources. The modern expansion into 4-byte addressing provides a significantly larger private pool ranging from 4200000000 to 4294967294. This massive allocation of 94,967,295 numbers supports extensive personal and IoT ASN deployments where global uniqueness is unnecessary. Using these private ranges allows organizations to implement complex topologies while bypassing the administrative burden of proving unique routing policies to Regional Internet Registries.

However, reliance on private identifiers prevents direct peering with external networks unless translation occurs at the network boundary. Traffic originating from a private ASN cannot traverse the global default-free zone without being mapped to a public identifier by an upstream provider. This architectural constraint forces a choice between operational sovereignty and universal reachability.

Network architects must verify that upstream providers support private ASN stripping before deployment. Failure to configure this translation correctly results in dropped updates at the edge.

Deploying Global Anycast VMs with BGP Sessions.

Anycast routing directs client requests to the topologically nearest node announcing a specific IP prefix. Operators seeking global redundancy often ask if they should use a private ASN for internal routing segments rather than acquiring scarce public numbers. A practical deployment model uses minimal VMs in distinct geographic locations like Düsseldorf, Marseille, and Toronto to announce identical blocks. Providers must support OpenBSD installation, BGP session establishment, and basic features like PTR records on small instances featuring 1cpu and 1G of ram. This approach allows operators to bypass traditional multi-homing requirements by using transit providers that already possess public autonomous system numbers. Using a private identifier with an upstream carrier simplifies initial setup but restricts direct peering capabilities and advanced traffic engineering options. True fault tolerance demands at least two diverse sites per region with separate power sources and upstream connections. TLD operators frequently apply assigned subnets to ensure global durability for domain root servers through this exact mechanism. Operators must carefully configure local preference values to prevent internal leaks from polluting the global routing table. Successful implementation requires strict adherence to RFC 7511 to avoid routing loops and ensure stable packet delivery across the distributed edge.

RFC 7511 Compliance and Routing Table Bloat Risks

Proper routing requires significant work to abide by RFC 7511 standards rather than simple announcements. Regional Internet Registries enforce strict policies to prevent routing table bloat, mandating that new ASNs are assigned only when a distinct routing policy is necessary rather than for simple connectivity. This constraint prevents the global default-free zone from becoming unmanageable due to excessive specific prefixes. Operators ignoring these guidelines risk having their announcements filtered by upstream peers who maintain strict ingress filters.

Resource Public Key Infrastructure acts as a security framework where network owners validate critical route updates between public networks. Unfortunately, routing equipment alone cannot distinguish between legitimate and malicious routing announcements without this validation layer. Network operators who implement RPKI validation can choose to reject announcements from networks not authorized to advertise those resources. Arelion was the first Tier-1 transit network that launched RPKI, successfully filtering invalid announcements from all external BGP sessions. Choosing an ISP with validation reduces the risk of personal data breaches and redirection to malicious sites.

The tension exists between rapid deployment using private identifiers and long-term stability on the public internet. Failure to distinguish routing logic results in rejected sessions and lost redundancy.

Inside the Data Plane: BGP Path Control and WireGuard Tunnel Mechanics

BGP Path Prepending Mechanics on WireGuard Tunnels

Appending the local ASN fifteen times to the AS path forces upstream routers to reject the WireGuard® link as a primary transit route. This mechanical repetition exploits the BGP best-path selection algorithm, which prioritizes shorter AS paths over longer ones by default. In this topology, R1 and R2 use a wg link between them to maintain flow if an upstream session fails or if a separate tunnel to R3 dies. The excessive length ensures this backup path remains dormant during normal operations, preventing suboptimal routing loops through the tunnel mesh.

However, reliance on manual prepend counts introduces static rigidity into flexible environments. Unlike automated traffic engineering solutions, a fixed value of fifteen offers no adaptability if upstream providers alter their own path lengths or apply path flattening techniques. The implication for the operator is a hard constraint: the backup link becomes usable only after a total upstream failure, not during partial degradation.

InterLIR emphasizes that current internet infrastructure remains predominantly based on IPv4, making such manual optimization of existing resources critical for availability. Proper configuration requires significant work to abide by RFC 7511 rather than simple announcements. Operators must verify that their bgpd rules correctly handle these modified paths without triggering loop detection mechanisms that discard valid but elongated routes.

Stateless Firewall Configuration for Asymmetric BGP Routing

Asymmetric traffic flows across WireGuard® tunnels necessitate switching from stateful to stateless firewall rules on border routers. Standard connection tracking drops return packets that arrive via a different path than the outbound request, a common failure mode in redundant BGP topologies. The entire infrastructure runs OpenBSD, using the base bgpd and rpki-client for ROA validation while relying on pf(4) for packet filtering.

Operators must restrict stateless policies to specific transit networks rather than applying them globally. This configuration allows return traffic from upstream providers to enter through any available wg link without triggering session mismatch errors. While this approach solves immediate connectivity issues, it removes the ability to track connection states locally on the edge router. The cost is reduced visibility into active sessions, requiring operators to rely on upstream filters for basic security hygiene.

Independent nodes operating without internal backbone connectivity simplify architecture but demand careful rule definition to prevent exposure. This design choice supports independent nodes that function without traditional IGP protocols.

Resource Validation Checklist for OpenBGPD on Minimal VMs

Confirming memory headroom before loading the full IPv6 unicast table prevents immediate process termination on constrained hosts. Most minimal VMs operate with only 1G of ram and 1 cpu, creating a tight budget for routing daemons. The total RIB usage consumes 148M of memory, leaving sufficient space for the operating system and other base services. Operators must prioritize BGP over IGP protocols because wg(4) interfaces lack multicast support required by ospf6d. Attempting to run stateful inspection on these tunnels often causes packet loss due to asymmetric return paths.

The strict reliance on unicast transport simplifies the data plane but eliminates flexible neighbor discovery features found in traditional LAN designs. While this architecture supports sovereign anycast, the lack of automatic peer detection increases manual configuration overhead during outages. InterLIR recommends verifying that your specific IPv6 anycast implementation accounts for these static routing constraints. The trade-off is reduced automation in exchange for stability on minimal hardware. Network engineers should validate that their chosen provider allows custom ASN usage before committing to this topology.

Deploying Resilient IPv6 Infrastructure with OpenBSD and Centralized Validation

Centralized RPKI Validation Architecture with rpki-client

Executing rpki-client on a dedicated web host preserves inodes on edge routers, as the utility consumes substantial file handles during cache generation. This centralized approach distributes validated Route Origin Authorizations to border routers using unencrypted RTR sessions because bgpd lacks native encrypted transport. Network architects tolerate this constraint to avoid installing auxiliary daemons like gortr or stayrtr on memory-constrained nodes.

1. Schedule the validation daemon to execute every 42 minutes on the dedicated web host.
2. Configure remote bgpd instances to fetch the generated cache via FTP every 57 minutes.
3. Allow approximately eight minutes for the full fetch and parse cycle to.

Unencrypted fetch intervals establish a localized trust boundary requiring strict internal network security. Current infrastructure often prioritizes availability over cryptographic transport for cache distribution while the industry moves toward ASPA adoption. A narrow window exists where stale or tampered cache data could propagate before the next 42-minute refresh cycle corrects the state. Minimal VMs with 1G of ram perform strong Route Origin Validation without exhausting local storage resources under this design.

Configuring WireGuard Tunnels and ASN Prepending on OpenBSD

Configuration of wg(4) interfaces between the Toronto VMs and the home router establishes the physical layer for backup paths. This technology entered OpenBSD kernels recently, making it a logical choice over ipsec. R1 and R2 announce the author's /48 to their providers using a public ASN.

1. Define the WireGuard interface on each host using static keys and assigned endpoints.
2. Enable the link to ensure traffic flows if an upstream session fails or if a primary tunnel dies.
3. Apply stateless firewall rules to pf(4) to accept asymmetric return packets that stateful inspection would drop.
4. Initiate the BGP session over the tunnel using bgpd, as multicast-dependent protocols like OSPF cannot function here.

Operators must prepend the local ASN 15 times on this specific link to enforce path preference. This excessive length ensures the backup route remains dormant during normal operations, preventing suboptimal routing loops through the tunnel mesh; the author states 15 minutes ought to be enough. The topology requires careful planning because anycast deployment relies on consistent prefix advertisement across all speakers. Static rigidity enters flexible environments when manual prepend counts dictate traffic flow. Fixed values offer no adaptation if primary upstream latency spikes unexpectedly, unlike automated traffic engineering solutions.

Operational Intervals and Timing for RPKI Data Fetching

Synchronization between the validator cycle and router fetch interval prevents validation gaps during route updates. The process involves running rpki-client on a central host, where the full execution currently consumes approximately eight minutes. Edge routers then retrieve this validated cache via ftp every 57 minutes, a window wide enough to accommodate the generation time plus a safety margin.

1. Execute the validation script on the central server at 42-minute intervals.
2. Configure bgpd on edge nodes to pull the updated cache file hourly.
3. Verify that the fetch completes before the next validation cycle begins.

Generation time must never exceed the fetch period, or routers will serve stale data. Increased table sizes now demand a longer window compared to the previous five-minute completion time. A tighter schedule risks serving incomplete ROA lists, causing valid routes to drop unexpectedly. This timing alignment ensures that border routers always possess a complete view of authorized origins before discarding traffic.

Operational Efficiency Through Text-Based IPAM and Cost Optimization

JSON-Inspired Text File IPAM Structure

The author transitioned from editing files with escaped colons in the shell to a single text file in a json-inspired format for IPAM v2, simplifying the management of updates. This structural shift allows immediate visual verification of which announcer, such as BGP-YYZ or NS4, handles specific prefixes without parsing multiple configuration files. While this approach simplifies editing, the format relies entirely on the operator to maintain synchronization with live BGP announcements. Unlike automated systems that query routers for truth, this text file may drift from reality if manual updates lag behind configuration changes; the author notes the file "may not be entirely up to date." Teams adopting this method must rely on manual discipline to prevent the inventory from becoming stale. Such diligence ensures the file remains a reliable source of truth rather than a misleading artifact. This static model is best suited for environments where the speed of manual review is prioritized over automated consistency checks.

Real-World BGP VM Hosting Costs

Hosting the BGP infrastructure incurs recurring monthly expenses, specifically for virtual machines meeting requirements such as 1cpu, 1G of ram, and 20G of disk. Administrative costs paid to Grifon include 15€/y for membership fees and 90€/y for administrative fees to get the ASN/IPv6 resources. The distributed architecture necessitates diverse sites with separate power and upstreams to achieve recommended redundancy standards. The current anycast network consists of VMs located in Düsseldorf, Marseille, and Toronto.

The reliance on text-based IPAM files reduces software licensing fees but increases the risk of human error during manual updates. Operators managing json-inspired inventory files must ensure strict synchronization between the static text definitions and live bgpd announcements. A discrepancy here causes route leaks that automated systems might otherwise catch. While cloud providers can lease ASN ranges to reduce complexity, independent ownership avoids vendor lock-in at the cost of higher administrative burden. Operators should validate all manual IPAM changes against live RIB entries before deployment. The total cash outlay remains low, yet the operational discipline required to prevent routing table pollution is substantial.

Router TCAM Scarcity vs Address Abundance

Router TCAM capacity remains physically constrained despite the theoretical abundance of 128-bit addresses. The author states that while resources like 32-bit ASNs and 128-bit IP addresses are plentiful, router TCAM is not. While private ASNs and vast IP blocks are plentiful, the hardware memory required to store individual routing entries in the global table is not infinite. The author's experiment represents 3 netblocks out of approximately 130k in the DFZ, a negligible amount that nevertheless consumes precious silicon resources. This disparity explains the recommendation that others should likely avoid similar public experiments. Effective anycast implementations require diverse sites with separate power and upstreams to ensure true redundancy, effectively doubling the infrastructure footprint per region.

The proliferation of micro-allocations increases the routing table size, forcing hardware upgrades across the backbone. Operators must weigh the educational value of personal BGP projects against the collective cost of increased memory usage on core routers. Advising optimization of existing resources rather than fragmenting the global registry with experimental prefixes helps mitigate these constraints. The scarcity of high-performance memory creates a natural bottleneck that limits the feasibility of widespread, small-scale anycast deployments.

References

• At the West Africa Peering Forum, in Cotonou, Benin
• How to Get Your Own ASN and IPv6 Space