[GTER] Packet Loss - Mikrotik

[Antonio Carlos Sanches]

Desculpe, vi la em cima, 5.25. Uso uma aqui com 5.24 com o mesmo volume de
uso seu, não tenho nenhum desses problemas, só que uso PPPoE e fica bem
menos clientes ON Line, uma media de 450~500, mas passando os mesmo 130~140
MB.


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