0,5 - Troubleshooting

Reset de sesiones: hard vs soft

Tras cambiar cualquier política (route-map, filtro, atributo), el cambio no aplica a las rutas ya intercambiadas hasta refrescar la sesión.

Hard reset (disruptivo, evitar en producción)

R1# clear ip bgp *
R1# clear ip bgp <ip-peer>

Tumba la sesión por completo y la reconstruye desde Idle. Se pierden todas las rutas del vecino durante la reconstrucción.

Soft reset vía route refresh (el preferido)

R1# clear ip bgp <ip-peer> soft in
R1# clear ip bgp <ip-peer> soft out
R1# clear ip bgp * soft

Reaplica las políticas sin tumbar la sesión. soft in reprocesa lo entrante (pide al vecino reenviar sus rutas vía route refresh); soft out reanuncia lo saliente con la política nueva. Requiere que ambos peers soporten route refresh (negociado en el Open; hoy es casi universal).

Soft reconfiguration inbound (alternativa cuando no hay route refresh)

R1(config-router)# neighbor <ip-peer> soft-reconfiguration inbound

Guarda una copia local de todas las rutas recibidas sin filtrar, para reaplicar políticas sin molestar al vecino. Cuesta memoria extra; hoy se prefiere route refresh.

Diagnóstico por estado de la FSM

El estado en show ip bgp summary indica dónde está el problema:

Estado	Problema probable	Qué revisar
Idle	BGP no puede arrancar	Ruta al peer, neighbor bien configurado, no shut
Active / Connect (flapping)	Problema de TCP	Puerto 179 filtrado, ruta faltante, alcanzabilidad de la IP del neighbor
OpenSent / OpenConfirm	Discrepancia de parámetros	Versión, número de AS, autenticación, holdtime
Established	Sesión OK	El problema (si hay) es de política o de rutas, no de sesión

Problemas comunes y su causa

Sesión no levanta (queda en Idle/Active):

• Falta ruta hacia la IP del neighbor (o hacia su loopback si es peering por loopback).
• Source IP no coincide con lo que el peer espera → falta update-source.
• eBGP a más de un salto sin ebgp-multihop.
• eBGP por loopback a un salto sin disable-connected-check.
• Autenticación con clave que no coincide.

Prueba de reachability para sesiones por loopback:

R1# ping <ip-loopback-peer> source loopback <número>

Si el ping normal funciona pero este falla, el problema es la ruta de retorno hacia tu loopback.

Ruta aprendida pero no instalada en la tabla de routing:

• Next-hop inalcanzable (falta next-hop-self en el border router, o el next-hop externo no está en el IGP). Es la causa más común en iBGP.
• Synchronization activada (legacy) reteniendo la ruta hasta que el IGP la tenga.

Ruta no se propaga a peers iBGP:

• Regla de split-horizon iBGP (falta full-mesh, route reflector o confederation).

Ruta no se anuncia con el comando network:

• El prefijo no existe exacto en la tabla de routing (recordar el exact match de network).

Synchronization (legacy)

Activar/desactivar la sincronización

R1(config-router)# synchronization
R1(config-router)# no synchronization

Desactivada por defecto en IOS moderno. Si una ruta iBGP válida no se instala sin razón aparente, verificar si está activada es un paso de diagnóstico clásico.

Comandos de debug

Ver eventos y cambios de estado de BGP

R1# debug ip bgp

Ver keepalives en tiempo real (confirmar que la sesión se mantiene)

R1# debug ip bgp keepalives

Ver el intercambio de updates (prefijos entrando/saliendo)

R1# debug ip bgp updates

Cuidado con debug en producción

Los comandos debug consumen CPU y pueden saturar la consola en un router con muchas sesiones o mucha actividad. Usarlos con precaución en equipos productivos, y desactivarlos con undebug all (o u all) al terminar.

Verificación de reset y refresh

Confirmar que la sesión sigue arriba tras un soft reset

R1# show ip bgp summary

El uptime del vecino no debe reiniciarse con un soft reset (a diferencia del hard reset, que lo pone en 0). Si el uptime se reinició, hiciste un hard reset por error.