[GTER] Packet Loss - Mikrotik

[Daniel Gurgel]

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.