Redes: BGP para redes pequeñas — La configuración mínima segura

Qué necesitas realmente (y qué no)

Las redes pequeñas no necesitan “BGP avanzado”. Necesitan BGP predecible. Si haces multihoming con dos upstreams,
tu objetivo es: mantener tus prefijos alcanzables, mantener las rutas de los demás sensatas y conmutar por error sin convertirse
en un titular por una fuga de rutas.

Aquí está la definición mínima segura:

• Un ASN (el tuyo, o un ASN asignado por el proveedor si realmente no puedes obtener uno).
• Una o más sesiones con proveedores (eBGP), idealmente en routers separados.
• Anunciar solo lo que posees (prefijos exactos, origen AS correcto).
• Aceptar solo lo que pretendes (tabla completa si es necesario, solo default si puedes).
• Filtros estrictos tanto de entrada como de salida.
• Límites (max-prefix, límites de tasa y protecciones de sesión).
• Observabilidad que muestre el estado de sesiones, recuentos de rutas y rutas reales del tráfico.
• Rollback documentado que funcione a las 3 a.m.

Lo que no necesitas en el día uno:

• Ingeniería de tráfico mediante diez capas de comunidades que no entiendes.
• Caza de caminos exóticos con prepends de AS en cinco sitios “por redundancia”.
• Reinicio elegante por todas partes porque alguien dijo que es “más limpio”.
• Reflectores de rutas y gimnasias de malla iBGP en una red que cabe en una pizarra.

Una red pequeña puede ejecutar BGP como un cinturón de seguridad: simple, aburrida y rara vez notada. Ese es el punto.

Breve contexto histórico y datos interesantes

Algo de contexto ayuda porque el comportamiento de BGP a menudo parece “extraño” hasta que recuerdas para qué se diseñó: política, no
perfección de la ruta más corta.

1. BGP reemplazó a EGP cuando Internet pasó de una topología arbórea a una malla desordenada de sistemas autónomos.
2. BGP es un protocolo vector-ruta: transporta una ruta de AS para evitar bucles, no un grafo completo de topología como los protocolos de estado de enlace.
3. CIDR y BGP crecieron juntos a principios de los 90 para frenar la explosión de la tabla de ruteo permitiendo agregación.
4. La “zona sin default” surgió cuando muchos routers centrales llevaban rutas completas sin ruta por defecto.
5. Las fugas de rutas siguen ocurriendo porque el modelo de confianza de BGP asume que los pares se comportan, y los humanos con frecuencia no lo hacen.
6. Se añadieron comunidades para permitir que las redes etiqueten rutas para políticas sin reescribir el protocolo base cada vez.
7. MP-BGP habilitó VPNs (como L3VPN) e IPv6 a escala sin inventar un protocolo totalmente nuevo.
8. RPKI es relativamente nuevo y todavía se despliega de forma desigual, pero es uno de los primeros mecanismos ampliamente usados para reducir secuestros por origen.

La conclusión: BGP tiene edad suficiente para votar, y algunas de sus suposiciones son más antiguas que tu pila de monitorización.

Modelo de amenazas para redes pequeñas: qué puede fallar

Para redes pequeñas, la “seguridad BGP” no trata de adversarios estatales. Trata de los modos de fallo cotidianos:
equivocaciones de dedo, mala comunicación y valores por defecto del proveedor que parecen inofensivos hasta que no lo son.

Modo de fallo: anuncias lo que no posees

Este es el clásico. Un error tipográfico en una lista de prefijos, una agregación demasiado amplia o una “prueba temporal” que nunca se revirtió.
Los upstreams pueden filtrar, pero no deberías externalizar tu seguridad a su diligencia.

Modo de fallo: aceptas basura y te autopones en un agujero negro

Tomar la tabla completa e instalarla en un router pequeño con memoria insuficiente es una manera fiable de inventar nuevos patrones de pérdida de paquetes.
Tomar solo default pero olvidar fijar next-hops o local-pref puede producir flaps extraños.

Modo de fallo: fuga de rutas vía políticas de tránsito

Una fuga de rutas ocurre cuando accidentalmente provees tránsito entre dos redes que nunca lo acordaron. Tu red se convierte
en un pasillo no intencionado. El tráfico sigue el pasillo hasta que se derrumba.

Modo de fallo: el plano de control dice “up” mientras el plano de datos arde

Las sesiones BGP pueden estar Established y felices mientras MTU, ACLs o asimetría silenciosamente matan el rendimiento.
BGP es un protocolo del plano de control. No es un terapeuta.

Una cita para mantener en mente: “La esperanza no es una estrategia.” — Gene Kranz.

