Guía Rápida para la Evaluación de una red

utilizando Wireshark
Elaborada por: Eloy Espozo Espinoza

Introducción

Esta guía no pretende ser un manual del uso de Wireshark ni mucho menos del estudio y
análisis de tráfico, pero provee ciertas pautas y puntos a tomar en cuenta para una
correcta medición y estimación de parámetros de rendimiento de una red basándonos en
una captura de tráfico realizada en esa red.

Debe recordarse que para una mejor comprensión e interpretación de las trazas de una
captura se debe tener un conocimiento claro acerca de los diferentes protocolos de red
sobre los que se está trabajando, por ejemplo a lo largo de esta guía se utilizan los
protocolos Ethernet, IP, TCP, UDP e ICMP, por lo que su conocimiento sin duda es
beneficioso.

Así mismo se recomienda estar muy atento a cualquier evento que se observe en el
tráfico de red, ya que muchas veces éstos eventos pueden ser indicadores de algún
problema o anomalía en la red, por ejemplo, si se está evaluando una red donde
únicamente existen terminales o equipos de trabajo y no existe ningún equipo servidor,
pues el tráfico que se capture debiera reflejar este aspecto mostrando que las conexiones
salientes de la red debieran ser realizadas exclusivamente por las terminales de dicha red
y no debieran por ejemplo, verse conexiones nuevas hacia las terminales tal cual si éstas
fueran un servidor.

Los gráficos y ejemplos vistos en éste documento están trabajados sobre la captura de un
archivo de ejemplo llamado traza_500.pcap.

Establecimiento del entorno de red

Conocer el entorno de la red donde se está realizando la evaluación es muy importante ya

que nos brinda pautas para poder determinar más fácilmente los patrones de tráfico y/o
las fuentes y destinos de la información que circula por la red. Esto no significa que no se
pueda evaluar y establecer el estado y condiciones de la red si es que no se cuenta con
algún mapa o esquema de la red de forma previa a la evaluación.

Wireshark muestra en su pantalla principal todo el tráfico capturado sin distinciones, o

sea, que podremos observar todo el tráfico generado por todas las terminales que
realizaron alguna transmisión en el momento de la captura, entremezclados entre sí, por
lo que una de las primeras actividades que se deberán realizar es la de poder determinar
adecuadamente el entorno de red que se ha capturado; esta información nos permitirá
poder verificar si existió algún problema o tráfico indeseado en la captura.

Generalmente, este trabajo se hace utilizando como referencia el diagrama de direcciones

físicas de la institución, pero muchas veces éste documento no existe o es bastante
incompleto, en tales casos lo único que queda es tratar de obtener un entorno de red
aproximado en función a las capturas de tráfico realizadas
Una forma para hacer esto es, utilizando el menú Estadísticas > Extremos; éste menú nos
presenta la información de todos los equipos finales (extremos) que han emitido o recibido
tráfico de algún tipo y que han sido capturados por Wireshark, nótese que esta
información es presentada de varias formas de acuerdo a los distintos protocolos de red
observados, por lo que en el reporte aparece la misma captura pero presentando
diferentes datos.

Como puede verse en el anterior gráfico, los datos capturados reflejan la existencia de
varios protocolos, se pueden observar datos a nivel del protocolo Ethernet (Capa 2 del
modelo OSI), protocolos IP e IPX(capa 3 del modelo OSI) y protocolos TCP y UDP (capa
4 del modelo OSI); cada una de estas pestañas nos reporta la misma captura pero desde
el punto de vista del protocolo seleccionado.

Así, se tienen 14 extremos o equipos conectados en red que fueron vistos por el
capturador a nivel de la capa 2 del modelo OSI, de éstos se puede notar que la dirección
ff:ff:ff:ff:ff:ff es la dirección física de difusión lo que significa que no pertenece en realidad a
ningún equipo o terminal pero el resto si, esto nos permite inferir preliminarmente que
existen 13 equipos o terminales, esto se confirmará o rechazará con un análisis más
profundo.

