Guia de Diagnóstico MikroTik RouterOS - Fluxogramas de Troubleshooting de Redes

Manual de consulta técnica com fluxogramas para diagnóstico e resolução de problemas no MikroTik RouterOS: falhas de internet, DHCP, VLANs, VPNs, BGP, filas e CPU alta.

outubro 26, 2026
2:08 pm

Metodologia de Troubleshooting Avançado em MikroTik RouterOS

A administração profissional de redes corporativas estruturadas sobre **MikroTik RouterOS** exige um processo estrito de diagnóstico lógico. Alterar parâmetros de roteamento, regras de firewall ou políticas de filas sem seguir uma metodologia analítica de causa e efeito frequentemente introduz novos pontos de falha no ambiente de produção. Para garantir a resolução rápida de incidentes e a alta disponibilidade de links, elaboramos este guia de referência rápida contendo **fluxogramas de solução de problemas (troubleshooting)**.

📊 Painel Metodológico: Engenharia de Diagnóstico no RouterOS
Escopo do Guia	Cenários Práticos (WAN, LAN, DHCP, DNS, VLANs, Firewall, NAT, VPNs, QoS e Hardware)
Ferramentas Nativas de Análise	`/tool ping`, `/tool traceroute`, `Torch`, `Packet Sniffer` e `/tool profile`
Nível de Aplicação	Administração de Redes Sênior / SysAdmin / Projetos de Borda e Core Router

⚠️ Diretriz Fundamental de Segurança e Troca de Parâmetros

Nunca altere múltiplas regras de Firewall ou rotas simultaneamente sem antes validar a conectividade básica da camada física (L1) e da camada de enlace (L2). Certifique-se sempre de manter um acesso seguro via porta de Console ou via MAC WinBox antes de aplicar alterações em interfaces WAN ativas.

Fluxogramas de Diagnóstico e Resolução de Problemas no RouterOS

01. Internet sem acesso

Objetivo: Localizar a causa provável antes de alterar outras configurações do roteador.
Primeiro Teste: O cliente possui link físico ativo (L1/L2)?
- SE NÃO: Confira cabo, porta, negociação duplex e status da interface WAN.
- SE SIM: Prossiga para a verificação do endereço IP da interface WAN.
SE AINDA FALHAR: Endereço IP ausente na WAN → Revise configurações do cliente DHCP, cliente PPPoE ou atribuição estática.
ATENÇÃO: Evite alterar servidores DNS antes de confirmar conectividade IP fim a fim.
PRÓXIMO PASSO: Validar gateway padrão em /ip route.

02. WAN sem endereço IP

Objetivo: Identificar o motivo do link WAN não obter IP da operadora ou provedor.
Primeiro Teste: A interface WAN está habilitada e ativa?
- SE NÃO: Vá em Interfaces > WAN > Enable e verifique a integridade física do cabo.
- SE SIM: Verifique o status do cliente DHCP, discador PPPoE ou IP estático.
SE AINDA FALHAR: Sem resposta da operadora → Confirme o ID da VLAN de entrega, credenciais do PPPoE e bloqueios no modem do provedor.
ATENÇÃO: Não atribua IPs manualmente sem confirmação prévia das sub-redes da operadora.
PRÓXIMO PASSO: Checar os contadores em /interface print.

03. Gateway offline

Objetivo: Diagnosticar a indisponibilidade do Gateway de saída.
Primeiro Teste: O enlace físico da porta de saída está ativo?
- SE NÃO: Reative a porta, substitua o patch cord ou verifique o equipamento da operadora.
- SE SIM: Dispare testes de ICMP diretamente para o IP do gateway e para o monitor de rota.
SE AINDA FALHAR: Gateway responde ao ping, mas o monitor marca offline → Revise a rota do Monitor IP e os alvos de `check-gateway`.
ATENÇÃO: Não desative o monitor de gateway apenas para ocultar o alerta no painel.
PRÓXIMO PASSO: Executar /tool ping via WinBox ou Terminal.

