miércoles, 13 de mayo de 2009

Traceroute vs Tracert

Posted by Nicolas | miércoles, 13 de mayo de 2009 | Category: |

Antes de utilizar esta herramienta para mostrar el funcionamiento de distintos protocolos, me pareció interesante mostrar porque puede suceder que si bien los tracert desde Windows funcionen, mientras los traceroutes (RFC 1393) de Unix/Cisco IOS no lo hagan o viceversa.

La diferencia radica en cómo funcionan estos comandos cuyo resultado pretende mostrarnos el path que sigue los paquetes IP (RFC 791) para llegar a un destino. Ambos se basan en enviar paquetes con valores de TTL incrementales cada tres paquetes hasta que el destino es alcanzado. La naturaleza de estos paquetes, sin embargo, es distinta para cada comando. Tracert envía Echo Requests (pings!!!: paquetes ICMP type 8, RFC 792) en tanto que los traceroutes envían segmentos UDP (RFC 768) destinados a puertos que esperamos no sean utilizados por ninguna aplicación (entonces inválidos) de manera aleatoria por sobre el 33434.

Tracert envía los tres primeros paquetes con TTL seteado en 1, el siguiente salto decrementa este valor, descartando así el paquete y enviando de vuelta un paquete ICMP type 11 code 0 ("time to live exceeded in transit") en respuesta, indicanto que el TTL alcanzó el valor 0, por ende el origen ya sabe quién es el primer salto. De la misma manera sucede con el segundo salto, esta vez el TTL es seteado a 2, por lo que el segundo salto es quién envía las respuesta. Ojo que los paquetes pueden tomar distintos paths, como a su vez el camino de vuelta no tiene por que necesariamente ser el mismo.

Traceroute en dispositivos Cisco utiliza un mecanismo similar en cuanto los saltos son determinados en base a paquetes ICMP (type 11 code 0) que recibe, sin embargo una vez que llega al destino, al utilizar un puerto inválido, la respuesta es un paquete ICMP type 3 code 3 ("port unreachable"), con lo que el proceso concluye. A continuación un sencillo ejemplo con un trace a dos saltos de distancia para la red de la figura (destino 1.1.1.1, loopback0 en P1R1).


P1R4#terminal monitor
P1R4#debug ip packet detail 100
IP packet debugging is on (detailed) for access list 100
P1R4#trace 1.1.1.1

Type escape sequence to abort.
Tracing the route to 1.1.1.1

1 P1R3-E0 (10.1.3.3) 4 msec
P1R2-F0.0 (10.1.2.2) 4 msec
P1R3-E0 (10.1.3.3) 4 msec
2 P1R1-F0.1 (10.1.0.1) 8 msec
P1R1-F0.0 (10.1.1.1) 4 msec
*Apr 5 23:43:48.133: IP: s=10.1.3.4 (local), d=1.1.1.1 (FastEthernet0/1), len 28, sending
*Apr 5 23:43:48.133: UDP src=37938, dst=33434
*Apr 5 23:43:48.137: IP: s=10.1.3.3 (FastEthernet0/1), d=10.1.3.4 (FastEthernet0/1), len 56, rcvd 3
*Apr 5 23:43:48.137: ICMP type=11, code=0
*Apr 5 23:43:48.137: IP: s=10.1.2.4 (local), d=1.1.1.1 (FastEthernet0/0), len 28, sending
*Apr 5 23:43:48.141: UDP src=35128, dst=33435
*Apr 5 23:43:48.141: IP: s=10.1.2.2 (FastEthernet0/0), d=10.1.2.4 (FastEthernet0/0), len 56, rcvd 3
*Apr 5 23:43:48.141: ICMP type=11, code=0
*Apr 5 23:43:48.145: IP: s=10.1.3.4 (local), d=1.1.1.1 (FastEthernet0/1), len 28, sending
*Apr 5 23:43:48.145: UDP src=38915, dst=33436
*Apr 5 23:43:48.149: IP: s=10.1.3.3 (FastEthernet0/1), d=10.1.3.4 (FastEthernet0/1), len 56, rcvd 3
*Apr 5 23:43:48.149: ICMP type=11, code=0
*Apr 5 23:43:48.149: IP: s=10.1.2.4 (local), d=1.1.1.1 (FastEthernet0/0), len 28, sending
*Apr 5 23:43:48.149: UDP src=39000, dst=33437
*Apr 5 23:43:48.157: IP: s=10.1.0.1 (FastEthernet0/0), d=10.1.2.4 (FastEthernet0/0), len 56, rcvd 3
*Apr 5 23:43:48.157: ICMP type=3, code=3
*Apr 5 23:43:48.157: IP: s=10.1.3.4 (local), d=1.1.1.1 (FastEthernet0/1), len 28, sending
*Apr 5 23:43:48.157: UDP src=33061, dst=33438
*Apr 5 23:43:48.165: IP: s=10.1.2.4 (local), d=1.1.1.1 (FastEthernet0/0), len 28, sending
*Apr 5 23:43:48.165: UDP src=39639, dst=33439 *
P1R4#


Para hacer traceroutes desde la red: www.traceroute.org

En total 0 comentarios:


Leave a Reply