Cuando un servicio empieza a ir lento, un API devuelve timeouts o un cliente jura que “Internet va mal”, muchos equipos de sistemas siguen mirando solo a su propio lado: gráficas internas, logs de firewall, traceroute desde el CPD o desde la oficina. Útil, sí, pero incompleto.
Para saber de verdad qué está pasando en la red, hace falta un punto de vista externo. Ahí es donde entra ping.pe, una herramienta web gratuita que se ha convertido, casi sin querer, en un pequeño “NOC distribuido” para administradores de sistemas y de red.
Este artículo repasa cómo sacar partido a ping.pe en el día a día de un sysadmin: desde validar incidencias con proveedores hasta documentar problemas de routing o paquet loss ante clientes y direcciones de TI.
¿Qué aporta ping.pe a un sysadmin que ya tiene ping, mtr y observabilidad?
La diferencia clave es el punto de vista.
Desde ping.pe se lanzan pruebas (ping, MTR, TCP, BGP, DNS…) desde decenas de ubicaciones distintas repartidas por el mundo, muchas de ellas conectadas a carriers Tier 1 o Tier 2. Eso permite:
- Ver si un problema afecta solo a una región o es global.
- Detectar si el cuello de botella está en el ISP del cliente, en el tránsito, en el propio DC o en el proveedor SaaS.
- Validar si los anuncios BGP de un prefijo se están propagando como deberían.
- Tener capturas objetivas para elevar un ticket a un carrier, cloud o CDN.
En lugar de discutir si “es cosa tuya o mía”, ping.pe da visibilidad neutral desde la red global.
Interfaz simple, comandos potentes
La interfaz web permite escribir consultas en formato “comando + sujeto”:
<COMANDO> <SUJETO>
Lenguaje del código: HTML, XML (xml)Donde el sujeto suele ser una IP, dominio o red CIDR. Si no se indica comando, por defecto se asume ping.
Ejemplos básicos:
example.com→ se ejecutaping example.com.ping 1.2.3.4→ ping + mtr (prueba completa).tcp example.com:443→ prueba de acceso al puerto 443.
Para los sysadmins, lo interesante es que combina varias tareas típicas (ping, traceroute, BGP, DNS…) en un único panel con múltiples orígenes.
Comandos clave que un sysadmin debería dominar
1. ping – prueba completa de conectividad (ping + MTR)
ping example.com
ping 1.2.3.4
Lenguaje del código: CSS (css)Ejecuta un ping y un mtr desde varios nodos:
- Latencias mínima, media y máxima.
- Porcentaje de pérdida de paquetes.
- Ruta completa (hops) hasta el destino.
Útil para:
- Ver desde qué regiones empieza la degradación.
- Distinguir pérdida en el último tramo (cerca del destino) frente a problemas en tránsito intermedio.
- Comparar comportamiento IPv4/IPv6 (usando
ping6cuando sea necesario).
2. mtr – centrado en rutas y saltos
mtr example.com
mtr 8.8.8.8
Lenguaje del código: CSS (css)Cuando lo que interesa es la topología de ruta más que la latencia fina, mtr muestra los hops y dónde se produce la pérdida o la dispersión de tiempos.
Escenario típico:
un cliente en cierta región se queja; desde el CPD todo parece bien, pero el mtr de ping.pe muestra que el problema está en uno de los carriers intermedios fuera de tu dominio.
3. chart – latencia en formato gráfico
chart example.com
chart 1.2.3.4
Lenguaje del código: CSS (css)Hace pings pero con gráficas de latencia, más cómodo para:
- Explicar a alguien no técnico que la conexión es inestable.
- Ver patrones de jitter.
- Hacer capturas para informes o tickets a terceros.
4. tcp / port – test de puertos desde fuera
tcp example.com:443
port 203.0.113.10:22
Lenguaje del código: CSS (css)Comprueba si un puerto TCP está accesible desde las ubicaciones de ping.pe. Muy útil para:
- Validar aperturas de firewall o cambios de security groups.
- Ver si un puerto está filtrado en algún punto del camino.
- Confirmar que un servicio recién desplegado es visible desde Internet.
Si no se especifica puerto, se asume el 80 por defecto.
5. dig – consultas DNS rápidas
dig example.com
dig example.com:AAAA
dig example.com:MX:1.1.1.1
Lenguaje del código: CSS (css)Permite hacer consultas DNS con soporte para tipos comunes (A, AAAA, CNAME, TXT, MX, NS, PTR, CAA) y seleccionar el resolver (por ejemplo, 8.8.8.8 o 1.1.1.1).
Casos de uso típicos:
- Ver si una actualización de DNS se ha propagado.
- Comparar la resolución entre distintos resolvers públicos.
- Comprobar registros PTR para IPs propias o de terceros.
6. bgp – tu pequeño looking glass BGP
bgp example.com
bgp 198.51.100.0/24
bgp 203.0.113.10
Muestra información BGP en tiempo real para dominios, IPs o redes. Para quienes gestionan prefijos propios o trabajan con varios carriers, esto ayuda a:
- Validar anuncios y rutas preferidas.
- Detectar problemas de propagación o hijacking.
- Documentar incidencias con capturas independientes.
URLs rápidas y flujo de trabajo en un NOC
Ping.pe también admite subdominios para indicar el comando, algo útil para compartir enlaces en un chat de equipo o en un ticket:
https://ping.pe/example.com→ping.https://chart.ping.pe/example.com→chart.https://tcp.ping.pe/example.com:443→tcp.https://dig.ping.pe/example.com→dig.
Ejemplo práctico de flujo para un sysadmin:
- Cliente reporta problemas con
api.ejemplo.com. - Se verifica desde el CPD: ping, curl, logs. Todo correcto.
- Se lanza
chart api.ejemplo.comen ping.pe y se comparte el enlace. - Se observa pérdida de paquetes desde ciertas regiones y se complementa con
mtr. - Con la evidencia, se abre ticket al carrier o al proveedor cloud afectado con las capturas de ping.pe.
Filosofía de diseño: pocos nodos, pero bien elegidos
El proyecto explica que su objetivo no es llenar el mapa de VPS baratos, sino trabajar con endpoints single-homed conectados a carriers Tier 1 o Tier 2. Esa elección aumenta el valor diagnóstico:
- Menos ruido de multihoming complejo.
- Rutas más representativas del tránsito IP real.
- Mejor visibilidad de problemas de propagación y congestión.
Para quien gestiona infraestructuras, esto se traduce en datos más útiles para discutir con proveedores de tránsito y grandes clouds.
Limitaciones y buenas prácticas para equipos de sistemas
Ping.pe es una herramienta de diagnóstico, no de estrés ni monitorización continua:
- No sustituye a un sistema de observabilidad interno, ni a tus propias sondas distribuidas.
- No está pensado para pruebas de carga ni DDoS “casero”.
- Las pruebas son ligeras y estándar (pings, traceroutes, conexiones TCP puntuales).
Su lugar natural es el de auxiliar externo cuando algo no cuadra:
- Validar si una incidencia es local, regional o global.
- Aportar datos independientes a conversaciones con proveedores.
- Documentar problemas intermitentes de routing o latencia.
Preguntas frecuentes para sysadmins
¿Tiene sentido usar ping.pe si ya tengo sondas propias y observabilidad distribuida?
Sí. Justamente por ser un tercero independiente, aporta valor para contrastar datos y adjuntar evidencias “neutrales” en tickets o informes. Además, sus nodos están conectados a carriers de alto nivel, lo que da otra perspectiva.
¿Puedo automatizar consultas a ping.pe desde scripts o herramientas internas?
La interfaz está pensada para uso interactivo vía web, pero las URLs por comando facilitan su integración básica (por ejemplo, abrir enlaces desde un panel interno o documentación de incidentes). Para monitorización continua es mejor usar tus propias sondas.
¿Genera mucho tráfico contra mis servidores si alguien los prueba en ping.pe?
No. Las pruebas son de diagnóstico estándar: pings, traceroutes y conexiones TCP puntuales. No está diseñado como herramienta de carga.
¿Es útil también para entornos sólo IPv6?
Sí. Existen variantes como ping6, mtr6, chart6 o tcp6 que fuerzan el uso de IPv6, lo que permite diagnosticar problemas específicos de ese stack.
En resumen, para cualquier medio orientado a administradores de sistemas y redes, ping.pe es una de esas utilidades que merece estar en la caja de herramientas: ligera, externa, independiente y tremendamente útil cuando la red se comporta de forma extraña y hay que demostrar, con datos, dónde está realmente el problema.