Broma #1: BGP es el único lugar donde “confianza” es una opción de configuración, no un estado de relación.

El diseño mínimo seguro: decisiones que adoptas

1) Elige tu modelo de ruteo: solo default o tabla completa

Si tu red es pequeña, probablemente no necesites la tabla completa de Internet. Solo-default (0.0.0.0/0 y ::/0) reduce
la presión de memoria y el riesgo operativo. La tabla completa te da control más fino y a veces mejor rendimiento, pero también
te da 900k+ formas de sufrir.

Mi regla de opinión:

• Si tienes un router de borde: solo-default suele ser lo correcto.
• Si tienes dos routers de borde y necesidades reales de ingeniería de tráfico: considera la tabla completa, pero solo con hardware que la soporte.
• Si haces scrubbing DDoS, multi-exit complejo o gran tráfico CDN: la tabla completa se vuelve más defendible.

2) Dos routers si puedes permitírtelo

Un router es un punto único de fallo. Dos routers son mucho papeleo. Aun así: si puedes costear dos cajas modestas, hazlo.
Colócalos en alimentación separada, enlaces ascendentes separados y, preferiblemente, entregas upstream independientes.

3) Mantén el iBGP pequeño y obvio

Si ejecutas dos routers de borde, probablemente ejecutes iBGP entre ellos. Mantenlo simple:
una sesión en cada sentido, políticas de rutas claras y un único IGP (o estático) para llevar next-hops.
No estás construyendo una columna vertebral tier-1. Compórtate en consecuencia.

4) Separa la política de la plomería

Tu demonio BGP puede ser FRR, BIRD, Junos, IOS, EOS—no importa tanto como tu disciplina.
Crea una estructura de políticas que puedas auditar:

• Filtro de entrada: qué aceptas, qué rechazas y qué etiquetas.
• Filtro de salida: qué originas, qué exportas y cómo lo marcas.
• Guardarraíles de sesión: max-prefix, seguridad TTL (cuando aplique), MD5/TCP-AO si es soportado, y temporizadores sensatos.

5) Decide tu estrategia de anuncios: primero exactos

Empieza con prefijos exactos. Anuncia solo los bloques específicos que posees y que pretendes originar. Las agregaciones pueden venir después,
y solo cuando estés seguro de que no vas a tragarte espacios de direcciones que no controlas.

Filtrado: tu verdadero cortafuegos es la política

En BGP, el filtrado es la diferencia entre “una red” y “un accidente”.
Necesitas filtros de salida para prevenir fugas y filtros de entrada para evitar que la tontería se instale.

Filtrado de salida: anuncia solo tus prefijos

Para una red pequeña, la política de salida suele ser:

• Permitir tus prefijos propios (y solo esos).
• Establecer tus propias comunidades si las usas.
• Rechazar todo lo demás.

Si eres un cliente (no un proveedor de tránsito), no deberías exportar la tabla completa que aprendiste del ISP A al ISP B.
Ese es el arquetipo de fuga de rutas.

Filtrado de entrada: acepta lo que puedas manejar

Tu política de entrada depende de si tomas solo-default o la tabla completa:

• Solo-default: acepta 0.0.0.0/0 y ::/0 de cada upstream, más tal vez un pequeño conjunto de rutas específicas del proveedor si es necesario.
• Tabla completa: acepta todo después de descartar bogons, martians, prefijos demasiado largos y orígenes RPKI inválidos.

Ideas básicas sobre bogons/martians

Como mínimo, descarta rutas para RFC1918, espacio carrier-grade NAT, loopback, link-local, multicast y otros rangos no globales obvios.
También puedes descartar rutas demasiado específicas (por ejemplo, IPv4 más largas que /24 e IPv6 más largas que /48) a menos que las necesites explícitamente.

Tu upstream puede ya filtrar esto. Genial. Aun así filtra tú mismo. La redundancia no es solo para fuentes de alimentación.

RPKI: seguridad barata, alto retorno

La validación RPKI comprueba si el AS de origen está autorizado a anunciar un prefijo (en base a ROAs).
No resuelve todos los problemas de seguridad de BGP. Reduce el radio de impacto de errores de origen y algunos secuestros.

Postura mínima de RPKI para redes pequeñas:

• Ejecuta un validador (como Routinator) internamente.
• Configura tus routers/demonios para hacer validación de origen.
• Rechaza rutas RPKI-inválidas en entrada desde tránsito (o al menos deprefiérelas fuertemente).
• Publica ROAs para tus propios prefijos correctamente (y mantenlos actualizados).

Si solo haces una cosa de “modernización”, haz esta. Es lo más parecido a que BGP lleve casco.

Límites y temporizadores: evita saturaciones sorpresa

