Guia de gerenciamento de dispositivos de rede: SNMP, TFTP e syslog sem um NMS completo

Gerenciar switches e roteadores sem softwares caros depende de três protocolos leves. Combinar a coleta SNMP via porta UDP 161, transferências de arquivos TFTP sob a RFC 1350 e coleta de syslog na porta UDP 514 oferece visibilidade e recuperação completas. Executar esses recursos a partir de um único utilitário cobre as tarefas diárias sem a sobrecarga de uma grande plataforma.

O que o SNMP, TFTP e syslog realmente fazem por você?

Cada protocolo responde a uma pergunta diferente sobre um dispositivo. Juntos, eles cobrem a maior parte do que você faz em um switch ou roteador entre as instalações.

O SNMP responde "em qual estado este dispositivo está agora?" O Simple Network Management Protocol (SNMP) permite que um gerenciador leia valores de um dispositivo. Uma solicitação get lê um único valor, como o tempo de atividade ou a contagem de erros de uma interface. Um walk lê todos os valores sob um ramo da árvore, um após o outro. Cada valor possui um identificador de objeto (OID), um número com pontos como 1.3.6.1.2.1.1.3 para sysUpTime. Uma Management Information Base (MIB) é o arquivo de texto que dá a esses números nomes legíveis por humanos.

O TFTP responde "como coloco ou retiro um arquivo deste dispositivo?" O Trivial File Transfer Protocol (TFTP), definido na RFC 1350, move arquivos pela porta UDP 69 sem necessidade de login. A maioria dos switches e roteadores gerenciados pode copiar sua configuração em execução para um servidor TFTP. Eles também podem baixar imagens de firmware de um deles.

O Syslog responde "o que este dispositivo tem me dito?" Os dispositivos enviam linhas de log para um receptor à medida que os eventos acontecem. O formato atual é a RFC 5424, e muitos equipamentos de rede ainda enviam o formato BSD mais antigo descrito na RFC 3164. Os traps SNMP fazem o mesmo trabalho para alertas estruturados. Um trap linkDown, por exemplo, chega na porta UDP 162 no momento em que uma porta cai.

Onde cada protocolo se encaixa

Tarefa	Protocolo	Transporte e porta	Padrão	Segurança integrada
Coletar estado do dispositivo sob demanda	SNMP get, getnext, getbulk	UDP 161	RFC 3416 (operações), RFC 3411 a 3418 (SNMPv3)	v2c: community string em texto simples. v3: autenticação e criptografia (RFC 3414, RFC 3826)
Receber alertas estruturados	SNMP trap ou inform	UDP 162	RFC 3416	Corresponde à versão SNMP em uso
Fazer backup de configs, restaurar configs, carregar firmware	TFTP	UDP 69, depois uma nova porta por transferência	RFC 1350, opções nas RFCs 2347 a 2349	Nenhuma: sem autenticação, sem criptografia
Coletar logs de dispositivos	Syslog	UDP 514, ou TLS na TCP 6514	RFC 5424, RFC 5426, RFC 5425	UDP: nenhuma. TLS: criptografia e autenticação de servidor

O que você precisa antes de começar?

A configuração é leve, mas cinco fatores decidem se ela funcionará desde o primeiro dia.

• Uma rede de gerenciamento. Coloque as interfaces de gerenciamento dos dispositivos em uma VLAN de gerenciamento. Uma VLAN é uma rede lógica separada que roda nos mesmos switches físicos. Isso mantém o tráfego de SNMP, TFTP e syslog longe do tráfego de convidados e funcionários.
• Um host de gerenciamento fixo. Use um notebook ou jump host nessa VLAN com um endereço estático. Os dispositivos enviam logs e traps para um endereço fixo, de modo que um endereço dinâmico interrompe a coleta de forma silenciosa.
• Credenciais. Crie um usuário SNMPv3 com autenticação e privacidade se o seu firmware for compatível. Se precisar usar v2c, altere a string de comunidade padrão e restrinja-a ao acesso de apenas leitura a partir do seu host de gerenciamento.
• Sincronização de tempo. Aponte todos os dispositivos para a mesma origem NTP. Sem isso, os carimbos de data/hora do syslog de diferentes dispositivos não poderão ser alinhados durante uma falha.
• Regras de firewall. Permita UDP 161 do seu host para os dispositivos. Permita UDP 162 e UDP 514 dos dispositivos para o seu host. O TFTP precisa do UDP 69 mais as portas adicionais cobertas abaixo.