Se puede observar también que a medida que vamos revisando los protocolos de capas
superiores del modelo OSI, la cantidad de extremos se va incrementando; esto es
correcto dado que un mismo equipo tiene una única dirección física (capa 2) pero puede
tener asociadas varias direcciones IP (capa 3) cada una de las cuales a su vez pueden
utilizarse para distintas sesiones denotadas por distintos números de puerto (capa 4).

Una vez determinados los nodos podemos hacer uso de la opción Estadísticas >
Conversaciones que nos presenta un reporte similar al reporte de extremos o nodos pero
esta vez se tiene una relación de las conexiones o conversaciones existentes entre
diferentes pares de nodos. Este gráfico es bastante útil puesto que nos permite establecer
la disposición aproximada de la red mostrándonos si un determinado nodo está en el
mismo segmento de red donde fue hecha la captura de tráfico o si es un nodo que
atraviesa dicho segmento pero no pertenece al mismo.
Por ejemplo el reporte anterior, nos muestra que entre los 14 nodos reconocidos
anteriormente, existen 13 conversaciones a nivel de Ethernet (capa 2) lo que significa que
únicamente 13 equipos o nodos conversan entre sí.

Podemos observar también que en realidad hay distintas comunicaciones entre un mismo
equipo (con MAC 00:04:ac:56:fa:c5) y el resto, también hay 4 equipos que se están
comunicando con la dirección de broadcast de capa 2.

Si asociamos las conversaciones a nivel de protocolo IP con las conversaciones a nivel de

protocolo Ethernet observaremos que a cada dirección MAC le corresponde una dirección
IP, pero que la dirección MAC 00:04:ac:56:fa:c5 está asociada con muchas direcciones IP
sin relación alguna entre sí, éste suceso se puede dar únicamente si:
 El equipo en cuestión soporta múltiples direcciones IP y ha sido configurado con cada
una de ellas
 El equipo sólo tiene una dirección IP pero sirve de puerta de enlace para varias
direcciones IP y/o subredes externas a la red evaluada
Claramente la segunda opción es la más factible y correcta, con lo cual ya podemos ir
definiendo la arquitectura o entorno de la red evaluada.

Así mismo, también se puede ir armando una tabla que contenga la cantidad de bytes
transmitidos/recibidos por cada nodo a partir de lo cual se puede obtener la tasa de
transferencia o throughput de cada flujo. En este sentido se debe observar que se pueden
obtener dos conjuntos de valores de throughput, un valor de thropughput relativo y otro
absoluto, el relativo, es un valor que está en función del tiempo de vida que tiene cada
flujo individual mientras que el throughput absoluto toma para todos los casos el tiempo
total de la captura, el segundo a diferencia del primero permite establecer relaciones entre
todos los flujos por lo que es el que se debe utilizar.
Determinación del tamaño de los flujos

Para determinar el tamaño de cada flujo que ocupa un enlace a partir una captura, se
debe primero determinar la cantidad de conexiones y conversaciones existentes,
basándonos en este dato además de tener los extremos de todos los flujos, se puede
tener una primera imagen acerca de la topología de la red.

Por ejemplo en el archivo de captura traza_500.pcap se tienen 48 conversaciones TCP y

5 conversaciones UDP, en cada caso Wireshark nos muestra el tamaño total enviado por
todos los flujos unidireccionales de cada una de las conversaciones, en base a este dato
procedemos a determinar el tamaño de cada archivo transmitido

Ejemplo