Los límites no son por cautela. Son para asegurar que las fallas fallen rápido, ruidosamente y de forma contenida.

Límites de max-prefix

Si tomas solo-default, tu max-prefix debería ser pequeño (como 10–100, dependiendo de extras del upstream).
Si tomas la tabla completa, ajústalo a tu tabla esperada más margen, pero no margen infinito.

Tu decisión es filosófica: ¿quieres que la sesión caiga cuando pase algo extraño (fail-closed),
o prefieres mantenerla arriba y esperar que tu caja sobreviva (fail-open)? Para redes pequeñas, fail-closed suele ser más amable.

Keepalives y hold timers

Los valores por defecto suelen estar bien. Afinar temporizadores para “conmutar más rápido” a menudo solo te hará flapear más rápido.
Si necesitas convergencia sub-segundo, ya no estás en territorio “mínimo seguro”; estás en “enginyear toda la pila”.

Graceful restart: útil, pero fácil de malusar

Graceful restart puede ocultar reinicios del plano de control, pero también puede preservar reenvío obsoleto y complicar el diagnóstico de fallos.
Si lo habilitas, pruébalo. Luego pruébalo de nuevo con fallos parciales.

Broma #2: Graceful restart es como poner tu router en “No molestar”. Está tranquilo hasta que te das cuenta de que se perdió la alarma de incendio.

Comprobaciones del plano de datos: no confíes en el plano de control

BGP intercambiará rutas felizmente sobre una sesión TCP mientras tu tráfico real muere por MTU, ACLs, asimetría de ruteo
o un upstream que silenciosamente descarta tráfico durante mitigación.

Postura operativa mínima:

• Valida siempre la alcanzabilidad de tus propios prefijos desde fuera (no solo desde dentro).
• Mantén un host de prueba conocido y fiable en otra red (una VM económica en otro sitio sirve).
• Monitorea la pérdida de paquetes y latencia por enlace ascendiente, no solo “BGP Established”.

Tareas prácticas: comandos, salidas y decisiones (12+)

Estas son tareas reales que puedes ejecutar en un router basado en Linux, un route server o una caja de troubleshooting.
Usaré estilo FRR vtysh y herramientas Linux comunes porque están ampliamente disponibles.
La clave es el flujo de trabajo: comando → interpretar salida → tomar una decisión.

Task 1: Verify BGP sessions are Established (FRR)

cr0x@server:~$ vtysh -c "show ip bgp summary"
BGP router identifier 203.0.113.2, local AS number 64512
BGP table version is 128, main routing table version 128
Neighbor        V         AS MsgRcvd MsgSent   TblVer  InQ OutQ  Up/Down State/PfxRcd
198.51.100.1    4      65001    9132    9050      128    0    0 2d03h        1
203.0.113.1     4      65002    8321    8204      128    0    0 2d03h        1

Qué significa: Ambos vecinos están arriba desde hace ~2 días y cada uno envía 1 prefijo (probablemente solo-default).
Decisión: Si esperabas rutas completas y ves “1”, tu política de entrada es solo-default (o está rota).
Si esperabas solo-default y ves “900000”, tus filtros están mal o tu upstream te está dando la tabla completa.

Task 2: Check received routes from an upstream and confirm filtering

cr0x@server:~$ vtysh -c "show ip bgp neighbor 198.51.100.1 received-routes" | head
BGP table version is 128, local router ID is 203.0.113.2
Status codes: s suppressed, d damped, h history, * valid, > best, = multipath
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*> 0.0.0.0/0        198.51.100.1             0    100      0 65001 i

Qué significa: Estás recibiendo solo default. Eso concuerda con el diseño solo-default.
Decisión: Si ves RFC1918 u otra basura aquí, ajusta los filtros de entrada inmediatamente.

Task 3: Confirm you only advertise your intended prefixes

cr0x@server:~$ vtysh -c "show ip bgp neighbor 198.51.100.1 advertised-routes"
BGP table version is 128, local router ID is 203.0.113.2

   Network          Next Hop            Metric LocPrf Weight Path
*> 203.0.113.0/24   0.0.0.0                  0         32768 i

Qué significa: Anuncias solo 203.0.113.0/24. Bien.
Decisión: Si ves 0.0.0.0/0 o una tabla completa aquí como red cliente, estás filtrando mal. Apágalo: deshabilita la exportación y luego corrige la política.

Task 4: Validate your router’s RIB vs BGP RIB (Linux)

cr0x@server:~$ ip route show default
default via 198.51.100.1 dev eth1 proto bgp metric 20

Qué significa: La ruta por defecto del kernel está instalada vía BGP en eth1.
Decisión: Si tu uplink preferido debería ser ISP2 pero esto apunta a ISP1, ajusta local-pref (preferido) o weight (específico del proveedor).

