Transferir como ODP, PPTX
Carregado porMauro Tapajós
Gerência de Redes - 2.Modelo SNMP
1) O documento descreve as versões SNMPv1 e SNMPv2, incluindo suas operações, formatos de mensagens e tipos de agentes. 2) SNMPv1 usa comunidades para autenticação, enquanto SNMPv2 introduz autenticação baseada em partições. 3) SNMPv2 também introduz novas operações como getBulkRequest e melhorias na manipulação de tabelas MIB.
Mais conteúdo relacionado
Semelhante a Gerência de Redes - 2.Modelo SNMP
![[CLASS 2014] Palestra Técnica - Marcelo Branquinho e Jan Seidl](https://cdn.slidesharecdn.com/ss_thumbnails/ptclass33-marcelobranquinhoejanseidl-141113071102-conversion-gate02-thumbnail.jpg?width=640&height=640&fit=bounds)
Gerência de Redes - 2.Modelo SNMP
- 1. Sumário Protocolos SNMPv1Operações
- 2.
- 3. Acesso a MIBsProtocolo SNMPv2 Novas operações
- 4. Alterações na SMITipos de Agentes SNMP
- 5. Introdução - SNMPSimple Network Management Protocol: Aberto
- 6. Padrão de mercado– TCP/IP
- 7.
- 8. SMI SNMP (RFC1155) sysUptime OBJECT-TYPE SYNTAX Time-Ticks ACCESS read-only STATUS mandatory DESCRIPTION “ The time (in hundredths of a second) since the network management portion of the system was last re-initialized.” ::= { system 3 }
- 9. Tipos de DadosSNMP INTEGER (signed 32-bit integer)
- 10.
- 11.
- 12.
- 13. IpAddress (OCTET STRINGde tamanho 4)
- 14. Counter (unsigned 32-bitinteger)
- 15. Gauge (unsigned 32-bitinteger)
- 16. TimeTicks (unsigned 32-bitinteger)
- 17. Opaque (tipos nãouados em SNMPv1)
- 18. Outros: DateAndTime,DisplayString, MacAddress, PhysAddress, TimeInterval, TimeStamp, TruthValue, VariablePointer – todos são textual conventions usados como tipos de dados
- 19.
- 20.
- 21.
- 22. Encapsulamento do ProtocoloSNMPv1 PDU da tecnologia de rede (Ethernet por exemplo) Pacote IP Datagrama UDP Mensagem SNMP
- 23. Mensagem SNMPv1 Númerointeiro indicando a versão do SNMP sendo usada (0 para SNMPv1) Este campo carrega o nome de comunidade que o originador da mensagem está usando. Dados efetivos de gerência a serem analisados e processados Versão Comunidade PDU (Protocol Data Unit)
- 24. Formato do PDUSNMPv1
- 25. O que podedar errado numa operação SNMPv1? Valores de error status : 0 - noError (não houve erro) 1 - tooBig (a resposta é muito grande para a implementação) 2 - noSuchName (uma das variáveis não consta na MIB do agente requisitado) 3 - badValue (erro no pedido de set ) 4 - readOnly (uma mensagem Set tenta alterar uma variável read-only ) 5 - genError (erro desconhecido)
- 26. Obtenção de Valoresde uma MIB Objetos com único valor (instância): 1.3.6.1.2.1.1.1. 0 Objetos com valores múltiplos (múltiplas instâncias) 1.3.6.1.2.12.2.1.2. 1
- 27.
- 28.
- 29. Obtenção de Valoresem Tabelas Tabelas são conjuntos de objetos com valores múltiplos
- 30. Uso do objetodo tipo entryStatus
- 31. Formato do PDUpara a trap SNMPv1 Campo “Generic Trap Type”: 0 – coldStart: reinicialização do dispositivo, configuração do agente não se altera
- 32. 1 – warmStart: reinicialização do dispositivo com possível alteração da configuração do agente
- 33. 2 – linkDown:falha num dos links do agente
- 34. 3 – linkUp:volta de um link do agente
- 35. 4 – authenticationFailure:falha na autenticação de uma mensagem recebida
- 36. 5 – egpNeighborLoss:perda da comunicação com um vizinho EGP
Notas do Editor
- #3 SNMP é o padrão para protocolo de gerência mais popular. Foi o padrão adotado por vários fabricantes e operadoras. Define como funciona a arquitetura de gerenciamento de redes TCP/IP. É simples para ser implementado em todo tipo de equipamentos e flexível o bastante para aceitar futuras modificações. É o protocolo de gerenciamento da arquitetura TCP/IP. Define como funciona a arquitetura de gerenciamento Internet. Está intimamente ligado à forma como as informações de gerenciamento estão organizadas. Apresenta uma SMI própria. Versão 1, 1990, RFC 1157.
- #4 Este é um exemplo de declaração de objeto, para SNMP. As variáveis e seus valores estão diretamente relacionadas com a realidade do equipamento. Um objeto é definido segundo a macro ASN.1 OBJECT-TYPE. As operações sobre objetos da MIB são restritas a leituras e escritas.
- #5 Nem todas as opções de tipos de dados oferecidos pela linguagem ASN.1 são usados com SNMP. O conjunto acima é, na verdade, um subconjunto dos tipos ASN.1 possíveis.
- #6 A arquitetura SNMP prevê o papel de gerentes e agentes. Um gerente mantém o monitoramento e controle de vários itens dentro de uma rede. Estes equipamentos contém um agente SNMP que responde às mensagens do gerente SNMP.
- #7 Nesta figura se vê as operações básicas para SNMPv1. Algumas características do protocolo: Não necessita de um serviço de transporte confiável (normalmente roda sobre UDP) Pode usar outras pilhas de transporte Baseado em arquitetura cliente-servidor (pedidos-respostas), daí não necessitar de serviço de transporte confiável. Utiliza as portas UDP 161 (agente) e 162 (gerente, para as traps).
- #8 Na sua versão 1, o SNMP possui apenas 5 mensagens. getRequest : coletam dados da MIB do agente sem alterá-los, para isso, especifica os objetos desejados por meio de uma lista de pares (ID das variáveis - Valor da variável). Trata-se de uma operação atômica: se ocorre um erros em algum dos objetos pedidos, toda a mensagem é perdida getNextRequest : coletam dados da MIB do agente de maneira semelhante à mensagem de get a diferença é que getNext pede um objeto que é o objeto com identificador imediatamente seguinte numericamente ao que está na mensagem. Isso permite que um gerente possa pedir novos objetos, mesmo sem conhecê-los. setRequest : alteram os dados na MIB do agente. Para isso, especifica os objetos desejados por meio de uma lista de pares (ID das variáveis - Valor desejado da variável). A mensagem de Set segue com os campos de valor das variáveis contendo os valores a serem inseridos. Sua resposta em caso de sucesso conterá os mesmos pares ID-Valor. getResponse : resposta do agente a qualquer uma das mensagens acima. trap : mensagem assíncrona enviada pelos agentes. Será vista en detalhes adiante.
- #9 Este é um exempo comum de encapsulamento do protocolo SNMP usando UDP como protocolo de transporte.
- #10 A mensagem SNMPv1 composta dos seguintes campos: Versão: versão do protocolo Comunidade: string que identifica um grupo de entidades SNMP PDU: específico do tipo de mensagem utilizada Uma comunidade é um nomes textual que especifica o nível de acesso às facilidades oferecidas pelos agentes. Trata-se de um mecanismo trival de autenticação (e uma falha de segurança no protocolo) para controlar quais dispositivos são controlados por qual gerente, pois uma comunidade casa um agente com um conjunto de entidades de aplicação. A idéia é prevenir que gerentes desautorizados escrevam na MIB de um determinado agente, restringindo, assim, a informação vista por determinado gerente. Este fraco esquema de autenticação inibe a utilização da operação de set (operações de escrita) pela inerente falta de segurança.
- #11 Os campos de um PDU SNMPv1 básico são: Tipo de PDU : especifica a operação SNMPv1 dentre as 5 apresentadas. Request ID : número sequencial para associar pedidos com respostas. Error Status : código de retorno da operação. Error Index : em caso de erro, aponta para o objeto onde houve o problema. Lista de pares objeto-valor : identifica objetos e valores a serem utilizados na operação.
- #12 Numa mensagem SNMPv1 response: O campo error status indica o que ocorreu O campo error index aponta para o primeiro objeto que apresentou falha
- #13 Uma variável SNMP é identificada pelo identificador de objeto (OID) e pelo identificador de instância. Por exemplo, para o objeto sysDescr, seu OID é: iso.org.dod.internet.mgmt.mib-2.system.sysDescr = 1.3.6.1.2.1.1.1 para obter o valor da variável (de instância única) efetua-se o get sobre 1.3.6.1.2.1.1.1.0 que é a varável que contém o valor na MIB. Para o caso de variáveis de múltiplas instâncias, utiliza-se os identificadores de cada instância, por exemplo, para o objeto ifDescr (1.3.6.1.2.12.2.1.2): 1.3.6.1.2.12.2.1.2. 1 (primeira instância) 1.3.6.1.2.12.2.1.2. 2 (segunda instância) 1.3.6.1.2.12.2.1.2. 3 (terceira instância) 1.3.6.1.2.12.2.1.2. 4 (quarta instância) ... Note que nem sempre os identificadores de instâncias são números sequenciais (1, 2, 3, ...). O padrão permite que se use qualquer valor. Por exemplo, usar números IP numa tabela de rotas.
- #14 Duas operações podem ser feitas numa tabela: cração e deleção de uma linha. Para manipular as linhas das tabelas em SNMP, é usado um objeto de status na tabela (de tipo entryStatus ). Este objeto possui dois valores possíveis: valid ou invalid . Ao se criar uma linha, uma operação de setRequest conterá valores para os objetos que compõem a tabela, Caso não se tenha todos os valores necessários, é possível que valores default sejam usados para inicializar os demais. A linha é criada realmente quando o valor do objeto de status for alterado para valid . Para se deletar uma linha, altera-se o valor do objeto de status para invalid . O uso de tabelas também é um aspecto de protocolo. Haja visto o uso da operação de getNextRequest. Esta varre a tabela, coluna por coluna, de cima a baixo, de forma que, ao se chear ao final da tabela se obtém o próximo objeto da MIB e com isso otimizando a troca de informações sendo feita pelas mensagens.
- #15 A mensagem de trap reporta ao gerente eventos, problemas e condições anormais. Correlação de alarmes : inteligência que realiza um primeiro diagnóstico da situação. Manipulação e diagnóstico a partir das várias traps que chegam. Uma boa razão para o uso de traps é definir outras política de monitoramento: se existem muitos dispositivos na rede fica inviável se fazer pollings periodicos. Uma solução é se fazer pollings menos frequentes e responder somente se uma trap foi recebida alertando algo. Campos da trap SNMPv1: Enterprise : OBJID que indica o tipo de dispositivo que enviou a trap Tipo da trap genérica : um dos 6 tipos de trap genérica Código específico da trap : identifica uma trap específica de uma determinada “Enterprise” Timestamp : Tempo passado entre o momento em que foi gerada a trap e a última reinicialização Lista de pares objeto-valor : específica da trap
- #16 Traps específicas são definidas pelo valor do enterprise OBJID e o número specific-trap. Existe uma macro (TRAP-TYPE) para definição de traps.
- #17 Uma MIB view é um subconjunto de objetos de uma MIB de um dispositivo, relacionados por grau de acesso. O controle de acesso SNMP define que uma determinada comunidade está restrita às variáveis de uma determinada MIB view. Um perfil de comunidade = MIB view + modo de acesso da view para aquela comunidade
- #18 Cada agente controla sua MIB e o seu uso por estações gerentes, segundo o nome de comunidade apresentado na mensagem SNMPv1. Este é o chamado “esquema de autenticação trivial” que torna SNMPv1 tão inseguro. O valor de not-acessible pode não fazer sentido à primeira vista, mas ele pode ser (usado, por exemplo, para evitar que se peça uma tabela inteira numa operação de get. Isto acontece por que a declaração de uma tabela, na verdade, é a declaração de uma sequência de linhas. Esta sequência tem um identificador como qualquer outro item de dado ASN.1 e poderia ser pedido via uma operação de get, o que não é possível. Assim, declara-se esta sequência como not-acessible para evitar pedidos diretos a ela, mas continua sendo possível se pedir os objetos que a compõem.
- #19 Limitações do protocolo SNMPv1: Não é adequado para gerenciar redes muito grandes Não é adequado para coletar grandes volumes de dados Traps não são confirmadas (não se sabe se chegaram ou não!) Autenticação trivial. Mais adequado a monitoramento (gets) do que controle (sets), falta de segurança Não permite comandos diretos no agente. Apenas alterações chaveadas por mudanças nos valores de objetos Não permite comunicação entre gerentes Pouca funcionalidade comparativamente ao CMIP/CMIS (protocolo/serviço de gerenciamento da arquitetura OSI) A característica atômica das mensagens, ou seja, o fato de uma mensagem obter total sucesso ou total fracasso nas operações (não há a possibilidade de sucesso parcial num request) Impossibilidade de configuração remota dos agentes Todos estes argumentos causaram a evolução para SNMPv2
- #20 A abrangente proposta SNMPv2 “Clássica” (SNMPv2p) baseada em parties foi um fracasso. Em 1995 foi feita mais uma revisão do protocolo em resposta à baixa aceitação da versão SNMPv2p. Tal revisão se deu principalmente no que diz respeito ao contexto baseado em parties, à configuração dos agentes, à dificuldade de descoberta automática da rede e à implementação do modelo administrativo e de segurança. O único consenso então obtido foi aceitar as novidades no protocolo, porém permanecendo o contexto de operação sob a antiga forma de comunidades. Assim, foi apresentada mais uma versão de SNMP, agora chamada de SNMPv2c (baseado em comunidades). Nesta, o modelo administrativo apresentado na versão “clássica” e baseado em parties, foi completamente descartado. Apesar do fracasso, pode-se considerar que há aspectos positivos apresentados na versão SNMPv2p como a criação de extensões da linguagem (que facilitam a declaração de novos objetos) e a melhoria da performance do protocolo na troca de informações com um melhor tratamento de erros. Uma útil experiência prática foi obtida nas implementações e testes com SNMPv2p. Em resumo, SNMPv2cassimilou somente as novas mensagens, correções e SMIv2, esperando ainda melhorias em: Segurança (o grande problema) Configuração Remota Infra-estrutura Administrativa
- #21 A SMIv2 é um superconjunto da primeira SMIv1 - RFCs 1442, 1443, 1444. Agora existem novos (e mais adequados) tipos de dados: Counter32, Counter64, BIT STRING, .. A SMIv2 é uma evolução totalmente compatível com a SMIv1 (a exceção é o novo tipo de dado Counter64).
- #22 Cláusula MAX-ACCESS (define agora o nível MÁXIMO de acesso): not-acessible, acessible-for-notify, read-only, read-write e read-create. Cláusula STATUS: current, obsolet e deprecated.
- #23 Uma nova macro para convenções de texto (TEXTUAL CONVENTIONS) que descreve melhor e com detalhes um tipo de dado específico definido pelo usuário. Várias novas textual conventions foram definidas para SNMPv2.
- #24 A nova convenção de texto rowStatus substituiu a antiga coluna entryStatus. O tratamento das operações com linhas de tabelas ficou mais clara. Às vezes não é possível se preencher uma linha da tabela num único set, por isso se deve mandar “esperar” pelo resto dos dados (createAndWait)
- #25 A pilha de transporte necessária para rodar SNMP sempre foi UDP. Esta característica ficou mais flexível em SNMPv2, onde outras pilhas de protocolos podem ser usadas. Entre as possibilidades de configuração para SNMPv2 estão: protocolos de transporte OSI, Appletalk (protocolo usado por máquinas macintosh), DDP e SPX, usado pelas redes Novell. getRequest / getNextRequest : não existe mais a perda da resposta toda em caso de problema numa das variáveis. Se num pedido de get/getNext ocorrer algum os seguintes erros, o valor da variável será preenchido com o código correspondente e o status de erro da mensagem (errorstatus) será sucesso (zero) noSuchObject noSuchInstance endOfMibView response : é o novo nome da operação getResponse setRequest : a operação de set é executada em duas fases: na primeira, as variáveis são testadas e na segunda elas são propriamente alteradas. Esta operação permanece atômica (tudo ou nada). A lista de códigos de erros aumentou defindo outras situações
- #26 Com a não aceitação do modelo de segurança proposto em SNMPv2p, a mensagem SNMPv2c possui os mesmos delimitadores e cabeçalhos da versão SNMPv1 (com exceção do campo versão que agora tem valor 1 indicando a versao 2) Foi mantido o mesmo esquema de comunidades da versão 1.
- #27 A nova mensagem informRequest permite a um gerente enviar uma notificação à outro gerente quando for necessário. É uma operação análoga à da mensagem trap, porém com confirmação explícita (através de uma mensagem response). Um gerente envia um informRequest a outro em resposta a eventos complexos como a ultrapassagem de um limite máximo de erros ou muitas falhas em operações. Esta nova possibilidade permite a hierarquização da estrutura gerencial do SNMPv2
- #28 Em SNMPv1 quando se desejava grandes quantidades de dados de uma MIB, a limitação do tamanho das respostas era função da implementação no agente distante. Se era pedido um volume muito grande de informações para um único get, a resposta era vazia com o campo error status com valor “tooBig”. Se era pedido um volume muito pequeno de informações para um único get, a coleta de dados não é eficiente A nova operação getBulkRequest otimiza a recuperação de um volume considerável de variáveis, pedindo eficientemente o máximo de dados que um agente pode enviar por meio de uma mensagem response . O pedido de um getBulkRequest pode ser tanto de variáveis individuais ou de linhas de uma tabela. A diferença entre as operações getBulkRequest e getNextRequest está na capacidade da primeira enviar linhas inteiras de uma tabela, além de “navegar” na MIB de forma sequencial exatamente como um getNext.
- #29 Non-repeaters – especifica o número de objetos escalares máximo a ser enviado no response Max-repetitions – define o máximo número de vezes que deve se seguir pelas variáveis de várias estâncias Note que o formato do PDU é o mesmo para as outras operações, simplesmente são usados os campos error status e error index
- #30 Houve uma uniformização do formato da PDU, de forma a evitar o processamento extra para lidar com dois diferentes tipos de PDU como na versão 1. Sobre as traps (agora chamada snmpv2-trap): A definição de uma trap pode ser feita pela nova macro NOTIFICATION-TYPE e apresenta basicamente seu nome e sua lista de variáveis. Todos os campos específicos da trap versão 1 estão agora dentro da lista de variáveis (no lugar do antigo campo timestamp agora é colocado o objeto sysUptime).
- #31 Agentes SNMP basicamente podem ser construídos de duas formas: Agentes extensíveis: são desenvolvidos com arquitetura aberta com design modular permitindo adaptações para novos requisitos de dados de gerenciamento e extensões operacionais Agentes Monolíticos: não são extensíveis. São construídos com otimizações para determinadas plataformas de hardware ou SO, visando melhor performance
- #32 É um agente SNMP que não está no mesmo sistema sendo gerenciado. Isto permite o acesso indireto a dispositivos: sem suporte SNMP sem suporte TCP/IP ou da rede sendo usada Além das vantagens acima, o uso de proxy pode ter aspectos de segurança num determinado ambiente de rede. Para maiores informações: http://www.snmplink.org/
- #33 O pacote NET_SNMP ( http://net-snmp.sourceforge.net/ ) é o pacote SNMP padrão no mundo Linux. Ele é composto de um agente, várias aplicações em linha de comando e uma biblioteca SNMP, desenvolvidos em C + PERL. Licença BSD (permissiva). Seu agente, o snmpd, pode ser configurado para qualquer versão SNMP (1, 2c e 3) sobre IPv4 ou IPv6. Além disso, o agente suporta várias MIBs sendo extensível (SMUX e AgentX). Os arquivos de configuração do pacote se localizam no diretório /etc/snmp/. Para o agente, os arquivos relevantes são: - snmp.conf – configurações padrões para o agente e as aplicações - snmpd.conf – configurações específicas para o agente O arquivo snmpd.conf possui inúmeras opções. Para maiores detalhes veja a man page relacionada com: “ man snmpd.conf” O diretório /usr/share/snmp/mibs/, disponibilizado na instalação do pacote, contém as definições de várias MIBs.
- #34 Dentre as aplicações disponíveis no pacote estão aplicações para: - Obter informação de dispositivos SNMP com requests ( snmpget , snmpgetnext ). - Obter informação de dispositivos SNMP com requests múltiplos: snmpwalk – obtém toda a MIB implementada no agente snmptable – obtém uma tabela SNMP completa snmpdelta – monitora as alterações em variáveis de uma MIB - Obter informações específicas de dispositivos SNMP snmpdf – obtém informações de espaço em disco na máquina remota snmpnetstat – obtém informações de rede (status e configuração) snmpstatus – obtém informações de estado do dispositivo remoto - Alterar a configuração de dispositivos SNMP ( snmpset ). - Mostrar o conteúdo de MIBs em formato numérico ou textual ( snmptranslate ). - Um MIB browser gráfico ( tkmib ) desenvolvido em Tk/perl. - Enviar traps SNMP ( snmptrap ). - Receber notificações SNMP ( snmptrapd ) e dar destino a elas (log, repasse para outro gerente SNMP ou outra aplicação). Ele possui um arquivo de configuração próprio (/etc/snmp/snmptrapd.conf)
- #35 Cada um dos comandos snmp deles possui sintaxes com vários opções. O comando snmpconf auxilia na configuração destes arquivos. Este comando, inclusive, pode comentar um arquivo de configuração existente, visando torna-lo mais legível. O comando snmptest inicia um diálogo interativo com um agente SNMP. Através deste se pode enviar vários comandos SNMP e obter respostas.
- #36 1. Configure o agente SNMP do pacote net-snmp (snmpd). Use configurações para SNMPv2 (baseado em comunidades somente). Use as configurações abaixo: - comunidade de leitura em todos os objetos: ucb - comunidade de escrita em todos os objetos: computacao - sysContact para o sistema: <nome_do_aluno> Note que a configuração do agente pode ser feita através da edição direta do arquivo de configuração ou usando o comando “snmpconf”. Inicie o agente. 2. Use snmpget para testar o agente usando SNMPv2c. Obtenha: sysContact sysName Se necessário, use o comando man <nome do comando SNMP> para saber mais detalhes da sintaxe do comando.
- #37 3. Use os comandos snmpgetbulk e snmptable para obter a tabela de interfaces do sistema do agente. 4. Configure o recebedor de traps (snmptrapd) para receber as traps e coloca-las num arquivo de texto. 5. Envie traps com o comando snmptrap. Verifique seu registro na estação onde foi configurado o recebedor. 6. Existem alguns agentes de teste na Internet. Use-os para obter informações: MG-Soft (somente SNMPv3): obter em http://www.mg-soft.com/snmpv3.html#SNMPv3ACCESS NET-SNMP: test.net-snmp.org