En el caso de la primera conversación UDP que se realiza entre los equipos con
direcciones IP 192.168.4.21(equipo A) y 190.129.73.10(equipo B), observamos que ésta
consta del intercambio de 2 paquetes, 1 en cada sentido; también podremos ver que el
paquete de A hacia B tiene un tamaño de 86 bytes de los cuales si quitamos los 42 bytes
de todas las cabeceras utilizadas en este paquete, 14 bytes de la cabecera Ethernet, 20
bytes de la cabecera IP y 8 bytes de la cabecera UDP, obtenemos el tamaño de la data
que es 44 bytes; mientras en el flujo opuesto, podemos observar que el tamaño de la data
en el paquete es de 253 bytes, lo que se puede verificar observando cada uno de los
paquetes que forman parte de esta conversación.
En el caso de conversaciones TCP se debe evaluar cada flujo unidireccional que forma
parte de la conversación, por ejemplo en el caso de una de las conversaciones entre
192.168.4.17 y 216.73.86.152:

ip.addr==192.168.4.17 && tcp.port==1669 && ip.addr==216.73.86.152 &&

tcp.port==80

Se tiene que el flujo de 192.168.4.17 hacia 216.73.86.152 presenta 5 paquetes con un

total de 805 bytes y 3 paquetes con 461 bytes en sentido opuesto.

Se puede observar también que el equipo 192.168.4.17 es el cliente y el equipo

216.73.86.152 es un servidor web. Se debe recordar que una conversación TCP primero
establece un intercambio de paquetes de sincronismo (saludo de tres vías) iniciado por el
cliente que no contienen data y para finalizar la transmisión se transmiten también
paquetes adicionales para finalizar la conversación que generalmente tampoco contienen
data.

Del primer flujo se puede observar que el tamaño de la información que se está
transmitiendo es de 509 bytes de data (MSS), y que sólo se está utilizando un paquete
para transmitir esta información, los restantes 4 paquetes son parte de los paquetes de
sincronismo y finalización, en total existen 296 bytes repartidos en los 5 paquetes que
representan la sobrecarga total del flujo. De estos 296 bytes 54 bytes corresponden a la
cabecera del paquete que contiene la data, y 242 bytes a las cabeceras de los paquetes
de sincronismo y finalización.

El flujo opuesto al igual que el anterior presenta 291 bytes de data (MSS) y 170 bytes de
sobrecarga repartidos en 3 paquetes de los que 2 son parte del sincronismo y finalización
de la conversación. De éstos el paquete que contiene data presenta una cabecera de 54
bytes y los restantes 116 bytes se reparten en los paquetes adicionales.

Se puede concluir diciendo que en toda conversación TCP se deben agregar 54 bytes a
cada paquete que contiene data y luego agregar 4 paquetes con un total de 242 bytes o 2
paquetes con 116 bytes respectivamente dependiendo si el flujo es el originado por el
cliente o el originado por el servidor. Sin embargo esto en la realidad sólo debe ser
tomado como un valor referencial ya que TCP va modificando el tamaño de MSS de
acuerdo a la congestión que va detectando en la transmisión.

Determinación de la latencia

Para poder estimar los tiempos de latencia de un enlace determinado, lo más

recomendable es utilizar las herramientas de red básicas como ping y traceroute (tracert)
que generan paquetes de prueba y miden los tiempos de respuesta de los mismos, cuya
finalidad es justamente establecer reportes estadísticos.

Ping

En el archivo icmps.pcap podemos observar que se tiene intentos de conexión con varias
redes
éste archivo contiene la captura de tráfico de la aplicación ping entre dos equipos
(192.168.20.20 y 192.168.10.15), el comando que se utilizó desde 192.168.20.20 fue:

ping 192.168.10.15

y la respuesta que se obtuvo al cortar la aplicación ping fue:

Se ha filtrado todo el tráfico correspondiente a los equipos origen y destino donde se está
utilizando el programa ping, el filtro es:

ip.addr eq 192.168.20.20 and ip.addr eq 192.168.10.15

Con este filtro y acomodando el tiempo para observar el tiempo relativo al último paquete
visualizado (Vista->Formato de tiempo) se puede observar la siguiente traza