Task 5: Check route counts at a glance (BIRD)

cr0x@server:~$ birdc show protocols all | sed -n '1,14p'
BIRD 2.0.12 ready.
Name       Proto      Table      State  Since         Info
up_isp1    BGP        master4    up     2026-02-04    Established
  BGP state:          Established
  Neighbor address:   198.51.100.1
  Neighbor AS:        65001
  Routes:             1 imported, 1 exported, 1 preferred
  Route change stats:     received   rejected   filtered    ignored   accepted
    Import updates:         2          0          0          0          2
    Export updates:         2          0          0          0          2

Qué significa: BIRD confirma la forma prevista “solo-default”.
Decisión: Si “rejected” aumenta, tu filtro está bloqueando algo; determina si es bloqueo correcto o un bloqueo accidental.

Task 6: Check that your prefix is visible externally (from a remote probe)

cr0x@server:~$ whois -h whois.radb.net 203.0.113.0/24 | head
route:          203.0.113.0/24
origin:         AS64512
descr:          Example Network
mnt-by:         EXAMPLENET-MNT
changed:        noc@example.net 20250101
source:         RADB

Qué significa: Hay un objeto de ruta (registro de ruteo) que indica tu intención de originar este prefijo.
Decisión: Si tu upstream usa filtrado basado en IRR y esto falta/está mal, tus anuncios pueden ser filtrados. Corrige el objeto del registro o la autorización del filtro upstream.

Task 7: Verify ROA status for your prefix (Routinator)

cr0x@server:~$ routinator validate 203.0.113.0/24 | head
203.0.113.0/24 AS64512 valid (maxLength 24)

Qué significa: Tu prefijo tiene un ROA válido para tu ASN.
Decisión: Si aparece “invalid” o “notfound”, corrige los ROAs. Si tu upstream descarta inválidos, desaparecerás de forma que parecerá “BGP está arriba pero nadie puede alcanzarnos”.

Task 8: Check RPKI validation state on the router (FRR example)

cr0x@server:~$ vtysh -c "show bgp rpki summary"
RPKI cache servers:
1) 127.0.0.1:3323  pref 1  state Established  uptime 2d03h  serial 12981
Prefix records: 214532

Qué significa: Tu router habla con el validador local y tiene datos RPKI.
Decisión: Si el estado no es Established, tu política de “rechazar inválidos” puede dejar de funcionar silenciosamente. Repara la conectividad RTR primero.

Task 9: Confirm you’re not melting your router (memory/CPU quick check)

cr0x@server:~$ top -b -n1 | head -n 8
top - 10:12:54 up 32 days,  4:19,  1 user,  load average: 0.22, 0.18, 0.15
Tasks: 134 total,   1 running, 133 sleeping,   0 stopped,   0 zombie
%Cpu(s):  1.4 us,  0.5 sy,  0.0 ni, 97.8 id,  0.2 wa,  0.0 hi,  0.1 si,  0.0 st
MiB Mem :   7984.2 total,   4231.7 free,    912.4 used,   2840.1 buff/cache
MiB Swap:      0.0 total,      0.0 free,      0.0 used.   6589.4 avail Mem

Qué significa: Mucha holgura. ¿Bueno para rutas completas? Tal vez. ¿Bueno para solo-default? Definitivamente.
Decisión: Si haces swapping o la CPU está al máximo durante actualizaciones, reduce la entrada de rutas (solo-default), mejora el hardware o traslada BGP a una caja de plano de control con enfoque limpio de programación de FIB.

Task 10: Check for packet loss on the uplink interface

cr0x@server:~$ ip -s link show dev eth1
2: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000
    link/ether 52:54:00:11:22:33 brd ff:ff:ff:ff:ff:ff
    RX:  bytes  packets  errors  dropped  missed  mcast
    9876543210  9123456  0       12       0       0
    TX:  bytes  packets  errors  dropped  carrier collsns
    1234567890  7345678  0       0        0       0

Qué significa: Existen algunas pérdidas en RX. Podría ser policing, presión de buffers o problemas de driver.
Decisión: Si las pérdidas aumentan en hora punta, probablemente hay congestión o desajuste de shaping. No “arregles” esto con BGP. Arréglalo con capacidad, QoS o ajuste de interfaz.

Task 11: Validate MTU with do-not-fragment ping

cr0x@server:~$ ping -M do -s 1472 -c 3 198.51.100.1
PING 198.51.100.1 (198.51.100.1) 1472(1500) bytes of data.
1472 bytes from 198.51.100.1: icmp_seq=1 ttl=64 time=0.61 ms
1472 bytes from 198.51.100.1: icmp_seq=2 ttl=64 time=0.58 ms
1472 bytes from 198.51.100.1: icmp_seq=3 ttl=64 time=0.60 ms

