[GTER] Packet Loss - Mikrotik

[Alisson]

ja tentou deixar sem rodar este seu script?

para ver se é ele quem está causando este alto processamento na RB?

ja tentou ohar o menu Tools > Profile para ver o que está com processamento
elevado?


Em 12 de maio de 2013 21:52, Antonio Carlos Sanches
<asanches at omni.net.br>escreveu:

> Qual a versao do ROS ?
>
>
> Em 10 de maio de 2013 22:31, Daniel Gurgel
> <daniel.gurgel at secrel.net.br>escreveu:
>
> > Pessoal,
> >
> > A historia é um pouco grande, vamos lá... recentemente decidimos mudar o
> > controle dos acessos de nossos usuários para algo mais fácil
> > administrativamente (tínhamos Linux + HTB + um Shell que atualizava as
> > regras em iptables de acesso dos clientes,
> liberando/suspendendo/cancelando
> > clientes - tudo funcionava perfeitamente, no entanto com o custo da
> > administração). Temos aproximadamente 1500 usuários nesse servidor -
> > Xeon/8gb/hdd sata, consumo médio de 130Mb.
> >
> > Migramos nos últimos dias para uma RouterBoard 1100Hx2, versão 5.25,
> > configurada da seguinte forma:
> > - Duas interfaces de rede (Externa e Trunk, para as VLANs de cada POP com
> > os respectivos clientes), funcionava dessa forma no Linux, tudo conectado
> > em switches Gigabit;
> > - NAT/Masquerades feito com o uso de address-list;
> > - Queue Simple, Interface All, uma classe-pai e classe-parents para o
> > clientes finais (prédio/segmento), com as respectivas bandas para os
> > clientes em  1Mbps, 5Mbps, 10Mbps, 15mbs...;
> > - Atualizamos nosso shell (script executado diretamente da RB, via sched)
> > para que todas as regras fossem geradas por nosso sistema interno e
> > atualizados de tempos em tempos. No linux tínhamos a atualização de
> regras
> > a cada 30 minutos, na RB adotamos a execução a cada 04 horas.
> >
> > Surgem os problemas:
> > 1. No primeiro momento, todos os clientes e a propria RB não tem
> > performance, ou seja, dos 130Mb médios, não conseguimos passar de 20mb
> para
> > Up/Down. (Descartamos problemas nas regras de queue -
> > excluindo/desativando, o comportamento permanece o mesmo).
> > 2. Perda de pacotes em todas as interfaces fisicas/vlans da RB.
> Realizamos
> > a troca para outras portas, alternando entre todas as ethers e o
> > comportamento não mudou. Forçamos no switch a negociação para duplex
> > full/speed 1000, o problema continuou. Chegamos a trocar de switch, para
> > uma 2960S zerada e o problema de perda continuou.
> > 3. Mudamos os parâmetros na Queue Type/Interfaces Queues, em todos os
> > casos, o problema persistiu. A melhor configuração que tivemos foi usar
> > SFQ, pertub 10, Allot 1514bytes (até ai nada diferente do que tínhamos
> com
> > o HTB).
> >
> > Num passe de mágica, independente da mudança realizada, quando já
> > estávamos decidindo voltar para o Linux, a RB "desentope" e o tráfego
> sobe
> > novamente para os 130Mb, a perda de pacotes some e tudo normaliza.
> >
> > 4. Não satisfeito, trocamos a RB por outra de mesmo modelo (incluindo
> todo
> > cabeamento, switches e instalação elétrica), o problema se repetiu, a
> > normalização ao acaso também. Chegamos a um detalhe quanto a utilização
> da
> > RAM, dos 750Mb disponíveis, estávamos com apenas 70Mb livres (devido a
> 775
> > regras de Queue para clientes). Rebootamos sem as regras de queue e o
> > comportamento foi o mesmo.
> >
> > 5. Trocamos a RB por um Xeon, placa de rede Intel dual com multi-filas
> > para tx/rx (alteramos também as IRQ para cada Core) e 8Gb de ram. O
> > comportamento foi o mesmo, excluímos então o problema de recursos na
> > RouterBoard. Um detalhe, em horário de picos, a CPU não chega a de 65%,
> > acredito que esse valor seja aceitável, porém mesmo com a CPU baixa, o
> > problema continuava, normalizando sem causa aparente.
> >
> > 6. Após alguns dias com o acesso normalizado, porém sem detectamos a
> causa
> > dos problemas acima, notamos que durante a execução de nossas regras via
> > script (atualização de address-list, NAT, queues), a RB mesmo com
> > processamento baixo, apresentava perda de pacotes durante a execução. O
> > tempo de download e execução das regras via FTP estava demorando cerca de
> > 30 minutos e para completar nesse meio tempo, toda a RB sofria de perda
> de
> > pacotes e consequentemente os clientes abaixo dela. Quando o script
> conclui
> > a execução, as perdas de pacote somem e todos os acessos ficam
> normalizados.
> >
> > Bom, isso resume um pouco do que foi feito ate agora. Alguma luz para
> > resolução desse problema? Achamos a solução do RouterOs bem mais
> amigável e
> > não imaginávamos que teríamos esse tipo de problema. Vemos cases de
> outros
> > provedores, algumas vezes ate com maior tráfego e sem problemas. Gostaria
> > da ajuda do Srs. ou pelo menos a troca de experiencia para chegar ao
> final
> > desse caso.
> >
> > Agradeço desde já o retorno.
> > Daniel M.
> > --
> > gter list    https://eng.registro.br/mailman/listinfo/gter
> >
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter
>