BGP en Keenetic: cómo configurar el enrutamiento dinámico mediante Entware y FRR

El protocolo troncal de enrutamiento dinámico BGP (Border Gateway Protocol) tradicionalmente se asocia con equipos empresariales o servidores Linux completos. Sin embargo, en la realidad actual, la tarea de construir redes VPN tolerantes a fallos (Mesh, Site-to-Site) o la distribución automática de tráfico a menudo obliga a los ingenieros a buscar formas de ejecutar BGP en routers SOHO de cliente.

Pocos saben que a partir de las versiones KeeneticOS 3.x el firmware incluye un componente BGP integrado oficial (por debajo funciona el demonio ligero BIRD, integrado con la subsistema NDM). Carece por completo de interfaz web, y toda la configuración se realiza exclusivamente a través del CLI de Keenetic (router bgp ...). Al mismo tiempo, las posibilidades de personalización de filtros, route-maps y community en la solución estándar están fuertemente limitadas.

Para ingenieros de red que requieren control total sobre el protocolo, una sintaxis familiar tipo Cisco (vtysh) y máxima flexibilidad de filtrado, existe una vía alternativa “hardcore”: el uso de OPKG/Entware para ejecutar una pila moderna completa FRRouting (FRR).

El propio protocolo BGP funciona sobre TCP/179. Antes de iniciar la integración es importante recordar: abrir este puerto al mundo exterior sin una filtración estricta hace al router vulnerable a ataques al plano de control. Keenetic permite la instalación de paquetes terceros Entware, pero no asesora sobre su configuración, por lo que toda la configuración de FRR la realiza el usuario por su cuenta.

2. Solución detallada

Arquitectura del esquema

El esquema práctico de interacción se ve de la siguiente manera:

             ┌──────────────────────┐
             │  Upstream / VPS / DC │
             │  AS 65001            │
             │  10.255.0.1          │
             └──────────┬───────────┘
                        │
                  WireGuard / GRE / IPIP / Ethernet
                        │
             ┌──────────▼───────────┐
             │      Keenetic         │
             │  KeeneticOS + Entware │
             │  FRR bgpd (vtysh)     │
             │  AS 65010             │
             │  10.255.0.2           │
             └──────────┬───────────┘
                        │
                 LAN / VLAN / clientes VPN

Es importante entender que en este esquema Keenetic actúa como un pequeño router Edge para una infraestructura doméstica, de laboratorio o de oficina. Sus tareas incluyen:

• Recepción de la ruta por defecto (default route) o de un conjunto limitado de prefijos desde el VPS / nodo central.
• Anuncio de subredes locales.
• Conmutación dinámica de rutas entre túneles VPN de respaldo.

Para obtener Full-View (tabla completa de rutas de Internet, que supera 1 millón de prefijos) Keenetic no es adecuado. Es un dispositivo embedded con recursos limitados de CPU y RAM.

Cuándo tiene sentido BGP en Keenetic

Escenarios justificados:

1. Site-to-site VPN con dinámica: Varias oficinas o ubicaciones domésticas conectadas mediante WireGuard/GRE. BGP informa automáticamente a los vecinos sobre la aparición o el cambio de subredes internas.
2. Failover entre túneles: Existencia de un proveedor/Canal VPN principal y uno de respaldo. El protocolo reacciona a la caída del enlace más rápido y más limpio que scripts personalizados de conmutación de rutas estáticas.
3. Bancos de pruebas de laboratorio: Estudio de los principios de BGP en combinación con VyOS, Cisco u otros vendors en hardware económico.
4. Anuncio de prefijos privados: Envío de rutas como 10.10.10.0/24 o 192.168.30.0/24 hacia el núcleo central de la red.

Escenarios malos:

• Intentar recibir Full-View desde un ISP.
• Construir el núcleo de la red de un gran proveedor (Production ISP Edge).
• Publicar BGP hacia fuera sin ACL.
• Usarlo como Route Reflector para un gran número de clientes.

Opciones de implementación

Opción A. Externalizar BGP a un nodo Linux vecino (Recomendado para Production)

