← All projects

BGP Mesh with Private ASNs

Active May 24, 2026 · 6 min read

Full eBGP triangle across a two-node Proxmox cluster and pfSense edge firewall. Private ASNs, redundant path learning, zero static routes.

BGP mesh topology — full eBGP triangle
3
eBGP peers
2
paths per prefix
0
static routes

Peer status

Cluster node 1
Hypervisor · VM + LXC host
Established
Cluster node 2
Hypervisor · always-on services
Established
Edge firewall
pfSense Plus · network boundary
Established

Route table

Network        Next Hop       Path
*> lab-subnet   edge-firewall   private-AS-fw i
*  lab-subnet   cluster-node-2 private-AS-n2 fw i

Two valid paths per prefix — automatic reroute if any peer drops.

The problem with static routes

Static routes work until the network changes. Every new subnet means updating routes on every node manually. Miss one and traffic silently breaks. BGP makes that automatic — advertise a new prefix from one node and every peer learns it within seconds.

RFC 6996 reserves a private ASN range (64512–65534) for exactly this use. No registration, no ISP involvement, no public routing. Same operational behavior as a real ASN inside the lab.

eBGP between all three

Running eBGP (different ASNs per node) rather than iBGP keeps path selection simple and gives each node an independent topology view. Adding a fourth peer is one config block.

FRRouting on everything

pfSense runs the same FRR daemon via the package manager — identical vtysh interface, identical config pattern, identical show bgp summary output. One mental model across the whole setup.

Cluster upgraded same session

Both nodes went from 9.1.9 → 9.2.2 and kernel 6.17 → 7.0.2 before BGP was configured. Rolling upgrade with HA maintained throughout — node 2 first, verify quorum, then node 1.

Advantages

No public ASN needed — RFC 6996 private range
Automatic failover — two paths per prefix
New subnets propagate — no static routes
FRRouting — same daemon used at hyperscale
Third node = one config block to add

Trade-offs

Overhead for a flat /24 network
FRR daemon on every node to maintain
Policy misconfig silently drops all prefixes
Both nodes share the same LAN segment
pfSense FRR lags upstream slightly

Roadmap

Dedicated subnets per workload tier — k8s pods, sandbox VMs, security tooling
Managed switch with 802.1Q trunking so VLANs and BGP prefixes align cleanly
Third node peering when cluster expands

Stack

FRRoutingeBGPProxmox VE 9.2pfSense PlusRFC 6996Linux kernel 7.0
← Previous
Network Automation Toolkit
Next →
AWS Detection Engineering