04. Cliente não recebe IP (DHCP)

Objetivo: Resolver a falha na entrega de concessões de endereço IP via servidor DHCP.
Primeiro Teste: O cliente está conectado à interface física ou VLAN correta?
- SE NÃO: Ajuste o mapeamento de porta, o SSID associado ou a PVID da bridge.
- SE SIM: Acesse /ip dhcp-server e confirme se o serviço está em estado ativo (sem tarja vermelha).
SE AINDA FALHAR: Ausência de requisição DHCP Discover → Verifique o pool de endereços, agentes de relay e conflitos de porta na bridge.
ATENÇÃO: Nunca habilite um Servidor DHCP e um DHCP Relay simultaneamente na mesma interface lógica.
PRÓXIMO PASSO: Inspecionar as concessões em /ip dhcp-server lease.

05. DHCP entrega IP errado

Objetivo: Eliminar a atribuição de sub-redes incorretas ou identificar a presença de servidores DHCP maliciosos (Rogue DHCP) na LAN.
Primeiro Teste: O IP recebido pertence à sub-rede atribuída àquela interface específica?
- SE NÃO: Corrija o escopo do pool e a associação de interface no servidor DHCP.
- SE SIM: Verifique reservas estáticas de MAC Address e a presença de outro roteador na rede.
SE AINDA FALHAR: Outro servidor responde na rede → Isole a porta do switch e ative o recurso de DHCP Snooping.
ATENÇÃO: Evite utilizar faixas de endereçamento sobrepostas na mesma Bridge.
PRÓXIMO PASSO: Utilizar a ferramenta Torch ou Packet Sniffer para rastrear pacotes na porta UDP 67/68.

06. DNS não resolve nomes

Objetivo: Corrigir a falha de resolução de nomes de domínio no roteador ou na rede.
Primeiro Teste: O cliente consegue alcançar o IP do firewall MikroTik (Gateway)?
- SE NÃO: Corrija primeiro o roteamento IP, a conectividade de camada 2 ou o firewall filter.
- SE SIM: Execute um teste de resolução interna em /tool dns-lookup.
SE AINDA FALHAR: Resolução interna falha → Verifique os DNS recursivos de upstream (1.1.1.1, 8.8.8.8) e ative a opção `Allow Remote Requests` se o MikroTik for o DNS da LAN.
ATENÇÃO: Não confunda uma falha de resolução de nomes (DNS) com queda geral da conexão WAN.
PRÓXIMO PASSO: Revisar as configurações em /ip dns.

07. DNS resolve, mas internet falha

Objetivo: Tratar cenários onde o ping para nomes (ex: google.com) resolve o IP, mas o tráfego HTTP/HTTPS não navega.
Primeiro Teste: O cliente alcança um IP externo diretamente via ICMP (ex: `ping 1.1.1.1`)?
- SE NÃO: Confira a tabela de rotas, as regras de masquerade (NAT) e bloqueios na chain forward do firewall.
- SE SIM: Verifique os servidores DNS entregues via opção 6 do servidor DHCP aos clientes.
SE AINDA FALHAR: Navegação via IP funciona e via nome falha → Ajuste as políticas de MTU/MSS ou altere os servidores DNS da estação.
ATENÇÃO: Não altere as políticas globais de DNS do roteador sem isolar se o problema afeta apenas uma estação.
PRÓXIMO PASSO: Limpar o cache do resolvedor em /ip dns cache flush.

08. Wi-Fi conectado sem internet