En esta traza podemos observar que se reflejan casi en su totalidad los valores
presentados por la misma aplicación ping, sin embargo existen algunas diferencias que
merecen ser destacadas, así mismo se puede obtener otros datos a partir de la traza
capturada

 El tiempo de envío de mensajes ICMP echo request (tipo 8) son mayores a los
mensajes de vuelta ICMP echo reply (tipo 0), ésto nos indica que el enlace que se está
utilizando es asimétrico o que se tienen algunos problemas sobre todo en el enlace de
transmisión
 Sin embargo, si suponemos que se tiene un enlace simétrico entre los puntos de
medición, lo que puede explicar la diferencia de tiempos entre la transmisión y la
recepción es la existencia de otros paquetes de datos que van congestionando el
enlace.
 El tiempo visualizado por la aplicación ping muestra el tiempo desde el envío del
mensaje de petición hasta la recepción del mensaje de eco, pero se puede observar
que la aplicación adiciona 0.024 ms a todos los mensajes recibidos, éste valor es el
valor de latencia de procesamiento lo que nos indica claramente que en realidad lo
que estamos observando es el tiempo de respuesta o latencia totales al igual que nos
permite determinar la latencia de cable real

Obtención del valor de Round-Trip Time en TCP

El valor de RTT es fundamental para una conexión TCP, pero se debe recordar siempre
que es un valor que puede cambiar constantemente debido al tráfico existente en la red,
cambios en las rutas activas, etc.; TCP miden el RTT entre el envío de un byte con un
número de secuencia particular y la recepción de la confirmación (ACK) que cubra a ese
valor de secuencia.

Por ejemplo en la traza llamada traza_500.pcap si aislamos cualquier conexión TCP, por
ejemplo la conexión HTTP existente entre los equipos 192.168.4.17 y 216.73.86.152 ,
aplicando el filtro:

ip.addr==192.168.4.17 && tcp.port==1669 && ip.addr==216.73.86.152 &&

tcp.port==80

Si se cambia el formato de visualización de tiempo de forma que se observe el tiempo

delta, Vista->Formato de visualización de tiempo->segundos desde el paquete previo
visualizado se puede advertir que el RTT de cada segmento es justamente el tiempo entre
éste y el segmento que confirma.

Puesto que los valores de RTT son demasiado variables, se hace necesario obtener el
valor de RTT promedio que resulta ser el valor representativo para todo el segmento de
red.
Grafico de throughput:

Podemos observar que en este gráfico se muestra únicamente los valores del flujo que va
desde 192.168.4.17 hacia 216.73.86.152 y que para la graficación de los punto sólo se
toma en cuenta el valor de la data acumulada.

gráfico de stevens

Este gráfico nos muestra que el tráfico en cuestión genera un tráfico sin problemas ya que
cada uno de los valores van apareciendo en forma ascendente como debiera esperarse.
Éste mismo valor es utilizado para generar el gráfico de tcptrace:

En el caso del protocolo UDP, al no existir algún parámetro de secuencia que sirva de
referencia para el cálculo de RTT, no se pueden aplicar las herramientas de Wireshark
aplicables a TCP, en éste caso lo que corresponde hacer es determinar el tiempo de
latencia en función de la tasa de transmisión en el emisor y de la tasa de recepción en el
receptor de un mismo datagrama UDP y establecer la diferencia entre ambas tasas, otra
alternativa es establecer el RTT de forma similar a como la hace TCP pero en función de
las aplicaciones que van siendo transportadas, éste método resulta útil sólo en algunos
casos, particularmente en las aplicaciones que siguen el modelo Cliente/Servidor, por
ejemplo peticiones y respuestas hacia servidores DNS o cualquier comunicación que sea
bidireccional, ya que aquellas comunicaciones que son unidireccionales no permiten
realizar éste método.

Determinación del throughput de un enlace

Para todo throughput se requiere dividir el tamaño total acumulado de la data sobre un
espacio de tiempo determinado.

