BGP en el homelab: peering entre sitios con WireGuard en 2026

Q: ¿Por qué BGP en el homelab: peering entre sitios con WireGuard en 2026 es relevante para sysadmins Linux?

Forma parte del flujo diario de administración. Los conceptos explicados se aplican directamente a servidores en producción y resuelven problemas reales que enfrentan sysadmins hispanohablantes.

Q: ¿Qué necesito para empezar con BGP en el homelab: peering?

Distribución Linux actualizada (Debian, Ubuntu, RHEL, Fedora o Arch), acceso root, y conexión a internet. Para producción: entorno de staging separado antes de aplicar cambios.

Q: ¿Cuáles son los errores más comunes con BGP en el homelab: peering?

Los tres más frecuentes: (1) saltar la lectura de logs, (2) aplicar cambios directos en producción sin probar, (3) olvidar permisos y ownership. La documentación y un plan de rollback siempre.

Q: ¿Cuándo usar BGP en el homelab: peering y cuándo una alternativa?

Esta solución es ideal para el caso descrito. Alternativas como Docker, Ansible o configuración manual pueden ser mejores según contexto: portabilidad, escala y reproducibilidad son los factores clave.

Q: ¿Cómo migro desde una configuración previa a BGP en el homelab: peering?

Documentar el estado actual, probar la nueva configuración en staging, validar funcionalmente, y aplicar en producción con rollback plan listo. Los posts de SoyLinux incluyen troubleshooting para los problemas más comunes.

septiembre 16, 2026 Alfonso Moreno | Sysadmin Senior 61 Visitas 12 min de lectura

BGP en un homelab suena a overkill hasta que tienes 3-4 sites remotos y quieres que se enruten entre sí de forma dinámica. Esta guía documenta el setup que recomiendo: BIRD2 sobre WireGuard para sesiones eBGP entre nodos, ASN privado (AS 64512-65534), prefix filtering estricto, y el truco de no necesitar un IP transit real. Es la guía que escribí para mi propio homelab y que documenta el viaje de “BGP suena a magia negra” a “BGP es bastante lógico una vez que entiendes los 4 mensajes”.

Si tienes un homelab distribuido y quieres que el routing sea dinámico, esto es para ti.

TL;DR — Lo que vas a tener al final

Tiempo de setup: 3-4 horas para el primer peer BGP, 1 hora por peer adicional.
Requisitos: 2+ nodos Linux, BIRD2, WireGuard entre ellos, ASN privado asignado.
Resultado: Sesión BGP entre nodos, prefijos anunciados, failover automático, route reflectors opcionales.
Troubleshooting típico: sesión no se levanta, prefijos no aceptados. Solución: `birdc show protocols` y logs.

Por qué BGP en un homelab de dos sitios

Cuando tienes dos sitios físicos — casa y oficina, o dos DCs pequeños en ciudades distintas — lo normal es levantar una VPN site-to-site con WireGuard y enrutar las subredes de cada lado con rutas estáticas. Funciona hasta que un túnel se cae o hasta que quieres failover automático y balanceo entre dos uplinks. Ahí entran los protocolos dinámicos, y BGP es el más liviano para eBGP entre sitios con prefijos de tu propiedad.

Este artículo arma un peering eBGP entre dos sitios con FRRouting 10.7 sobre WireGuard como underlay, con neighbor IFNAME interface v6only (BGP unnumbered) para evitar configurar direcciones IPv4 punto a punto en cada túnel. El resultado: cuando un túnel cae, BGP retira los prefijos anunciados por ese peer en menos de un segundo si tienes BFD encendido, y el tráfico fluye por el otro túnel sin tocar rutas estáticas.

Qué necesitas antes de empezar

Dos servidores Linux headless. Para este artículo uso Debian 13 (trixie, kernel 6.12 LTS) y Ubuntu 24.04 LTS (noble, kernel 6.8), ambos con WireGuard ya en el kernel mainline desde la versión 5.6 (marzo 2020), por lo que solo necesitas el paquete wireguard-tools con los binarios wg y wg-quick.
Cada servidor con un ASN privado propio del rango RFC 6996: 64512–65534 (1023 ASNs de 16 bits) o 4200000000–4294967294 (94 millones de ASNs de 32 bits). Para este ejemplo uso 64512 (sitio A) y 64513 (sitio B).
Cada sitio anuncia un prefijo IPv4 de tu propiedad (RFC 1918 si quieres enrutar solo dentro del homelab, o un prefijo público delegado por tu proveedor si quieres llegar a Internet por ambos sitios). Para el ejemplo asumo 10.10.0.0/24 en sitio A y 10.20.0.0/24 en sitio B.
Acceso root en ambos nodos y un puerto UDP 51820 abierto en el firewall de cada sitio (o el que prefieras; el default de WireGuard es 51820).