Objetivo: Isolar falhas em redes sem fio locais (Wireless nativo ou CAPsMAN).
Primeiro Teste: O dispositivo sem fio recebeu IP, máscara e gateway válidos do servidor DHCP?
- SE NÃO: Revise o SSID, a associação com a VLAN correta e o servidor DHCP atribuído à interface virtual/CAPsMAN.
- SE SIM: Teste a conectividade por ping para o gateway e para um IP público na WAN.
SE AINDA FALHAR: Pings para o gateway funcionam, mas para a WAN falham → Verifique as regras de Firewall Filter e o Masquerade (NAT) da sub-rede sem fio.
ATENÇÃO: Nunca presuma que a associação física da chave WPA2/WPA3 garante o tráfego de dados para a internet.
PRÓXIMO PASSO: Inspecionar os registros na aba de associação em /interface wireless registration-table ou /capsman remote-cap.

09. VLAN sem comunicação

Objetivo: Resolver falhas de marcação de tags (802.1Q) e roteamento inter-VLAN.
Primeiro Teste: A tag VLAN (VLAN ID) está chegando corretamente ao MikroTik pela porta Trunk?
- SE NÃO: Revise as portas Trunk/Access no switch, o PVID da porta e as regras no equipamento de borda.
- SE SIM: Verifique a tabela em /interface bridge vlan e se a interface lógica de VLAN está associada à Bridge correta.
SE AINDA FALHAR: O gateway da VLAN não responde → Revise o IP atribuído à interface lógica da VLAN em /ip address e o serviço DHCP.
ATENÇÃO: Evite misturar portas tagged e untagged na mesma Bridge sem utilizar a arquitetura moderna de Bridge VLAN Filtering do RouterOS.
PRÓXIMO PASSO: Inspecionar o menu /interface bridge vlan.

10. VLAN alcança gateway, mas não internet

Objetivo: Liberar a navegação externa para sub-redes isoladas em VLANs.
Primeiro Teste: Existe uma rota padrão ativa para a tabela de roteamento principal daquela VLAN?
- SE NÃO: Crie ou corrija a rota estática em /ip route.
- SE SIM: Verifique se a regra de NAT (Masquerade/SRCNAT) contempla a sub-rede IP específica daquela VLAN.
SE AINDA FALHAR: Regra de NAT correta → Revise se a chain `forward` do Firewall Filter possui regras bloqueando o tráfego com destino à interface WAN.
ATENÇÃO: Não crie regras de permissão genéricas (`action=accept` sem filtro de origem) como solução paliativa.
PRÓXIMO PASSO: Conferir as regras no menu /ip firewall nat.

11. Firewall bloqueando tráfego legítimo

Objetivo: Ajustar as regras de filtro para liberar conexões legítimas bloqueadas por engano.
Primeiro Teste: A regra de liberação (`action=accept`) está posicionada acima da regra de bloqueio geral (`action=drop`)?
- SE NÃO: Mova a regra de exceção para cima na lista (a leitura do firewall é sequencial do topo para a base).
- SE SIM: Confira os parâmetros da regra: chain (input/forward), in-interface, out-interface, protocolo e portas.
SE AINDA FALHAR: O contador da regra não incrementa → Ative temporariamente a opção `log=yes` na regra para inspecionar os pacotes no log do sistema.
ATENÇÃO: Nunca desative todas as regras de bloqueio do firewall ao mesmo tempo para realizar um teste.
PRÓXIMO PASSO: Inspecionar as regras no menu /ip firewall filter.

12. Firewall permite mais do que deveria

Objetivo: Restringir permissões excessivas e fechar brechas de segurança no perímetro.
Primeiro Teste: O campo de endereço de origem (`src-address`) está restrito a IPs autorizados?
- SE NÃO: Substitua o escopo genérico por uma sub-rede específica ou por uma `address-list` de confiança.
- SE SIM: Revise o destino, os protocolos liberados e a ordem de prioridade das regras de descarte.
SE AINDA FALHAR: Acesso não autorizado persiste → Crie regras explícitas de bloqueio na chain `input` para a interface WAN (`in-interface-list=WAN`).
ATENÇÃO: Nunca deixe serviços administrativos (WinBox, SSH, Web/HTTP) expostos publicamente na WAN sem restrição de IP ou VPN.
PRÓXIMO PASSO: Executar testes de varredura de portas permitidas vs. bloqueadas.