--- 198.51.100.1 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms

Qué significa: El Path MTU parece correcto para Ethernet de 1500 bytes.
Decisión: Si falla esto y tamaños menores funcionan, tienes riesgo de agujero MTU. Arregla MTU/MSS clamping antes de culpar a BGP por lentitud “aleatoria”.

Task 12: Check actual egress path selection with traceroute

cr0x@server:~$ traceroute -n -w 1 -q 1 1.1.1.1 | head
traceroute to 1.1.1.1 (1.1.1.1), 30 hops max, 60 byte packets
 1  198.51.100.1  0.530 ms
 2  198.51.100.254  1.212 ms
 3  203.0.113.254  2.891 ms

Qué significa: Sales por ISP1.
Decisión: Si pretendías que ISP2 fuera primario, cambia local-pref/weight o la preferencia de la ruta por defecto. No solo hagas prepends y esperes; controla entrada y salida por separado.

Task 13: Confirm kernel sees the expected BGP-learned routes (size sanity)

cr0x@server:~$ ip route | grep -c "proto bgp"
1

Qué significa: Instalaste exactamente una ruta BGP (probablemente default). Esa es tu intención declarada en modo solo-default.
Decisión: Si este recuento explota inesperadamente, tu demonio puede estar instalando rutas completas. Confirma políticas y si deberías usar un VRF/tabla separada.

Task 14: Spot a route leak pattern by checking AS-path on unexpected routes