Por qué FRR y no BIRD (o por qué sí BIRD)

FRRouting y BIRD son los dos motores BGP de uso común en Linux. Para un homelab de dos sitios la elección es casi estética.

Característica	FRR 10.7	BIRD 3.3.x
Estilo de configuración	Cisco-like (`router bgp 64512`, `neighbor X remote-as Y`)	Secciones `protocol bgp` con bloques `template` + instancia
RPKI nativo	Sí, vía `rpki` subdaemon	Sí, desde BIRD 2.0 (diciembre 2017)
BGP unnumbered (`neighbor IFNAME`)	Sí, estable desde FRR 4.0	Sí, BGP dynamic unnumbered desde BIRD 3.2.0 (enero 2026)
EVPN / VXLAN / segment routing	Sí, soporte amplio	No; BIRD se enfoca en unicast IP
Multi-thread	Sí, cada daemon en proceso separado	Sí, desde BIRD 3.0.0 (17 dic 2024)
Curva de aprendizaje viniendo de Cisco/Juniper	Baja — la CLI es prácticamente idéntica	Media — la sintaxis es propia
Consumo en homelab pequeño	~50 MB RAM con un par de prefijos	~10 MB RAM

Si vienes de redes de proveedor y quieres sentirte en casa con show ip bgp summary, usa FRR. Si quieres la pila más liviana y limpia, BIRD. Para esta guía voy con FRR porque su CLI se mapea 1:1 a lo que muestra cualquier tutorial de BGP en Internet.

Levantar el underlay WireGuard

Antes de BGP necesitas los túneles entre los dos sitios. WireGuard en Linux mainline no requiere módulos extra desde el kernel 5.6, así que en Debian 13 y Ubuntu 24.04 solo instalas el userspace.

# Debian 13 / Ubuntu 24.04 — WireGuard ya está en el kernel
sudo apt update
sudo apt install -y wireguard-tools frr

Genera un par de claves por sitio. Guárdalas en /etc/wireguard/ con permisos 600. La clave privada NO se comparte nunca.

# Sitio A (10.10.0.1)
wg genkey | tee /etc/wireguard/wg-bgp_private.key | wg pubkey > /etc/wireguard/wg-bgp_public.key
chmod 600 /etc/wireguard/wg-bgp_*.key
# Sitio B (10.20.0.1) — mismo procedimiento, copiar public.key al sitio A y viceversa

El default MTU de WireGuard es 1420, que sigue siendo correcto en 2026: la suma del overhead cuando el underlay es IPv6 es 80 bytes (40 bytes de header IPv6 + 8 de UDP + 32 de WireGuard entre handshake, cookie y counter) y 60 cuando el underlay es IPv4. Si tu ISP usa PPPoE, baja a 1412. Si vas sobre CGNAT móvil, 1400 o menos.

En Debian 13 y Ubuntu 24.04, systemd-networkd ya trae soporte nativo para WireGuard desde systemd 237 (estable desde mediados de 2018; el release 240 salió en diciembre 2018) y es la opción más limpia para un servidor headless: archivos declarativos versionados en /etc/systemd/network/, sin daemon de estado, orden de arranque determinista. Si tu distro usa NetworkManager y no quieres reconfigurar todo, NM 1.16+ también soporta WireGuard nativamente; funciona igual, solo cambia dónde declarás la interfaz.

Configurar la interfaz wg-bgp en sitio A

Crea /etc/systemd/network/wg-bgp.netdev. Esta unidad define la interfaz; el archivo .network asociado le pone dirección y la activa.

# /etc/systemd/network/wg-bgp.netdev
[NetDev]
Name=wg-bgp
Kind=wireguard
Description=WireGuard underlay para peering BGP sitio A <-> B
[WireGuard]
PrivateKey=<CLAVE_PRIVADA_SITIO_A>
ListenPort=51820
[WireGuardPeer]
PublicKey=<CLAVE_PUBLICA_SITIO_B>
PresharedKey=<PSK_OPCIONAL_PERO_RECOMENDADO>
AllowedIPs=fe80::/64,10.20.0.1/32
Endpoint=wg.sitio-b.example.com:51820
PersistentKeepalive=25

El PersistentKeepalive=25 es importante: WireGuard es silencioso por diseño (no manda nada si no hay tráfico), pero BGP espera hellos cada pocos segundos para detectar fallas. Si el túnel está idle, los NAT mappings expiran y BGP tarda en converger cuando hay tráfico nuevo. 25 segundos es el default recomendado y lo que casi toda configuración homelab usa.

# /etc/systemd/network/wg-bgp.network
[Match]
Name=wg-bgp
[Network]
Address=fd00:bbbb::1/64
IPv6AcceptRA=no