13. NAT masquerade não funciona

Objetivo: Corrigir falhas de mascaramento (Source NAT) que impedem o acesso à internet.
Primeiro Teste: A regra de masquerade especifica a interface correta de saída (`out-interface` ou `out-interface-list=WAN`)?
- SE NÃO: Selecione a interface de saída pública correta ou a lista de interfaces WAN.
- SE SIM: Verifique o campo `src-address` para garantir que ele contempla o bloco de IPs da LAN.
SE AINDA FALHAR: Os contadores de pacotes da regra de NAT não incrementam → O tráfego da LAN não está alcançando a chain `srcnat` do firewall.
ATENÇÃO: Não utilize regras de masquerade genéricas sem filtro de saída, pois isso pode transformar seu roteador em um open-relay.
PRÓXIMO PASSO: Verificar a tabela em /ip firewall nat.

14. Port forwarding não funciona (Destination NAT)

Objetivo: Diagnosticar falhas no redirecionamento de portas para servidores internos.
Primeiro Teste: A requisição externa chega efetivamente à interface WAN pública do MikroTik?
- SE NÃO: Confirme se o IP da WAN é realmente um IP público válido e se a operadora não aplica CGNAT (100.64.0.0/10) ou se o modem do provedor não está bloqueando as portas.
- SE SIM: Revise a regra `dst-nat`: chain (`dstnat`), protocolo, porta de entrada (`dst-port`), IP de destino (`to-addresses`) e porta de destino (`to-ports`).
SE AINDA FALHAR: Servidor interno não responde → Confira se o servidor interno possui o IP do MikroTik como seu gateway padrão e se o firewall local do servidor autoriza a conexão.
ATENÇÃO: Incompatibilidades de porta causadas por CGNAT da operadora não podem ser resolvidas apenas configurando o MikroTik.
PRÓXIMO PASSO: Monitorar o tráfego usando a ferramenta Torch ou checar a tabela em /ip firewall connection.

15. Serviço publicado funciona fora, mas não dentro (Hairpin NAT)

Objetivo: Resolver a falha de acesso ao IP público por dispositivos que estão na mesma rede local que o servidor publicado (Loopback).
Primeiro Teste: Trata-se de um cenário característico de Hairpin NAT?
- SE SIM: Adicione uma regra de `srcnat` (masquerade) com `src-address` correspondente à LAN e `dst-address` correspondente ao servidor interno.
- SE NÃO: Verifique se a estação tenta acessar o serviço utilizando o nome de domínio e configure um DNS interno.
SE AINDA FALHAR: Simplifique a arquitetura configurando um registro de Split DNS em /ip dns static apontando o domínio diretamente para o IP local do servidor.
ATENÇÃO: Evite testar publicações externas a partir da mesma máquina que hospeda o serviço.
PRÓXIMO PASSO: Configurar DNS estático no menu /ip dns static ou adicionar a regra de Hairpin NAT.

16. VPN WireGuard sem handshake

Objetivo: Estabelecer a negociação e a comunicação inicial do túnel WireGuard.
Primeiro Teste: O endpoint remoto alcança a porta UDP configurada para o WireGuard no MikroTik?
- SE NÃO: Verifique o IP/domínio da WAN, liberações na chain `input` do Firewall Filter (porta UDP) e o endereço do endpoint.
- SE SIM: Revise com rigor as chaves públicas e privadas nos dois lados (Server e Peer) e os blocos autorizados em `Allowed Address`.
SE AINDA FALHAR: Sem resposta de handshake → Confira se o relógio do sistema está sincronizado via cliente NTP e se o parâmetro `Persistent Keepalive` está ativo no peer.
ATENÇÃO: Nunca compartilhe a chave privada da interface do WireGuard com os clientes.
PRÓXIMO PASSO: Inspecionar o status nos menus /interface wireguard e /interface wireguard peers.

