@Panchou: Les pago cerca de 60 mil pesos mensuales por esta basura de servicio
Ni siquiera los mirrors de CDNs funcionan bien en VTR
iTunes utiliza los servicios de Akamai para distribuir los contenidos de su tienda digital. Estoy obteniendo velocidades de descarga ridículamente bajas de iTunes, como consta en la siguiente imagen:
Lo irónico del caso es que, tras consultar con netstat, puedo verificar que las direcciones IP desde donde se están descargando son efectivamente de VTR, ante lo cual las velocidades de descarga deberían ser mucho mayores:
$ netstat -n -p tcp|grep ESTABLISHED tcp4 0 0 192.168.6.20.53345 190.46.255.17.80 ESTABLISHED tcp4 0 0 192.168.6.20.53340 190.46.255.11.80 ESTABLISHED tcp4 0 0 192.168.6.20.53339 190.46.255.9.80 ESTABLISHED
Un simple whois nos revela el bloque al cual pertenece la IP en cuestión…
$ whois 190.46.255.17 # # Query terms are ambiguous. The query is assumed to be: # "n 190.46.255.17" # # Use "?" to get help. # # # The following results may also be obtained via: # http://whois.arin.net/rest/nets;q=190.46.255.17?showDetails=true&showARIN=false # NetRange: 190.0.0.0 - 190.255.255.255 CIDR: 190.0.0.0/8 OriginAS: NetName: NET190 NetHandle: NET-190-0-0-0-1 Parent: NetType: Allocated to LACNIC Comment: This IP address range is under LACNIC responsibility for further Comment: allocations to users in LACNIC region. Comment: Please see http://www.lacnic.net/ for further details, or check the Comment: WHOIS server located at http://whois.lacnic.net RegDate: 2005-06-17 Updated: 2010-07-21 Ref: http://whois.arin.net/rest/net/NET-190-0-0-0-1 OrgName: Latin American and Caribbean IP address Regional Registry OrgId: LACNIC Address: Rambla Republica de Mexico 6125 City: Montevideo StateProv: PostalCode: 11400 Country: UY RegDate: 2002-07-27 Updated: 2007-01-09 Ref: http://whois.arin.net/rest/org/LACNIC ReferralServer: whois://whois.lacnic.net OrgTechHandle: LACNIC-ARIN OrgTechName: LACNIC Whois Info OrgTechPhone: 999-999-9999 OrgTechEmail: whois-contact@lacnic.net OrgTechRef: http://whois.arin.net/rest/poc/LACNIC-ARIN # # ARIN WHOIS data and services are subject to the Terms of Use # available at: https://www.arin.net/whois_tou.html # % Joint Whois - whois.lacnic.net % This server accepts single ASN, IPv4 or IPv6 queries % LACNIC resource: whois.lacnic.net % Copyright LACNIC lacnic.net % The data below is provided for information purposes % and to assist persons in obtaining information about or % related to AS and IP numbers registrations % By submitting a whois query, you agree to use this data % only for lawful purposes. % 2011-06-20 01:04:05 (BRT -03:00) inetnum: 190.46/15 status: allocated owner: VTR BANDA ANCHA S.A. ownerid: CL-VPNS-LACNIC responsible: Italo Sambuceti address: Reyes Lavalle, 3340, 4th floor address: 6760335 - Santiago - country: CL phone: +56 02 3101502 [] owner-c: ISO tech-c: ISO abuse-c: ISO inetrev: 190.46/15 nserver: NS00.VTR.NET nsstat: 20110618 AA nslastaa: 20110618 nserver: NS01.VTR.NET nsstat: 20110618 AA nslastaa: 20110618 created: 20060627 changed: 20060627 nic-hdl: ISO person: Contacto VTR e-mail: isambuce@VTR.CL address: Reyes Lavalle, 3340, 4 th floor address: 676-0335 - Santiago - country: CL phone: +56 02 3101609 [] created: 20020906 changed: 20110419 % whois.lacnic.net accepts only direct match queries. % Types of queries are: POCs, ownerid, CIDR blocks, IP % and AS numbers.
Por último, una mirada a los headers de respuesta a un request http nos indica que efectivamente se trata de un mirror de Akamai:
$ wget -S 190.46.255.40 --2011-06-19 23:58:00-- http://190.46.255.40/ Connecting to 190.46.255.40:80... conectado. Petición HTTP enviada, esperando respuesta... HTTP/1.0 400 Bad Request Server: AkamaiGHost Mime-Version: 1.0 Content-Type: text/html Content-Length: 194 Expires: Mon, 20 Jun 2011 03:58:00 GMT Date: Mon, 20 Jun 2011 03:58:00 GMT Connection: close 2011-06-19 23:58:00 ERROR 400: Bad Request.
Luego de lo anteriormente expuesto, solo me queda decir:
WHAT THE FUCK IS GOING ON?!?!
Problema con los DNS de VTR
Quienes me siguen en Twitter saben que frecuentemente reclamo en contra de VTR (@VTRsoporte), ya que las velocidades de descarga distan mucho de ser las prometidas según el servicio contratado y sus soluciones se limitan a reiniciar el módem.
Un par de noches atrás alguien de Akamai (@edgescl) intentó ayudarme a diagnosticar el problema. En el camino logré descubrir algo interesante y tiene que ver con los resolver que VTR asigna por DHCP.
DHCP es el protocolo que se utiliza para asignar una dirección IP en forma dinámica, DNS es el sistema utilizado para resolver nombres de host (ej: www.google.com) a una dirección IP.
Mediante DHCP el proveedor indica cuales son los servidores de DNS (o resolver) que se deben utilizar para realizar las consultas. VTR asigna 3:
190.160.0.11 200.83.1.5 200.74.121.12
Intenté utilizar directamente cada uno de ellos mediante nslookup, una herramienta de consulta y diagnóstico a nivel de DNS, los resultados a continuación:
Con el primero (190.160.0.11) no obtuve respuesta, lo cual significa que dicho resolver está abajo. La consecuencia de esto es que al menos una de cada tres consultas derivará en un timeout (un tiempo de espera agotado de alrededor de 15 segundos) antes de intentar con el siguiente resolver lo cual lógicamente se traduce en una mayor demora en la navegación habitual u otras operaciones normales de conectividad:
$ nslookup > server 190.160.0.11 Default server: 190.160.0.11 Address: 190.160.0.11#53 > www.google.com ;; connection timed out; no servers could be reached
Los otros dos resolvers (200.83.1.5 y 200.74.121.12) sí funcionan, sin embargo de manera dispar. Hoy en día cada vez más diversos sitios hacen uso de redes de distribución de contenidos (CDN), que cuentan con réplicas de datos en diversos servidores en distintas ubicaciones geográficas. Mediante un truco de DNS se derivan las consultas al que está más cercano del requerimiento, de manera de que sea atendido de la manera más rápida y descongestionada posible. Estos dos resolvers responden con direcciones IP distintas para un mismo request, pudiendo potencialmente ser este otro problema que se traduce en lentitud de acceso a contenidos:
$ nslookup > server 200.83.1.5 Default server: 200.83.1.5 Address: 200.83.1.5#53 > www.nike.com ;; Truncated, retrying in TCP mode. Server: 200.83.1.5 Address: 200.83.1.5#53 Non-authoritative answer: www.nike.com canonical name = www.nike.com.edgekey.net. www.nike.com.edgekey.net canonical name = www.nike.com.edgekey.net.globalredir.akadns.net. www.nike.com.edgekey.net.globalredir.akadns.net canonical name = e2698.b.akamaiedge.net. Name: e2698.b.akamaiedge.net Address: 96.17.27.19
v/s
$ nslookup > server 200.74.121.12 Default server: 200.74.121.12 Address: 200.74.121.12#53 > www.nike.com Server: 200.74.121.12 Address: 200.74.121.12#53 Non-authoritative answer: www.nike.com canonical name = www.nike.com.edgekey.net. www.nike.com.edgekey.net canonical name = www.nike.com.edgekey.net.globalredir.akadns.net. www.nike.com.edgekey.net.globalredir.akadns.net canonical name = e2698.b.akamaiedge.net. Name: e2698.b.akamaiedge.net Address: 96.16.195.19
Con el solo hecho de que uno de los 3 resolvers asignados no funcione claramente existe un problema de parte del proveedor de Internet en cuestión. Desconozco a ciencia cierta si es que los otros dos resolvers se encuentran en ubicaciones geográficas dispersas que puedan provocar respuestas equívocas de parte de las CDNs.
Por lo pronto lo único que se me ocurre es hacer un override manual a la configuración de DNS otorgada por VTR vía DHCP eliminando el primero de los resolvers (190.160.0.11) y dejando solo los otros dos. No recomiendo utilizar los DNS públicos de Google (8.8.8.8 y 8.8.4.4) ya que éstos sufren del mismo problema mencionado más arriba con las CDNs (lo cual está reconocido por Google).
