Durante mucho tiempo he tenido un problema difícil de alcanzar con mi red.
Cambié el enrutador, el punto de acceso y realicé conexiones inalámbricas por cable en busca de un ladrón de rendimiento sin estar más cerca de comprender qué está mal en mi configuración.
El problema es tan vago como "la red se siente lenta" y ningún síntoma particular del problema ha sido lo suficientemente persistente como para que pueda encontrar su causa raíz.
Mi infraestructura actual está compuesta por:
Una máquina virtual pfsense que se ejecuta en esxi. Actualmente, la única máquina virtual que se ejecuta en el host (Proliant ML110, Core 2 Duo) elimina las otras máquinas virtuales como ladrones de rendimiento. El servidor tiene dos NIC, una para WAN y otra para LAN.
Tres conmutadores Procurve 1800/1810 de 8 y 24 puertos. Dos VLAN, una para LAN y otra para WAN.
Un Ubiquiti Unifi UAP-AC.
Esa red brinda conectividad a veintitantos unidades.
Ayer hubo un problema más persistente en el que no podía iniciar una película en Netflix, googleando un poco me trajoaquídespués de tener soporte de Netflix dime que el problema no es de ellos sino de mi ISP.
La descripción allí coincide bien con los problemas que tengo, el inicio de la aplicación es muy lento y la reproducción no siempre funciona.
Intenté desconectar el Apple-TV y conectar mi Macbook usando el mismo cable. En la computadora, Netflix funcionó sin problemas. Al realizar una prueba de velocidad en ese mismo cable, verifiqué mi ancho de banda en 100 megabits bidireccionales. Volver a conectar el Apple-TV Netflix se negó a funcionar.
Cambiar la vlan del puerto al que está conectado el Apple-TV de LAN a WAN hizo que se conectara directamente a internet con una IP pública, con la que podía transmitir la película sin problema.
Volver a ponerlo en la reproducción LAN falló nuevamente. Desconecté todo menos el Apple-TV y el enlace ascendente del conmutador. Fui al conmutador con Internet entrante, desconecté todo menos los dos puertos pfsense, la conexión al convertidor de fibra y el enlace ascendente al conmutador con el Apple-TV. Después de lo cual pudo iniciar la reproducción.
En consecuencia, razoné que debería poder identificar al alborotador reconectando todo y ver qué cable interrumpe la reproducción. Ninguno lo hizo. Todo siguió funcionando cuando todo volvió a estar conectado.
Esa ha sido mi experiencia cada vez que intento descubrir por qué mi conexión funciona mal. Con 100 megabits bidireccionales debería ser bastante ágil, pero he apagado varias veces el wifi de mi teléfono móvil porque 4G es más rápido. Speedtest siempre muestra 100 megabits.
La transmisión parece particularmente difícil de manejar, reflejar mi pantalla usando Airplay es prácticamente inútil. Reproducir música con la misma tecnología funciona, pero las interrupciones en la reproducción son comunes.
Mientras que ayer saltarse el cortafuegos parecía indicar que él es el culpable de todo esto, hoy los resultados son inversos:
$ ip addr show dev eth0 | grep "inet\b" && time for i in {1..100}; do ping -c 1 -s 1600 -M dont google.se > /dev/null; done
inet 80.216.153.211/22 brd 80.216.155.255 scope global eth0
real 2m23.383s
user 0m0.046s
sys 0m0.253s
$ ip addr show dev eth0 | grep "inet\b" && time for i in {1..100}; do ping -c 1 -s 1600 -M dont google.se > /dev/null; done
inet 10.11.12.162/24 brd 10.11.12.255 scope global eth0
real 0m52.497s
user 0m0.054s
sys 0m0.253s
Además, para intentar verificar la MTU de la red (según la teoría del foro de Apple), intenté hacer ping con diferentes tamaños de paquetes desde la WAN; mis pruebas mostraron que los paquetes grandes no atravesaron bien la red:
$ ip addr show dev eth0 | grep "inet\b" && time for i in {1..2}; do ping -c 1 -s 1500 google.se ; done
inet 80.216.153.211/22 brd 80.216.155.255 scope global eth0
PING google.se (64.233.163.94) 1500(1528) bytes of data.
--- google.se ping statistics ---
1 packets transmitted, 0 received, 100% packet loss, time 0ms
PING google.se (64.233.163.94) 1500(1528) bytes of data.
--- google.se ping statistics ---
1 packets transmitted, 0 received, 100% packet loss, time 0ms
real 0m20.015s
user 0m0.003s
sys 0m0.003s
Algunos experimentos parecieron verificar que la MTU es efectivamente 1500 en la WAN:
$ ip addr show dev eth0 | grep "inet\b" && time for i in {1..2}; do ping -c 1 -s 1472 google.se ; done
inet 80.216.153.211/22 brd 80.216.155.255 scope global eth0
PING google.se (216.58.209.131) 1472(1500) bytes of data.
72 bytes from arn09s05-in-f3.1e100.net (216.58.209.131): icmp_seq=1 ttl=59 (truncated)
--- google.se ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 4.497/4.497/4.497/0.000 ms
PING google.se (216.58.209.131) 1472(1500) bytes of data.
72 bytes from arn09s05-in-f3.1e100.net (216.58.209.131): icmp_seq=1 ttl=59 (truncated)
--- google.se ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 4.454/4.454/4.454/0.000 ms
real 0m0.034s
user 0m0.003s
sys 0m0.003s
$ ip addr show dev eth0 | grep "inet\b" && time for i in {1..2}; do ping -c 1 -s 1473 google.se ; done
inet 80.216.153.211/22 brd 80.216.155.255 scope global eth0
PING google.se (216.58.209.131) 1473(1501) bytes of data.
--- google.se ping statistics ---
1 packets transmitted, 0 received, 100% packet loss, time 0ms
PING google.se (216.58.209.131) 1473(1501) bytes of data.
--- google.se ping statistics ---
1 packets transmitted, 0 received, 100% packet loss, time 0ms
real 0m20.018s
user 0m0.001s
sys 0m0.007s
En la LAN, el punto de interrupción tiene el mismo tamaño de paquete, pero debo especificar manualmente que no permito que se rompa la fragmentación del paquete:
$ ip addr show dev eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether 68:b5:99:e7:07:a8 brd ff:ff:ff:ff:ff:ff
inet 10.11.12.162/24 brd 10.11.12.255 scope global eth0
valid_lft forever preferred_lft forever
inet6 fe80::6ab5:99ff:fee7:7a8/64 scope link
valid_lft forever preferred_lft forever
$ ping -c 1 -s 3000 google.se
PING google.se (83.255.235.35) 3000(3028) bytes of data.
3008 bytes from 83.255.235.35: icmp_seq=1 ttl=61 time=82.3 ms
--- google.se ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 82.324/82.324/82.324/0.000 ms
$ ping -c 1 -s 1472 -M do google.se
PING google.se (83.255.235.123) 1472(1500) bytes of data.
1480 bytes from cache.google.com (83.255.235.123): icmp_seq=1 ttl=61 time=74.7 ms
--- google.se ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 74.779/74.779/74.779/0.000 ms
$ ping -c 1 -s 1473 -M do google.se
PING google.se (83.255.235.35) 1473(1501) bytes of data.
ping: local error: Message too long, mtu=1500
--- google.se ping statistics ---
1 packets transmitted, 0 received, +1 errors, 100% packet loss, time 0ms
No entiendo qué está mal con mi red y no sé cómo solucionarlo más. Ayúdenme a reestructurar la resolución de problemas para poder eliminar los fantasmas de la red de una vez por todas.
EDITAR, con respecto a mi configuración de DNS:
Si lo entiendo correctamente, significa que los solucionadores de Google solo se utilizan como alternativa cuando el servidor de nombres asignado por DHCP del ISP no está disponible. ¿Es eso correcto? ¿O estoy pidiendo direcciones al azar a un servidor de nombres muy, muy lejano?
Como puede ver a continuación, pfsense intenta manejar la resolución de nombres por sí solo primero, preguntando al ISP en segundo y tercer lugar y solo recurre a Google como cuarta y quinta opción, lo que me parece bastante razonable.
El Apple TV tiene configuraciones de red asignadas por DHCP y utiliza la puerta de enlace como servidor de nombres. El servidor DHCP no tiene configuraciones DNS dedicadas, pero hereda la lista de servidores de nombres anterior:
EDITAR, con respecto al bucle for:
La razón para ejecutar ping 100 veces en lugar de una vez con 100 paquetes es/era realizar la resolución de nombres cada vez, ya que parecía llevar cantidades de tiempo bastante variables "iniciar" el ping cuando lo ejecuté a mano y pensé que tal vez Podría hacer que ese sentimiento sea más distintivo multiplicando la acción por 100.
Dado que Ubuntu tiene la siguiente configuración:
$ grep nameserver /etc/resolv.conf
nameserver 127.0.1.1
Ese pensamiento podría ser un poco tonto y duro...
EDITAR, con respecto al Apple TV:
He restablecido el Apple TV a los valores predeterminados de fábrica. He desconectado el dispositivo en múltiples ocasiones (a veces con no tan poca furia en la sangre).
EDITAR, pfSense:
El otro día configuré pfSense por defecto y solo volví a habilitar las partes más esenciales (dns, dhcp, nat, arrendamientos de dhcp estáticos, algunos reenvíos de puertos), pero ayer Netflix aún dejó de reproducirse a mitad de camino. Sin embargo, el problema volvió a desaparecer, por lo que reiniciar la película funcionó.
Me pregunto si Netflix necesita DNS a mitad de camino, siento que eso ya debería estar solucionado para entonces.
Y dado que el servidor ejecuta la última versión de pfsense (2.2.2), utilizasin consolidarpor defecto.
Se puede verificar que el solucionador esté almacenando en caché las resoluciones correctamente realizando dos búsquedas consecutivas con la herramienta de diagnóstico:
Sin embargo, las diferentes respuestas me confunden.
EDITAR, MTU:
La MTU está configurada en automático.
EDITAR, prueba de velocidad de ATV:
Hacer una prueba de velocidad en el Apple TV produce el siguiente gráfico en pfsense:
Después de lo cual el Apple TV dice "la prueba finalizó exitosamente", pero solo por una fracción de segundo, luego cambia a:
Puedo usar Netflix a pesar del error.
Respuesta1
Asegúrese de utilizar el servidor DNS de su ISP local, no algún servicio DNS distante.
La mayor parte del contenido que puede descargar o transmitir a su Apple TV proviene de la CDN de Akamai (Apple ha sido uno de los mayores clientes de Akamai durante años). Akamai encuentra el nodo perimetral (servidor) CDN más cercano a usted en función de dónde proviene su búsqueda de DNS, y su búsqueda de DNS generalmente proviene de cualquier servidor DNS local recursivo/de resolución que haya configurado para usar en su dispositivo cliente.
Asegúrese de que su Apple TV esté configurado para usar los servidores DNS de su ISP local, y no algunos servidores potencialmente distantes como Google DNS (8.8.8.8 y 8.8.4.4) o Nivel 3 (4.2.2.x) u OpenDNS o cualquier otro similar. Tenga en cuenta que su Apple TV puede estar obteniendo su configuración DNS a través de DHCP, y su servidor DHCP puede ser un proceso en su enrutador/puerta de enlace. Si el servidor DHCP le indica a su Apple TV que use la dirección IP privada de su puerta de enlace NAT (u otro firewall o enrutador local) como su dirección DNS, significa que su puerta de enlace NAT está actuando como un proxy DNS. Si desea seguir haciendo eso, asegúrese de que esa puerta de enlace NAT esté utilizando los servidores DNS de su ISP local comoesServidores DNS.
Al utilizar un servidor DNS local, Akamai le indicará a su cliente que realice solicitudes de descarga/transmisión desde su servidor Akamai más cercano en Suecia, a diferencia de, digamos, algún servidor cerca de un centro de datos de Google en los EE. UU. donde se encuentra el servidor DNS 8.8.8.8 de Google. situado.
[Incluso si esta no es la respuesta correcta para usted, podría ser la respuesta correcta para otras personas que encuentren esta pregunta, así que la dejaré aquí de todos modos.]