Facultad de Ciencias Exactas y Naturales – UBA
Departamento de computacion
Teoria de las compunicaciones
TP2: Rutas en Internet
Integrantes email
Marcos Cravero [email protected]
Indice
Introduccion
Aplicación traceroute
Protocolo IP
Campo TTL de paquete IP
Protocolo ICMP
Paquetes ICMP de tipo echo request y echo replay
Desarrollo de aplicación traceroute
Envio de paquetes ICMP, TTL de paqueta IP incremental
Universidades seleccionadas para experimentar con la aplicacion
Renmin University
Enlaces más importantes
Distancia Argentina-EEUU
Distancia EEUU-China
Experimentos con la aplicación desarrollada en las universidades seleccionadas
Segunda universidad: Renmin University
Datos en bruto obtenidos con la aplicación
Ip, rtt de cada envió, media de los rtts, desviación estándar de los rtts
Datos procesados, agregar ubicación y completar datos de host que no responden
Ip, proveedores, tiempos acumulados e incrementos
Grafico de tiempos acumulados, incrementos y z-score
Pruebas estadísticas
Test de normalidad
Incrementos en tiempos atípicos
Análisis de datos
Conclusión
Introducción
Este trabajo tiene varios objetivos. En primer lugar se desarrollo una aplicación que consta de dos
módulos principales. El primer modulo, desarrollo en c#, realiza un traceroute utilizando el
protocolo ICMP y datagramas con TTL incremental. Luego calcula el RTT medio de cada traza y su
desviación estándar. El segundo modulo, desarrollado en python, que se comunica por archivo
compartido con el primer modulo, calcula los enlaces transoceánicos en base a los outlies, esto es
los tiempos que son estadísticamente inconsistentes con el resto de los tiempos. Luego se usa la
aplicación desarrollada para estudiar la ruta a una universidad que está en un continente diferente.
Se grafican los datos obtenidos con la aplicación y se cotejan con sitios de geolocalización. Se dan
explicaciones para los falsos positivos, esto es los tiempos que son inconsistentes con el resto de los
tiempos pero que no son enlaces transoceánicos y se proponen hipótesis para comportamientos
anómalos obtenidos en las rutas.
Aplicación traceroute
Traceroute es una de las herramientas diagnosticas mas usadas de internet. La herramienta nos
brinda información sobre el camino que sigue un paquete desde que es enviado hasta que llega al
destino. Traceroute nos muestra todos los router por los que pasa un paquete y una estimación de
los RTT de cada uno de los enlaces que atraviesa el paquete hasta llegar a destino. Con estos datos
uno puede saber si los paquetes atraviesan una ruta óptima y si algún enlace tiene demoras o
mucha latencia.
Protocolo IP
Campo TTL de paquete IP
Los paquetes IP tienen un capo tiempo de vida, TTL, para evitar que si la red esta mal configurada
los paquetes pueden entrar en un loop y circulen eternamente. El tiempo de vida se mide en
cantidad de saltos entre host. Cuando un host recibe un paquete descuenta en uno el tiempo de vida
y si el tiempo de vida llega a 0 descarta el paquete y avisa al origen enviando un paquete ICMP de
tipo Time Exceeded.
Protocolo ICMP
Paquetes ICMP de tipo echo request y echo replay
El protocolo ICMP se usa para obtener información de error en la red. Por ejemplo para averiguar
el estado de un host, si esta disponible y si se puede alcanzar. Hay varios tipos de paquetes ICMP,
pero para este trabajo solo vamos a usar los tipos de paquete ICMP Echo Request y ICMP Echo
Replay. Un host envía un paquete ICMP Echo Request y el host destino responde con un paquete
ICMP Echo Replay.
En la figura 1 se muestra un paquete ICMP encapsulado dentro de un paquete IP. Se puede ver el
campo TTL del paquete IP y los campo Type y Code del paquete ICMP. Si Type es 8 y Code es 0 el
paquete es Echo Request, si el Type es 0 y Code es 0 el paquete es Echo Replay
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Ver = 4|IHL |Type of Serv =0| Total Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identification |Flg | Fragment Offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TTL | Protocol = 1 | Header Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| source address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| destination address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 8 | Code = 0 | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ICMP data (variable) ...
+-+-+-+-+-+-+-+-+-+-+-+-
Ejemplo de paguete ICMP echo request encapsulado dentro de datagrama IP
Figura 1.
La aplicación envía un paquete ICMP encapsulado en un paquete IP con el campo TTL igual a 1, el
primer router que recibe el paquete descuenta en uno el campo TTL y como queda en 0, el router
descarta el paquete y envía al origen un paquete ICMP de tipo Time Exceeded. De esta manera la
aplicación sabe cual es la dirección ip del primer router y el tiempo que le tomo ir y volver al
paquete. Luego para conocer cual es el segundo router en la ruta al destino la aplicación envía un
paquete ICMP encapsulado en un paquete IP pero esta vez con TTL igual a 2. Aumentando el TTL
hasta que el paquete llega al destino o, hasta un TTL máximo, la aplicación conocer todos los router
en el camino. Cuando el paquete llega al destino el host informa al origen que el paquete llego al
destino enviando un paquete ICMP de tipo Echo Replay.
Aplicación traceroute
Envio de paquetes ICMP, TTL de paqueta IP incremental
La aplicación esta desarrollada en c#, es un archivo .exe (RealizarTraceRouteDeHost.exe), corre en
cualquier versión de Windows. La aplicación recibe como parámetro la dirección del host destino,
la cantidad de envíos a cada router intermedio, el número de repeticiones y el nombre del archivo
donde se almacenaran los resultados. La aplicación, como se explico en la introducción usa el
protocolo ICMP y el campo TTL de los datagramas para averiguar la ip de los router intermedios,
realiza varios envíos para cada router intermedio y calcula el rtt promedio a cada router
intermedio, la desviación estándar y el incremento, esto es, una aproximación a la latencia del
enlace entre los router intermedios.
Hay router que no responden con un paquete Time Exceeded exeeden cuando descartan un
paquete. Por ejemplo, en el caso analizado, el segundo, tercero, cuarto y quito router, no responden
con paquetes ICMP Time Exceeded cuando descartan un paquete. En estos casos calculo el rtt
proporcional a los router que no responden, esto es, por ejemplo, si el router 1 tienen un rtt de 0ms
y el router 6 tienen un rtt de 10ms, supongo que el rtt al router 2 fue de 2ms, el rtt del router 3 fue
de 4ms, el rtt del router 4 fue de 6ms, el rtt del router 5 fue de 8ms y el router 6 de 10ms.
Puede ser que la maquina destino no responda con un paquete ICMP de tipo Echo Reply a un
paquete ICMP Echo Replay. Por ejemplo en el caso analizado, el host destino no responde con un
paquete ICMP Echo Reply, tampo responde a un ping, pero si se puede acceder a la pagina web. Esto
se puede deber a un firewall que tiene bloqueado ICMP echo replay.
Universidad seleccionada
Para realizar el experimento con la aplicación desarrollada elegi una universidad china, Renmin
University. El motivo de la eleccion, fue que ademas de tener un enlace transocenico, como pide el
enunciado del proyecto, tiene mas de 20 router intermedios. Es importante que tenga mas de 20
enlaces porque el enunciado del proyecto pide realizar pruebas estadisticas, y para algunas de las
pruebas estadisticas relizadas se necesitan mas de 20 datos. Resumiendo, los dos motivos de la
eleccion fueron, el primero es que hay un enlace transocenico y el segundo es por razones
estadisticas, se necesitan mas de 20 enlaces para realizar algunas pruebas estadisticas.
Renmin University
La url de la pagina de la universidad es:
http://www.ruc.edu.cn/
Las direcciones ip correpondiente a la pagina web de la universidad es: 181.167.129.38
Experimentos realizados
El modulo de la aplicación que fue desarrollado en c, realiza el traceroute, almacena en un archivo
los resultados y también los muestra en pantalla.
Datos obtenidos con la aplicación
Datos procesados, agregar ubicación y completar datos de host que responden a
Ip, proveedores, tiempos acumulados e incrementos
Nota: los datos fueron procesados con:
>> python ProcesarDatos.py
Ip Proveedor Rtt Incrementos z-score
192.168.0.1 CABLEVISION S.A.,AR 10.333 10.333 -0.001037663
*
10.277 -0.07 -0.004224185
*
10.2 -0.07 -0.004224185
*
10.133 -0.07 -0.004224185
*
10.07 -0.07 -0.004224185
200.89.166.209 CABLEVISION S.A.,AR 10 -0.07 -0.004224185
200.89.165.222 CABLEVISION S.A.,AR 15 5 -0.002671777
208.178.195.205 LVLT-3549 - Level 3 Communications, Inc.,US 10 -5 -0.005735741
67.17.68.234 LVLT-3549 - Level 3 Communications, Inc.,US 140 130 0.035627776
4.68.111.121 LEVEL3 - Level 3 Communications, Inc.,US 150.333 10.33 -0.001037663
4.69.138.69 LEVEL3 - Level 3 Communications, Inc.,US 155.677 5.33 -0.002569645
144.232.18.233 SPRINTLINK - Sprint,US 145.333 -10.33 -0.007369855
144.232.15.94 SPRINTLINK - Sprint,US 166 20.67 0.002128434
144.232.0.130 SPRINTLINK - Sprint,US 166 0 -0.004203759
144.232.1.167 SPRINTLINK - Sprint,US 202 36 0.006826512
144.232.9.194 SPRINTLINK - Sprint,US 207.33 5.33 -0.002569645
Se perdio
202 -5.33 -0.005837873
219.158.103.1 CHINA169-BACKBONE CNCGROUP China169 Backbone,CN 428.5 226.5 0.065195031
Se perdio
428.5 0 -0.004203759
219.158.101.33 CHINA169-BACKBONE CNCGROUP China169 Backbone,CN 436 7.5 -0.001905786
123.126.0.78 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network,CN 353 -83 -0.029634662
*
387 34 0.00621372
202.106.230.246 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network,CN 421 34 0.00621372
61.49.43.14 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network,CN 368.677 -52.33 -0.020238505
123.125.23.148 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network,CN 343 -25.67 -0.012067934
Grafico de tiempos acumulados, incrementos, z-score e histograma
Este grafico muestra los rtt a los distintos host por donde pasa el paquete.
Grafico de incrementos
Graficos de z-score
Histogramas
En el primer grafico se discretiza en 5 ms el tiempo, en el segundo grafo en 15ms. Los datos, limite
inferior, limite superior, cantidad de enlaces en cada intervalo se muestran en el apendice.
Como se puede ver en el grafo 4 enlaces tienen tiempos entre 2.67 a 7.67, 2 enlaces tienen tiempos
entre 7.67 y 12.67, 2 enlaces tienen tiempos entre, 2 enlaces entre -2.33 y 2.67. La partición de los
tiempos detallados esta en el apéndice 1.
Como se puede ver en el grafo 13 enlaces tienen tiempos entre -7.33 y 7.67, 3 entre 7.67 y 22.67, y
el resto de los datos esta en el apéndice 2.
Enlaces más importantes
Algunos de los enlaces más importantes que tiene que atravesar un paquete para llegar ir de
Argentina a China
Cable submarino Argentina-EEUU
South American Crossing (SAC)/Latin American Nautilus (LAN)
RFS: September 2000
Cable Length: 20,000 km
Propietario: Level 3, Telecom Italia Sparkle
Landing Points
Las Toninas, Argentina
St. Croix, Virgin Islands, United States
La distancia aproximada de Argentina a EEUU es de 9.000 km.
Cable submarino EEUU-China
China-U.S. Cable Network (CHUS)
Cable Length: 30.476km
Landing points:
Bandon, Oregon, United States
Chongming, China
San Luis Obispo, California, United States
Shantou, China
La distancia entre EEUU y China es aproximadamente 12.000km
Pruebas estadísticas, test de normalidad, puntos atípicos
El modulo de la aplicación desarrollado en python (AnalizarDatos.py), usa las librerías
smirnov_grubbs y stats. Recibe un archivo con la lista de los tiempos y devuelve un archivo
conteniendo los resultados del test de hipótesis de normalidad y los valores atípicos.
Nota: el programa que realiza el test de normalidad y calcula los tiempos atípicos es:
>> python AnalizarDatos.py
Los datos de los tiempos están en: RucEduCn_EnBruto.csv
El resultado esta en: ResultadoDelAnalisis_listaDeTiempos_rucEduCn.txt
Los incrementos en los tiempos son los siguientes:
{10.333,-0.07,-0.07,-0.07,-0.07,-0.07,5,-5,130,10.33,5.33,-10.33,20.67,0,36,5.33,-5.33,226.5,0,7.5,-
83,34,34,-52.33,-25.67}
Un test de normalidad, la prueba Kolmogorov-Smirnov nos da el siguiente resultado:
Z-score = 29.85
P-value = 3.30e-07
Por lo tanto se rechaza la hipótesis de que los datos tengan una distribución normal.
Aunque los datos no estén distribuidos en forma normal pueden usar el test de Grubb para
determinar los valores atípicos, dijo del profesor de teoría de las comunicaciones, en un email, el
cuatrimestre anterior.
El test de grubbs nos da que los puntos atípicos son los siguientes:
Outliers: [130.0, 226.5 ]
Análisis de datos
Si bien viendo los histogramas parecería que los datos se tenderían a distribuir poison. Las pruebas
estadísticas dan que no es una distribución normal. El test de normalidad da que los datos no
tienen una distribución normal y la prueba para ver los outliers o puntos atípicos nos da que son
puntos atípicos el 130ms y 226ms.
Se puede ver que el incremento de la mayoría de los puntos es menor a 10ms, solamente 2 puntos,
(130ms y 226ms) tienen valores mucho mayores que el resto. 130 ms corresponde al enlace que
une 208.178.195.205 con 67.17.68.234
La herramienta de geolocalizacion usada (http://whatismyipaddress.com/) nos da que
208.178.195.205 esta geolocalizada en EEUU y 67.17.68.234 también esta geolocalizada en EEUU.
Pero, si suponemos que todos los router tienen tiempos de encolamiento, procesamiento y de
transmisión similares, y que la principal diferencia entre los tiempos es causada por el tiempo de
propagacion y dado que este es uno de los dos puntos atípicos, podemos concluir que la distancia
de este enlace es varias veces mayor que la distancia del resto de los enlaces que no son puntos
atípicos.
Podemos ver que hay dos enlaces que son mucho más largos que el resto de los enlaces. Uno es un
cable submarino que une Argentina con EEUU, una distancia aproximada de 9.000km. El otro es un
cable transoceánico que une EEUU con Chica, una distancia aproximada de 12.000km.
Podemos concluir que los puntos atípicos corresponden a estos dos enlaces. El punto atípico de
130ms corresponde al enlace que une Argentina con EEUU, esto es al enlace que une
208.178.195.205 con 67.17.68.234. Por lo tanto la dirección 208.178.195.205 no puede estar en
EEUU, tiene que estar en Argentina.
El segundo punto atípico, 226.5ms, corresponde al enlace transoceánico que une EEUU con Chica.
Algunos router dan baja prioridad a los paquetes ICMP, por lo que los resultados medidos de
latencia no siempre son confiables. Lo importante es la distancia del enlace, no importa que el cable
atraviese o no el océano.
Por lo tanto concluimos:
El primero valor atípico, 130ms, corresponde al cable submarino que une Argentina con EEUU.
El segundo valor atípico, 226.5ms, corresponde al enlace transoceánico de EEUU a China.
La dirección ip, 162.105.131.196, correspondiente a la página http://www.pku.edu.cn/ de la
universidad, Peking University, no responde no responde al comando ping, cuando se le envía un
paquete ICMP Echo Request no responde con un paquete ICMP Echo Reply. La hipótesis propuesta
para el comportamientos anómalos es que hay un firewall que no permite solicitud ICMP echo
request.
Conclusión
Fue útil la aplicación desarrollada para encontrar el enlace transoceánico que había en la traza a la
universidad elegida. Con la aplicación encontramos 2 valores atípicos, uno correspondía a un enlace
submarino que une Argentina con EEUU, de aproximadamente 9.000km y el otro valor atípico
corresponde al enlace transoceánico que une EEUU con China, con una distancia aproximada de
12.000km. La distancia es mayor, el tiempo de propagación es mayor. Todos los router deben tener
tiempos de procesamiento, encolamiento y trasmisión similares, para que los valores atípicos sean
los que tienen mayor tiempo de propagación.
Encontramos que una IP, 208.178.195.205, que según herramienta de geolocalizacion estaría en
EEUU, pero, usando traceroute y analizando los tiempos obtenidos, deducimos que tiene que estar
localizada en Argentina y no en EEUU. Para que el enlace que una las direcciones. Dado que une
208.178.195.205 con 67.17.68.234 es un valor atípico, tiene un rtt de 130ms y es el enlace que une
Argentina con EEUU, la dirección ip 208.178.195.205 no puede estar localizada en EEUU, tiene que
estar en Argentina.
Encontramos que algunos router, por ejemplo, los correspondientes al segundo, tercero, cuarto y
quinto salto, no responden con paquetes ICMP Time Exceeded cuando descartan un paquete.
Pudimos ver que algunas universidades Chinas, como la universidad Peking University, no
responde con un paquete ICMP Echo Reply cuando le llega un paquete ICMP Echo Request, no
responde al ping, seguramente por un firewall que tiene bloqueado mensajes ICMP Echo Replay.
Apéndice I
Datos con los que se construyo el histograma 1
Inferior Superior Frecuencia Frecuencia Relativa Densidad
[-52.33 , -47.33[ 1 0.042 0.008
[-47.33 , -42.33[ 1 0.042 0.008
[-42.33 , -37.33[ 1 0.042 0.008
[-37.33 , -32.33[ 1 0.042 0.008
[-32.33 , -27.33[ 1 0.042 0.008
[-27.33 , -22.33[ 1 0.042 0.008
[-22.33 , -17.33[ 1 0.042 0.008
[-17.33 , -12.33[ 1 0.042 0.008
[-12.33 , -7.33[ 1 0.042 0.008
[-7.33 , -2.33[ 1 0.042 0.008
[-2.33 , 2.67[ 2 0.083 0.017
[2.67, 7.67[ 4 0.167 0.033
[7.67, 12.67[ 2 0.083 0.017
[12.67, 17.67[ 1 0.042 0.008
[17.67, 22.67[ 1 0.042 0.008
[22.67, 27.67[ 1 0.042 0.008
[27.67, 32.67[ 1 0.042 0.008
[32.67, 37.67[ 1 0.042 0.008
[37.67, 42.67[ 1 0.042 0.008
[42.67, 47.67[ 0 0.000 0.000
[47.67, 52.67[ 0 0.000 0.000
[52.67, 57.67[ 0 0.000 0.000
[57.67, 62.67[ 0 0.000 0.000
[62.67, 67.67[ 0 0.000 0.000
[67.67, 72.67[ 0 0.000 0.000
[72.67, 77.67[ 0 0.000 0.000
[77.67, 82.67[ 0 0.000 0.000
[82.67, 87.67[ 0 0.000 0.000
[87.67, 92.67[ 0 0.000 0.000
[92.67, 97.67[ 0 0.000 0.000
[97.67, 102.67[ 0 0.000 0.000
[102.67, 107.67[ 0 0.000 0.000
[107.67, 112.67[ 0 0.000 0.000
[112.67, 117.67[ 0 0.000 0.000
[117.67, 122.67[ 0 0.000 0.000
[122.67, 127.67[ 0 0.000 0.000
[127.67, 132.67[ 0 0.000 0.000
[132.67, 137.67[ 0 0.000 0.000
[137.67, 142.67[ 0 0.000 0.000
[142.67, 147.67[ 0 0.000 0.000
[147.67, 152.67[ 0 0.000 0.000
[152.67, 157.67[ 0 0.000 0.000
[157.67, 162.67[ 0 0.000 0.000
[162.67, 167.67[ 0 0.000 0.000
[167.67, 172.67[ 0 0.000 0.000
[172.67, 177.67[ 0 0.000 0.000
[177.67, 182.67[ 0 0.000 0.000
[182.67, 187.67[ 0 0.000 0.000
[187.67, 192.67[ 0 0.000 0.000
[192.67, 197.67[ 0 0.000 0.000
[197.67, 202.67[ 0 0.000 0.000
[202.67, 207.67[ 0 0.000 0.000
[207.67, 212.67[ 0 0.000 0.000
[212.67, 217.67[ 0 0.000 0.000
[217.67, 222.67[ 0 0.000 0.000
[222.67, 227.67] 0 0.000 0.000
Apéndice II
Datos con los que se construyo el histograma 2
Inferior Superior Frecuencia Frecuencia Relativa Densidad
[-52.33 , -37.33[ 1 0.042 0.003
[-37.33 , -22.33[ 1 0.042 0.003
[-22.33 , -7.33[ 1 0.042 0.003
[-7.33 , 7.67[ 13 0.542 0.036
[7.67, 22.67[ 3 0.125 0.008
[22.67, 37.67[ 3 0.125 0.008
[37.67, 52.67[ 1 0.042 0.003
[52.67, 67.67[ 1 0.042 0.003
[67.67, 82.67[ 0 0.000 0.000
[82.67, 97.67[ 0 0.000 0.000
[97.67, 112.67[ 0 0.000 0.000
[112.67, 127.67[ 0 0.000 0.000
[127.67, 142.67[ 0 0.000 0.000
[142.67, 157.67[ 0 0.000 0.000
[157.67, 172.67[ 0 0.000 0.000
[172.67, 187.67[ 0 0.000 0.000
[187.67, 202.67[ 0 0.000 0.000
[202.67, 217.67[ 0 0.000 0.000
[217.67, 232.67] 0 0.000 0.000