About
 |
 |
Todas las pruebas de diagnóstico de problemas en la red debe realizarse bajo las siguientes condiciones:
En el diagnóstico y resolución de fallas es imperante evitar las siguientes prácticas:
Es importante entender y valorar la diferencia entre un enlace punto a punto (multi-punto) e Internet para evitar confusión en la ejecución de prueba e interpretación de sus resultados.
En el caso de enlaces punto a punto (e.g. Ethernet) y multi-punto (e.g. MPLS/VPLS) los nodos de las rutas de tránsito con configurados y controlados por el Carrier(s) que han acordado una calidad de servicio (QoS) específica por cliente, incluyendo el origen y/o el destino son controlador por un proveedor y un consumidor (cliente) o por ambos de forma conjunta (certificada).
Por ejemplo, para enlaces punto a punto podremos iniciar y controlar aplicativos en el origen y destino, para certificar la cantidad de ancho de banda disponibles.
En Internet cada nodo de la ruta de tránsito, el origen y el destino, generalmente son contralados por por entidades independientes desde el punto de vista de calidad de servicio (QoS), la garantía que erróneamente confunden los clientes existe en la última milla porque este si es un enlace dedicado (no hay o es impercetible la sobresubcripción).
Esta política democrática es la razones de que cualquier persona sin importar la cantidad de recursos que tenga disponibles pueda conectarse a Internet, para consumir o servir contenido sin restricción alguna.
Para el caso de Internet, se han ido estableciendo puntos neutros de destino, en los principales puntos (centros de datos) que ofrecen acceso y tránsito (convergencia) en Internet. Estos puntos neutros (servidores) cuentan con recursos de red estándarizados y quasi-libres de ruido (carga) desde el punto de vista de consumo de ancho de banda, latencia y congestión.
Gracias a estos permiten determinar las mejores rutas en función de los valores de ancho de banda, tasa de transferencia, congestión, latencia y otros valores importantes en Internet.
Con respecto, a la rutas es importante conocer las rutas de acceso a contenido público (Internet):
Así mismo, es importante diferenciar los puntos de presencia (PoP) de centros de datos y los puntos de presencia (PoP) de Carriers, estos últimos son los puntos neurales de acceso a Internet ofrecidos por los Carriers desde el punto de vista de los centros de datos.
A continuación un listado de puntos neutros que pueden ser utilizados para establecer (triangular) mediciones de la calidad del servicio de acceso a Internet, es importante realizar las pruebas siempre con EL MISMO PUNTO MÁS CERCANO a su localidad, (Venezuela) entendiendo del principio de neutralidad de Internet con respecto a la calidad de servicio (QoS).
Para la certificación de la latencia (retardo), jitter (delta de latencia), rutas y alcanzabilidad de destinos, es importante utilizar MTR (http://winmtr.net/).
MTR utiliza una combinación de PING y TRACEROUTE mejorada con respecto a uso de estos de ambos separado, especialmente porque realiza pruebas estádisticas, acumulativas y variables sobre todos los nodos alcanzables de la ruta, aunque algunos no admitan consultas ICMP (https://www.linode.com/docs/networking/diagnostics/diagnosing-network-issues-with-mtr).
Dado que PING y TRACEROUTE están basados en el protocolo ICMP basado en el protocolo no orientado a conexión UDP, éste último asociado a ataques de denegación de servicio (DDoS), es importante evitar pruebas con escenarios de comportamientos anormales de red, por ejemplo:
Por una parte, estas pruebas serían viables entre dos equipos cercanos en una red LAN de baja latencia (0.0XX milisegundos y menos de 1 KM de distancia), pero no tiene sentido en una red WAN o en Internet con múltiples saltos conmutados o enrutados separados por decenas, cientos o miles de kilómetros.
Por otra parte, estas pruebas anormales suelen disparar umbrales de contención (throttling) en el sistema operativo de la mayoría de equipos de red con funcionalidades básicas de seguridad y no son idóneas para certificar el correcto funcionamiento de la red en su estado normal o durante una situación normal de estrés o congestión.
Ejemplo de comandos (Linux) a ejecutar en el origen/destino:
ping -c10 192.168.130.2
ping -f -c100 192.168.130.2 (Inundación)
mtr --no-dns -c 3 -r 192.168.130.2
traceroute 192.168.130.2NOTA: Nunca subestime ni tampoco sobre-estime el valor de una prueba de PING/TRACEROUTE, recueden son referenciales no absolutas, especialmente porque solo están probando protocolo UDP/IP no TCP/IP.
Opcionalmente, en caso que se estén realizando pruebas en una red local (LAN) o extensión de red (MetroLAN), es importante verificar *casting: unicast, broadcast y multicast.
Conviene realizar pruebas de resolución ARP con PING (Unicast), para determinar la integralidad de la ubicación de equipos dentro de una misma LAN partiendo de la dirección. El comando a utilizar sería:
Finalmente, conviene realizar pruebas de difusión (broadcast) bajo protocolo UDP:
ping -c <cantidad> -f -b <ip-broadcast> (La dirección "ip-broadcast" específica de la red, y en su defecto, 255.255.255.255).NOTA: El broadcast puede ser bloqueado por equipos de seguridad (Capa 3 OSI) u otros límites de protección pre-establecidos en equipos de conmutación o enrutamiento (Capa 2/3 OSI).
Para certificación del desempeño (ancho de banda) es importante utilizar iperf (https://iperf.fr / software libre) y WAN Killer (www.solarwinds.com / comercial).
Es importante acotar que la diferencia entre ambas herramientas y otras similares, es el uso y pericia con que se dé el uso de las mismas.
Iperf (siempre) debería utilizarse instanciando un cliente y un servidor, porque es importante confirmar que datos de la prueba se reciben, en cualquier otro caso de uso unidireccional (inundación) no se tiene una visión completa cuantificable de la realidad, en caso de pérdida de datos.
En su defecto, y solo para el caso de Internet es mejor utilizar herramientas de descarga de archivos (véase más adelante en este documento).
iperf permite realizar pruebas bidireccionales, en tiempo real y con certificación de recepción de datos, por esta razón debe estar activo tanto en el origen como en el destino simultáneamente. iperf evita cometer el error de enviar ráfagas de paquetes para saturar, de lo cual sólo se obtienen resultados aleatorios no concluyentes e inclusive más confusos.
Los reportes de iperf permite más claramente detectar comportamiento anormales en:
Ejemplos de comandos (Linux) a ejecutar en el origen/destino como servidor (10.0.30.99):
**TCP**
iperf -s -i 1
**UDP**
iperf -s -u -i 1
# UDP/Multicast
iperf -s -u -i 1 -B 224.4.4.4Ejemplos de comandos (Linux) a ejecutar en el origen/destino como cliente (10.0.30.100):
# TCP
iperf -i 1 -m -c 10.0.30.99
iperf -i 1 -m -c 10.0.30.99 -d
iperf -i 1 -m -c 10.0.30.99 -r
iperf -i 1 -m -c 10.0.30.99 -P 2
iperf -i 1 -m -c 10.0.30.99 -P 2 -d
iperf -i 1 -m -c 10.0.30.99 -P 2 -rNOTA: Las opciones -d y -r activar transferencia bidireccional de forma simultánea e individual, respectivamente.
# UDP
iperf -i 1 -m -c 10.0.30.99 -u
iperf -i 1 -m -c 10.0.30.99 -u -b 10m
iperf -i 1 -m -c 10.0.30.99 -u -b 100m
iperf -i 1 -m -c 10.0.30.99 -u -b 1g
NOTA: La opción -b solo aplica para pruebas de tráfico UDP
# UDP/Multicast
iperf -i 1 -m -c 224.4.4.4 -u --ttl 5 -t 5Se pueden realizar transferencias de archivos con (https://filezilla-project.org/):
En el origen antes de iniciar y en el destino al finalizar la transferencia se debe calcular la firma de digital del archivo, con la se puede verificar si hubo errores de transmisión Capa 4 - 5 OSI, es factible utilizar cualquier algoritmo de Hash (http://www.nirsoft.net/utils/hash_my_files.html).
En el caso de Windows se puede utilizar el Download Speed Tester http://www.nirsoft.net/utils/download_speed_tester.html o cualquier gestor de descargas confiable.
Ejemplos de comandos (Linux) a ejecutar en el origen:
# Crear archivo de 1 MegaByte
dd if=/dev/zero of=f1.dummy bs=1M count=1
# Crear archivo de 10 MegaBytes
dd if=/dev/zero of=f10.dummy bs=1M count=10
# Crear archivo de 100 MegaBytes
dd if=/dev/zero of=f100.dummy bs=1M count=100
# Verificar firma md5sum (origen/destino)
md5sum *.dummy
2f282b84e7e608d5852449ed940bfc51 f100.dummy
f1c9645dbc14efddc7d8a322685f26eb f10.dummy
b6d81b360a5672d80c27430f39153e2c f1.dummy
# Transferir archivo via SSH (SCP):
scp *.dummy root@10.0.30.99:~
# Descargar archivo via FTP/HTTP (wget):
wget http://www.google.com/download.iso (u otra URL local o en Internet)En escenarios de pérdida y retransmisión de paquetes en protocolos orientados a conexión (TCP) y no orientandos a conexión (UDP), es importante determinar el patrón de comportamiento de la red escuchando el canal de transporte, en función de encontrar un posible patrón de tráfico que identifique la anomalía.
Para esto se utiliza un capturador (sniffer) con analizador de protocolos (disector), tales como:
Estos permiten escuchar de forma promiscua una interfaz de red de un equipo Windows/Linux, y es aún especialmente más util si la interfaz está conectada a un puerto configurado en modo espejo (mirror), este último es conocido en Cisco como puerto SPAN (Switch Port Analyzer).
Algunos filtros inteligentes utiles para detectar pérdidas, retransmisiones, ciclos y congestión son:
tcp.analysis.retransmission
tcp.analysis.fast_retransmission
tcp.analysis.out_of_order
tcp.analysis.duplicate_ack
tcp.analysis.lost_segment
tcp.analysis.ack_lost_segmentLa aparición de paquetes de forma continua, regular, acelerada y cuantiosa (en relación con el total de paquetes capturados) coincidentes con los filtros anteriores puede ser un indicador de problemas en los equipos, partes, piezas y componentes asociados al segmento de red donde se realiza la captura. Sin embargo, para interpretarlos es importante el cruce de dichas capturas con el resto de las pruebas ejecutadas en tiempo real bajo juicio experto asertivo.
Los acuerdos de servicio (SLA) para servicios en redes IP (Ethernet) son los siguientes:
Caída de red: intervalo de tiempo durante el cual no puede pasar tráfico saliente o entrante a través de un punto de presencia (PoP) selecionado en una porción de la red del Carrier.
Latencia: es el tiempo promedio requerido de la transferencia de paquetes de ida y vuelta (RTT: Round Trip Time) entre en puntos de presencia (PoP) seleccionados en una porción de la red del Carrier.
Pérdida de Paquetes: es el promedio del porcentaje de paquetes IP transmitidos y que no fueron exitósamente entregados entre puntos de presencia (PoP) seleccionados en una porción de la red del Carrier.
Jitter: es el promedio de la variación del retraso para la transferencia de paquetes entre puntos de presencia (PoP) seleccionados en una porción de la red del Carrier.
Estos valores son medidos generalmente durante un mes de calendario dependiendo del medio (cableado o aereo).
En el backbone de los Estados Unidos (2016) los valores aceptables definidos para cumplir con el acuerdo de servicio (SLA) son generalmente:
Updated: 2016/09/01
|
|