17. WireGuard conecta (há handshake), mas não trafega dados

Objetivo: Garantir o roteamento de pacotes através do túnel WireGuard estabelecido.
Primeiro Teste: A sub-rede remota de destino está devidamente declarada no campo `Allowed Address` do peer?
- SE NÃO: Adicione os prefixos IP e as máscaras corretas no campo `Allowed Address` em ambas as pontas.
- SE SIM: Confira a existência de rotas ativas apontando para a interface WireGuard e se a chain `forward` do firewall autoriza o tráfego inter-redes.
SE AINDA FALHAR: Tráfego de retorno ausente → Adicione regras de roteamento de retorno ou aplique masquerade na interface da VPN dependendo da topologia da rede.
ATENÇÃO: A presença do registro de handshake confirma a autenticação criptográfica, mas não garante que o roteamento de pacotes esteja funcional.
PRÓXIMO PASSO: Disparar pings entre os IPs internos de transferência do túnel.

18. VPN IPsec não estabelece

Objetivo: Corrigir falhas na negociação da Fase 1 (Main/Aggressive Mode) e Fase 2 (Quick Mode) do IPsec.
Primeiro Teste: As propostas de criptografia (`Proposals` / `Profiles`), autenticação e algoritmos de hash são idênticos nas duas pontas?
- SE NÃO: Alinhe rigorosamente os parâmetros de IKE (IKEv1/IKEv2), chave pré-compartilhada (Secret) e algoritmos de criptografia.
- SE SIM: Confira o status em `Active Peers`, o suporte a NAT-Traversal (NAT-T) e o bloqueio de portas UDP 500/4500 no firewall.
SE AINDA FALHAR: Fase 1 estabelece e a Fase 2 falha → Revise as chaves de seleção de tráfego (`Traffic Selectors` / `Policies`) para garantir que as sub-redes local e remota coincidem.
ATENÇÃO: Nunca reduza a criptografia para algoritmos obsoletos (como DES ou MD5) para contornar falhas de negociação.
PRÓXIMO PASSO: Checar os logs em /ip ipsec active-peers e /ip ipsec installed-sa.

19. Rota estática não funciona

Objetivo: Validar o encaminhamento de pacotes para redes e gateways remotos.
Primeiro Teste: O IP do gateway especificado no campo `gateway` (next-hop) está em estado alcançável (`reachable`)?
- SE NÃO: Corrija o endereço IP do gateway de próximo salto ou selecione a interface física/lógica de saída adequada.
- SE SIM: Verifique a máscara de sub-rede do destino e confirme se a rede remota possui uma rota de retorno apontando para a sua rede.
SE AINDA FALHAR: Rota aparece como ativa (AS) mas o tráfego não passa → Revise o Firewall Filter na chain `forward`.
ATENÇÃO: Não utilize mascaramento (NAT) apenas para compensar a ausência de uma rota de retorno na rede remota.
PRÓXIMO PASSO: Inspecionar as rotas no menu /ip route.

20. Policy routing (PBR) ignora a regra

Objetivo: Garantir que o tráfego seja desviado para tabelas de roteamento específicas conforme regras de marcação.
Primeiro Teste: A regra de marcação no Mangle (`action=mark-routing`) ou em `Routing Rules` possui uma tabela de destino válida?
- SE NÃO: Crie a tabela em `/routing table` e associe a rota de saída correspondente.
- SE SIM: Confira a ordem sequencial das regras no Mangle e certifique-se de que o tráfego local não está sendo capturado por engano.
SE AINDA FALHAR: Tráfego de destino interno sendo desviado para a WAN → Crie regras de exceção (`action=accept` ou bypass de marcação) para os blocos de IP locais antes da regra de marcação de rota.
ATENÇÃO: Não force o roteamento de conexões administrativas locais para tabelas que utilizam interfaces WAN alternativas.
PRÓXIMO PASSO: Checar o fluxo no menu /ip firewall mangle e em /routing rule.