La dirección link-local fd00:bbbb::1/64 (ULA) no se enruta a Internet pero sí entre tus dos túneles WireGuard. BGP unnumbered va a usar el link-local del peer, así que no necesitas una subred enrutable global para que funcione. Activa la interfaz y verifica.

sudo systemctl enable --now systemd-networkd
sudo networkctl reload
sudo networkctl status wg-bgp
sudo wg show wg-bgp

Deberías ver latest handshake menor a un minuto después de levantar el peer en el otro sitio. Si no hay handshake, el firewall está bloqueando UDP 51820 o el endpoint del otro lado no resuelve.

Configurar la interfaz wg-bgp en sitio B

Espejo del sitio A: clave privada de B, public key de A en el bloque WireGuardPeer, dirección fd00:bbbb::2/64 en el archivo .network, y un endpoint que apunte al sitio A.

# /etc/systemd/network/wg-bgp.netdev en sitio B
[NetDev]
Name=wg-bgp
Kind=wireguard
[WireGuard]
PrivateKey=<CLAVE_PRIVADA_SITIO_B>
ListenPort=51820
[WireGuardPeer]
PublicKey=<CLAVE_PUBLICA_SITIO_A>
PresharedKey=<MISMO_PSK_QUE_SITIO_A>
AllowedIPs=fe80::/64,10.10.0.1/32
Endpoint=wg.sitio-a.example.com:51820
PersistentKeepalive=25

Cuando sudo wg show en cualquiera de los dos sitios muestre peer: ... latest handshake: 30 seconds ago, el underlay está listo para BGP.

Habilitar bgpd en FRR

El paquete frr en Debian y Ubuntu instala los daemons deshabilitados por defecto. Hay que editar /etc/frr/daemons y habilitar bgpd (y opcionalmente bfdd si quieres detección de fallas sub-segundo).

sudo sed -i 's/^bgpd=no/bgpd=yes/' /etc/frr/daemons
sudo sed -i 's/^bfdd=no/bfdd=yes/' /etc/frr/daemons
sudo systemctl enable --now frr
sudo systemctl status frr

FRR arranca con configuración vacía (vtysh te lleva al modo enable sin nada configurado). Toda la config que viene a continuación va en /etc/frr/frr.conf, que es un wrapper que incluye /etc/frr/bgpd.conf.

Configurar BGP unnumbered en sitio A

El truco de BGP unnumbered (neighbor IFNAME interface v6only remote-as <asn>) es que NO necesitas una dirección IP de peering por túnel: FRR toma la dirección link-local IPv6 de la interfaz WireGuard como next-hop BGP, según RFC 5549 (v4 NLRI con v6 next-hop). El kernel Linux sabe enrutar al peer vía el link-local aunque no haya una subred ruteada entre los dos.

! /etc/frr/bgpd.conf — sitio A
frr version 10.7
frr defaults traditional
hostname sitio-a
log syslog informational
router bgp 64512
 bgp router-id 10.10.0.1
 bgp bestpath as-path multipath-relax
 no bgp ebgp-requires-policy
 neighbor wg-bgp interface v6only remote-as 64513
 neighbor wg-bgp bfd
 neighbor wg-bgp advertisement-interval 5
 address-family ipv4 unicast
  network 10.10.0.0/24
  maximum-paths 4
  neighbor wg-bgp activate
  neighbor wg-bgp next-hop-self
 exit-address-family
bfd
 peer wg-bgp
  receive-interval 300
  transmit-interval 300
  detect-multiplier 3
 !
!
ip forwarding
ipv6 forwarding

Las líneas clave son bgp bestpath as-path multipath-relax (que permite ECMP entre prefijos aunque los AS_PATH difieran en longitud — útil cuando un uplink va por un ISP y el otro por otro) y neighbor wg-bgp interface v6only remote-as 64513 (que le dice a FRR: el peer está en la interfaz wg-bgp, no en una IP; usa el link-local IPv6 como next-hop BGP según RFC 5549).

El neighbor wg-bgp bfd activa BFD contra ese peer; el bloque bfd debajo configura los intervalos (300 ms de transmisión × 3 multiplicador = 900 ms de detección). BFD sobre WireGuard funciona sin problemas: los paquetes de control BFD son de 24 a 26 octetos sobre UDP 3784, entran sobrados en cualquier MTU de WireGuard. Lo que sí necesitas es que el túnel esté vivo (PersistentKeepalive=25); BFD no rompe WireGuard, pero si WireGuard se cae por falta de keepalive, BFD tampoco tiene sobre qué correr.

El no bgp ebgp-requires-policy desactiva el check estricto que exige un policy-map para peers eBGP en FRR 10.x. Para un homelab con un solo peer es seguro y te ahorra dos bloques route-map que no aportan nada aquí.