Como o modelo de gerenciamento do seu fabricante altera o plano

Plataformas gerenciadas na nuvem mantêm a configuração em sua nuvem, portanto, o backup via TFTP é menos importante nelas. O SNMP e o syslog ainda oferecem uma visão local do comportamento do dispositivo.

Fabricante	Modelo de gerenciamento	Onde fica a configuração	O que uma ferramenta local ainda faz
Cisco Meraki	Dashboard de nuvem Meraki	Dashboard Meraki	Recebe syslog, faz varredura SNMP onde ativado no dashboard
HPE Aruba	CLI nos switches AOS-S e AOS-CX, ou Aruba Central	No switch, espelhado no Central onde utilizado	Varredura SNMP, syslog, cópia de configuração por TFTP
Ruckus	CLI nos switches ICX, ou controladora Ruckus e gerenciamento em nuvem	No switch	Varredura SNMP, syslog, cópia de configuração por TFTP
Juniper Mist	Nuvem Mist gerenciando switches Junos EX	Nuvem Mist	Varredura SNMP e syslog a partir do Junos
Ubiquiti UniFi	Aplicativo UniFi Network	Backups do aplicativo UniFi Network	Syslog remoto, SNMP onde ativado
Cambium	cnMaestro, ou gerenciamento local em switches cnMatrix	cnMaestro ou o switch	Varredura SNMP e syslog
Extreme	CLI no Switch Engine (EXOS), ou ExtremeCloud IQ	No switch	Varredura SNMP, syslog, cópia de configuração por TFTP
Fortinet	GUI ou CLI do FortiGate e FortiSwitch, ou FortiManager	No dispositivo	Varredura SNMP, syslog, backup de configuração por TFTP a partir da CLI

Os switches Cisco Catalyst que rodam IOS ou IOS XE ficam fora do modelo Meraki. A configuração deles fica no switch e é copiada para um servidor TFTP a partir da CLI.

Como configurar a varredura SNMP, backups por TFTP e um receptor syslog?

O Netforge Network Multi-Tool inclui um cliente SNMP, um servidor TFTP e um receptor syslog. Uma instalação no seu host de gerenciamento cobre as três etapas abaixo. As mesmas etapas funcionam com ferramentas autônomas se você já as utiliza.

Etapa 1: executar um SNMP walk sem um navegador MIB

Você não precisa de um navegador MIB para obter respostas úteis. Uma MIB apenas traduz números em nomes. Faça o walk na ramificação numérica correta e os valores falarão por si mesmos. Comece com estas quatro ramificações padrão:

• 1.3.6.1.2.1.1 (grupo do sistema). Retorna sysDescr (modelo e string de firmware), sysUpTime, sysName e sysLocation. Definido na RFC 3418.
• 1.3.6.1.2.1.2.2 (ifTable). Retorna descrições de interface, status operacional, erros e contadores de tráfego de 32 bits. Definido na RFC 2863.
• 1.3.6.1.2.1.31.1.1 (ifXTable). Retorna contadores de alta capacidade de 64 bits e os aliases de interface que você digitou como descrições de porta.
• 1.3.6.1.4.1 (private enterprise branch). Retorna valores específicos do fabricante sob números de empresa atribuídos pela IANA. O número da Cisco, por exemplo, é 9.

No Netforge, insira o endereço do dispositivo, suas credenciais SNMP e um OID inicial, depois execute um walk. Cada resultado é lido como um OID, um tipo e um valor. Uma STRING em sysDescr é lida como texto simples. Um valor de Timeticks em sysUpTime conta centésimos de segundo desde que o agente foi iniciado.

