Durante muito tempo tive um problema indescritível com minha rede.
Troquei roteador, ponto de acesso e fiz conexões sem fio com fio em busca de um ladrão de desempenho sem chegar mais perto de entender o que há de errado com minha configuração.
O problema é tão vago quanto "a rede parece lenta" e nenhum sintoma específico do problema foi persistente o suficiente para que eu pudesse encontrar sua causa raiz.
Minha infraestrutura atual é composta por:
Uma máquina virtual pfsense rodando em esxi. Atualmente a única VM em execução no host (Proliant ML110, Core 2 Duo) para eliminar as outras VMs como ladrões de desempenho. O servidor possui duas NICs, uma para WAN e outra para LAN.
Três switches Procurve 1800/1810 de 8 e 24 portas. Duas VLANs, uma para LAN e outra para WAN.
Um Ubiquiti Unifi UAP-AC.
Essa rede atende 20 unidades com conectividade.
Ontem houve um problema mais persistente em que não consegui iniciar um filme no Netflix, um pouco de pesquisa no Google me trouxeaquidepois de ter suporte da Netflix, diga-me que o problema não é com eles, mas com meu ISP.
A descrição aí corresponde bem aos problemas que tenho, iniciar o aplicativo é muito lento, a reprodução nem sempre funciona.
Tentei desconectar o Apple-TV e conectar meu Macbook usando o mesmo cabo. No computador, o Netflix funcionou sem problemas. Executando um teste de velocidade naquele mesmo cabo, verifiquei minha largura de banda em 100 megabits bidirecionais. Reconectar o Apple-TV Netflix recusou-se a funcionar.
Mudar a vlan da porta à qual o Apple-TV está conectado da LAN para a WAN fez com que ele se conectasse diretamente à internet com um IP público, com o qual poderia transmitir o filme sem problemas.
Colocá-lo novamente na reprodução da LAN falhou novamente. Desconectei tudo, exceto o Apple-TV e o uplink do switch. Fui até o switch com internet entrando, desconectei tudo menos as duas portas pfsense, a conexão com o conversor de fibra e o uplink para o switch com o Apple-TV. Depois disso, foi possível iniciar a reprodução.
Conseqüentemente, concluí que deveria ser capaz de identificar o causador de problemas reconectando tudo e ver qual cabo interrompe a reprodução. Nenhum o fez. Tudo continuou funcionando quando tudo foi conectado novamente.
Essa tem sido minha experiência sempre que tento descobrir por que minha conexão funciona mal. Em 100 megabits bidirecionais deveria ser bastante rápido, mas várias vezes desliguei o wifi do meu celular porque o 4G é mais rápido. O Speedtest sempre mostra 100 megabits.
O streaming parece particularmente difícil de controlar, espelhar minha tela usando airplay é praticamente inútil. Reproduzir música usando a mesma tecnologia funciona, mas interrupções na reprodução são comuns.
Embora ontem contornar o firewall parecesse indicar que ele é o bandido em tudo isso, hoje os resultados são 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
Além disso, para tentar verificar o MTU da rede (de acordo com a teoria do fórum da Apple), tentei executar ping com diferentes tamanhos de pacotes da WAN, meus testes mostrando que pacotes grandes não atravessavam bem a rede:
$ 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
Algumas experiências pareceram verificar se o MTU é de fato 1500 na 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
Na LAN, o ponto de interrupção tem o mesmo tamanho de pacote, mas devo especificar manualmente que não permito a fragmentação do pacote:
$ 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
Não entendo o que há de errado com minha rede e não consigo descobrir como solucionar o problema. Por favor, ajude-me a reestruturar minha solução de problemas para que eu possa livrar a rede de fantasmas de uma vez por todas.
EDIT, em relação às minhas configurações de DNS:
Se bem entendi, significa que os resolvedores do Google são usados apenas como substituto quando o servidor de nomes atribuído pelo DHCP do ISP não está disponível. Isso está correto? Ou estou pedindo endereços aleatoriamente a um servidor de nomes muito distante?
Como você pode ver abaixo, o pfsense tenta lidar com a resolução de nomes sozinho primeiro, perguntando ao ISP em segundo e terceiro lugar e recorrendo apenas ao google como quarta e quinta opções, o que me parece bastante razoável?
A Apple TV possui configurações de rede atribuídas por DHCP e usa o gateway como servidor de nomes. O servidor DHCP não possui configurações de DNS dedicadas, mas herda a lista de servidores de nomes acima:
EDIT, em relação ao loop for:
A razão para executar o ping 100 vezes em vez de uma vez com 100 pacotes é/era para ter a resolução de nomes executada a cada vez, pois parecia levar uma quantidade de tempo bastante variável para "iniciar" o ping quando o executei manualmente e pensei que talvez eu poderia tornar esse sentimento mais distinto multiplicando a ação por 100.
Dado que o Ubuntu tem a seguinte configuração:
$ grep nameserver /etc/resolv.conf
nameserver 127.0.1.1
Esse pensamento pode ser um pouco bobo e difícil...
EDITAR, em relação ao Apple TV:
Redefini o Apple TV para os padrões de fábrica. Desliguei o dispositivo em várias ocasiões (às vezes com não tão pouca fúria no sangue).
EDITAR, pfSense:
Outro dia, padronizei o pfSense de fábrica e reativei apenas as partes mais essenciais dele (dns, dhcp, nat, arrendamentos estáticos de dhcp, alguns encaminhamentos de porta), mas ontem o Netflix ainda parou de reproduzir no meio do stream. O problema desapareceu novamente, então reiniciar o filme funcionou.
Eu me pergunto se a Netflix precisa de DNS mid stream, parece que isso já deveria ter sido resolvido até então.
E como o servidor está rodando a versão mais recente do pfsense (2.2.2), ele usanão vinculadopor padrão.
Se o resolvedor está armazenando em cache as resoluções com êxito, pode ser verificado fazendo duas pesquisas consecutivas com a ferramenta de diagnóstico:
As diferentes respostas me confundem.
EDITAR, MTU:
O MTU está definido como automático.
EDITAR, teste de velocidade do ATV:
Fazer um teste de velocidade na Apple TV produz o seguinte gráfico no pfsense:
Depois disso, a Apple TV diz "teste concluído com sucesso", mas apenas por uma fração de segundo, e depois muda para:
Posso usar o Netflix apesar do erro.
Responder1
Certifique-se de usar o servidor DNS do seu ISP local, e não algum serviço DNS distante.
A maior parte do conteúdo que você pode baixar ou transmitir para sua Apple TV vem por meio do Akamai CDN (a Apple é um dos maiores clientes da Akamai há muito tempo). A Akamai encontra o nó de borda CDN (servidor) mais próximo de você com base na origem de sua pesquisa de DNS, e sua pesquisa de DNS geralmente vem de qualquer servidor DNS recursivo/de resolução local que você configurou para usar no dispositivo cliente.
Certifique-se de que sua Apple TV esteja configurada para usar os servidores DNS do seu ISP local, e não alguns servidores potencialmente distantes, como Google DNS (8.8.8.8 e 8.8.4.4) ou Nível 3 (4.2.2.x) ou OpenDNS ou qualquer outro semelhante. Observe que sua Apple TV pode estar recebendo configurações de DNS via DHCP e seu servidor DHCP pode ser um processo em seu roteador/gateway. Se o servidor DHCP estiver informando à sua Apple TV para usar o endereço IP privado do seu gateway NAT (ou outro firewall ou roteador local) como endereço DNS, isso significa que o seu gateway NAT está agindo como um proxy DNS. Se você quiser continuar fazendo isso, certifique-se de que o gateway NAT esteja usando os servidores DNS do seu ISP local comoisso éServidores DNS.
Ao usar um servidor DNS local, a Akamai direcionará seu cliente para fazer solicitações de download/transmissão do servidor Akamai mais próximo na Suécia, em vez de, digamos, algum servidor próximo a um data center do Google nos EUA, onde o servidor DNS 8.8.8.8 do Google está localizado. localizado.
[Mesmo que esta não seja a resposta certa para você, pode ser a resposta certa para outras pessoas que encontrarem essa pergunta, então vou deixá-la aqui de qualquer maneira.]