SNMP

Equipamentos de rede que respondem SNMP v1, v2c ou v3 (nobreaks, PDUs, switches, roteadores, ar-condicionado de precisão e sensores de ambiente) lidos pelo seu agente no intervalo de leitura de cada tag: o cartão Agente SNMP, o OID de uma tag em números ou pelo nome padrão, os tipos de dado em que cada objeto é lido, leitura e escrita, a varredura que descobre os objetos de um agente e dois exemplos completos.

O driver SNMP lê e escreve os equipamentos de uma sala técnica pelo agente SNMP deles: nobreaks, PDUs, switches, roteadores, ar-condicionado de precisão e sensores de temperatura ou umidade. Ele completa o driver Redfish, que lê as controladoras de gerenciamento dos servidores: juntos, os dois cobrem a sala técnica. Cada tag lê um objeto do agente pelo seu OID, como upsBatteryStatus.0 ou ifHCInOctets.2, e os valores chegam onde chegam os de toda outra tag: no Logic, nos dashboards, nas execuções de uma bancada de teste do Process.

A estação pergunta: cada tag é lida no seu intervalo de leitura, em SNMPv1, SNMPv2c ou SNMPv3, e o Intervalo de leitura (ms) do cartão Dispositivo funciona como em qualquer driver, com cada tag podendo sobrescrevê-lo. O que o equipamento manda por conta própria, os traps, não é recebido; veja Limites que vale conhecer.

Um dispositivo deste driver é um agente, alcançado no seu host pela porta UDP 161. Os dispositivos ficam sob o driver e podem ser arquivados em pastas, Driver → Pasta → Dispositivo → Tag, como em todo driver sem linha serial nem broker.

A página do driver

Para Configurar Connector, a página traz o cartão Escopo da varredura próprio do driver, com o agente e as subárvores que o Descobrir percorre (veja Descoberta). Abaixo dele fica a tabela Dispositivos de qualquer driver (veja A tabela de dispositivos), que cresce com Acrescentar dispositivo, à direita do título; vazia, diz "Nenhum dispositivo ainda." A barra do driver traz Descobrir, cinza até o cartão Escopo da varredura estar completo.

Dispositivo

Conexão

Um dispositivo novo não tem host: diz "Host ainda não informado", e nada é enviado até ele ter um. A Base URI que o cabeçalho mostra é o endereço de runtime, com a versão, a segurança SNMPv3 em vigor, o timeout de resposta e as novas tentativas: snmp://192.168.10.40:161?version=2c&timeoutMs=2000&retries=1, ou snmp://192.168.10.2:161?version=3&security=authPriv&auth=sha256&priv=aes128&timeoutMs=2000&retries=1. Ela nunca leva a community, o usuário nem uma senha.

O cartão Agente SNMP

Abaixo do cartão Conexão, o cartão Agente SNMP diz como o agente é consultado. Os campos que ele mostra seguem a versão e, no SNMPv3, o nível de segurança.

Abaixo das duas senhas: "Cada senha é a que o agente guarda para este usuário, com pelo menos 8 caracteres." O usuário, o nível de segurança e os dois protocolos são os que o agente tem configurados para esse usuário, na página de configuração do próprio equipamento: a estação não tem como perguntá-los ao agente. MD5, SHA-1 e DES são oferecidos porque muito equipamento instalado não aceita nada mais novo.

Uma credencial ainda não informada não é um erro: o dispositivo é salvo, o driver não manda nada ao agente até ela existir, e uma linha calma abaixo do cartão diz o que falta, a primeira destas:

Um dispositivo que tem o host e ainda não tem uma credencial não se conecta, e o último erro dele nomeia a credencial que o agente espera. Um valor que o cartão não aceita não é salvo, e o cartão diz por que, em vermelho:

O salvamento segue as mesmas regras do cartão, e o feed de ações avisa quando recusa: "O dispositivo 'UPS room 1' tem uma configuração SNMP que o driver não consegue usar. Abra-o e corrija o campo que o painel marca." A community e as duas senhas são guardadas como toda credencial de dispositivo (veja Credenciais e certificados): protegidas em repouso para a conta do Windows que as digitou, lacradas na exportação da configuração, e nunca mostradas na Base URI, no diário nem na resposta de um agente. Uma credencial digitada em outra conta do Windows volta vazia, e o dispositivo espera por ela como por uma nunca informada.

Endereçamento da tag

O OID

Uma tag deste driver lê um objeto do seu agente. O cartão Origem da tag traz a caixa OID, com a dica "Um OID em números, por exemplo 1.3.6.1.2.1.1.3.0, ou um nome padrão com a sua instância, por exemplo sysUpTime.0, ifInOctets.2 ou upsBatteryStatus.0" embaixo. Toda requisição leva o número, seja qual for a forma em que a tag é escrita:

Abaixo da caixa, só para leitura, o OID das duas formas:

Um objeto sem nome padrão acrescenta a linha "Um objeto da MIB própria do equipamento: aparece pelo número, porque nenhum arquivo de MIB é lido." Uma tag cujo OID o driver não consegue ler não é salva, e a página da tag diz por quê:

O salvamento segue a mesma regra: "A tag 'Battery status' não nomeia um OID que o driver SNMP consiga ler. Abra-a e corrija o endereço que o painel da tag marca." A linha só de leitura Endereço de origem (barramento) mostra o número que o driver recebe: 1.3.6.1.2.1.33.1.2.1.0 para uma tag escrita upsBatteryStatus.0.

Os nomes que o driver conhece

O driver traz uma tabela dos objetos das MIBs padrão que vale a pena nomear, escrita a partir das RFCs, então um nome quer dizer a mesma coisa em toda estação. Nenhum arquivo de MIB é lido.

O driver_capabilities lista todos os nomes com o OID de cada um; veja Ferramentas do agente.

Tipos de dado e acesso

A lista Tipo de dado oferece só aquilo em que o objeto é lido sem perda:

Um contador não é oferecido como Float, que arredonda acima de 16.777.216, e um Counter64 não é oferecido como Int64, que recusaria uma contagem acima da metade. Boolean nunca é oferecido: o SNMP não tem booleano, e o TruthValue dele (1 verdadeiro, 2 falso) e o 0 e 1 próprios de um equipamento leriam o mesmo tipo de dois jeitos opostos, então um estado é lido como Int32. Quando o OID muda, um tipo em que o novo objeto não é lido passa a ser aquele em que ele é lido de forma mais natural; e um tipo em que ele não é lido é recusado, nomeando aqueles em que é: "ifHCOutOctets.2 é lido como um destes: UInt64, Double, String."

Um objeto padrão que a MIB declara somente leitura (os contadores, sysUpTime, os estados) só é oferecido como Somente leitura, e o campo Acesso diz "Somente leitura: o dispositivo informa este valor, e nada de fora o define." Um objeto padrão que a MIB declara gravável (sysContact, sysName, sysLocation, ifAdminStatus, ifAlias, os objetos de teste, controle e configuração da UPS-MIB) e um objeto da MIB própria do equipamento recebem todos os acessos: se o agente aceita a escrita é resposta dele.

Leitura

No intervalo de leitura de cada tag, a estação manda um GET. O que o agente responde decide o que a tag mostra (veja A cadeia de valor):

Um dispositivo faz uma requisição por vez. Uma leitura pede o objeto da tag e, na mesma requisição, as outras tags do dispositivo que não têm resposta recente, até 32 OIDs; um agente que responde que a requisição é grande demais (tooBig) recebe metade disso dali em diante. Uma resposta trazida assim serve a leitura de outra tag enquanto for mais nova que a metade do intervalo de leitura dessa tag, então quarenta tags custam uma ou duas requisições por passada. O motor de um agente SNMPv3 é aprendido uma vez por conexão, e uma requisição que o agente diz estar fora da sua janela de tempo é enviada mais uma vez com os números do próprio agente.

