[GTER] Packet Loss - Mikrotik

[Leonardo Costa]

Daniel, você pode enviar o script?! Seguinte, tenho um cenário onde tem um servido HP ML 110 ethernet Intel pro dual, com +/- 150 megas e 1200 clientes online, quando usamos no servidor HP a CPU fica aproximadamente em 35~40% contudo se analisar os núcleos separadamente temos para core0 60~65% core1 50~60% core2e3 5~7% esses são valores máximos em horario de pico o RouterOS na versão 5 nao consegue colocar a interface em 2 núcleos logo tenho ether1 em core0 ether2 em core1   e assim por diante, mesmo ficando em auto ele faz desta forma. É bom ver como ficam os núcleos para você compreender o que acontece quando você roda o script. colocamos uma CCR 1036 que faz em gerenciamento melhor quanto ao uso das interface e trafego, mas estamos com problemas com uso de fast e queues. Então no 
momento voltamos a usar o HP.

Enviado via iPhone

Em 10/05/2013, às 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