Se você preferir a linha de comando, o snmpwalk do Net-SNMP faz o mesmo trabalho:

snmpwalk -v3 -l authPriv -u <user> -a SHA -A <auth-passphrase> -x AES -X <priv-passphrase> <switch-address> 1.3.6.1.2.1.1

Comece de forma restrita. Um walk a partir da raiz em um grande switch de núcleo pode retornar dezenas de milhares de linhas e expirar o tempo limite. Faça o walk em um único ramo, encontre o que precisa e, na próxima vez, use um get para esse OID específico.

Leia o tráfego dos contadores de 64 bits. Um contador de octetos de 32 bits reinicia em cerca de 4,29 bilhões de bytes. Em um link de 1 Gbps em taxa de linha, esse reinício ocorre aproximadamente a cada 34 segundos. A RFC 2863 exige contadores de octetos de 64 bits em interfaces mais rápidas que 20 Mbps exatamente por esse motivo.

Passo 2: execute um servidor TFTP para backups de configuração do switch

Inicie o servidor TFTP no Netforge, escolha uma pasta raiz e permita gravações de arquivos. Em seguida, envie a configuração do dispositivo para o seu host. O comando varia de acordo com o fabricante:

• Cisco IOS e IOS XE: copy running-config tftp: solicita o endereço do servidor e um nome de arquivo.
• HPE Aruba AOS-S: copy running-config tftp seguido pelo endereço do servidor e nome do arquivo.
• Extreme Switch Engine (EXOS): tftp put com o endereço do servidor e detalhes do arquivo.
• Fortinet FortiGate: execute backup config tftp seguido por um nome de arquivo e o endereço do servidor.

Verifique a referência de comandos do seu fabricante para a sintaxe exata na versão do seu firmware. Nomeie cada arquivo com o hostname e a data, para que uma restauração nunca puxe a configuração do switch errado. Mova os backups finalizados do host TFTP para um armazenamento protegido.

Os carregamentos de firmware funcionam da mesma forma ao contrário. Imagens maiores que cerca de 32 MB podem falhar em servidores limitados a blocos de 512 bytes. O contador de blocos de 16 bits se esgota nesse tamanho. A opção blocksize na RFC 2348 elimina esse limite quando ambas as extremidades o suportam.

Desligue o servidor TFTP quando terminar. O TFTP não possui autenticação, portanto, um servidor sempre ativo é um ponto de descarte de arquivos aberto em sua rede de gerenciamento.

Passo 3: execute um receptor de syslog e SNMP trap

Aponte o host de logs de cada dispositivo para o endereço do seu host de gerenciamento. Em seguida, defina um limite de severidade. As severidades do syslog vão de 0 (Emergency) a 7 (Debug). Enviar de 0 a 5 (Notice) captura falhas e alterações de estado sem inundar o receptor. Aumente o nível de um dispositivo para Debug apenas enquanto estiver investigando uma falha específica.

Adicione seu host como um destino de trap SNMP com as mesmas credenciais que você usa para polling. Ative as notificações padrão de SNMPv2-MIB e IF-MIB: coldStart, linkDown, linkUp e authenticationFailure. Use informs em vez de traps onde o dispositivo os suportar. Um inform aguarda uma confirmação, de modo que um alerta perdido é reenviado.

O receptor de syslog Netforge exibe logs e traps na mesma ferramenta que você usa para polling e transferência de arquivos. Isso elimina a necessidade de executar o Kiwi Syslog Server junto com o Tftpd64 e um navegador MIB separado.

Cenário real: um hotel de 200 quartos restaura um switch com falha

Situação. Um hotel de 200 quartos operava 14 switches: dois de core e 12 de acesso. Um evento de energia danificou um switch de acesso que atendia a dois andares de hóspedes. Não existia backup de configuração. O engenheiro reconstruiu as VLANs e as configurações de porta a partir de fotos e de memória, o que levou um dia inteiro de trabalho.