cr0x@server:~$ vtysh -c "show ip bgp 8.8.8.0/24"
BGP routing table entry for 8.8.8.0/24
Paths: (1 available, best #1, table default)
  65001 15169
    198.51.100.1 from 198.51.100.1 (198.51.100.1)
      Origin IGP, localpref 100, valid, external, best

Qué significa: Aprendiste esta ruta de ISP1. Normal si tomas rutas completas.
Decisión: Si estás en modo solo-default pero ves específicas como esta instaladas, tu filtro de entrada no está haciendo lo que crees.

Task 15: Check BGP flap history to detect intermittent transport issues

cr0x@server:~$ vtysh -c "show ip bgp neighbor 198.51.100.1"
BGP neighbor is 198.51.100.1, remote AS 65001, local AS 64512, external link
  BGP version 4, remote router ID 198.51.100.1
  BGP state = Established, up for 2d03h
  Last read 00:00:19, Last write 00:00:21
  Connections established 3; dropped 2
  Last reset 1d01h, due to Hold Timer Expired

Qué significa: La sesión ha caído dos veces, la última por expiración del hold timer. Eso suele ser pérdida de transporte o agotamiento de CPU.
Decisión: Si las expiraciones de hold se correlacionan con congestión o DDoS, mejora la fiabilidad del transporte primero (QoS, coordinación de policing, protección del plano de control).

Tres microhistorias corporativas desde el campo

Microhistoria 1: El incidente causado por una suposición equivocada

Una empresa SaaS mediana hizo multihoming por primera vez. Dos upstreams, un router, FRR. Tenían una ventana de cambio,
un runbook y un canal de Slack con un nombre confiado como #bgp-cutover.

La suposición equivocada: “Nuestro upstream filtrará todo lo que no debamos anunciar.” El ingeniero escribió una política de salida
pensada para anunciar solo su /24, pero también redistribuyó rutas connected. Una subred de gestión resultó ser espacio público de
una adquisición anterior y aún estaba en una interfaz. Se anunció.

Nada parecía roto internamente. BGP estaba Established. Las IPs de sus servicios siguieron arriba. La única señal fue un aumento extraño
de tráfico entrante en la interfaz de gestión y algunas alertas de monitorización por CPU elevada.

Entonces el upstream lo notó. El upstream cerró la sesión BGP—de forma tajante. La conectividad de salida falló hacia el segundo ISP,
pero el tráfico entrante no se recuperó limpiamente. Algunos clientes siguieron alcanzando la ruta retirada durante minutos, porque el
cacheo y la propagación no están obligados a coincidir con tu ventana de mantenimiento.

La solución fue simple y humillante: listas de prefijos de salida explícitas, nada de redistribuir en eBGP y una comprobación previa al cambio
que imprime las rutas anunciadas y requiere que una persona firme. La mejor línea del postmortem fue: “Externalizamos la corrección a alguien
con incentivos distintos.”

Microhistoria 2: La optimización que salió mal

Una empresa de retail quería “conmutar más rápido”. Leyeron sobre BFD y temporizadores agresivos. Su borde tenía dos routers, cada uno con dos sesiones.
El equipo activó keepalives y hold timers más cortos, y también BFD en todas partes.

Durante una semana, fue estupendo. Una caída de enlace conmutaba rápido. Todos se sintieron listos. Luego un mantenimiento benigno de un upstream
introdujo microburstings intermitentes de pérdida de paquetes en un circuito. No lo suficiente para dañar mucho los flujos TCP. Suficiente para molestar a BFD.

El resultado fue un modo de fallo difícil de explicar a no networkers: las sesiones flapeaban repetidamente, las rutas churnearon,
la CPU subió y la pérdida de paquetes empeoró porque el plano de control consumía ciclado de reconvergencia. La “optimización” creó inestabilidad autoinfligida.
La red era rápida para fallar y lenta para sanar.

Revirtieron a temporizadores más conservadores y activaron BFD solo donde el transporte era limpio y bien comprendido. La lección perdurable:
la convergencia es una propiedad del sistema. Si aprietas una parte demasiado, otra se deforma.

Microhistoria 3: La práctica aburrida pero correcta que salvó el día

Un pequeño proveedor de hosting ejecutó una configuración mínima de BGP durante años: listas de prefijos estrictas, límites max-prefix,
validación RPKI y un trabajo nocturno que diferenciaba “rutas anunciadas por vecino” frente a un archivo esperado. No era glamoroso. También
fue la razón por la que dormían.

Una tarde recibieron una llamada de un upstream: “Estamos viendo un número inusual de prefijos desde vuestra sesión.” Internamente,
su monitorización ya había paginado. El trabajo de diff detectó que su router estaba a punto de exportar más de los dos prefijos esperados.
Max-prefix en export no es universal, pero su política era estricta: denegar todo excepto una lista explícita.

La causa raíz fue un error de gestión de configuración: una expansión de variable de plantilla produjo una lista de prefijos más amplia en un solo router.
La política estricta de “denegar todo lo demás” impidió exportar algo inesperado, así que el radio de impacto se limitó a “no anunciamos uno de nuestros
prefijos previstos durante unos minutos” en lugar de “filtramos la tabla”.

Corregieron la plantilla, re-desplegaron y cerraron el incidente con apenas impacto para clientes. Lo que los salvó no fue el genio.
Fue el aburrimiento: allowlists explícitas, expectativas diferenciables y negarse a confiar en la misericordia del upstream.

Guía rápida de diagnóstico

Cuando algo falla, tu trabajo es encontrar el cuello de botella rápido, no admirar los restos. Aquí el orden que tiende a producir respuestas rápidas.

Primero: ¿es plano de control, plano de datos o política?

• Chequeo plano de control: ¿Las sesiones están Established? ¿Los prefijos recibidos/enviados están en los recuentos esperados?
• Chequeo plano de datos: ¿Puedes hacer ping/traceroute hacia fuera? ¿Pueden otros alcanzar tus prefijos? ¿Hay pérdidas/errores?
• Chequeo de política: ¿Cambió local-pref/weight? ¿Nuevos filtros, cambios RPKI o max-prefix disparados?

Segundo: valida tus propios anuncios

• En el router: verifica que las rutas anunciadas por vecino coincidan con tu allowlist.
• Externamente: verifica que los ROAs sean válidos y que los registros coincidan con lo que el upstream espera.
• Comprueba que el AS de origen sea correcto y estable.

Tercero: verifica simetría de ruteo entrante y next-hops

• ¿Recibes default de ambos? ¿Cuál está ganando?
• ¿El tráfico de retorno vuelve por el ISP que esperas? Si no, ¿tienes firewalls stateful que lo odiarán?
• ¿Tu IGP/rutas estáticas son consistentes con los next-hops de BGP?

Cuarto: busca agotamiento de recursos y churn

• Picos de CPU durante actualizaciones de rutas pueden causar expiraciones de hold timer.
• Presión de memoria puede causar demoras en el procesamiento de rutas y lag en la programación de FIB.
• Logs: resets de sesión, eventos de límite de prefijos, desconexiones del caché RPKI.

Quinto: aisla forzando una conmutación limpia (con cuidado)

Si tienes dos upstreams, temporalmente cierra una sesión BGP (o ajusta local-pref) y observa. Si el problema desaparece,
probablemente es específico del upstream o de la política. Si persiste, probablemente es tu borde o la red downstream.

Errores comunes: síntoma → causa raíz → solución

1) Síntoma: Internet “funciona” pero algunos sitios hacen timeout

Causa raíz: Agujero MTU o PMTUD roto, frecuentemente a través de túneles o handoffs de proveedor.

