Nivel de expertise: Medio
Es posible que el soporte técnico de iWeb le pida completar un informe de MyTraceRoute (MTR) ya que los cortafuegos pueden comprometer los resultados. El procedimiento es simple. Siga estos pasos:
Genere un informe de MTR con Windows
- Descargue un programa winMTR, como http://sourceforge.net/projects/winmtr/
- Una vez que la instalación se haya completado, abra la aplicación. No hace falta instalarla, abrir el ejectuable es suficiente.
- En la sección de host, introduzca la información del servidor remoto (nombre del dominio o dirección IP).
- Haga clic en el botón de comenzar.
- Espere a que el programa finalice cada salto. No existe ninguna indicación de que el programa haya finalizado, pero se ejecutará de manera continua para que los datos sean más precisos. El programa finalizó de examinar todos los saltos cuando no ya no genera más saltos.
- Haga clic en el botón de exportar texto.
- Guarde los resultados como un archivo de texto.
Envío de su dirección IP a iWeb
Para interpretar los resultados, iWeb necesitará su dirección IP pública. Es común que los clientes utilicen direcciones IP locales en sus estaciones de trabajo. En este caso, tendrá que utilizar una herramienta para determinar su dirección IP pública. Esta herramienta es fiable y fácil de usar: http://www.whatismyip.com/
Interpretación de resultados de MTR
Los resultados del informe de MTR suministran información utilizada en el diagnóstico de problemas. Los resultados se basan en el análisis e incluyen lo siguiente:
- Pruebas de salto de red
- Número y distancia entre saltos
- Porcentaje de paquetes perdidos (promedio de los paquetes perdidos en porcentaje)
- Cantidad de paquetes enviados (total de enviados)
- Cantidad de paquetes recibidos
- Tiempo de respuesta más rapido de salto
- Tiempo de respuesta promedio de salto
- Tiempo de respuesta más lento de salto
- Retraso de respuesta del último salto
La información más importante para diagnosticar y resolver problemas de conectividad es el porcentaje de paquetes perdidos.
He aquí dos ejemplos visuales de informes de MTR, el primero muestra un caso extremo de paquetes perdidos (negrita).
| WinMTR statistics |
| Host - % | Sent | Recv | Best | Avrg | Wrst | Last |
|------------------------------------------------|------|------|------|------|------|------|
| 70.38.99.3 - 4 | 771 | 747 | 0 | 0 | 122 | 3 |
| te8-3.cr2.mtl.iweb.com - 4 | 762 | 736 | 0 | 2 | 198 | 3 |
| po21.cr1.mtl.iweb.com - 5 | 740 | 709 | 0 | 1 | 170 | 0 |
| xe-0-0-0.er1.tor.iweb.com - 5 | 721 | 687 | 0 | 8 | 81 | 7 |
| gw-google.torontointernetxchange.net - 3 | 802 | 785 | 0 | 9 | 83 | 7 |
| 216.239.47.114 - 2 | 811 | 796 | 8 | 8 | 38 | 9 |
| 216.239.46.160 - 20 | 464 | 373 | 0 | 23 | 43 | 27 |
| 209.85.248.214 - 63 | 229 | 85 | 0 | 35 | 50 | 36 |
| 216.239.43.219 - 17 | 506 | 423 | 0 | 35 | 80 | 36 |
| No response from host - 100 | 159 | 0 | 0 | 0 | 0 | 0 |
| google-public-dns-a.google.com - 91 | 173 | 17 | 0 | 34 | 36 | 34 |
|________________________________________________|______|______|______|______|______|______|
1 69.42.85.82 0 % 5 5 0.341 4.312 17.362
2 csd180.gsc.webair.net(173.239.0.53) 0 % 5 5 0.506 0.705 1.206
3 csc180.gsc.webair.net(173.239.32.1) 0 % 5 5 0.415 0.728 1.047
4 es0.nyc2.webair.net(173.239.0.25) 0 % 5 5 0.887 1.123 1.468
5 208.178.245.149 0 % 5 5 0.881 16.704 22.378
6 ae7-70G.scr4.NYC1.gblx.net(67.16.142.53) 0 % 5 5 0.855 4.814 19.778
7 po4-40G.ar5.NYC1.gblx.net(67.17.105.238) 0 % 5 5 1.003 1.487 2.956
8 64.215.195.214 0 % 5 5 0.835 1.184 1.641
9 vlan60.csw1.NewYork1.Level3.net(4.69.155.62) 0 % 5 5 8.233 8.324 8.504
10 ae-62-62.ebr2.NewYork1.Level3.net(4.69.148.33) 0 % 5 5 8.356 8.618 8.927
11 ae-5-5.car1.Montreal2.Level3.net(4.69.141.5) 0 % 5 5 8.355 10.300 13.459
12 te6-2.cl-core05.level3.mtl.iweb.com(4.59.176.10)20 % 4 5 8.894 13.456 22.702
13 te8-3.dr10.mtl.iweb.com(67.205.127.238) 0 % 5 5 9.152 14.627 25.000
La segunda imagen muestra que no se perdieron los paquetes excepto en el penúltimo salto (negrita). Si los resultados que obtuvo son similares a estos, es importante que tenga en cuenta que, para poder aislar y minimizar los saltos de ping, trace route y MTR, iWeb controla el flujo de protocolos ICMP en sus propios routers. Esto nos ayuda a diagnosticar los resultados al concentrarnos en el último salto en un informe de MTR. En casos similares a estos resultados, no existe ningún problema de conectividad.
0 Comentarios