BGP

Thu, 14 May 2026 00:00:00 +0000

BGP (Border Gateway Protocol) is the routing protocol that holds the internet together. Every major network operator uses it to advertise which IP prefixes they own and to exchange that information with peers. In a homelab context the scale is different but the mechanics are the same.

BGP is a path-vector protocol: each router advertises routes along with the path (sequence of ASNs) taken to reach them. Routers choose the best path based on a set of attributes and policy rules, then advertise that path to their peers.

eBGP vs iBGP

eBGP (external BGP) — sessions between routers in different autonomous systems. Each party has a different ASN. This is what you configure between VyOS and OPNsense, and between VyOS and MetalLB.

iBGP (internal BGP) — sessions between routers in the same autonomous system. Used inside large networks to distribute external routes internally. Not relevant for a basic homelab setup.

ASNs for private use

Autonomous System Numbers in the range 64512–65534 are reserved for private use (RFC 6996) — the same concept as RFC 1918 private IP addresses. Assign one to each participant in your BGP topology:

Participant	Example ASN
OPNsense	64512
VyOS	64513
MetalLB (Talos cluster)	64514

Why BGP for Kubernetes LoadBalancer IPs

Kubernetes LoadBalancer services need something external to the cluster to route traffic to them. In a cloud environment the cloud provider handles this automatically. On bare metal you need to do it yourself.

Two common approaches with MetalLB:

L2 mode — MetalLB uses ARP (IPv4) or NDP (IPv6) to announce service IPs directly on the LAN. Simple to set up. Limitations: only one node handles traffic for each IP at a time (no real load balancing at the network layer), and the service IP must be in the same subnet as the nodes.

BGP mode — MetalLB establishes a BGP session with an upstream router (VyOS, for example) and announces service IPs as /32 prefixes. The router learns the route and can ECMP across all nodes that are advertising it. More correct: actual load balancing, no subnet constraint, clean separation between cluster and network layer.

The tradeoff is that BGP mode requires a BGP-capable router in the path, which is why VyOS exists in this topology.

Testing with a real BGP network

DN42 is a community-run experimental network that simulates the real internet using actual BGP, DNS, and whois infrastructure. Participants connect via WireGuard or other tunnels and peer with each other using real BGP sessions and real (private-range) ASNs. A good way to practice BGP outside the homelab without needing a production ASN.

VyOS — the BGP peer router
VyOS + BGP experiment — the actual setup in this homelab

VyOS

Thu, 14 May 2026 00:00:00 +0000

VyOS is an open-source network operating system built on Debian Linux. It runs on bare metal or as a VM, and is configured via a CLI with a commit/rollback model similar to Juniper JunOS. Configuration changes are staged and only take effect when you explicitly commit — there is no live-editing a running config and hoping nothing breaks.

It ships FRRouting (FRR) as the routing engine, giving it native support for BGP, OSPF, IS-IS, and other protocols. This is its main distinction from OPNsense for homelab use: OPNsense is a firewall appliance that can do some routing; VyOS is a routing OS that can also do firewall.

Configuration model

vyos@router# set interfaces ethernet eth0 address '192.168.1.254/24'
vyos@router# set protocols bgp system-as '65001'
vyos@router# commit
vyos@router# save

configure enters configuration mode. set stages a change. commit applies it. save persists it to disk. rollback reverts to the last committed state if something goes wrong. The separation between staging and applying is genuinely useful when changing routing configuration remotely.

Key features

Feature	Notes
BGP	Via FRRouting; full eBGP/iBGP support
OSPF / IS-IS	Also via FRR
Static routing	Standard
VLAN	802.1Q trunking
NAT	Source and destination NAT
Firewall	Zone-based, stateful
WireGuard	Built-in
OpenVPN	Built-in
DHCP server	Built-in
VXLAN	Supported

VyOS vs OPNsense

VyOS is the right choice when you want a dedicated BGP peer or a router VM with a clean CLI config model. OPNsense is the right choice when you want a full gateway appliance with a web UI.

Automation

VyOS is designed to be automated — the commit/rollback model maps cleanly onto infrastructure-as-code workflows.

REST API — built-in HTTP API for retrieving and applying configuration programmatically. Useful for scripting config changes without SSH.

Ansible — official vyos.vyos collection on Ansible Galaxy. Modules for interfaces, BGP, firewall rules, and more. Changes go through the normal commit/rollback cycle.

Terraform — community provider available. Less mature than the Ansible collection but usable for provisioning router config alongside other infrastructure.

VyOS documentation
VyOS REST API
VyOS Ansible collection
VyOS rolling release downloads
BGP — protocol background
OPNsense — the complementary edge gateway
VyOS + BGP in the homelab — the actual setup

Bgp on Backend Engineering Strategy Tools

BGP