Por ejemplo en el archivo traza_500.pcap se pueden observar de acuerdo a la

estadísticas generales (Estadísticas->Sumario) que se tiene en total 199944 bytes en 500
paquetes capturados en un tiempo de 14.116 segundos que en promedio se tiene un
consumo de 14164,364 bytes/seg (0,113 Mbps) que es un relativamente pequeño para
enlaces de 10 Mbps, cerca al 1,13% de la capacidad del enlace, lo cual nos indica que el
enlace no esta saturado por lo que, si existieran problemas de saturación o congestión del
enlace no deben atribuirse al enlace en sí sino deberían buscarse otras alternativas.
Un detalle importante a considerar es el hecho de que el reporte dado por Wireshark en
esta pantalla muestra el total de byte acumulados en toda la captura, es decir tanto los
bytes de la data como los bytes de la sobrecarga de cada mensaje de datos por lo que si
hicimos nuestras estimaciones en base a data únicamente se deberá ajustar este valor.
Caso de estudio.

El presenta caso de estudio pretende servir de ejemplo para poder establecer el

diagnóstico preliminar de una red, es decir que a partir de los datos obtenidos a
continuación el evaluador debería poder establecer qué problemas existen en la red y
donde se originan.

Para comenzar es necesario conocer la arquitectura de la red, ya que a partir de aquí se

puede establecer el sentido de los flujos y se facilita la comprensión de las trazas
capturadas, sin embargo en algunos casos no se tiene acceso a dicha información por lo
que el evaluador debe inferir la arquitectura de la red en base a la información provista por
la traza lo cual no es muy adecuado porque pude originar mucha información errada.

El diagrama de la red de estudio es el siguiente:

En el gráfico se muestra una red conmutada de 10 Mbps con una topología física en
estrella que cuenta con algunas terminales conectadas que se comunica hacia Internet a
través de un cortafuegos y entre ellas directamente.

Se realizó la captura de tráfico en el cortafuegos a través de la interfaz que está

conectada al segmento de la red local y se almacenaron los datos de la captura en el
archivo traza_500.pcap.

A partir de la información provista por el diagrama de red se puede inferir que en la red
local donde se encuentran las terminales, en su mayoría se deben iniciar conexiones de
clientes hacia servidores externos a esta red, por lo que cualquier conexión que haya sido
iniciada fuera de esta red y tenga como destino algún equipo dentro de la red ha de ser
algo extraño y a tener en cuenta.

Otro punto a considerar es que cada terminal deberá tener una dirección IP perteneciente
a la misma subred de la interfaz de red que estamos utilizando y que cualquier dirección
IP externa a esta subred no es originada por ninguna de estas terminales.

Determinación del ancho de banda de cada enlace

Debemos sin embargo notar que este throughput es un valor que ha sido calculado en
base a la agregación de todos los flujos que entran y salen al segmento correspondiente
por lo que se puede esperar que el consumo real del enlace de subida y del enlace de
bajada sean mucho menores.

Para determinar esto primero deberemos establecer cuales son los extremos de cada
transmisión/recepción de datos, esto lo hacemos viendo reporte de Estadísticas-
>Extremos que nos muestra el siguiente gráfico:

Como se puede observar se tienen 14 extremos Ethernet que participan de la red y el

conteo de paquetes que fueron enviados o recibidos por cada uno de éstos, nótese que
uno de los extremos es una dirección de broadcast lo que significa que no puede estar
asociada a ningún equipo físico. A continuación la tabla extraída del anterior gráfico.

Dirección Dirección IP Paquetes Bytes Paquetes Tx Bytes Tx Paquetes Rx Bytes Rx