Configurar BGP unnumbered en sitio B

Espejo del sitio A, con ASN 64513 y el prefijo 10.20.0.0/24. La línea neighbor wg-bgp interface v6only remote-as 64512 apunta al ASN de A.

! /etc/frr/bgpd.conf — sitio B
frr version 10.7
frr defaults traditional
hostname sitio-b
log syslog informational
router bgp 64513
 bgp router-id 10.20.0.1
 bgp bestpath as-path multipath-relax
 no bgp ebgp-requires-policy
 neighbor wg-bgp interface v6only remote-as 64512
 neighbor wg-bgp bfd
 neighbor wg-bgp advertisement-interval 5
 address-family ipv4 unicast
  network 10.20.0.0/24
  maximum-paths 4
  neighbor wg-bgp activate
  neighbor wg-bgp next-hop-self
 exit-address-family
bfd
 peer wg-bgp
  receive-interval 300
  transmit-interval 300
  detect-multiplier 3
 !
!
ip forwarding
ipv6 forwarding

Recarga FRR en ambos sitios.

sudo systemctl reload frr
sudo vtysh -c 'show ip bgp summary'
sudo vtysh -c 'show ip bgp ipv4 unicast'
sudo vtysh -c 'show bfd peer'

En la salida de show ip bgp summary deberías ver el peer con State/PfxRcd = 1 (un prefijo recibido) y Up/Down indicando el tiempo desde que subió la sesión. show bfd peer tiene que mostrar Up con el remote-discriminator de tu peer.

Verificar convergencia y failover

Una vez que ambos sitios vean el prefijo del otro (10.20.0.0/24 en A, 10.10.0.0/24 en B), prueba el failover. La forma más rápida es tirar el túnel WireGuard en uno de los sitios.

# En sitio A: simular caída del túnel
sudo ip link set wg-bgp down
# En sitio A: observar qué pasa con la ruta BGP
watch -n1 'vtysh -c "show ip bgp ipv4 unicast"'
# Restaurar
sudo ip link set wg-bgp up

Con BFD activo, BGP retira el prefijo del peer en menos de un segundo: el prefijo desaparece de show ip bgp directamente (no queda con marca de RIB failure como r — eso es otra cosa, ocurre cuando hay una ruta mejor ya instalada). Sin BFD, depende del holdtime BGP, que por default es 180 segundos; eso es lo que motiva tener BFD en homelabs con túneles que pueden flappear.

Cuándo NO hacer esto

Si tienes un solo túnel: rutas estáticas con wireguard-tools y un script de watchdog son más simples. BGP vale la pena a partir de dos túneles o dos uplinks, donde quieres failover automático sin un script bash que reescriba rutas cada vez que un peer cae.
Si tus prefijos no son tuyos: BGP sirve para anunciar prefijos que controlás. Si tu ISP te da una /32 dinámica o un prefijo delegado por CGNAT, BGP no aporta; usa rutas estáticas + un cliente DDNS.
Si quieres RPKI estricto: las dos direcciones que estás anunciando son RFC 1918, no necesitan RPKI. Cuando anuncies prefijos públicos, conviene activar rpki y validar contra un cache (Cloudflare rpki.cloudflare.com/rpki.json o RIPE NCC).
Si tu kernel es < 5.6: necesitas wireguard-dkms o el repo backport wireguard-linux-compat de zx2c4. En Debian 13 y Ubuntu 24.04 no aplica — el módulo ya viene en el kernel mainline.

Resumen

Para peering eBGP entre dos sitios con WireGuard como underlay necesitas cuatro cosas:

Dos interfaces WireGuard con PersistentKeepalive=25 y claves distintas por sitio.
ASNs privados del rango RFC 6996 (64512–65534 o 4200000000–4294967294), uno por sitio.
FRR con bgpd y opcionalmente bfdd habilitados, configuración con neighbor IFNAME interface v6only remote-as <asn> (BGP unnumbered según RFC 5549) y bgp bestpath as-path multipath-relax para ECMP entre uplinks asimétricos.
BFD con transmit-interval 300, receive-interval 300, detect-multiplier 3 para detectar caída del túnel en < 1 segundo.

El MTU de WireGuard sigue siendo 1420 en 2026 (asume overhead IPv6), y la pila funciona en Debian 13 y Ubuntu 24.04 sin parches porque WireGuard está en el kernel mainline desde 5.6 (marzo 2020). Cuando termines, vas a tener failover automático entre sitios y vas a poder agregar un tercer sitio como nuevo peer BGP sin tocar rutas estáticas.

Preguntas frecuentes

¿Por qué BGP en el homelab: peering entre sitios con WireGuard en 2026 es relevante para sysadmins Linux?