La opción más estable y segura, que no carga el router:

Keenetic ── LAN ── Linux/VyOS/FRR (en LXC/VM/Mini-PC) ── VPN/BGP ── Upstream

El router sólo se encarga del switching y NAT, y toda la lógica BGP queda encapsulada en el servidor. En Keenetic se configura únicamente una ruta estática hacia el router Linux local.

Opción B. Ejecutar BGP directamente en Keenetic mediante Entware

La opción principal de este artículo. Requiere un modelo de router con puerto USB (el sistema de archivos del almacenamiento debe ser EXT4) o un modelo moderno con soporte para instalar Entware directamente en la memoria NAND interna (disponible desde KeeneticOS 3.7.x). Como demonio se usa la pila moderna FRR.

Opción C. Usar la pila obsoleta Quagga

Quagga es el predecesor histórico de FRR. Esta opción debe considerarse únicamente como escenario de fallback si para la arquitectura de CPU de su router no existe el paquete FRR en el repositorio Entware. Tenga en cuenta que el proyecto Quagga es oficialmente obsoleto (desarrollo activo terminado en 2018), por lo que todas las nuevas instalaciones deberían desplegarse en FRR.

Preparación de Keenetic para la instalación de FRR

Paso 1. Habilitar soporte OPKG

En la interfaz web de Keenetic vaya a Administración → Configuración general → Cambiar conjunto de componentes y active el elemento «Soporte de paquetes abiertos (OPKG)».

Si se usa un almacenamiento USB, forméelo en EXT4, conéctelo al dispositivo y elija como almacenamiento para OPKG. Para la instalación en la memoria interna (en modelos soportados) se usa el comando CLI:

(config)> opkg disk storage:

Tras la instalación exitosa del entorno Entware se crea automáticamente un script de inicialización /opt/etc/init.d/rc.unslung, a través del cual se arrancarán nuestros servicios.

Paso 2. Entrada al entorno Entware y actualización

Conéctese a Keenetic por SSH y entre al shell de Entware:

(config)> exec sh

Actualice el árbol de paquetes y establezca la contraseña del superusuario:

opkg update
opkg upgrade
passwd root

Paso 3. Instalación de paquetes de enrutamiento

Busque paquetes disponibles:

opkg list | grep -E '^(frr|quagga)'

Si existe una build estable de FRR, instale el demonio principal, la extensión para BGP, la interfaz de interacción con el kernel y la utilidad de gestión:

opkg install frr frr-bgpd frr-zebra frr-vtysh

Si FRR no está disponible para su arquitectura, instale los paquetes legacy Quagga:

opkg install quagga quagga-bgpd quagga-zebra

Nota: Los nombres de paquetes en distintos repositorios (MIPS/ARM/AArch64) pueden variar levemente.

Configuración de BGP mediante FRRouting (FRR)

Veamos una configuración mínima funcional para los siguientes datos:

• Sistema autónomo Keenetic: 65010
• Sistema autónomo VPS: 65001
• IP del túnel Keenetic: 10.255.0.2
• IP del túnel VPS: 10.255.0.1
• Red local detrás de Keenetic: 192.168.10.0/24

Paso 1. Crear la estructura de directorios

mkdir -p /opt/etc/frr
mkdir -p /opt/var/log/frr
mkdir -p /opt/var/run/frr

Paso 2. Crear el archivo de configuración frr.conf

Abra el editor: vi /opt/etc/frr/frr.conf y aplique la siguiente configuración:

frr version 8
frr defaults traditional
hostname keenetic-bgp
log file /opt/var/log/frr/frr.log informational
service integrated-vtysh-config
!
! Filtro para anuncios salientes (permitimos solo la LAN local)
ip prefix-list PL-LAN seq 10 permit 192.168.10.0/24
ip prefix-list PL-LAN seq 999 deny 0.0.0.0/0 le 32
!
! Filtro para anuncios entrantes (bloqueamos full-view, permitimos default y redes privadas)
ip prefix-list PL-IN seq 10 permit 0.0.0.0/0
ip prefix-list PL-IN seq 20 permit 10.0.0.0/8 le 24
ip prefix-list PL-IN seq 30 permit 172.16.0.0/12 le 24
ip prefix-list PL-IN seq 40 permit 192.168.0.0/16 le 24
ip prefix-list PL-IN seq 999 deny 0.0.0.0/0 le 32
!
router bgp 65010
 bgp router-id 10.255.0.2
 no bgp ebgp-requires-policy
 neighbor 10.255.0.1 remote-as 65001
 neighbor 10.255.0.1 description upstream-vps
 neighbor 10.255.0.1 timers 10 30
 !
 address-family ipv4 unicast
  network 192.168.10.0/24
  neighbor 10.255.0.1 activate
  neighbor 10.255.0.1 prefix-list PL-IN in
  neighbor 10.255.0.1 prefix-list PL-LAN out
 exit-address-family
!
line vty

Importante: La indicación explícita de bgp router-id es necesaria, ya que en un entorno aislado Entware el demonio zebra no siempre puede leer correctamente las direcciones de las interfaces físicas del router.

Paso 3. Verificar la tabla de enrutamiento local

El demonio BGP anuncia la red indicada en la directiva network solo si este prefijo está físicamente presente en la tabla de enrutamiento del kernel. Asegúrese con el comando:

ip route show 192.168.10.0/24

Paso 4. Arranque de los servicios

Si el paquete FRR del repositorio creó automáticamente scripts de automatización, ejecute:

/opt/etc/init.d/S*frr start

En caso contrario, los demonios se inician manualmente en segundo plano:

zebra -d -f /opt/etc/frr/frr.conf -z /opt/var/run/frr/zserv.api -i /opt/var/run/frr/zebra.pid
bgpd -d -f /opt/etc/frr/frr.conf -z /opt/var/run/frr/zserv.api -i /opt/var/run/frr/bgpd.pid

Configuración del extremo opuesto (Linux / VPS)

Ejemplo de configuración frr.conf en el servidor en la nube:

frr version 8
frr defaults traditional
hostname upstream-vps
log syslog informational
service integrated-vtysh-config
!
ip prefix-list FROM-KEENETIC seq 10 permit 192.168.10.0/24
ip prefix-list FROM-KEENETIC seq 999 deny 0.0.0.0/0 le 32
!
ip prefix-list TO-KEENETIC seq 10 permit 0.0.0.0/0
ip prefix-list TO-KEENETIC seq 999 deny 0.0.0.0/0 le 32
!
router bgp 65001
 bgp router-id 10.255.0.1
 neighbor 10.255.0.2 remote-as 65010
 neighbor 10.255.0.2 description keenetic-router
 !
 address-family ipv4 unicast
  neighbor 10.255.0.2 activate
  neighbor 10.255.0.2 prefix-list FROM-KEENETIC in
  neighbor 10.255.0.2 prefix-list TO-KEENETIC out
  network 0.0.0.0/0
 exit-address-family

No olvide habilitar el reenvío de paquetes en el servidor Linux:

sysctl -w net.ipv4.ip_forward=1
echo "net.ipv4.ip_forward=1" >> /etc/sysctl.d/99-forwarding.conf

Configuración de autoarranque en Keenetic

Para garantizar tolerancia a fallos tras un reinicio, cree un script init /opt/etc/init.d/S80frr:

#!/opt/bin/sh

PATH=/opt/sbin:/opt/bin:/sbin:/bin:/usr/sbin:/usr/bin
CONF="/opt/etc/frr/frr.conf"
RUN_DIR="/opt/var/run/frr"
LOG_DIR="/opt/var/log/frr"
ZEBRA_PID="${RUN_DIR}/zebra.pid"
BGPD_PID="${RUN_DIR}/bgpd.pid"
ZSOCK="${RUN_DIR}/zserv.api"

