Download rápido, navegação lenta. Packet loss 20% e CONNECTION_TIMED_OUT

Bom dia,

aos que quiserem ajudar uma alma perdida, o negócio é o seguinte:

uso uma RB450G para controlar a rede de um hotel (com moradores mensalistas). A conexão é de 15M da GVT e eu distribuo para os quartos, 1M para cada, com simplequeue, burst de 2M de 8s. São mais ou menos 60 usuários, mas raramente tem mais de 10 conectados.

tenho uma interface que dá num switch 24 portas e redistribui para alguns quartos, outra interface é wireless, liga num switch 8 portas, este por sua vez ligado em outro switch 8 portas e deles saem cabos para 7 AP em bridge espalhados pelo prédio.

o modem que a GVT mandou já veio roteado e eu nunca mexi nele, porque tenho medo de estragar tudo.

faço controle com layer7 copiado deste aqui: Basic traffic shaping based on layer-7 protocols - MikroTik Wiki

no firewall tenho configurações para dropar vários tipos de vírus (coisas que vi em tópicos aqui do under), bloqueio de NETBIOS, bloqueio da porta 0 UDP, limite de sessões por IP (25 sessões -- e para os que usam muito Ares eu diminuo pra 5 até eles desistirem).

já troquei o MTU pra vários valores diferentes, mas não adiantou nada, hoje deixo em 1480 para wireless e 1500 para os outros.

o DNS já testei usar o da operadora, o do Google, um outro aí que disseram que era "o Google brasileiro" e OpenDNS, mas tudo dá na mesma.

Não faço Web Proxy nem Cache Full nem nada. Acredito que se fizesse melhoraria bastante, mas mesmo sem fazer, o que está acontecendo não devia estar.

--------------------------

acontece que a conexão às vezes vai bem, às vezes vai mal (e pode variar a cada 2min, por aí). Quando vai bem, abre tudo, quando vai mal, demora horas para carregar uma página simples e às vezes não carrega imagens nem nada. Na maior parte do tempo está mal. Quanto mais usuários estiverem conectados, pior fica, mesmo que não exceda a banda (nunca excede). Mas mesmo que só tenha eu mesmo conectado, ainda assim é problemático.

O download, se conseguir ser iniciado, fica sempre na velocidade máxima.

o Gooogle Chrome acusa "Erro 118 (net::ERR_CONNECTION_TIMED_OUT): O tempo limite da operação foi atingido." quando não consegue abrir as páginas e o TRACERT do Windows acusa o seguinte:

Rastreando a rota para UOL - O melhor conte [200.221.2.45] com no máximo 30 saltos:

1 <1ms <1ms <1ms 192.168.15.1 [aqui é o ip da RB]
2 3ms 3ms 3ms 192.168.1.254 [aqui o ip do modem GVT]
3 * * * Esgotado o tempo limite do pedido.
4 * * * Esgotado o tempo limite do pedido.
5 * * * Esgotado o tempo limite do pedido.
6 * * * Esgotado o tempo limite do pedido.
7 * * * Esgotado o tempo limite do pedido.
8 * * * Esgotado o tempo limite do pedido.
9 36ms 29ms 29ms home.uol.com.br [200.221.2.45]

Rastreamento concluído.

(isto tentando de um computador ligado com cabo direto na RB numa interface exclusiva)

Alguém tem idéia do que pode ser ?
Já sou enormemente grato só por você ter lido até aqui: muito obrigado.

Olha tenho tipo 99% de certeza que o problema é o layer7! Ja experimentou retirar todas essas regras? Pelo que eu vi ele esta usando strings ou seja ele esta usando o match string. Cara isso é horrivel! É possivel utilizar esse eskema, totalmente, mas pode acontecer coisas inexperadas, totalmente! Oque esse cara faz e dropar o pacote com a determinada string. Mas isso é um tanto quanto loucura. Nem em teoria parece ser eficiente. É mais facil trabalhar fechando tudo é liberando portas especificas e sim, colocar um Squid! IMO.

Na verdade já estava ruim antes d'eu colocar esse layer7 e eu o coloquei porque antes não conseguia controlar o bittorrent e achei que a culpa fosse dele. Agora eu consigo controlar, mas a navegação continua ruim.

Mas talvez você tenha razão em parte, porque depois que eu coloquei ouvi reclamações do pessoal falando que tinha piorado, mas achei que fosse coincidência deles terem pegado um dia ruim e tal (também imaginei que quem reclamou era quem usava bittorrent e estava vendo que a velocidade dos torrents diminuíra). Em todo caso, vou experimentar desativar os layer7 e ver o que acontece.

Vi num outro tópico aqui alguém com um problema parecido, mas lá acabou que a causa do problema era que alguns clientes com sinal wireless ruim estavam prejudicando TODA a rede. É uma possibilidade que eu nunca considerei. É possível isto? Mesmo em interfaces diferentes?

amigo já fez o teste limpando o firewall e o layer 7?
se tu usa DSL (se é GVT é 99% certo) o acesso já é compartilhado e com esse firewall cheio de regras de FORWARD e INPUT realmente não vai dar boa coisa.

abraço e aguardo retorno.

ah e posta melhor como é essa rede.

