[GTER] Packet Loss - Mikrotik

[Paiva, Gilson de]

Experimente fixar a taxa de transmissão nas interfaces da rb e no seu
switch.

Tivemos comportamento parecido com o cenário descrito que se resolveu desta
forma.

Boa sorte!
On May 12, 2013 8:21 PM, "Daniel Gurgel" <daniel.gurgel at secrel.net.br>
wrote:

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