start() {
  mkdir -p "$RUN_DIR" "$LOG_DIR"
  if [ -f "$ZEBRA_PID" ] && kill -0 "$(cat "$ZEBRA_PID")" 2>/dev/null; then
    echo "Zebra ya está en ejecución."
  else
    zebra -d -f "$CONF" -z "$ZSOCK" -i "$ZEBRA_PID"
  fi

  if [ -f "$BGPD_PID" ] && kill -0 "$(cat "$BGPD_PID")" 2>/dev/null; then
    echo "Bgpd ya está en ejecución."
  else
    bgpd -d -f "$CONF" -z "$ZSOCK" -i "$BGPD_PID"
  fi
}

stop() {
  [ -f "$BGPD_PID" ] && kill "$(cat "$BGPD_PID")" 2>/dev/null && rm -f "$BGPD_PID"
  [ -f "$ZEBRA_PID" ] && kill "$(cat "$ZEBRA_PID")" 2>/dev/null && rm -f "$ZEBRA_PID"
}

case "$1" in
  start) start ;;
  stop) stop ;;
  restart) stop; sleep 2; start ;;
  *) echo "Uso: $0 {start|stop|restart}"; exit 1 ;;
esac

Haga el script ejecutable: chmod +x /opt/etc/init.d/S80frr.

3. Diagnóstico y depuración

Para entrar en la consola interactiva del enrutador ejecute:

vtysh

Comandos principales para monitorizar la sesión:

• show bgp summary — comprobar el estado de la vecindad. Estado deseado: Established.
• show ip bgp — ver la tabla de prefijos BGP.
• show ip bgp neighbors 10.255.0.1 received-routes — rutas recibidas del vecino (requiere habilitar soft-reconfiguration).
• show ip route bgp — rutas que han sido correctamente inyectadas desde BGP a la subsistema Zebra.

La salida de la consola se hace con exit. Para asegurarse de que las rutas han llegado efectivamente al propio kernel Linux del Keenetic, ejecute desde el shell principal del router:

ip route show proto bgp

Fallos típicos

1. Sesión en estado Active/Connect: Compruebe la accesibilidad del puerto TCP/179 con nc -vz 10.255.0.1 179. Revise las reglas del firewall integrado de KeeneticOS — pueden bloquear tráfico entrante en la interfaz del túnel.
2. Sesión establecida (Established), pero sin prefijos: Error en el prefix-list. Verifique que los filtros no estén bloqueando los anuncios en ambos lados.
3. Tras reiniciar el router la configuración desaparece: Particularidad de Entware. Los servicios se inicializan sólo después del montaje completo del disco con sistema de archivos EXT4. Asegúrese de que se haya ejecutado el script padre rc.unslung.

4. Potenciales desventajas de la solución

A pesar del atractivo del esquema, ejecutar FRR en Keenetic conlleva riesgos arquitectónicos:

• Conflicto con la lógica de enrutamiento de KeeneticOS (NDM): El propio kernel del sistema operativo Keenetic controla fuertemente sus tablas de enrutamiento, la lógica Multi-WAN (políticas de enrutamiento), el binding de interfaces y el offload de hardware (PPE/WhNat). Las rutas inyectadas por el demonio externo zebra directamente en el kernel Linux no son visibles en la interfaz web de Keenetic. Esto puede provocar conflictos difíciles de diagnosticar (por ejemplo, el tráfico sale por el WAN equivocado debido a prioridades de tablas).
• Fragilidad del subsistema de almacenamiento: Si la memoria USB falla o se desmonta por un fallo de alimentación —toda la red caerá, ya que los demonios Entware dejarán de estar disponibles.
• Consumo de recursos: Incluso una pequeña inestabilidad en el enlace del vecino (route flapping) provocará constantes recálculos de rutas, lo que puede cargar al 100% el débil procesador del router SOHO y paralizar sus otras funciones.

Conclusión

Usar BGP en Keenetic mediante Entware y FRR es una herramienta funcional, flexible pero muy especializada. Es ideal para instalaciones de hobby, laboratorios domésticos y conexión de puntos remotos cuando desplegar un servidor dedicado no es razonable.

Para uso comercial estable (Production Enterprise) la opción preferente sigue siendo externalizar BGP a máquinas virtuales dedicadas o emplear dispositivos especializados (VyOS, MikroTik, Juniper) diseñados desde el inicio para tareas de enrutamiento dinámico.