O que foi feito. O gerente de TI configurou um host de gerenciamento com TFTP, SNMP e syslog em uma única ferramenta. Toda configuração de switch era enviada para o TFTP semanalmente e antes de cada alteração. Um SNMP walk mensal do grupo de sistemas registrava cada modelo e versão de firmware. Todos os 14 switches enviavam syslog e traps para o mesmo receptor.

Resultado. Quando um segundo switch de acesso falhou, a substituição chegou como o mesmo modelo. O engenheiro carregou a configuração da semana anterior do servidor TFTP. Os hóspedes daqueles andares estavam online novamente em menos de uma hora, em comparação com um dia inteiro na primeira vez. As equipes de hotéis que operam redes de WiFi para hóspedes em grande escala enfrentam o mesmo padrão em todas as propriedades: consulte Hotéis.

Como você verifica se funciona?

Teste cada protocolo em relação a um resultado conhecido antes de confiar nele.

• SNMP. Obtenha o sysUpTime duas vezes, com um minuto de intervalo. O valor deve aumentar em cerca de 6.000 centésimos de segundo. Confirme se o sysName corresponde ao hostname esperado.
• Backup TFTP. Abra o arquivo salvo e leia-o. Uma configuração do Cisco IOS termina com a linha end, de modo que um arquivo truncado aparece imediatamente. Compare o tamanho do arquivo com o backup anterior.
• Restauração TFTP. Restaure um backup em um switch reserva ou de laboratório. Um backup que você nunca restaurou é uma esperança, não um plano de recuperação.
• Syslog e traps. Desative e reative uma porta não utilizada. Você deve ver um trap linkDown e um linkUp, além de linhas de syslog correspondentes. Seus carimbos de data/hora devem coincidir ao segundo se o NTP estiver funcionando.
• Cobertura. Confirme se todos os dispositivos em seu inventário enviaram pelo menos uma linha de log nas últimas 24 horas. Um dispositivo silencioso geralmente é um dispositivo mal configurado.

O que dá errado e como corrigir?

A maioria das falhas se resume a firewalls, credenciais ou interfaces de origem. Esta tabela mapeia os sintomas comuns para suas correções.

Sintoma	Causa provável	Correção
A solicitação SNMP expira (timeout)	A lista de controle de acesso do dispositivo bloqueia seu host, ou o UDP 161 está filtrado	Adicione seu host à lista de acesso SNMP e abra a porta UDP 161
SNMPv3 falha com erro de autenticação	Incompatibilidade de algoritmo de autenticação ou privacidade	Combine as configurações de SHA e AES em ambas as pontas e insira as senhas novamente
Walk retorna dados do sistema, mas nada sob a ramificação enterprise	O controle de acesso baseado em visualização (RFC 3415) limita o que seu usuário pode ver	Amplie a visualização SNMP para seu usuário somente leitura
A transferência TFTP inicia e depois trava	O firewall ou NAT bloqueia a porta de acompanhamento de onde o servidor responde	Permita a faixa de portas de transferência do servidor ou mantenha o TFTP dentro de uma única VLAN
Gravação TFTP recusada	O servidor não criará novos arquivos ou as permissões de pasta bloqueiam as gravações	Permita a criação de arquivos no servidor e verifique as permissões de pasta
Firmware grande falha no meio do caminho	Limite de bloco de 512 bytes atingido em cerca de 32 MB	Ative a opção blocksize ou use o upload SCP ou HTTP do fornecedor
Nenhum syslog chega	O dispositivo envia de uma interface diferente ou o firewall do host bloqueia a porta UDP 514	Defina a interface de origem do log e permita a entrada de UDP 514
Os logs aparecem fora de ordem	Os dispositivos não estão sincronizados com o NTP	Configure a mesma origem NTP em todos os dispositivos
Os gráficos de interface ficam planos ou dão saltos	Estouro do contador de 32 bits	Monitore ifHCInOctets e ifHCOutOctets a partir da ifXTable

