SNMP: como funciona o protocolo, quais OIDs monitorar e o que muda entre as versões
Autor: Pedro Tebaldi PM do KeepGreen
Revisão técnica: Ednilson Correa SREAbra a configuração de qualquer switch gerenciado, roteador, nobreak ou impressora da sua rede. O agente SNMP provavelmente está lá, ligado desde a instalação, respondendo a quem perguntar. A questão que decide a qualidade do monitoramento não é se o equipamento fala o protocolo. É qual número você pede a ele, em que intervalo e com qual credencial.
O SNMP (Simple Network Management Protocol) é o protocolo de gerenciamento mais suportado do mercado desde 1988. Praticamente todo ativo gerenciável o implementa, o que faz dele o caminho mais curto para tirar um parque do escuro.
Em contrapartida, a facilidade cobra o preço na configuração. Coletar o objeto errado, no intervalo errado, produz painel cheio de dado que ninguém usa.
Este guia percorre o caminho de quem vai operar. Você vai encontrar a arquitetura e as portas, além do comando que descobre qual identificador o equipamento expõe. Em seguida vêm os objetos que valem coleta em switch, roteador e servidor. Por fim, o texto trata do que muda entre as três versões e de onde o protocolo deixa de responder.
O que é SNMP e para que serve o protocolo
O SNMP é o protocolo padrão para consultar informações de gerenciamento em dispositivos de redes IP. Ele define três peças. Um agente roda no equipamento e expõe valores de operação. Um gerente consulta esses valores em intervalos regulares. Uma notificação parte do equipamento quando um evento acontece, o que cobre medição e alerta.
Além disso, a padronização é o que torna tudo isso viável em escala. Um switch Cisco, um roteador Mikrotik, um servidor Linux e um nobreak APC respondem à mesma pergunta com a mesma sintaxe. Ainda assim, cada fabricante acrescenta objetos próprios. Dessa forma, um único coletor cobre centenas de equipamentos sem integração dedicada por marca.
Vale situar o protocolo dentro de um escopo maior. Ele resolve a coleta de estado e a notificação de falha. No modelo FCAPS de gerenciamento de redes, isso corresponde às camadas de falha e desempenho. Configuração, contabilização e segurança, por outro lado, pedem outras ferramentas.
Gerente, agente e as portas 161 e 162
A comunicação acontece em duas direções, por duas portas UDP distintas. O agente escuta na porta UDP 161 e responde às consultas do gerente. O gerente escuta na porta UDP 162 e recebe as notificações que o agente envia por conta própria.
Vale destacar que confundir as duas é a causa mais comum de trap que nunca chega. Quando o firewall libera apenas a 161, o polling funciona, os gráficos enchem normalmente e o alerta silencia. Antes de abrir chamado com o fabricante, portanto, confirme que a 162 está liberada no sentido equipamento para coletor.
O protocolo trabalha com um conjunto pequeno de operações. Conhecê-las evita configuração por tentativa.
As operações que você vai usar
GET busca um valor único. GETNEXT caminha para o próximo objeto da árvore, o que permite varrer uma tabela sem saber de antemão quantas linhas ela tem. GETBULK, disponível a partir do v2c, traz várias linhas em uma única resposta e reduz drasticamente o número de pacotes em tabelas grandes.
SET escreve um valor no equipamento. Ele existe, funciona e, ainda assim, raramente deveria estar habilitado: acesso de escrita via rede transforma o coletor em vetor de mudança de configuração. Em seguida vêm as notificações. TRAP é o aviso disparado pelo agente sem confirmação de entrega, enquanto INFORM exige que o gerente confirme o recebimento.
Como o agente já vem embarcado no firmware, o SNMP se tornou a espinha dorsal do monitoramento sem agente instalado. Nenhum software adicional entra no switch, no roteador ou na impressora de rede. Dessa forma, o protocolo cobre justamente os ativos onde instalar qualquer coisa é impossível.
MIB e OID: como descobrir o número que você precisa
A MIB (Management Information Base) é o catálogo dos objetos que um equipamento expõe. O OID (Object Identifier) é o endereço numérico de cada objeto dentro desse catálogo, escrito como uma sequência hierárquica. O OID 1.3.6.1.2.1.1.3.0, por exemplo, guarda o tempo desde a última inicialização do sistema.
Existem dois universos de MIB. As padrão, publicadas em RFC, cobrem o que todo equipamento tem: interfaces, uptime, descrição do sistema. As proprietárias, por outro lado, expõem o que é específico daquele hardware, como potência óptica de um SFP ou temperatura de uma placa.
Na prática, o trabalho é descobrir qual OID responde ao que você quer medir naquele equipamento específico. Três comandos resolvem quase todos os casos.
Rode o snmpwalk sem OID e você recebe a árvore inteira, o que em um switch de 48 portas passa de mil linhas. Comece sempre pelo ramo que interessa.
Depois carregue os arquivos de MIB do fabricante no coletor. Eles traduzem número em nome legível, o que mantém o template compreensível meses depois. O aprofundamento em MIBs proprietárias por fabricante segue em artigo dedicado.
Os OIDs que valem coleta em qualquer parque
Esta é a lista mínima que sustenta diagnóstico de verdade. Todos os identificadores abaixo vêm de MIBs padrão. Por isso funcionam em equipamento de qualquer fabricante que siga a especificação.
| Objeto | OID | O que ele entrega |
|---|---|---|
| sysUpTime | 1.3.6.1.2.1.1.3.0 |
Denuncia o reboot que ninguém reportou. Uptime que zerou de madrugada é incidente, não estatística. |
| ifOperStatus | 1.3.6.1.2.1.2.2.1.8 |
Estado real da porta. Compare com ifAdminStatus para separar queda de porta desligada de propósito. |
| ifHCInOctets / ifHCOutOctets | 1.3.6.1.2.1.31.1.1.1.6 e 1.3.6.1.2.1.31.1.1.1.10 |
Tráfego em contadores de 64 bits. É o par correto acima de 20 Mbit/s, pelo motivo explicado adiante. |
| ifInErrors / ifOutErrors | 1.3.6.1.2.1.2.2.1.14 e 1.3.6.1.2.1.2.2.1.20 |
Erro de camada física. Sobe com cabo ruim, SFP degradado ou negociação de duplex divergente. |
| ifInDiscards / ifOutDiscards | 1.3.6.1.2.1.2.2.1.13 e 1.3.6.1.2.1.2.2.1.19 |
Descarte por buffer cheio. Sobe antes da reclamação de lentidão e antecipa saturação de banda. |
| ifAlias | 1.3.6.1.2.1.31.1.1.1.18 |
A descrição que o administrador escreveu na porta. Transforma “Gi1/0/24” em “link matriz para filial”. |
| hrProcessorLoad | 1.3.6.1.2.1.25.3.3.1.2 |
Ocupação média do último minuto, por processador. Vale a média entre núcleos, nunca o pico de um só. |
| hrStorageUsed / hrStorageSize | 1.3.6.1.2.1.25.2.3.1.6 e 1.3.6.1.2.1.25.2.3.1.5 |
Disco, memória e swap. Multiplique pelo hrStorageAllocationUnits (…25.2.3.1.4) ou o número sai errado. |
| entPhySensorValue | 1.3.6.1.2.1.99.1.1.1.4 |
Temperatura, rotação de ventoinha, tensão de fonte. É o sensor que avisa antes do desligamento térmico. |
Estado, contador e erro respondem perguntas diferentes
Repare no critério por trás da lista. Estado (ifOperStatus) diz que caiu. Contador (ifHCInOctets) diz quanto passou. Erro e descarte, no entanto, dizem por que a experiência piorou sem nada cair.
Um template de switch que traz só tráfego e estado deixa o degrau mais informativo de fora.
Do lado de servidor, os objetos de HOST-RESOURCES-MIB cobrem o básico de CPU, memória e disco sem instalar nada. Ainda assim, eles não enxergam processo, serviço nem fila de aplicação. Para monitorar servidores com profundidade, o protocolo é a camada de entrada, não o destino final.
SNMPv1, v2c e v3: o que muda além da senha
As versões 1 e 2c autenticam por community string, um texto simples que trafega sem cifragem. Qualquer captura de pacotes no caminho revela a credencial de gerenciamento inteira. O v2c acrescentou o GETBULK e os contadores de 64 bits, mas manteve exatamente o mesmo modelo de autenticação do v1.
Isso não é opinião de fornecedor. Já em dezembro de 2002, o IETF recomendou reclassificar como documentos históricos as RFCs que definem o v1 e o v2c.
O texto é explícito ao dizer que essas operações “suportam apenas autenticação trivial baseada em community strings em texto claro” sendo por isso “fundamentalmente inseguras”. A íntegra está na recomendação formal do IETF.
Em contrapartida, o SNMPv3 adiciona três camadas que mudam a operação. São elas autenticação por usuário com HMAC, privacidade com cifragem AES do conteúdo da mensagem e controle de acesso por visão. Esse último, a saber, restringe quais ramos da árvore cada usuário enxerga. Com ele, o coletor recebe um usuário de leitura limitado ao que precisa ler.
Por que o v3 não dispensa a segmentação
Versão moderna não substitui controle de acesso na rede.
Em setembro de 2025, uma falha no subsistema do protocolo em Cisco IOS e IOS XE entrou no catálogo de vulnerabilidades exploradas da CISA. O caso está no registro público da falha.
Classificada com CVSS 7,7, a CVE-2025-20352 permite negação de serviço ou execução de código como root a partir de pacotes forjados. Ou seja, credencial válida de leitura já basta para o estrago começar.
A conclusão operacional é direta. Restrinja a origem das consultas por ACL no equipamento e mantenha a coleta em VLAN de gerenciamento dedicada. Em seguida, troque as community strings de fábrica e desabilite o acesso de escrita onde ninguém o usa. Community string public ainda ativa em um ativo de borda é porta aberta com placa.
Polling ou trap: o contador que estoura sem avisar
As duas formas de coleta resolvem problemas diferentes. O polling responde “quanto” em série temporal contínua, o que sustenta gráfico, linha de base e capacity planning. A trap responde “aconteceu agora” em evento único, o que encurta o tempo de detecção de queda.
Um intervalo de 60 segundos atende bem interface e estado de porta. Do mesmo modo, métricas de capacidade toleram 5 minutos sem perder utilidade. Já queda de link não deve depender de polling nenhum: é caso de trap chegando na 162 e virando acionamento imediato para o time de NOC na fila certa.
Aqui mora a armadilha mais cara do protocolo. Contadores de interface de 32 bits dão a volta ao chegar em 4.294.967.296 bytes. Quando isso acontece entre duas coletas, o gráfico registra um pico absurdo ou um vale impossível.
A conta é simples. Um link de 1 Gbit/s saturado transfere 125 milhões de bytes por segundo. Logo, o contador de 32 bits estoura em 34 segundos, bem antes do próximo polling.
A especificação dos contadores de interface registra o mesmo raciocínio. Até 20 Mbit/s os contadores de 32 bits bastam; acima disso os de 64 bits passam a ser obrigatórios para octetos. Por isso a tabela acima indica ifHCInOctets, nunca ifInOctets.
Escala e ruído: o que quebra quando a rede cresce
Coletor tem orçamento finito de consultas por segundo. Multiplique equipamentos por itens por frequência e você chega ao volume real de polling. Passando do que o coletor sustenta, as consultas estouram por timeout, o valor chega vazio e o sistema lê ausência de resposta como falha.
O resultado é o pior tipo de alerta: o que dispara sozinho, às três da manhã, sem que nada tenha caído. Fadiga de alerta nasce quase sempre daí, não de limiar mal escolhido. Antes de afrouxar o limiar, portanto, verifique timeout, retry e distribuição de carga entre coletores.
No projeto com a Klabin, esse foi o gargalo central. A operação é distribuída, com unidades em áreas florestais ligadas por antenas de rádio. O volume de falso positivo estava corroendo a confiança no console.
Implantamos o OpMon com console centralizado, monitoramento das antenas e capacity planning com previsão de esgotamento, sobre mais de 700 dispositivos monitorados. O ganho não foi coletar mais: foi notificar apenas incidente real, como descreve o case de unificação da visibilidade da Klabin.
Duas providências evitam a maior parte desse ruído. Antes de tudo, use GETBULK em tabelas grandes, o que reduz o número de pacotes por coleta. Separe também o intervalo por criticidade, em vez de aplicar o mesmo tempo a todo o parque: porta de core não precisa da mesma frequência que impressora de andar.
Onde o protocolo para e outra coleta começa
O SNMP entrega volume agregado por interface. Ele não diz quem gerou o tráfego, para onde ele foi, nem em qual aplicação. Quando a pergunta vira “o que ocupou o link às 14h”, a resposta exige fluxo. Nesse sentido, o caminho é NetFlow ou sFlow no monitoramento de tráfego de redes.
Além disso, há um teto de granularidade. Polling de 60 segundos não enxerga microrrajada de 200 milissegundos que estourou o buffer e derrubou a chamada de voz. Para essa resolução, o caminho é telemetria por streaming, em que o equipamento publica métrica continuamente em vez de esperar a pergunta.
No entanto, nenhuma dessas alternativas aposenta o protocolo. Elas cobrem a lacuna dele em cima de uma base que já existe em todo ativo gerenciável. Em síntese, o SNMP é a camada de cobertura ampla. As demais entregam profundidade onde o incidente exige.
Identificamos gargalos de rede antes que virem incidentes críticos.
Análise de tráfego com NetFlow, sFlow e SNMP para mapeamento completo de latência, perda de pacotes e capacidade de banda.
O que dá para configurar ainda esta semana
Comece pelo inventário do que já responde. Um snmpwalk na faixa de gerenciamento mostra quais ativos têm agente ligado, quais ainda usam community de fábrica e quais nunca entraram no coletor. Esse levantamento costuma revelar equipamento monitorado por ninguém há anos.
Em seguida, ajuste o template antes de ampliar a cobertura. Troque contador de 32 bits por ifHCInOctets em tudo acima de 20 Mbit/s. Além disso, acrescente erro e descarte às interfaces que só coletam tráfego e confirme que a porta 162 chega ao coletor. São três mudanças pequenas que melhoram o diagnóstico sem adicionar um único item novo.
Por fim, trate a versão como decisão de segurança, não de compatibilidade. Onde houver dado sensível ou requisito de conformidade, o v3 com autenticação e privacidade é o piso. Onde ainda houver v2c, a segmentação em VLAN de gerenciamento com ACL de origem é o que segura o risco até a migração.
Para desenhar a coleta da sua infraestrutura de rede com limiares que aguentam auditoria, fale com nossos especialistas.
Perguntas Frequentes
O que é SNMP e para que serve?
Qual é a porta usada pelo SNMP?
Qual a diferença entre SNMPv1, SNMPv2c e SNMPv3?
GETBULK e os contadores de 64 bits, mas manteve o mesmo modelo de autenticação do v1. O v3 adiciona autenticação por usuário com HMAC, privacidade com cifragem AES e controle de acesso por visão, que limita quais ramos da árvore cada usuário enxerga. Desde 2002 o IETF recomenda reclassificar o v1 e o v2c como documentos históricos.O que é MIB e OID?
1.3.6.1.2.1.1.3.0, por exemplo, guarda o tempo desde a última inicialização do sistema. MIBs padrão publicadas em RFC cobrem o que todo equipamento tem, como interfaces e uptime. MIBs proprietárias do fabricante expõem o que é específico daquele hardware, como potência óptica de um SFP.Como descobrir os OIDs de um equipamento?
snmpwalk apontando para o ramo que interessa, por exemplo snmpwalk -v2c -c SUA_COMMUNITY 10.0.0.1 1.3.6.1.2.1.2.2.1.2 para listar as interfaces. Rodar o snmpwalk sem OID devolve a árvore inteira, o que em um switch de 48 portas passa facilmente de mil linhas. Depois use o snmptranslate para converter um OID numérico no nome do objeto e carregue os arquivos de MIB do fabricante no coletor, porque eles traduzem número em nome legível e mantêm o template legível meses depois.
