Troubleshooting de aplicaciones

Resumen

Esta nota recorre los síntomas más comunes de una aplicación publicada en BIG-IP —no carga, resetea, pierde la sesión, devuelve un error HTTP, certificado inválido— y para cada uno indica qué revisar y cómo arreglarlo. Usa el método de Troubleshooting Toolkit (F5) y empieza siempre por lo más simple.

Requisitos previos

• IP del cliente, VIP, URL y hora del problema
• Acceso a la GUI y a bash del BIG-IP
• Acceso a los logs del servidor web (o a su equipo)

Conceptos clave

Código HTTP	Significado	Quién suele generarlo
100	Continue	Servidor
200	OK	Servidor
301 / 302	Redirección (302 = fallback host)	Servidor o BIG-IP
304	Not Modified (usa tu caché)	Servidor o caché del BIG-IP
401 / 403	Requiere autenticación / prohibido	Servidor, APM o WAF
404	No encontrado	Servidor
405	Método no permitido (ej. subir a un sitio de solo lectura)	Servidor
500 / 502 / 503 / 504	Errores del servidor o de un proxy intermedio	Servidor (o BIG-IP si no hay miembros)
511	Network Authentication Required (portal cautivo)	Red

Flag TCP	Significado
FIN	Cierre ordenado: “terminé de enviar”
RST	Corte inmediato

Configuración (Ejemplo, Lab CBT Nuggets)

1. Ver el código HTTP real

curl -v http://172.16.101.20/
curl -v http://10.10.101.101/

Compara la respuesta a través del VIP con la respuesta directa del servidor: si difieren, el cambio lo introduce el BIG-IP (iRule, policy, fallback, WAF).

2. Ver el HTTP en Wireshark

Captura y filtra por http en Wireshark:

tcpdump -ni 0.0:nnnp -s0 -w /var/tmp/http.pcap host 172.16.101.5

En Wireshark: http.response.code >= 400, tcp.flags.reset == 1, tcp.analysis.retransmission.

Verificación

Comando o lugar	Qué debes ver	Si no lo ves
curl -v al VIP	Código 200 y el contenido esperado	Ver Errores comunes
curl -v directo al servidor	Lo mismo	Problema de la aplicación, no del BIG-IP
Network Map	VS y miembros 🟢	Revisa monitores
tmsh show /net rst-cause	Ningún contador creciendo	Revisa la causa

Errores comunes

La página no carga y el pool está verde

• Causa: el retorno no pasa por el BIG-IP (sin SNAT y servidores con otro gateway).
• Revisa: captura en internal: llega el SYN al servidor pero el SYN-ACK no vuelve.
• Solución: SNAT Auto Map o floating IP como gateway (SNAT, NAT y X-Forwarded-For).

El VS está verde pero los usuarios reciben resets

• Causa: límite de conexiones, iRule con reject, error TCL, handshake SSL fallido, combinación de perfiles inválida.
• Revisa: tmsh show /net rst-cause, /var/log/ltm.
• Solución: corrige según la causa que crece.

Los usuarios pierden la sesión al azar

• Causa: persistencia ausente o vencida, cookie bloqueada, failover sin mirroring, miembro que cae.
• Revisa: registros de persistencia, timeout, logs de monitores.
• Solución: ajusta la persistencia (Persistence).

503 / la página de mantenimiento aparece para todos

• Causa: ningún miembro disponible (actúa el fallback host o BIG-IP responde sin servidor).
• Revisa: Network Map y grep "monitor status down" /var/log/ltm.
• Solución: recupera los servidores o corrige el monitor.

Certificado inválido en algunos clientes

• Causa: falta la cadena intermedia, certificado vencido o SNI incorrecto.
• Revisa: openssl s_client -showcerts -servername <sitio>.
• Solución: Certificados y Client SSL.

Ping al servidor funciona pero el sitio no

• Causa: ICMP permitido pero el puerto filtrado, servicio caído o problema en la aplicación.
• Revisa: nc -vz <servidor> 80, curl -v.
• Solución: abre el puerto o levanta el servicio; empieza siempre por lo más simple.

Las peticiones encadenadas (pipelining) fallan a veces

• Causa: cualquier participante (cliente, servidor, proxy) puede cerrar la conexión TCP en cualquier momento; las peticiones pendientes se pierden.
• Solución: el cliente debe reintentar; revisa los idle timeouts de los perfiles TCP/HTTP.

Un cliente cae en el virtual server equivocado

• Causa: otro VS más específico coincide (Destino → Origen → Puerto).
• Solución: revisa tmsh list ltm virtual destination.