entao, eu dei uma olhada denovo no que vc disse, e eu acho que talvez vc devesse limpar seu firewall e substituir sua tatica de layer7, pra traffic shaping. Uma outra abordagem seria o controle de acesso de quais portas externas podem ser acessadas pelos clientes... exemplo: se vc permitir que eles acessem a porta 53 udp e 80 tcp, isso ja da acesso ao web browser. Na verdade pode parecer muito trabalhoso, mas na verdade simplifica demais oque realmente esta em uso na rede. o layer7 pode ser muito util, mas deve ser bem testado.

Bom. Desativei o firewall todo aqui. Vamos ver o que acontece.

felco, como seria esse traffic shapping a que você se referiu? achei que o controle com o layer7 fosse traffic shapping. a outra idéia é bloquear todas as portas e abrir só as que eu achar que devo (por exemplo, só 53 udc e 80 tcp) ?

Essa lentidão que aparece no tracert, por exemplo, pros pacotes encontrarem seu destino, ela tem a ver com o firewall? Eu fico imaginando que seja culpa do modem roteado da GVT. É? Ou o modem roteado não traz nenhum prejuízo à rede?

agrinfo, a estrutura da rede é mais ou menos assim (não sei se tem um esquema padrão pra desenhar a estrutura, então, vou ligar com setinhas):

DSL da GVT --> modem roteado --(DHCP)--> RB450G --> 4 interfaces:
. interface internet: recebe o sinal via DHCP client;
. interface cabo --> DHCP --> Switch 24 portas --> quartos
. interface wireless --> DHCP --> Switch 8 portas -> saem 6 cabos pra 5 5460 (em modo AP-bridge);
. . e um outro Switch 8 portas --> 2 cabos pra 2 APs (em modo AP-bridge)
. interface portaria --> o computador onde eu estou agora e só.

Traffic Shaping é um feature do kernel Linux, no mikrotik não sei se esta disponivel. É conhecido tambem como iproute2.
O cara que faz as queue chama-se 'tc'. Esse metodo de layer7 é extremamente poderoso, só que deve ser muito extensivamente testado, pelo menos eu tive problema com ele. Eu utilizava o match string, que se nao me falha a memoria era --mstring como parametro do iptables.
Sobre o tracert, esta normal, nem sempre todos os saltos nos mostram um endereco valido, o importante no tracert é a latencia em cada salto medido e se o destino será alcançado, e tambem é muito bom pra saber como seu provedor esta te enviando pra internet e qual o caminho até essa saída e por onde, principalmente, vc está saindo. Alias, esse tracert ta cruel em, não da pra saber como vc está chegando no UOL, ou melhor por onde haha.
Bom, eu acredito que o TS é uma otima solução ai no seu caso, uma vez que vc pode separar por partes a sua banda disponivel e tambem acrescentar uma certa 'folga' para trabalhar com o link, um link demasiadamente saturado é muito problematico para os clientes. Uma outra coisa que me ocorreu, e que vc deveria verificar é se o seu provedor não esta limitando sua conexão de alguma maneira, como limitar o numero de sessoes tcp. Mas de qualquer maneira, o TS é uma otima solucao nesse caso e limitar o numero de conexoes por cliente tambem pode ser necessario.

Estou com a impressão de que tirar as regras do firewall funcionou maravilhosamente, mas só para quando tem poucos usuários conectados (à noite fica ruim de novo). Como é que eu faço pra pra bloquear todas as portas e abrir só pra navegação, downloads comuns e afins? Quais portas é normal deixar aberta neste tipo de situação?

O esquema do traffic shapping eu não tenho esperança de conseguir fazer em pouco tempo, a menos que eu encontre um guia prático ilustrados (e que seja possível no Mikrotik), então vamos tentar com esse bloqueio de portas.

A princípio vou tentar limitar o número de sessões por IP da galera aqui e ver se melhora à noite.

deixando uma resposta aqui pra quem por acaso chegar:

resolvi o problema realizando três ações mais-ou-menos simultâneas, foram elas:

- a primeira delas foi pedir para a GVT o plano com IP fixo, que eu desconfiava que vinha junto com o fim do LIMITE DE SESSÕES TCP/IP que os planos comuns têm.
- em seguida eu apliquei esta regra de priorização de navegação HTTP sobre downloads: MikroTik RouterOS &bull; View topic - Http browsing over download Prioritization
- no mesmo dia também retirei todos os limites de sessões que eu mesmo impunha aos meus usuários no Mikrotik (em geral 25 pra cada).

a retirada do limite de sessões eu já tinha tentado várias vezes, ficava tirando e recolocando e nunca notava diferença na qualidade da navegação. em compensação a priorização de tráfego era algo que meu controle com layer7 devia fazer, mas nunca tinha adiantado nada, e eu também não achava que era o excesso de downloads que estava prejudicando a conexão. a mudança na GVT eu não sei o que fez, então não posso saber se foi ela a parte decisiva no processo.

a única pista que eu tenho sobre as causas da melhora da navegação aqui são que tudo SÓ FUNCIONOU depois d'eu ter tirado a regra de limite de sessões. desconfio, portanto de que os usuários precisassem de mais sessões para navegar do que eu estava dando, e ao mesmo tempo a GVT limitava o número de sessões a um número ridiculamente baixo, com o fim simultâneo dessas duas limitações, tudo passou a fluir bem.

esta explicação não bate com o uso -- que eu mesmo já vi -- de conexões GVT iguais à minha em redes grandes e lan-houses sem nenhum roteamento central, mas ainda assim é uma explicação possível.