Escrita

Uma tag cujo acesso escreve manda um SET pela fila do dispositivo. A escrita passa pelo mesmo funil da de qualquer outro driver: a caixa de escrita recebe o valor de engenharia, e os estágios de conversão são invertidos antes de o valor bruto ser enviado (veja Connector). O SET leva o tipo de valor com que o agente respondeu o objeto pela última vez; na falta dele, o que a MIB declara; na falta deste, o que um GET responde agora; e por último o da própria tag (um Int32 como Integer32, um UInt32 como Gauge32, uma String como OCTET STRING). Um valor que esse tipo não comporta é recusado antes de qualquer envio.

Descoberta

O cartão Escopo da varredura

Para Configurar Connector, a página do driver traz o seu cartão Escopo da varredura, sob a linha "Percorre as subárvores padrão de um agente e lista o que encontra. Um agente SNMPv3 é varrido pelo seu dispositivo: escolha-o como o agente a varrer."

O que ainda falta ao escopo é dito em vermelho abaixo do cartão, e o Descobrir fica cinza até ele estar completo:

Quando o dispositivo a varrer tem uma edição que não pode ser salva, a varredura não começa: "A descoberta não começou porque a edição do dispositivo a varrer não pôde ser salva."

O que a varredura oferece

O Descobrir primeiro pergunta ao agente o nome dele (sysName.0), o que também prova que o agente responde a essas credenciais, e depois percorre cada subárvore marcada e a nomeada, com GETBULK no SNMPv2c e no SNMPv3 e GETNEXT no SNMPv1, até o agente responder fora dela. A linha de progresso conta o que leu: "Percorrendo o agente SNMP em 192.168.10.40:161: 120 objetos encontrados." Uma varredura lista no máximo 2000 objetos e percorre por no máximo 60 segundos; quando é cortada ali, ou quando o agente se cala no meio, ela guarda o que encontrou e diz isso: "A leitura de 192.168.10.40:161 parou antes do fim, com 2000 objetos encontrados. Uma varredura lista no máximo 2000 objetos e percorre por no máximo 60 s, e para onde o agente se cala."

A varredura oferece um candidato por agente, com o nome do sysName dele (o nome do dispositivo ou o host quando o agente não dá nenhum), com a versão, o timeout e as novas tentativas com que foi lido, e os objetos que encontrou como tags candidatas:

Um valor que nenhum tipo de tag comporta fica de fora. Um dispositivo adicionado a partir de uma varredura digitada guarda a community que a varredura usou, protegida como toda credencial de dispositivo; um dispositivo adicionado a partir da varredura de um dispositivo leva as credenciais desse dispositivo. Um candidato cujo agente um dispositivo do driver já lê (o dispositivo varrido, ou outro no mesmo host e porta) é marcado Já configurado: o cartão dele lista só os objetos que nenhuma tag desse dispositivo lê ainda, um OID escrito pelo nome e pelo número contando como o mesmo, e Acrescentar tags, antes de Abrir, acrescenta os marcados a esse dispositivo. O resto do comportamento da varredura está em Descoberta.

A própria página de um dispositivo faz o mesmo sem a página do driver: Descobrir tags, no cabeçalho do cartão Tags dele, caminha pelo agente daquele dispositivo com as configurações e credenciais dele, pelas subárvores padrão e pelo ramo do fabricante que as tags dele já leem (enterprises.318 para uma tag abaixo dele), e oferece só os objetos para os quais ele ainda não tem tag (veja Descobrir as tags de um dispositivo).

Exemplo: um nobreak por SNMPv2c

Um nobreak com placa de rede responde SNMPv2c em 192.168.10.40, com uma community de leitura definida nessa placa. Leia a bateria dele:

1. Na página do driver, Acrescentar dispositivo; dê o nome UPS room 1, informe Host ou IP 192.168.10.40 e mantenha Porta 161.
2. No cartão Agente SNMP mantenha SNMPv2c, digite a community de leitura da placa em Community, e mantenha um Timeout de resposta (ms) de 2000 e 1 em Novas tentativas. A linha que pedia a community some.
3. Acrescentar tag Battery status, OID upsBatteryStatus.0, Tipo de dado Int32. Abaixo da caixa, o nome na MIB diz upsBatteryStatus.0 com UPS-MIB · Integer32 · somente leitura, o OID numérico 1.3.6.1.2.1.33.1.2.1.0, e o acesso fica em Somente leitura. O valor é 1 unknown, 2 batteryNormal, 3 batteryLow ou 4 batteryDepleted.
4. Acrescentar tag Battery charge, OID upsEstimatedChargeRemaining.0, Tipo de dado Int32, Unidade %.
5. Se o nobreak informar, Acrescentar tag Minutes remaining, OID upsEstimatedMinutesRemaining.0, Tipo de dado Int32, Unidade min.

A Base URI diz snmp://192.168.10.40:161?version=2c&timeoutMs=2000&retries=1. Um agente faz o mesmo com as ferramentas:

device_upsert name="UPS room 1" driver=Snmp host=192.168.10.40 snmpVersion=V2c snmpCommunity="<the UPS card's read community>"
tag_upsert device="UPS room 1" name="Battery status" address=upsBatteryStatus.0 opcUaType=Int32
tag_upsert device="UPS room 1" name="Battery charge" address=upsEstimatedChargeRemaining.0 opcUaType=Int32 unit=%
tag_upsert device="UPS room 1" name="Minutes remaining" address=upsEstimatedMinutesRemaining.0 opcUaType=Int32 unit=min

Exemplo: os contadores de interface de um switch por SNMPv3

Um switch gerenciável em 192.168.10.2 responde SNMPv3 para o usuário scada, configurado no switch com autenticação SHA-256 e privacidade AES-128. Leia o tráfego e o estado da porta 2 dele:

1. Acrescentar dispositivo; dê o nome Core switch, Host ou IP 192.168.10.2, Porta 161.
2. No cartão Agente SNMP escolha SNMPv3, digite scada em Usuário SNMPv3, mantenha Assinado e criptografado (authPriv), escolha SHA-256 em Protocolo de autenticação e digite a senha dele, mantenha AES-128 em Protocolo de privacidade e digite a senha dele: cada uma a que o switch guarda para scada, com pelo menos 8 caracteres.
3. Acrescentar tag Port 2 in, OID ifHCInOctets.2. O tipo de dado passa a UInt64, o tipo em que um contador de 64 bits é lido, e a lista oferece só UInt64, Double e String; Unidade B.
4. Acrescentar tag Port 2 out, OID ifHCOutOctets.2, UInt64, Unidade B.
5. Acrescentar tag Port 2 state, OID ifOperStatus.2, Tipo de dado Int32: 1 up, 2 down, 3 testing, 7 lowerLayerDown.

O .2 é o índice da interface no switch, o que ifName.2 nomeia; uma varredura da subárvore de interfaces lista cada interface com o seu índice. A Base URI diz snmp://192.168.10.2:161?version=3&security=authPriv&auth=sha256&priv=aes128&timeoutMs=2000&retries=1. Com as ferramentas, um opcUaType em que o objeto não é lido, como Int32 em ifHCOutOctets.2, é recusado com os tipos em que ele é lido:

device_upsert name="Core switch" driver=Snmp host=192.168.10.2 snmpVersion=V3 username=scada password="<authentication password>" snmpSecurityLevel=AuthPriv snmpAuthProtocol=Sha256 snmpPrivacyProtocol=Aes128 snmpPrivacyPassword="<privacy password>"
tag_upsert device="Core switch" name="Port 2 in" address=ifHCInOctets.2 opcUaType=UInt64 unit=B
tag_upsert device="Core switch" name="Port 2 out" address=ifHCOutOctets.2 opcUaType=UInt64 unit=B
tag_upsert device="Core switch" name="Port 2 state" address=ifOperStatus.2 opcUaType=Int32

Ferramentas do agente

O driver_capabilities descreve este driver em snmp: as versões e as credenciais que cada uma recebe, os níveis de segurança e os protocolos, o timeout de resposta e as novas tentativas, como um OID é escrito, os tipos por espécie de valor, todos os nomes que o driver conhece com a MIB, o OID e se aceitam escrita, como leituras e escritas se comportam, a descoberta e os dois exemplos acima. O device_upsert driver=Snmp recebe host, port (161 por padrão), snmpVersion (V1, V2c, o padrão, ou V3), snmpCommunity no SNMPv1 e no SNMPv2c ('' a apaga), e no SNMPv3 username (o usuário), password (a senha de autenticação, com pelo menos 8 caracteres), snmpSecurityLevel (AuthPriv, o padrão, AuthNoPriv ou NoAuthNoPriv), snmpAuthProtocol (Md5, Sha1, o padrão, Sha256, Sha384 ou Sha512), snmpPrivacyProtocol (Des, Aes128, o padrão, Aes192 ou Aes256) e snmpPrivacyPassword; com responseTimeoutMs (de 100 a 60000, 2000 por padrão) e snmpRetries (de 0 a 5, 1 por padrão). Uma community num dispositivo SNMPv3, ou um campo SNMPv3 num dispositivo de community, é recusado. Um dispositivo que as ferramentas devolvem traz snmp: a versão, hasCommunity, o nível de segurança e os protocolos em vigor, hasPrivacyPassword, o timeout, as novas tentativas e missingCredential, a credencial que ele ainda espera; nenhum segredo é devolvido. O tag_upsert recebe o OID como address e opcUaType, que por padrão é o tipo em que o objeto é lido de forma mais natural; wireQuantity e eipPath são recusados. O device_discover driver=Snmp percorre ou target (um host, com port quando não for 161) com snmpVersion (V1 ou V2c) e snmpCommunity, ou snmpDevice, o nome de um dispositivo do driver, que é o único jeito de varrer um agente SNMPv3; snmpSubtrees escolhe as subárvores padrão (System, Interfaces, Ups, Sensors, HostResources, separadas por vírgula) e snmpSubtree acrescenta mais uma. As ferramentas não guardam uma community de varredura: um dispositivo criado a partir do que a varredura encontrou a recebe de novo no device_upsert, e as tags que faltam a um dispositivo configurado são acrescentadas com tag_upsert. As outras ferramentas estão em Ferramentas do agente.

Limites que vale conhecer

• Traps e informs, o que o equipamento manda por conta própria quando algo acontece, não são recebidos: cada valor é lido no seu intervalo de leitura, então uma bateria que fica fraca é vista na próxima leitura do seu estado.
• Nenhum arquivo de MIB é importado. Os nomes que o driver conhece são os das MIBs padrão que ele traz; um objeto da MIB própria do equipamento, sob enterprises, é escrito e mostrado pelo número, e o que ele significa se lê na documentação do fabricante.
• A estação não é um agente SNMP: nada lê a própria estação por SNMP.
• Uma varredura só alcança um agente SNMPv3 por um dispositivo que guarda o usuário e as senhas dele, e não tenta nenhuma community nem usuário por conta própria.
• Uma varredura lista no máximo 2000 objetos e percorre por no máximo 60 segundos: num switch grande, desmarque as subárvores que não servem, ou nomeie a que serve.
• Nenhuma tag é Boolean: um TruthValue ou um ligado e desligado próprio do equipamento é lido como Int32.