00:04:ac:56:fa:c5 varios 484 198468 228 154849 256 43619
00:16:76:64:34:a2 192.168.4.13 244 60542 130 21081 114 39461
00:16:76:64:33:6b 192.168.4.17 119 85099 54 9604 65 75495
00:16:76:64:b1:cb 192.168.4.21 80 48106 40 9280 40 38826
00:16:76:64:b0:c2 192.168.4.22 24 3214 18 2317 6 897
00:16:76:64:ba:31 192.168.4.15 13 1287 12 1225 1 62
00:13:20:5c:6d:f1 192.168.4.26 6 348 4 240 2 108
00:16:76:64:88:c4 no tiene (Netware) 3 294 3 294 0 0
00:13:20:5b:c9:f9 192.168.4.45 3 330 3 330 0 0
00:16:76:64:3d:9c no tiene (Netware) 3 294 3 294 0 0
00:13:20:5b:cb:6b 192.168.4.48 2 132 2 132 0 0
00:13:20:64:93:28 192.168.4.31 2 238 2 238 0 0
00:13:20:5c:78:eb no tiene (Netware) 1 60 1 60 0 0
ff:ff:ff:ff:ff:ff 192.168.4.63/ffffffffffff 16 1476 0 0 16 1476

Ahora que se sabe que existen 13 equipos emisores/receptores de datos, se procede a

determinar la ubicación de éstos en base a su dirección lógica (IP) para lo cual se pueden
filtrar los datos en base a las dirección físicas visualizadas y observar las direcciones IP
asociadas, por ejemplo en el caso de la primera dirección física (usando el filtro
eth.addr==00:04:ac:56:fa:c5) se pueden obtener varias direcciones IP asociadas a ésta
dirección MAC, todas estas direcciones son públicas lo cual indica que son los mensajes
iniciados fuera de la red pero que han sido re-transmitidas a la red local por el cortafuegos
existente, por lo tanto pueden considerarse las respuestas a las peticiones realizadas en
la red local, si en base al filtro usado volvemos a obtener el sumario podremos visualizar
el throughput de estos equipos únicamente y podemos ver que se tiene 484 paquetes con
una tasa de transferencia de 0.112 Mbps, ahora si cambiamos el filtro a
eth.src==00:04:ac:56:fa:c5 y luego a eth.dst==00:04:ac:56:fa:c5 podremos observar que
Wireshark nos brinda el conteo de paquetes y la tasa de transferencia (throughput)
relativa de cada flujo, en este caso se obtiene 228 paquetes con una tasa relativa de
0.088 Mbps y 256 paquetes con una tasa relativa de 0.025 Mbps respectivamente; así
hemos obtenido el consumo en el enlace de bajada y en el enlace de subida
respectivamente.

Para obtener la tasa absoluta solamente tenemos que dividir la cantidad de bytes en
curso sobre el tiempo total de captura en este caso 14.116 seg, así podemos obtener un
conjunto de tasas que si es coherente con el consumo de canal y con el resto de las
transacciones de red que existen.

En el caso del ejemplo podemos ver que la tasa relativa y absoluta del primer nodo
coinciden, esto es debido a que el primer nodo tiene un tiempo e vida similar o igual al del
tiempo de captura. La segunda dirección MAC (eth.src==00:16:76:64:34:a2) corresponde
solamente con la dirección IP 192.168.4.13 que es parte de la red local y presenta una
dirección IP privada, se tienen 244 paquetes con una tasa total de 0.034 Mbps, de los
cuales 130 paquetes son originados en este equipo con una tasa de 0.012 Mbps y 114
paquetes destinados hacia este equipo con una tasa de 0.023 Mbps. Si continuamos este
procedimiento con todas las direcciones MAC reportadas, podremos obtener una tabla
como la siguiente:

Dirección Dirección IP Paquetes Bytes Ancho de Paquetes Bytes Ancho Paqu Bytes Ancho
Banda Tx Tx de etes Rx de
(Mbps) Banda Rx Banda
(Mbps) (Mbps)
00:04:ac:56:fa:c5 Varios 484 198468 0,11248 228 154849 0,0877 256 43619 0,02472
6
00:16:76:64:34:a2 192.168.4.13 244 60542 0,03431 130 21081 0,0119 114 39461 0,02236
5
00:16:76:64:33:6b 192.168.4.17 119 85099 0,04823 54 9604 0,0054 65 75495 0,04279
4
00:16:76:64:b1:cb 192.168.4.21 80 48106 0,02726 40 9280 0,0052 40 38826 0,022
6
00:16:76:64:b0:c2 192.168.4.22 24 3214 0,00182 18 2317 0,0013 6 897 0,00051
1
00:16:76:64:ba:31 192.168.4.15 13 1287 0,00073 12 1225 0,0006 1 62 0,00004
9
 00:13:20:5c:6d:f1 192.168.4.26 6 348 0,0002 4 240 0,0001 2 108 0,00006
4
00:16:76:64:88:c4 no tiene (Netware) 3 294 0,00017 3 294 0,0001 0 0 0
7
00:13:20:5b:c9:f9 192.168.4.45 3 330 0,00019 3 330 0,0001 0 0 0
9
00:16:76:64:3d:9c no tiene (Netware) 3 294 0,00017 3 294 0,0001 0 0 0
7
00:13:20:5b:cb:6b 192.168.4.48 2 132 0,00007 2 132 0,0000 0 0 0
7
00:13:20:64:93:28 192.168.4.31 2 238 0,00013 2 238 0,0001 0 0 0
3
00:13:20:5c:78:eb no tiene (Netware) 1 60 0,00003 1 60 0,0000 0 0 0
3
ff:ff:ff:ff:ff:ff 192.168.4.63/ffffffffffff 16 1476 0,00084 0 0 0 16 1476 0,00084

En base a esta tabla podremos determinar los equipos locales y los equipos remotos, el
consumo disgregado por subida y bajada con lo que podemos determinar como están los
flujos de red en este punto de captura.
Si se utiliza la opción de Estadísticas->conversaciones, se puede observar otra versión de
la misma tabla que muestra la siguiente información:

Origen (A) Destino (B) Pacqute Bytes Ancho Paquete Bytes Ancho Paquete Bytes Ancho
s de s A->B A->B de s A<-B A<-B de
Banda Banda Banda
(Mbps) (Mbps) (Mbps)
00:04:ac:56:fa:c 00:16:76:64:33: 119 85099 0,0482 65 75495 0,0427 54 9604 0,0054
5 6b 3 9 4
00:04:ac:56:fa:c 00:16:76:64:34: 244 60542 0,0343 114 39461 0,0223 130 21081 0,0119
5 a2 1 6 5
00:04:ac:56:fa:c 00:16:76:64:b1: 80 48106 0,0272 40 38826 0,022 40 9280 0,0052
5 cb 6 6
00:04:ac:56:fa:c 00:16:76:64:b0: 24 3214 0,0018 6 897 0,0005 18 2317 0,0013
5 c2 2 1 1
00:16:76:64:ba: ff:ff:ff:ff:ff:ff 9 828 0,0004 9 828 0,0004 0 0 0
31 7 7
00:04:ac:56:fa:c 00:16:76:64:ba: 4 459 0,0002 1 62 0,0000 3 397 0,0002
5 31 6 4 2
00:04:ac:56:fa:c 00:13:20:5c:6d:f 6 348 0,0002 2 108 0,0000 4 240 0,0001
5 1 6 4
00:04:ac:56:fa:c 00:13:20:5b:c9:f 3 330 0,0001 0 0 0 3 330 0,0001
5 9 9 9
00:16:76:64:3d: ff:ff:ff:ff:ff:ff 3 294 0,0001 3 294 0,0001 0 0 0
9c 7 7
00:16:76:64:88: ff:ff:ff:ff:ff:ff 3 294 0,0001 3 294 0,0001 0 0 0
c4 7 7
00:04:ac:56:fa:c 00:13:20:64:93: 2 238 0,0001 0 0 0 2 238 0,0001
5 28 3 3
00:04:ac:56:fa:c 00:13:20:5b:cb: 2 132 0,0000 0 0 0 2 132 0,0000
5 6b 7 7
00:13:20:5c:78: ff:ff:ff:ff:ff:ff 1 60 0,0000 1 60 0,0000 0 0 0
eb 3 3