21. Dois links, sem failover automático

Objetivo: Garantir a comutação automática de tráfego quando o link de internet principal cai.
Primeiro Teste: O RouterOS detecta a perda real de conectividade no link principal?
- SE NÃO: Configure a verificação por ping em `check-gateway=ping` ou crie scripts de monitoramento recursivo via Netwatch.
- SE SIM: Revise o parâmetro `distance` das rotas padrão (ex: Link 1 com `distance=1` e Link 2 com `distance=2`).
SE AINDA FALHAR: A rota comuta no painel mas sessões de usuários permanecem presas → Lembre-se de que a tabela de conexões do firewall mantém sessões TCP antigas na tabela de rastreamento.
ATENÇÃO: O failover de rotas não altera o IP público de conexões TCP já estabelecidas sem o reinício da sessão pelo cliente.
PRÓXIMO PASSO: Inspecionar as configurações em /ip route e no menu de rastreamento de conexões.

22. Load balance desigual ou instável

Objetivo: Distribuir o tráfego proporcionalmente à capacidade da largura de banda de cada conexão WAN (ex: PCC / NTH).
Primeiro Teste: As regras de distribuição (ex: `Per Connection Classifier - PCC`) contemplam a proporção correta de velocidade dos links?
- SE NÃO: Ajuste os divisores do PCC (ex: 2/0, 2/1 para links iguais ou 3/0, 3/1, 3/2 para links de capacidades diferentes).
- SE SIM: Teste o tráfego gerando múltiplas sessões simultâneas a partir de diferentes dispositivos da LAN.
SE AINDA FALHAR: Baixa velocidade em um único teste de download em um site → Lembre-se de que uma única conexão TCP/HTTP não soma a velocidade de dois links fisicamente separados.
ATENÇÃO: Nunca prometa a soma da largura de banda de dois links de internet em um único teste de velocidade monoconexão.
PRÓXIMO PASSO: Analisar a tabela em /ip firewall connection para conferir o comportamento do PCC (`sticky connections`).

23. Hotspot não autentica ou não redireciona

Objetivo: Corrigir falhas de exibição do Portal Cativo e autenticação de usuários no serviço Hotspot.
Primeiro Teste: O serviço de Hotspot está ativo e associado à interface lógica correta da LAN?
- SE NÃO: Execute o assistente de instalação em IP > Hotspot > Hotspot Setup.
- SE SIM: Verifique o perfil do servidor (`Server Profile`), o DNS Name configurado para a página de login e as contas de usuários em `Users`.
SE AINDA FALHAR: O cliente autentica mas não navega → Revise as regras automáticas criadas pelo Hotspot na aba de NAT e Firewall.
ATENÇÃO: Evite expor a página do Portal Cativo do Hotspot diretamente para a interface pública da WAN.
PRÓXIMO PASSO: Checar as conexões ativas no menu /ip hotspot active e os logs do sistema.

24. Controle de banda (QoS) não surte efeito

Objetivo: Ajustar regras de limitação de velocidade e priorização de tráfego (`Simple Queues` ou `Queue Tree`).
Primeiro Teste: A regra de fila está interceptando o endereço IP ou a interface correta do cliente?
- SE NÃO: Corrija o parâmetro `target` especificando a sub-rede, o IP estático do cliente ou a interface da LAN.
- SE SIM: Verifique os valores configurados nos campos `Max Limit` (Upload/Download) e o limite garantido em `Limit At`.
SE AINDA FALHAR: A fila não contabiliza bytes → Confirme se o recurso de Fasttrack (`action=fasttrack-connection`) no Firewall Filter não está ignorando o processamento das filas.
ATENÇÃO: O uso de regras de Fasttrack desativa o processamento detalhado de filas de QoS em pacotes estabelecidos.
PRÓXIMO PASSO: Inspecionar as estatísticas em /queue simple ou /queue tree.