Solución: Valida MTU con pings DF; implementa MSS clamping en el borde para TCP; alinea MTU a través de los handoffs.

2) Síntoma: BGP Established, pero nadie puede alcanzar tus IPs

Causa raíz: No estás anunciando realmente tu prefijo (error de política), o el upstream lo filtra (desajuste IRR/RPKI).

Solución: Revisa advertised-routes; confirma origin AS; valida ROAs; asegúrate de que los objetos de registro coincidan con los requisitos de filtrado del upstream.

3) Síntoma: CPU del router se dispara y las sesiones flapean en hora punta

Causa raíz: Sobrecarga del plano de control por actualizaciones de tabla completa, temporizadores demasiado agresivos o churn de rutas.

Solución: Incrementa temporizadores a valores sensatos; reduce rutas (solo-default); asegura protección del plano de control; considera hardware o separar plano de control.

4) Síntoma: De repente recibes muchas más rutas de lo habitual

Causa raíz: Un upstream filtró la tabla completa a tu sesión solo-default, o cambió tu filtro de entrada.

Solución: Aplica filtros de entrada estrictos; establece max-prefix; coordina con el upstream; considera rechazar todo excepto default si ese es tu diseño.

5) Síntoma: Tu upstream amenaza con desconexión por “fuga de rutas”

Causa raíz: Exportaste rutas aprendidas a otro vecino, o redistribuiste IGP/connected en eBGP.

Solución: Elimina la redistribución a eBGP; implementa una allowlist de salida explícita; valida rutas anunciadas antes de habilitar sesiones.

6) Síntoma: La conmutación funciona de salida, pero el tráfico entrante se queda con el ISP muerto

Causa raíz: El ruteo entrante depende de la selección de ruta del resto de Internet; tus cambios de anuncio no son inmediatos o preferidos.

Solución: Usa comunidades soportadas por los proveedores; asegúrate de que ambos upstreams vean tus anuncios; considera anuncios más específicos para conmutación controlada (con cuidado).

7) Síntoma: RPKI “rompió Internet” tras activarlo

Causa raíz: Rechazaste inválidos pero tus propios ROAs estaban mal, o la conectividad del validador falló y la política por defecto actuó inesperadamente.

Solución: Valida primero tus propios prefijos; asegúrate de una conexión RTR estable; implementa política escalonada (preferir válidos, depreference unknown, rechazar inválidos) si es necesario.

8) Síntoma: Ruteo asimétrico rompe sesiones stateful del firewall

Causa raíz: Diferentes uplinks para entrada y salida, más un firewall que espera simetría.

Solución: Diseña para simetría (política/local-pref) o despliega sincronización de estado / firewalls conscientes del ruteo; evita ECMP “aleatorio” sobre dispositivos stateful.

Listas de comprobación / plan paso a paso

Fase 0: Antes de tocar BGP

• Ordena espacio de direcciones y ASN: quién posee qué, quién origina qué.
• Decide solo-default vs tabla completa; dimensiona hardware en consecuencia.
• Construye un camino de gestión fuera de banda que no dependa del nuevo diseño BGP.
• Escribe una allowlist de prefijos que anunciarás (prefijos exactos, longitudes de máscara correctas).
• Decide tus valores de max-prefix por vecino y documéntalos.

Fase 1: Levantar sesiones de forma segura (una a la vez)

1. Configura el vecino con deny-all de salida temporalmente.
2. Establece la sesión BGP y confirma que se mantiene Established al menos 15–30 minutos.
3. Habilita la política de entrada (solo-default o tabla completa) y confirma que el recuento de prefijos recibidos coincide con lo esperado.
4. Habilita la allowlist de salida y confirma que la lista de prefijos anunciados coincide con tu archivo esperado.
5. Valida la alcanzabilidad externa de tus prefijos desde una sonda remota.

Fase 2: Añadir guardarraíles

• Establece max-prefix y define comportamiento al exceder (aviso vs shutdown; prefiero shutdown para redes pequeñas).
• Habilita validación RPKI y elige política (rechazar inválidos es común; sé deliberado con “notfound”).
• Descarta bogons/martians inbound; evita prefijos demasiado específicos salvo necesidad.
• Asegura que no haya redistribución de connected/IGP a eBGP salvo que sea intencionado y filtrado.

Fase 3: Redundancia y conmutación controlada

• Levanta el segundo upstream con la misma disciplina: deny-all y luego allowlist.
• Decide preferencia de salida (local-pref/weight) y prueba conmutación cerrando una sesión.
• Para preferencia entrante, usa comunidades soportadas por el proveedor o anuncios más específicos controlados.
• Prueba durante una ventana de bajo riesgo; mide convergencia e impacto en aplicaciones.

