El 18 de junio de 2010 07:11, Pedro M. López <pmlopez@multimensaje.es> escribió:El Fri, 18 Jun 2010 11:53:17 +0200
Marc Aymerich <glicerinu@gmail.com> escribió:
> 2010/6/17 Jorge A. Secreto <jorgesecreto@gmail.com>:
> >
> >
> > El 17 de junio de 2010 11:13, Camaleón <noelamac@gmail.com>
> > escribió:
> >>
> >> El Wed, 16 Jun 2010 12:49:50 -0300, Jorge A. Secreto escribió:
> >>
> >> > A ver si a alguien se le ocurre que puede estar pasando (o cómo
> >> > tengo que buscar la solución):
> >> > Tengo la pc conectada en una red con dos puertas de enlace. Una
> >> > es un modem de speedy, routeado.
> >> > Este modem es mi servidor DNS y mi puerta de enlace a internet.
> >> > La otra es un Brazil-fw discando un modem de speedy, que a su
> >> > vez, también es puerta de enlace a otra red.
> >> > La cuestión es que si hago un ping (o trato de cargar la pagina
> >> > en el navegador) a google o cualquier otro servidor hay una
> >> > demora de no menos de 15 o 20 segundos, antes de que la empiece
> >> > a cargar, o responder los ping. De hecho cada ping individual
> >> > tarda menos de 1 segundo en volver, pero entre cada ping se
> >> > vuelve a producir la demora. Si, en vez de buscar la dirección
> >> > por URL pongo la dirección IP, las respuesta son inmediatas,
> >> > siempre.
> >>
> >> ¿Tienes los mismos síntomas en el resto de equipos que tienes
> >> conectado a ese módem-router?
> >
> > No, solo pasa en esa máquina
> >
> >>
> >> ¿Has probado a resolver un dominio de la red local?
> >
> >
> > No, con el modem como DNS no puedo resolver direcciones internas.
> > Tendría que ver si le puedo decir al modem que ip tiene algun
> > servidor interno.
> > Para que no lo salga a buscar a internet
> > Lo que acabo de hacer es agregar en /etc/hosts la ip que resuelve
> > www.google.com y asi funciona bien sin el retardo.
> > Daría la impresión de que tiene que ver con la resolucion de
> > nombres, si no fuera porque inmediatamente que hago el ping, me
> > devuelve la ip de google y luego se produce la demora.
> >
> >>
> >> ¿Tienes algún serviico de cortafuegos o proxy que puediera estar
> >> interfiriendo, bloqueando o ralentizando la entrada o recepción de
> >> paquetes externos?
> >
> > No, ese modem está con la configuración por defecto, no filtra mas
> > que lo que da el nateo.
> > Es decir: no hay ningun servicio interno expuesto a internet.
> >
> >
>
> Solo por curiosidad un "ping -f 172.16.0.58" te reporta paquetes
> perdidos?
>
>
x# ping -f www.google.com
PING www.l.google.com (72.14.253.104) 56(84) bytes of data.
............^C
--- www.l.google.com ping statistics ---
14 packets transmitted, 14 received, 0% packet loss, time 155ms
rtt min/avg/max/mdev = 158.202/162.773/168.155/2.939 ms, pipe 14, ipg/ewma 11.934/163.006 ms
¿Podrías darnos la salida de un ping -n www.google.com?
Estos retrasos con el ping pueden ser debidos a problemas en las
resoluciones inversas de DNS.
Y también podrías hacer una prueba con root (si no es con el
superusuario a mi no me deja hacer un strace del ping)
strace -C -r -T ping www.google.com
x# strace -c -r -T ping www.google.com
PING www.l.google.com (72.14.253.104) 56(84) bytes of data.
64 bytes from 72.14.253.104: icmp_seq=1 ttl=55 time=165 ms
64 bytes from 72.14.253.104: icmp_seq=2 ttl=55 time=165 ms
64 bytes from 72.14.253.104: icmp_seq=3 ttl=55 time=162 ms
^C% time seconds usecs/call calls errors syscall
------ ----------- ----------- --------- --------- ----------------
nan 0.000000 0 27 read
nan 0.000000 0 7 write
nan 0.000000 0 20 open
nan 0.000000 0 30 close
nan 0.000000 0 1 execve
nan 0.000000 0 1 getpid
nan 0.000000 0 8 8 access
nan 0.000000 0 3 brk
nan 0.000000 0 3 ioctl
nan 0.000000 0 18 gettimeofday
nan 0.000000 0 17 munmap
nan 0.000000 0 2 uname
nan 0.000000 0 1 mprotect
nan 0.000000 0 3 3 _llseek
nan 0.000000 0 17 poll
nan 0.000000 0 3 rt_sigaction
nan 0.000000 0 34 mmap2
nan 0.000000 0 7 stat64
nan 0.000000 0 24 fstat64
nan 0.000000 0 1 getuid32
nan 0.000000 0 1 setuid32
nan 0.000000 0 22 fcntl64
nan 0.000000 0 1 set_thread_area
nan 0.000000 0 12 socket
nan 0.000000 0 11 2 connect
nan 0.000000 0 1 getsockname
nan 0.000000 0 9 send
nan 0.000000 0 1 recvfrom
nan 0.000000 0 7 setsockopt
nan 0.000000 0 1 getsockopt
nan 0.000000 0 4 sendmsg
nan 0.000000 0 4 recvmsg
------ ----------- ----------- --------- --------- ----------------
100.00 0.000000 301 13 total
# strace -c -r -T ping 72.14.253.104
PING 72.14.253.104 (72.14.253.104) 56(84) bytes of data.
64 bytes from 72.14.253.104: icmp_seq=1 ttl=54 time=166 ms
64 bytes from 72.14.253.104: icmp_seq=2 ttl=55 time=159 ms
64 bytes from 72.14.253.104: icmp_seq=3 ttl=54 time=162 ms
^C% time seconds usecs/call calls errors syscall
------ ----------- ----------- --------- --------- ----------------
nan 0.000000 0 2 read
nan 0.000000 0 4 write
nan 0.000000 0 3 open
nan 0.000000 0 4 close
nan 0.000000 0 1 execve
nan 0.000000 0 1 getpid
nan 0.000000 0 4 4 access
nan 0.000000 0 3 brk
nan 0.000000 0 2 ioctl
nan 0.000000 0 10 gettimeofday
nan 0.000000 0 1 munmap
nan 0.000000 0 1 mprotect
nan 0.000000 0 2 poll
nan 0.000000 0 3 rt_sigaction
nan 0.000000 0 10 mmap2
nan 0.000000 0 4 fstat64
nan 0.000000 0 1 getuid32
nan 0.000000 0 1 setuid32
nan 0.000000 0 1 set_thread_area
nan 0.000000 0 2 socket
nan 0.000000 0 1 connect
nan 0.000000 0 1 getsockname
nan 0.000000 0 7 setsockopt
nan 0.000000 0 1 getsockopt
nan 0.000000 0 3 sendmsg
nan 0.000000 0 3 recvmsg
------ ----------- ----------- --------- --------- ----------------
100.00 0.000000 76 4 total
# strace -c -r -T ping -n www.google.com
PING www.l.google.com (72.14.253.104) 56(84) bytes of data.
64 bytes from 72.14.253.104: icmp_seq=1 ttl=55 time=158 ms
64 bytes from 72.14.253.104: icmp_seq=2 ttl=54 time=163 ms
64 bytes from 72.14.253.104: icmp_seq=3 ttl=55 time=162 ms
^C% time seconds usecs/call calls errors syscall
------ ----------- ----------- --------- --------- ----------------
nan 0.000000 0 15 read
nan 0.000000 0 4 write
nan 0.000000 0 14 open
nan 0.000000 0 18 close
nan 0.000000 0 1 execve
nan 0.000000 0 1 getpid
nan 0.000000 0 7 7 access
nan 0.000000 0 3 brk
nan 0.000000 0 3 ioctl
nan 0.000000 0 11 gettimeofday
nan 0.000000 0 9 munmap
nan 0.000000 0 2 uname
nan 0.000000 0 1 mprotect
nan 0.000000 0 4 poll
nan 0.000000 0 3 rt_sigaction
nan 0.000000 0 24 mmap2
nan 0.000000 0 2 stat64
nan 0.000000 0 15 fstat64
nan 0.000000 0 1 getuid32
nan 0.000000 0 1 setuid32
nan 0.000000 0 5 fcntl64
nan 0.000000 0 1 set_thread_area
nan 0.000000 0 5 socket
nan 0.000000 0 4 2 connect
nan 0.000000 0 1 getsockname
nan 0.000000 0 1 send
nan 0.000000 0 1 recvfrom
nan 0.000000 0 7 setsockopt
nan 0.000000 0 1 getsockopt
nan 0.000000 0 3 sendmsg
nan 0.000000 0 3 recvmsg
------ ----------- ----------- --------- --------- ----------------
100.00 0.000000 171 9 total
y finalmente, como me había pedido camaleon, cambié el DNS de 172.16.0.58 a 172.16.0.254, que es un servidor interno, que ni siquiera es puerta de enlace, y¿saben qué?
# ping www.google.com
PING www.l.google.com (72.14.253.104) 56(84) bytes of data.
64 bytes from mia04s03-in-f104.1e100.net (72.14.253.104): icmp_seq=1 ttl=54 time=198 ms
64 bytes from mia04s03-in-f104.1e100.net (72.14.253.104): icmp_seq=2 ttl=55 time=191 ms
64 bytes from mia04s03-in-f104.1e100.net (72.14.253.104): icmp_seq=3 ttl=55 time=165 ms
64 bytes from mia04s03-in-f104.1e100.net (72.14.253.104): icmp_seq=4 ttl=55 time=162 ms
64 bytes from mia04s03-in-f104.1e100.net (72.14.253.104): icmp_seq=5 ttl=55 time=158 ms
64 bytes from mia04s03-in-f104.1e100.net (72.14.253.104): icmp_seq=6 ttl=55 time=166 ms
^C
--- www.l.google.com ping statistics ---
7 packets transmitted, 6 received, 14% packet loss, time 7406ms <--- 7 segundos para 6 pings
rtt min/avg/max/mdev = 158.978/173.993/198.822/15.325 ms
Si antes estaba mareado....
Ahora estoy vomitando :-P
A esta altura no pretendo solucionar nada..... con entender lo que está pasando ya estaría conforme :-(
Muchísimas gracias por molestarse en analizar esto.
--
Jorge A Secreto
Analista de Sistemas
MP 361