25. CPU alta no MikroTik (100% uso)

Objetivo: Identificar e mitigar processos que causam estouro de processamento na RouterBOARD.
Primeiro Teste: Qual serviço ou processo específico está consumindo os recursos da CPU?
- SE NÃO SABE: Abra a ferramenta /tool profile e ordene por uso de CPU para identificar o processo responsável (ex: firewall, routing, bfd, wireless, dns).
- SE IDENTIFICOU: Correlacione o processo com o excesso de pacotes por segundo (pps), ataques de força bruta no SSH/WinBox ou regras de Mangle complexas.
SE AINDA FALHAR: Picos constantes sem causa aparente → Ative regras de mitigação de ataques de negação de serviço (DDoS) na chain `input` e reduza os registros de log em disco.
ATENÇÃO: Nunca reinicie a caixa sem antes coletar dados e registrar a análise do `Profile`.
PRÓXIMO PASSO: Executar a análise detalhada no menu /tool profile.

26. Memória RAM baixa ou esgotada

Objetivo: Resolver o consumo excessivo de memória RAM em roteadores com rotas cheias ou serviços extensos.
Primeiro Teste: O consumo de memória cresce continuamente sem estagnar (Memory Leak)?
- SE SIM: Inspecione a tabela de rastreamento de conexões (`/ip firewall connection`), o tamanho do cache DNS e a retenção de logs em RAM.
- SE NÃO: Verifique os limites de tabelas de roteamento BGP ou o acúmulo de arquivos temporários na memória.
SE AINDA FALHAR: Falta de espaço em armazenamento interno (Flash) ou RAM → Remova pacotes (.npk) desnecessários, arquivos de backup antigos e logs retidos no menu Files.
ATENÇÃO: Nunca apague arquivos de sistema sem confirmar previamente sua integridade e função.
PRÓXIMO PASSO: Inspecionar o status no menu /system resource e na aba Files.

27. Interface com perda de pacotes ou caindo (Flapping)

Objetivo: Estabilizar a conectividade de camada física (L1) e a autonegociação de portas ethernet ou ópticas.
Primeiro Teste: A porta está negociando na velocidade (100Mbps/1Gbps/10Gbps) e modo Duplex esperados?
- SE NÃO: Substitua o cabo de rede/patch cord, troque de porta no switch e revise as configurações de `Auto Negotiation`.
- SE SIM: Compare os contadores de erros (`Errors`), descartes (`Drops`) e erros de alinhamento CRC na aba de estatísticas.
SE AINDA FALHAR: Erros de CRC persistentes em links ópticos → Limpe os conectores, substitua o cordão óptico ou troque o transceiver SFP/SFP+.
ATENÇÃO: Erros de CRC e drops em interfaces físicas indicam falhas de hardware ou interferência eletromagnética que não podem ser corrigidas via software.
PRÓXIMO PASSO: Checar os contadores na aba Stats da interface ethernet em /interface ethernet.

28. Latência alta ou perda de pacotes na rede

Objetivo: Isolar a origem de degradações de desempenho e gargalos de tráfego.
Primeiro Teste: A perda de pacotes ou a alta latência ocorre logo no primeiro salto (Gateway local)?
- SE SIM: Investigue o enlace local, interferência no enlace sem fio/Wi-Fi ou sobrecarga do cabo de rede e porta do roteador.
- SE NÃO: Compare a latência disparando pings para o gateway local, para o roteador de borda do provedor e para o destino final na WAN.
SE AINDA FALHAR: Apenas um destino específico apresenta alta latência → Utilize a ferramenta Traceroute para identificar em qual AS/operadora de trânsito ocorre o gargalo.
ATENÇÃO: Nunca tire conclusões sobre a qualidade de uma rede executando um único teste de ICMP isolado.
PRÓXIMO PASSO: Utilizar as ferramentas no menu /tool ping e /tool traceroute.

