Roteador de borda com CPU em 100%: causas, diagnóstico e quando chamar um Especialista
Roteador de borda com CPU em 100%: o primeiro passo é ver quem está usando o processador, se o BGP, o tráfego encaminhado ou o tráfego destinado ao próprio roteador. As causas mais comuns são encaminhamento por software no limite, firewall e NAT na borda, BGP recalculando rotas e ataque contra o IP do roteador.
Resumo
- Em roteador com encaminhamento em hardware, a CPU cuida do BGP e da gerência, não do tráfego dos clientes.
- Se a CPU acompanha o tráfego no pico, o equipamento chegou ao limite ou está fazendo trabalho que não é dele.
- Se a CPU dispara sem aumento de tráfego, a suspeita é ataque contra o roteador ou sessão caindo e voltando.
- Reiniciar a borda no pico faz todas as sessões recomeçarem juntas e costuma piorar o quadro.
O que significa um roteador de borda com CPU em 100%?
Um roteador de borda com CPU em 100% é um equipamento sem folga para processar as sessões BGP, a gerência e o que chega endereçado a ele. Nesse ponto, as sessões podem cair, o acesso remoto trava e o tráfego começa a perder pacotes.
A borda é o roteador que liga o provedor às operadoras de trânsito e ao IX.br. Ela recebe a tabela de rotas de cada vizinho, escolhe por onde sai o tráfego de cada destino e anuncia os blocos do provedor para fora. Quando o processador para de dar conta, tudo isso fica mais lento ao mesmo tempo.
CPU alta pode ser defeito de configuração, ataque ou simplesmente um equipamento pequeno para a rede de hoje. O dimensionamento de roteador de borda para provedores mede o que a borda faz no pico e mostra se ainda cabe ou se é hora de trocar. Se a borda está travando agora, peça suporte emergencial para provedor.
Encaminhamento em hardware ou em software?
A resposta muda a leitura da CPU. Em roteadores com encaminhamento em hardware, o tráfego dos clientes passa por um chip dedicado e quase não toca no processador.
Em equipamentos que encaminham tudo por software, como boa parte dos roteadores MikroTik, a CPU também carrega cada pacote. Neles, CPU alta no pico pode ser só falta de capacidade, e o gráfico de CPU acompanha o de tráfego quase linha a linha.
Saber em qual dos dois grupos está a sua borda evita meia hora de investigação. Em hardware, CPU alta quase nunca é volume de clientes; em software, quase sempre é.
Roteador de borda com CPU em 100%: causas em ordem de probabilidade
As causas mais comuns são encaminhamento por software no limite e regras de firewall ou NAT tirando o tráfego do caminho rápido. Depois vêm BGP recalculando rotas, ataque contra o roteador e gerência pesada.
- Encaminhamento por software no limite: o tráfego cresceu e o equipamento não aguenta mais no pico.
- Firewall, NAT ou filas na borda: regras que olham cada conexão tiram o tráfego do caminho rápido.
- BGP recalculando rotas: sessão caindo e voltando ou muitas mudanças na tabela completa fazem a CPU disparar.
- Ataque contra o roteador: tráfego destinado ao IP da borda, como ping, consultas ou fragmentos, cai direto na CPU.
- Gerência pesada: coleta de SNMP muito frequente, registros em excesso ou espelhamento de tráfego.
- Laço de roteamento: pacotes com tempo de vida esgotado geram respostas que a CPU precisa montar.
O peso do NAT quando a borda acumula funções
Em muitos provedores pequenos, a mesma caixa faz borda, concentrador e CGNAT. Cada sessão de cliente vira entrada na tabela de conexões, e cada pacote precisa ser conferido contra ela.
Isso funciona com poucos assinantes e vai ficando pesado conforme a base cresce. O guia sobre concentrador PPPoE com CPU em 100% mostra o mesmo problema visto do lado do concentrador.
Como identificar a causa pelo comportamento da CPU
O comportamento da CPU no tempo e a lista de processos mostram a causa na maioria dos casos. Compare sempre com o gráfico de tráfego do mesmo período.
| O que você vê | Causa provável | Primeira conferência |
|---|---|---|
| CPU acompanha o tráfego e chega a 100% no pico | Encaminhamento por software no limite | Tráfego e pacotes por segundo no pico |
| CPU alta depois de criar regra de firewall ou NAT | Tráfego fora do caminho rápido | Regras novas e contadores de cada uma |
| Picos junto com quedas de sessão BGP | BGP recalculando rotas | Histórico de sessões e mudanças de rota |
| CPU dispara de repente, sem aumento de tráfego | Ataque contra o IP do roteador | Tráfego destinado à própria borda |
| Processo de gerência ou de registros no topo | Coleta ou registros em excesso | Intervalo do SNMP e volume de logs |
Link cheio também parece CPU alta
Lentidão na borda nem sempre é processador. Se a CPU está folgada e o link está no limite, veja o guia de link de trânsito saturado.
CPU no teto e proposta de roteador novo na mesa?
O dimensionamento mede tráfego, pacotes, rotas e sessões da sua borda no pico e indica as plataformas que atendem com folga, sem venda de hardware.
Roteador de borda com CPU em 100%: o que fazer
A ordem começa por leitura e só depois mexe no roteador, para não derrubar as sessões no meio do diagnóstico. Tenha uma cópia da configuração antes de proteger a CPU ou tirar funções da borda.
- Veja os processos: anote qual processo usa mais CPU agora e em quais núcleos.
- Compare com o tráfego: veja se a CPU sobe junto com o volume ou sozinha.
- Confira as sessões BGP: procure sessões que caíram e voltaram nos últimos minutos.
- Olhe o tráfego para o roteador: veja se há volume anormal destinado ao IP da própria borda.
- Proteja a CPU: limite o que pode chegar ao roteador e aceite gerência só da rede interna.
- Tire o que não é da borda: NAT, filas por cliente e firewall pesado vão para outro equipamento.
Em roteadores MikroTik com RouterOS 7, os comandos abaixo só leem o estado do equipamento e ajudam nos quatro primeiros passos. O profile mostra em tempo real qual processo está no topo.
/system resource print
/system resource cpu print
/tool profile
/routing bgp session print
/ip firewall connection print count-onlySe a CPU cai depois de proteger o roteador, a causa era tráfego contra ele. Se só cai quando NAT e filas saem da borda, o equipamento estava fazendo trabalho que não era dele.
Exemplo: CPU no teto só no horário de pico
Um cenário típico ajuda a ler os sinais. Toda noite, no pico, a CPU de uma borda MikroTik chega a 100%, os clientes reclamam de lentidão e, às vezes, a sessão com uma operadora cai e volta.
O profile mostra o firewall e as filas no topo, e o gráfico de CPU acompanha o de tráfego. A borda também faz NAT e controle de banda por cliente, então cada pacote passa por regras que deveriam estar em outro equipamento.
Tirar o NAT e as filas da borda costuma devolver a folga. Se mesmo assim a CPU acompanha o tráfego, o equipamento chegou ao limite e o próximo passo é dimensionar a troca.
Erros comuns que derrubam o provedor junto com a CPU
O erro mais comum é reiniciar a borda no pico, porque todas as sessões BGP recomeçam juntas e a CPU sobe de novo. Outros erros deixam a borda exposta ou fazem destinos sumirem.
Evite
- Reiniciar a borda no pico, com todas as sessões BGP recomeçando ao mesmo tempo.
- Apagar regras de firewall sem saber qual pesa, deixando a borda exposta.
- Reduzir a tabela BGP às pressas sem rota padrão de reserva, fazendo destinos sumirem.
- Ligar registros detalhados de tudo para investigar, já que a gravação também usa CPU.
- Comprar um roteador maior sem medir pacotes por segundo e rotas, só pela velocidade das portas.
Quando a sessão cai por falta de CPU, o vizinho desiste depois do tempo de espera combinado entre os dois roteadores. A RFC 4271 sugere 90 segundos para esse temporizador, e o guia sobre BGP caindo no provedor ajuda a separar essa causa das outras.
Quando vale chamar um Especialista?
Vale chamar um Especialista quando a CPU alta derruba sessões BGP, quando ela volta a 100% todo dia no mesmo horário ou quando há suspeita de ataque. Nesses casos, o problema já está chegando aos assinantes.
Proteger o plano de controle, tirar funções da borda e ajustar a política de rotas sem derrubar o tráfego é trabalho de suporte técnico N3. Feito às pressas, qualquer um desses passos pode deixar o provedor fora do ar por mais tempo do que a própria CPU alta.
Se a CPU sobe junto com tráfego estranho destinado à borda, trate o caso como ataque. O guia sobre ataque DDoS no provedor mostra como confirmar e conter.
A Táquion Tech não vende roteador: o dimensionamento entrega os números da sua borda e as plataformas que atendem com folga. O atendimento de emergência e o SLA são [PREENCHER tempo de resposta e SLA].
Quando vale trocar o roteador de borda
Trocar o equipamento só resolve quando o limite é dele, não da configuração. Confira antes de pedir orçamento.
Marque o que vale para a sua borda
- A CPU acompanha o tráfego mesmo sem NAT, filas ou firewall pesado na borda.
- O tráfego de pico cresce mês a mês e já passou da metade da capacidade medida.
- A memória está perto do limite com as tabelas completas das operadoras.
- Há planos de receber mais uma operadora ou entrar num novo ponto do IX.br.
- A gerência já trava no pico, mesmo com o tráfego normal.
Duas marcas ou mais indicam que a borda está pequena para a rede. Uma marca só costuma ser resolvida com ajuste de configuração.
Para ver se o gargalo está mesmo na borda ou em outro ponto da rede, o guia de internet lenta no horário de pico mostra onde medir.
Perguntas frequentes sobre roteador de borda com CPU em 100%
CPU em 100% na borda derruba o BGP?
Pode derrubar. Se a CPU não consegue responder a tempo, o vizinho desiste da sessão e as rotas somem até ela voltar.
Por que a CPU sobe só no horário de pico?
Normalmente porque o roteador encaminha o tráfego por software e chegou ao limite. Também acontece quando regras de firewall e NAT pesam mais com mais conexões abertas.
Como proteger a CPU do roteador de borda?
Limitando o tráfego que pode chegar ao próprio roteador e aceitando gerência só da rede interna. Também ajuda deixar NAT e firewall pesado em outro equipamento.
A tabela completa de rotas pesa na CPU?
Pesa mais na memória e nos momentos em que a sessão sobe ou a tabela muda muito. Com sessões estáveis, a tabela completa raramente é a causa de CPU alta constante.
Um núcleo em 100% já é problema?
Pode ser, porque alguns processos usam só um núcleo e travam mesmo com a média baixa. Olhe a carga por núcleo, não só o número geral.
Serviços ligados a este guia
- Gestão de BGP para provedores BGP e roteamento
- Dimensionamento de roteador de borda para provedores BGP e roteamento
- Hardening de roteadores para provedores Segurança e anti-DDoS
Responsável técnico da Táquion Tech · Registro profissional [PREENCHER]
Mais de 15 anos em operações de rede, com gestão de infraestruturas de TI, administração de data centers e condução de equipes em migrações de TI e telecomunicações, com foco em alta disponibilidade e segurança.
A Táquion Tech é uma empresa de engenharia de redes de Balneário Camboriú (SC) que projeta, opera e dá suporte a redes de provedores de internet e de empresas.
Fontes
- RFC 6192, Protecting the Router Control Plane: como limitar o tráfego que chega à CPU do roteador.
- RFC 7454, BGP Operations and Security: boas práticas de proteção das sessões BGP e da borda.
- RFC 4271, A Border Gateway Protocol 4 (BGP-4): temporizadores que derrubam a sessão quando o roteador não responde.