Quanto custa e o que você recebe de volta?

O custo real do gerenciamento de dispositivos é o tempo do engenheiro e o tempo de inatividade, não o software. Compare as três abordagens comuns sob os eixos que impulsionam ambos.

Abordagem	Ferramentas para instalar	Protocolos cobertos	Desenvolvido para	Adequado para
Freeware de finalidade única	Três: Tftpd64, Kiwi Syslog Server, um navegador MIB	TFTP e syslog, traps SNMP via Kiwi, monitoramento SNMP via navegador	Tarefas ad hoc, uma ferramenta por trabalho	Um engenheiro que já domina as três
Multi-ferramenta leve (Netforge Network Multi-Tool)	Uma	SNMP get e walk, servidor TFTP, receptor de syslog e trap	Monitoramento sob demanda, transferências e logs em tempo real	Pequenas propriedades, trabalho de campo de MSP, locais únicos
NMS completo	Uma plataforma mais um banco de dados e servidor	SNMP, syslog, traps, além de descoberta, gráficos e roteamento de alertas	Monitoramento contínuo e histórico de tendências de longo prazo	Propriedades grandes ou multi-site com equipes de plantão

Quando você precisa de um NMS completo

Uma ferramenta leve lê o estado quando você solicita. Um NMS completo monitora continuamente e lembra. Mude para um NMS completo quando uma destas condições for verdadeira:

• Você precisa de semanas de histórico de interface para planejamento de capacidade.
• Os alertas devem acionar um engenheiro de plantão às 3h sem que ninguém precise monitorar uma tela.
• Sua propriedade abrange dezenas de locais, como estações em uma rede ferroviária. Consulte Trens.
• Os auditores exigem relatórios automatizados em vez de arquivos exportados manualmente.

Abaixo dessa linha, um NMS completo adiciona um servidor, um banco de dados e manutenção para recursos que você não usará.

Cenário prático: uma rede de varejo de 40 lojas encontra falhas de link ocultas

Situação. Um MSP prestava suporte a uma rede de 40 lojas. Cada loja operava um firewall Fortinet FortiGate e dois switches. As equipes das lojas relatavam que os terminais de cartão ficavam offline várias vezes por semana. As visitas dos engenheiros não revelavam nada, pois a falha já havia sido resolvida antes que alguém chegasse.

O que foi feito. O MSP direcionou o syslog e os traps SNMP de todos os 120 dispositivos para um receptor através da VPN site-to-site existente. Cada switch enviou traps linkDown e linkUp. A equipe revisou o receptor diariamente por duas semanas.

Resultado. Os logs mostraram flutuações repetidas de link (link flaps) em portas de uplink em três lojas, coincidindo com os horários de queda relatados. A equipe da loja substituiu três cabos de manobra (patch leads) defeituosos sob orientação remota. O MSP encerrou as visitas reativas para essa falha, e as três lojas não relataram novas quedas de terminal. Saiba mais sobre como redes de varejo gerenciam sua infraestrutura: Retail.

Conformidade e manuseio de dados

Os logs de dispositivos têm peso regulatório. O PCI-DSS exige que os padrões de fábrica sejam alterados, e a versão 3.2.1 nomeia explicitamente as community strings SNMP. O requisito 10.5.1 do PCI-DSS versão 4.0 solicita que você retenha logs de auditoria por pelo menos 12 meses, com três meses imediatamente disponíveis. O controle 8.15 do Anexo A da ISO 27001 cobre logs.

As linhas de syslog podem conter endereços IP e MAC, que podem ser considerados dados pessoais sob o GDPR. Defina um período de retenção e restrinja quem pode ler os arquivos do receptor. Isso é ainda mais crítico em ambientes regulados: consulte Healthcare.

Onde a Purple se encaixa

A Purple é agnóstica em relação a hardware. Nosso Guest WiFi funciona como um overlay em nuvem sobre Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme Networks e Fortinet, em mais de 80.000 locais ativos (dados da Purple). Switches saudáveis e bem documentados na base tornam qualquer serviço de overlay mais fácil de operar. O Netforge Network Multi-Tool oferece aos seus engenheiros a visão em nível de dispositivo para mantê-los assim.

