Kassinipedia

IP SLA - Troubleshooting

Se lee en 4 min

IP SLA - Troubleshooting

Método general (de lo mínimo a lo complejo)

  1. ¿La operación está programada? Sin ip sla schedule corre nada (show ip sla configuration).
  2. ¿El probe responde? show ip sla statistics → return code.
  3. ¿El track refleja el resultado? show track.
  4. ¿La ruta reacciona al track? show ip route.
  5. Recuerda el orden: operación definida, operación programada, track que la observa, y ruta atada al track.

Comando base:

Router# show ip sla statistics
Router# show track

Caso 1 — La operación no corre (sin estadísticas)

Síntoma: show ip sla statistics no muestra éxitos ni fallos, o la operación parece inactiva.

Causa: falta programar la operación con ip sla schedule.

Diagnóstico:

Router# show ip sla configuration 1    ! ¿tiene schedule / start time?

Solución:

Router(config)# ip sla schedule 1 life forever start-time now

Caso 2 — El probe siempre falla (return code Timeout)

Síntoma: show ip sla statistics muestra return code: Timeout y los fallos suben, aunque el destino debería responder.

Causas:

  • El destino no es alcanzable desde el router (no hay ruta hacia él, o él no tiene ruta de regreso).
  • Un ACL o firewall bloquea el ICMP del probe.
  • El source-ip/source-interface elegido no tiene camino de retorno.

Diagnóstico:

Router# ping 172.16.10.3
Router# show ip sla statistics 1
Router# show access-lists

Solución: asegurar alcanzabilidad y retorno del ICMP. Si se usa origen específico, que esa IP sea enrutable de vuelta.

Router(config-ip-sla)# icmp-echo 172.16.10.3 source-ip 10.10.10.1

Caso 3 — El probe responde pero el track no cambia

Síntoma: show ip sla statistics dice OK, pero show track sigue Down (o al revés).

Causa: el objeto de tracking apunta a otra operación, o al tipo equivocado.

Diagnóstico:

Router# show track 20        ! ¿referencia "ip sla 1 reachability"?

Solución: que el track apunte al número correcto de IP SLA y a reachability.

Router(config)# track 20 ip sla 1 reachability

Caso 4 — El track cambia pero la ruta no reacciona

Síntoma: show track sube/baja correctamente, pero la ruta estática siempre está (o nunca está) en la tabla.

Causa: la ruta no fue atada al track, o se ató a otro número de track.

Diagnóstico:

Router# show ip route
Router# show running-config | include ip route

Solución: volver a crear la ruta con la cláusula track correcta.

Router(config)# ip route 0.0.0.0 0.0.0.0 10.10.20.1 track 20

Caso 5 — El failover no ocurre (no entra la ruta de respaldo)

Síntoma: el track baja y la ruta primaria se retira, pero el tráfico no pasa al respaldo.

Causas:

  • No existe ruta de respaldo, o su distancia administrativa está mal (debe ser mayor que la primaria para ser flotante).
  • La ruta de respaldo apunta a un salto que tampoco es alcanzable.

Diagnóstico:

Router# show ip route
Router# show running-config | include ip route

Solución: definir la ruta flotante con AD mayor y un salto válido.

Router(config)# ip route 0.0.0.0 0.0.0.0 10.10.10.1 10

Caso 6 — El enlace “aletea” (el track cambia constantemente)

Síntoma: show track muestra muchos changes; la ruta entra y sale sin parar.

Causa: el destino responde de forma intermitente y el frequency/timeout es muy agresivo, o hay pérdida de paquetes real.

Diagnóstico:

Router# show ip sla statistics 1     ! relación successes/failures
Router# show track 20                ! número de changes

Solución: subir el timeout/frequency para tolerar pérdidas breves, o aplicar retardo en el track para que no reaccione a picos.

Router(config-ip-sla)# frequency 15
Router(config-ip-sla)# timeout 3000
Router(config)# track 20 ip sla 1 reachability
Router(config-track)# delay up 10 down 20

Recuerda el orden: operación programada (schedule), probe respondiendo (return code OK), track observando la operación correcta, ruta atada al track, y ruta de respaldo flotante con AD mayor. Para inestabilidad, ajusta frequency/timeout o delay del track.

Vista Gráfica

Retroenlaces