29. Logs não mostram a causa do evento

Objetivo: Configurar regras de diagnóstico detalhadas quando os registros padrão do sistema são insuficientes.
Primeiro Teste: O tráfego analisado está sendo capturado por alguma regra com a opção `log=yes` ativa?
- SE NÃO: Crie uma regra específica no Firewall Filter ou Mangle com `action=log` para registrar o tráfego desejado.
- SE SIM: Ajuste os tópicos de log em `/system logging` adicionando o tópico correspondente (ex: `firewall`, `vpn`, `dhcp`, `dns`, `ipsec`).
SE AINDA FALHAR: Ausência total de registros nos logs → Utilize a ferramenta `Torch` para análise em tempo real ou realize uma captura completa de pacotes via `Packet Sniffer` para leitura no Wireshark.
ATENÇÃO: Desative registros de log detalhados em disco após a conclusão dos testes para evitar o desgaste prematuro da memória Flash do roteador.
PRÓXIMO PASSO: Inspecionar o menu /system logging e a ferramenta /tool packet-sniffer.

30. Configuração perdida ou acesso administrativo bloqueado

Objetivo: Recuperar o gerenciamento do equipamento em cenários de emergência ou perda de credenciais.
Primeiro Teste: Existe um backup recente em arquivo binário (`.backup`) ou uma cópia das configurações em texto (`.rsc / export`)?
- SE NÃO: Conecte-se via porta serial de Console ou tente o acesso por endereço MAC via WinBox/MNDP.
- SE SIM: Restaure a configuração em um ambiente isolado ou utilize a porta de Console para redefinir as credenciais.
SE AINDA FALHAR: Acesso impossível por esquecimento de senha → Execute o procedimento de reset físico do equipamento mantendo o botão de Reset pressionado durante o boot até o LED de USR piscar, reiniciando o RouterOS com as configurações padrão de fábrica.
ATENÇÃO: Nunca restaure arquivos de backup binários (`.backup`) em roteadores de modelos ou revisões de hardware diferentes, pois isso corrompe o mapeamento de portas e interfaces do sistema.
PRÓXIMO PASSO: Utilizar a ferramenta WinBox via MAC Address ou acessar o menu /system reset-configuration para restauração limpa.

Conclusão

Adotar um protocolo de diagnóstico fundamentado em testes metódicos garante a rápida recuperação de serviços críticos e eleva a confiabilidade da infraestrutura de rede. Manter a documentação do ambiente atualizada, automatizar rotinas de backup das configurações em formato de texto e utilizar as ferramentas nativas de análise do RouterOS são as melhores práticas para a gestão sênior de redes.

📰 Fontes Informativas Consultadas: Documentação oficial do MikroTik Wiki / RouterOS Documentation, boletins de engenharia MikroTik MUM (MikroTik User Meeting) e manuais de arquitetura compilados pelo canal de consultoria Gestor Técnico.

📬 Solicitar Atendimento Técnico Direto

Prefere não preencher formulários extensos? Inicie seu atendimento de engenharia de infraestrutura de forma rápida por e-mail:

📧 contato@gestortecnico.com.br

⚡ Como funciona: Ao clicar no botão abaixo, seu aplicativo de e-mail abrirá com um roteiro de triagem pré-formatado. Basta preencher seu contato, selecionar a opção desejada e enviar!

✉️ Falar com um Especialista em MikroTik

Aproveite Ofertas Imperdíveis
de Produtos Eletrônicos nos nossos links de Afiliado

Não perca estas ofertas incríveis em produtos eletrônicos disponíveis através dos nossos links de afiliado! Aproveite esta oportunidade única para adquirir itens de qualidade a preços imbatíveis. Visite agora e descubra as promoções que podem transformar sua experiência de compra!