Como se puede observar en esta tabla, se verifica que el consumo total de cada flujo es
mínimo en comparación con la capacidad del enlace, así mismo se puede determinar
cada uno de los flujos compuestos que pudieran existir en este enlace tomando en cuenta
el origen y destino de cada flujo individual.

También podemos determinar un mapa de flujos por equipo y flujos compuestos por
segmentos con sus respectivos tamaños en base a las tablas anteriores tomando como
punto de referencia el punto de medición en el cortafuegos.
Segmen Paquetes Bytes Ancho de Paquetes Bytes Tx Ancho de Paquetes Bytes Rx Ancho de
Banda Tx Banda Rx Banda
to (Mbps) (Mbps) (Mbps)
0 484 198468 0,11248 256 43619 0,02472 228 154849 0,08776
1 500 199944 0,11331 228 154849 0,08776 272 45095 0.02556
2 500 199944 0,11331 228 154849 0,08776 272 45095 0.02556

Se debe poner énfasis que tomando como punto de referencia el cortafuegos, el tráfico
recibido de un lado que tenga como destino a equipos del otro lado, será inyectado
(transmitido) hacia este lado

Éstos datos deberían verificarse con el diagrama de flujos del diseño correspondiente
para evaluar si realmente la red se acerca a los valores definidos para esa red.

Nótese también que si se quiere determinar los flujos por aplicación, se deberá realizar
todo este procedimiento partiendo de las conversaciones o extremos en los protocolos de
transporte (TCP o UDP)

Práctica. Determinar los flujos por aplicación individuales y compuestos en la traza

utilizada en este caso.

Tasa de error

Para determinar la tasa de error, se debe evaluar cada enlace y determinar esta tasa en
función a cada uno de los extremos existentes en ese enlace, por ejemplo en nuestro
caso se filtró el tráfico correspondiente al equipo 192.168.4.17 (ip.dst == 192.168.4.17) y
se puede observar que de todos los 65 paquetes que ha recibido, existen 7 paquetes que
han sido retransmitidos (ip.dst == 192.168.4.17 and tcp.analysis.retransmission) lo que
implica que se perdieron en su trayecto hacia este equipo por lo tanto fueron errores, por
lo que si aplicamos la fórmula que conocemos, nuestra tasa de error en el enlace que va a
este equipo es de 10,76%, por lo que la precisión de la red es de 89.24%.

Práctica. Determinar las tasas de error de las demás terminales.

Práctica. En base a los datos obtenidos hasta el momento, determinar la utilización de la
red en cada segmento.

Cálculo de la latencia por nodo

Para calcular la latencia por nodo se pueden utilizar las técnicas indicadas anteriormente,
utilizando algún utilitario, como ping o traceroute, o, utilizando un valor de RTT promedio
de las conexiones TCP u UDP existentes.

Otra forma es utilizando la fórmula Latencia=MTU/Ancho_de_Banda

En nuestro caso la latencia de cada segmento considerando un MTU máximo de 1514

bytes (el peor de los casos) nos resulta una latencia introducida por nodo en cada enlace
de 0.001514 segundos en cada segmento y se tiene una latencia de cable de 1.1587
segundos (144849*8/1000000=1.2387), por lo que la latencia total para transmitir toda
esta información desde Internet al segmento 2 medido en el conmutador 2 sería:

Latencia total = 3 x 1.2387 + 2 x 0.0015 = 3.719376 segundos

Práctica. ¿Cuál es la latencia total en el conmutador 1 ?