Kassinipedia

Troubleshooting Toolkit (F5)

Se lee en 3 min

Troubleshooting Toolkit (F5)

Resumen

Cuando “la aplicación no funciona”, lo importante es tener un método, no memorizar comandos. Primero se acota el problema (¿a quién le pasa? ¿desde cuándo? ¿qué cambió?), luego se sigue el camino del tráfico: ¿llega al virtual server? ¿el pool está sano? ¿la respuesta vuelve por el BIG-IP? Esta nota reúne las herramientas de BIG-IP para cada paso: estadísticas, tabla de conexiones, causas de reset, logs, tcpdump, pruebas con curl/openssl y QKview.

Requisitos previos

  • Acceso SSH al BIG-IP como usuario con bash
  • Datos del problema: IP del cliente, VIP, hora exacta, mensaje de error
  • Espacio en /var/tmp para capturas

Método en 6 preguntas

  1. ¿A quién le pasa? Un usuario, una red, todos. ¿Una app o todas?
  2. ¿Llega el tráfico al VS? Contadores del VS y tabla de conexiones.
  3. ¿Hay miembros disponibles? Network Map, monitores, /var/log/ltm.
  4. ¿El servidor responde y vuelve por el BIG-IP? SNAT, gateway, tcpdump en internal.
  5. ¿Algo cambia el camino? Persistencia, iRules, policies.
  6. ¿Hay límites o recursos agotados? Connection limit, CPU, memoria, disco.

Configuración y uso (Ejemplo, Lab CBT Nuggets)

1. Estado general

Local Traffic > Network Map (VS, pools y miembros con sus íconos).

tmsh show ltm virtual VS-172.16.101.20-HTTP-APP1
tmsh show ltm pool HTTP_APP1_Pool members

2. Tabla de conexiones

tmsh show /sys connection
tmsh show /sys connection cs-client-addr 172.16.101.5
tmsh show /sys connection cs-server-addr 172.16.101.20

Cada entrada muestra lado cliente (cliente → VIP) y lado servidor (IP SNAT → miembro).

3. Por qué el BIG-IP envió un reset

tmsh show /net rst-cause

Causas típicas: Connection limit exceeded, No pool member available, Port denied, No flow found for ACK, RST from BIG-IP internal Linux host.

4. Logs

tail -f /var/log/ltm
grep -i "limit" /var/log/ltm
grep -i "monitor status down" /var/log/ltm
tail /var/log/secure

5. Probar desde el BIG-IP hacia los servidores

curl -v http://10.10.101.101/
curl -vk https://172.16.101.20/
openssl s_client -connect 172.16.101.20:443 -servername www.f5lab.int -showcerts
nc -vz 10.10.101.101 80

6. Captura de paquetes

Lado cliente y lado servidor a la vez (la p incluye el flujo del otro lado):

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

Más opciones en tcpdump - Captura de paquetes.

7. Recursos

tmsh show sys performance system
tmsh show sys memory
top
df -h

8. QKview para soporte

tmsh run /util qkview

Súbelo a ihealth.f5.com o adjúntalo al caso en my.f5.com con la captura y la línea de tiempo.

Verificación

Comando o lugarQué debes verSi no lo ves
Contadores del VSTotal Connections sube al probarEl tráfico no llega: DNS, routing, ARP, firewall previo
tmsh show /sys connectionEntrada con lado servidorNo se eligió miembro: pool caído o iRule
Captura en internalSYN y SYN-ACK con el miembroEl servidor no responde o responde por otro camino
tmsh show /net rst-causeContadores sin crecerRevisa la causa que sube

Errores comunes

El ping al VIP funciona pero la web no

  • Causa: ICMP lo responde la virtual address; el servicio falla.
  • Revisa: pool, puerto, SSL y el retorno (SNAT/gateway).

La captura sale vacía

  • Causa: interfaz/VLAN equivocada, filtro demasiado estricto o tráfico acelerado por PVA (FastL4).
  • Solución: usa -i 0.0, afloja el filtro, desactiva temporalmente la aceleración.

El BIG-IP se pone lento al capturar

  • Causa: tcpdump consume CPU y disco.
  • Solución: filtra por host/puerto, limita con -c y guarda en /var/tmp.

No encuentro el mensaje en los logs

  • Causa: nivel de log bajo o el evento es de otro módulo.
  • Solución: revisa /var/log/ltm, /var/log/messages y sube temporalmente el nivel del servicio.

Retroenlaces