Página 2 de 2 PrimeiroPrimeiro 12
+ Responder ao Tópico



  1. 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?

  2. 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ó.



  3. 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.

  4. 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.



  5. 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 • 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.






Tópicos Similares

  1. Navegação Lenta e Download Normal
    Por Claudineibj no fórum Redes
    Respostas: 6
    Último Post: 05-04-2013, 07:59
  2. Respostas: 9
    Último Post: 28-03-2011, 00:36
  3. Download rápido e Internet Lenta
    Por DSSS no fórum Redes
    Respostas: 8
    Último Post: 15-06-2010, 21:13
  4. Squid + Iptables -> Navegaçao lenta nas estaçoes...
    Por marcelo0 no fórum Servidores de Rede
    Respostas: 3
    Último Post: 06-06-2005, 22:50
  5. Navegacao Lenta
    Por mmedinabr no fórum Servidores de Rede
    Respostas: 0
    Último Post: 01-10-2004, 14:10

Visite: BR-Linux ·  VivaOLinux ·  Dicas-L