Perguntas frequentes

Preciso de um NMS completo para gerenciar apenas alguns switches?

Não. Para um único local ou uma infraestrutura pequena, polling SNMP, backups TFTP e um receptor syslog cobrem a maior parte do gerenciamento diário. Um NMS completo justifica seu custo quando você precisa de monitoramento contínuo, semanas de histórico de tendências, alertas automatizados para engenheiros de plantão ou gerenciamento em dezenas de locais. Abaixo desse patamar, ele apenas adiciona um servidor, um banco de dados e custos de manutenção para recursos que você não usará.

Posso fazer um SNMP walk sem um navegador MIB?

Sim. Uma MIB apenas traduz OIDs numéricos em nomes, então você pode percorrer (walk) as ramificações numéricas diretamente. Comece com 1.3.6.1.2.1.1 para modelo, firmware e uptime, e 1.3.6.1.2.1.31.1.1 para nomes de interfaces e contadores de tráfego de 64 bits. O Netforge Network Multi-Tool executa comandos get e walk a partir de um OID inicial. O snmpwalk do Net-SNMP faz o mesmo a partir da linha de comando.

O TFTP é seguro para fazer backup de configurações de switch?

Sim, se você o mantiver isolado. O TFTP não possui autenticação ou criptografia sob a RFC 1350, portanto, qualquer pessoa no caminho pode ler uma configuração em trânsito. Execute o servidor TFTP apenas em uma VLAN de gerenciamento e somente durante um backup ou restauração. Mova os arquivos finalizados para um armazenamento protegido. Onde seu fabricante oferecer suporte a SCP ou SFTP, use-os para backups agendados.

Isso funcionará com meu hardware Cisco, Aruba ou Fortinet existente?

Sim. SNMP, TFTP e syslog são padrões abertos suportados pelo Cisco IOS, HPE Aruba AOS-S e AOS-CX, Ruckus ICX, Extreme Switch Engine e Fortinet FortiGate. Plataformas gerenciadas na nuvem, como Cisco Meraki, Juniper Mist e Ubiquiti UniFi, mantêm a configuração em sua nuvem. Nelas, você usa SNMP e syslog localmente e faz o backup da configuração por meio da própria plataforma do fabricante.

Uma única ferramenta pode substituir o Tftpd64 e o Kiwi Syslog Server?

Sim. O Netforge Network Multi-Tool inclui um servidor TFTP, um receptor de syslog e SNMP trap, e SNMP get e walk em um único aplicativo. Isso substitui o Tftpd64 para transferências de arquivos e o Kiwi Syslog Server para logs, além de eliminar a necessidade de um navegador MIB separado. Se você precisar de armazenamento de logs de longo prazo ou roteamento automatizado de alertas, combine-o com uma plataforma de logs ou um NMS completo.

Os logs de dispositivos se enquadram no PCI-DSS e GDPR?

Sim, na maioria dos locais. O requisito 10.5.1 da versão 4.0 do PCI-DSS exige que os logs de auditoria sejam retidos por pelo menos 12 meses, com três meses imediatamente disponíveis, para sistemas no escopo. As linhas de syslog podem incluir endereços IP e MAC, que podem ser considerados dados pessoais sob a GDPR. Defina um período de retenção, restrinja o acesso aos arquivos de log e documente ambos.

Quanto tempo leva a configuração para um ambiente pequeno?

A maior parte do esforço está na configuração do lado do dispositivo, e não na ferramenta em si. Definir um host de log, um destino de trap e um usuário SNMPv3 leva alguns minutos por switch a partir da CLI. Para um site com 14 switches, espere uma tarde de trabalho, incluindo regras de firewall e verificação. O trabalho de NTP e VLAN de gerenciamento, se ainda não estiver implementado, geralmente leva mais tempo do que a configuração da ferramenta.