Fase 4: Operarlo como producción

• Monitoriza: estado de sesiones, recuento de prefijos, tasa de actualizaciones, CPU/memoria, drops/errores de interfaz.
• Alerta en: sesión caída, desviación en recuento de prefijos, desconexión del validador RPKI, eventos max-prefix.
• Control de cambios: cambios en política de pares requieren diff y una segunda revisión.
• Mantén un plan de rollback: deshabilitar export, cerrar sesiones, revertir configuración, verificar alcanzabilidad.

Preguntas frecuentes

¿Necesito BGP si estoy con un solo proveedor?

Normalmente no. Si tienes un ISP y no tienes espacio de direcciones portable, BGP suele introducir modos de fallo extra.
Usa ruteo estático/por defecto y enfócate en redundancia en otros sitios.

Solo-default vs tabla completa: ¿qué debería elegir?

Solo-default si eres pequeño y quieres estabilidad. Tabla completa si tienes razones fuertes: necesidades de ingeniería de tráfico,
múltiples salidas con política significativa, o operas a una escala donde solo-default causa ruteo realmente subóptimo.

¿Puedo hacer multihoming con un solo router con seguridad?

Puedes, pero compras redundancia parcial. El router sigue siendo un punto único de fallo. Si lo haces, mantén el diseño mínimo
y asegúrate de poder acceder remotamente vía un camino fuera de banda cuando te quedes fuera.

¿Debería usar BFD para acelerar la conmutación?

Solo si tu transporte es limpio y lo has probado en condiciones reales de pérdida. Detecciones agresivas pueden causar flapping,
y el flapping puede ser peor que una conmutación ligeramente más lenta.

¿Qué son las comunidades BGP y las necesito?

Las comunidades son etiquetas que adjuntas a rutas para solicitar comportamiento al upstream (como prepend, blackholing o cambios de local-pref).
No las necesitas para la configuración mínima segura, pero son la forma más limpia de influir tráfico entrante una vez que entiendes la semántica del proveedor.

¿RPKI es obligatorio?

No es obligatorio, pero es una de las mejores mejoras de seguridad por hora de esfuerzo. Empieza validando y monitorizando; luego pasa a rechazar inválidos
cuando estés seguro de que tus propios ROAs son correctos.

¿Cuál es la forma más simple de prevenir una fuga de rutas?

Allowlists de salida. Permite solo tus prefijos. Rechaza todo lo demás. No redistribuyas connected o IGP en eBGP a menos que esté filtrado a la misma allowlist.

¿Por qué la conmutación entrante a veces dura minutos?

Porque el ruteo entrante depende de lo que el resto de Internet cree. La propagación por retiro, dampening y cacheo remoto existen.
Puedes influir con comunidades, anuncios más específicos y buenas elecciones de upstreams, pero no puedes forzar convergencia global instantánea.

¿Cómo sé si el problema es mi borde o mi upstream?

Compara plano de control vs plano de datos. Si las sesiones son estables y tus anuncios son correctos, pero hay pérdida de paquetes o picos de latencia,
revisa estadísticas de interfaz, MTU y calidad del camino upstream. Si puedes conmutar a un segundo upstream y el problema desaparece, probablemente es específico del upstream.

¿Debería ejecutar iBGP entre dos routers de borde?

Si ambos originan los mismos prefijos y quieres selección de salida coordinada, sí—mantenlo mínimo y explícito.
Si tu red es ínfima y puedes operar con defaults independientes, puedes evitar iBGP, pero entiende las compensaciones.

Conclusión: siguientes pasos que no te harán daño

La configuración mínima segura de BGP no trata de ingenio. Trata de contención: allowlists explícitas, filtros de entrada estrictos, límites sensatos
y la observabilidad suficiente para detectar errores antes que tu upstream.

Pasos prácticos siguientes:

1. Escribe tus anuncios previstos (prefijos exactos) y trata esa lista como código de producción.
2. Decide solo-default vs tabla completa y dimensiona tu router en consecuencia—las limitaciones de hardware son limitaciones de política.
3. Implementa allowlists de salida y filtros de entrada (bogons, longitudes máximas y max-prefix).
4. Habilita validación RPKI, valida tus propios ROAs y elige una política deliberada para invalid/notfound.
5. Incluye el bucle rápido de diagnóstico en tu monitorización: estado de sesiones, recuentos de prefijos, drops de interfaz y alcanzabilidad externa.

Si quieres hacer ingeniería de tráfico después de eso, está bien. Gánatelo. Primero asegúrate de que tu red no pueda accidentalmente convertirse en proveedor de tránsito
un martes.