View
215
Download
0
Category
Preview:
Citation preview
Inteligência em Gestão de Redes e Serviços
• Gestão de Redes e Serviços– Motivação
• Heterogeneidade e complexidade das redes e serviços• Requisitos de diferentes participantes
– Eixos e pirâmide da gestão• Diferentes níveis de responsabilidade• Diferentes eixos e áreas de gestão (FCAPS)
– Arquitecturas de sistemas de gestão• Arquitectura de Gestão OSI• Arquitectura de Gestão do IETF (SNMP, SMI e MIB)• Telecommunications Manegement Network (TMN)• Telecommunications Information Networking Architecture (TINA)
Caracterização das redes e serviços• Tecnologias:
– ATM– RDIS– LANs– Wireless LANs– IP– GSM– UMTS
• Equipamentos– PCs– Telefones fixos– Telefones móveis– Routers– Bridges– Comutadores– Servidores
• Serviços– Voz– Dados– Imagem– Áudio– Vídeo
• Aplicações– Telefonia– Email– FTP– Acesso Web– Vídeo-conferência
Conclusão (recordar):• Diversidade• Complexidade• Interligação
VozDados
Multimédia
Tipo de Informação
VPNs
WANsRedes Empresariais
MANsLANs
Tipo de rede
Requisitos de evolução• Maior Largura de Banda
– Maior volume de tráfego e mais diversificado
– Número de utilizadores em expansão
• Capacidade de interligação– Coexistência de diferentes tecnologias de rede– Protocolos de transporte normalizados
• Diversificação da oferta de serviços– Integração de voz, dados e serviços associados– Serviços acessíveis globalmente: interfaces de acesso, espaços de nomes, de
endereços e directórios uniformes
• Introdução de mecanismos de segurança– Acesso à Internet, a redes públicas, ou outras redes de outras Organizações
• Introdução de mecanismos de mobilidade– Livre movimentação dos utilizadores possível pela introdução do wireless
• Introdução de mecanismos de qualidade de serviço– Partilha de voz, dados e vídeo só é possível se a rede suportar QoS
Que gestão ?
• No futuro como gerir ?(opções)– Não gerir– Gerir isoladamente– Gerir de uma forma integrada
• O que é a Gestão ?– É uma forma de assegurar a
correcta e eficiente operaçãodum sistema, com os seusrecursos, de acordo comobjectivos globais.
– Recordar: “Os objectivos são nageneralidade económicos!”
• Na Gestão Integrada os recursosa gerir englobam a Rede, osServiços e as Aplicações.
• Necessidade de decompor osproblemas, existência de váriasperspectivas sobre o mesmoaspecto.
Estruturação da gestão em níveis:• Modelo de responsabilidade ou Pirâmide da gestão
– Os diferentes aspectos/áreas da gestão podem ser vistos de perspectivasdiferentes de acordo com diferentes níveis de responsabilidade
– Origem na British Telecom, deu origem posteriormente aoTelecommunications Management Network - TMN
Negócio
Serviço
Rede
Elementos de rede
Componentes individuais
Interligação de componentes
Oferta de serviço com qualidade
Investimento, Mercado, Contratos
O que se pode fazer
O que sedeve fazer
Grau de abstracção: funções de um nível assumem arealização das tarefas do nível inferior
ITU-T, 1996, "M.3010 Principles for a telecommunications management network"
Modelo do ciclo de vida da gestão: fases
Operação
Alteração Instalação
Planeamento• O processo de gestão de redese serviços é um processo:– Composto por fases/estados
• Planeamento• Instalação• Operação• Alteração
– Iterativo• Possuí um ciclo de vida
Áreas funcionais da gestão em telecomunicações
• Objectivos: classificação das diferentes tarefas de gestão• Origem: arquitectura de gestão do OSI• Nota: está longe de ser indiscutível
Configuração
Faltas
Desempenho
Segurança
Contabilidade e administração
de utilizadores
Áreas Funcionais
Faults, Configuration, Accounting, Performance, Security (FCAPS)
ITU-T, 1997, "M.3400 TMN management functions"
Gestão de Configuração:• Centrada nos recursos (físicos, ex. equipamento de rede,
processadores; e lógicos, ex., módulo SW, base de dados) e suascaracterísticas
• Objectivos:– Descrição de um sistema distribuído baseada na localização dos seus
recursos.– Processo de configuração de um sistema distribuído.– Resultado de um processo de configuração.
• Funções associadas:– Activação de parâmetros.– Definição de valores de limiar.– Activação de filtros.– Alocação de nomes a objectos geridos.– Carregamento de dados de configuração.– Fornecimento de documentação sobre alterações de configuração.– Realização de alterações de configuração.
Gestão de Faltas* (fault):
• Objectivos:– Detecção, isolamento e resolução de situações de funcionamento anormal
num sistema distribuído.
• Funções associadas:– Monitorização da rede e do estado do sistema.– Vigilância de alarmes.– Diagnóstico de faltas.– Resolução de falhas.– Realização de testes de diagnóstico.– Operação de sistemas de Gestão de Problemas (Trouble Ticket).– Assistência ao cliente (User Help Desk).
* Falta: desvio que as operações dos sistemas apresentam face aos objectivosfuncionais, operacionais, ou de serviço. Diferente de falha.
Gestão de Desempenho:
• Objectivos:– Assegurar que uma rede ou um sistema distribuído opera de forma a
satisfazer objectivos de desempenho (Qualidade de Serviço).• Definido na interface entre o cliente e o prestador de serviço• Intimamente ligado com o estabelecimento e cumprimento de Acordos
de Nível de Serviço (Service Level Agreement – SLA)
• Funções associadas:– Estabelecimento de métricas e de parâmetros de QoS.– Monitorização de recursos.– Realização de medidas e avaliação de tendências, que permitam antever
falhas.– Manutenção e análise de logs com o histórico do estado do sistema.– Processamento de dados e compilação de relatórios de desempenho.– Planeamento do desempenho e da capacidade do sistema.
Gestão de Contabilidade e Administração deutilizadores:• Objectivos:
– Administração de nomes e de endereços– Gestão de contas de utilizador.
• Funções associadas:– Serviço de directório.– Autorização de acesso/utilização de recursos.– Identificação dos custos de utilizador.– Tarifação.– Facturação das contas do utilizador.
Gestão de Segurança:
• Objectivos:– Gestão da segurança dos sistema distribuídos. Detectar, prevenir e
resolver problemas relacionados com a violação de segurança*.
• Funções associadas:– Monitorização e detecção de violações de segurança.– Definição de políticas de segurança.
(ex., alteração periódica das palavras de passe)– Verificação de identidade (autenticação).– Controlo de acessos.– Garantia de confidencialidade (criptografia).– Integridade dos dados.– Relatórios de estado de segurança e de violações de segurança.
* Violação de segurança: acções que deliberadamente prejudicam ofuncionamento do sistema
Conclusão: eixos da gestão
Configuração
Desempenho
Falhas
Segurança
Taxação
Áreas Funcionais
PlaneamentoInstalação
OperaçãoAlteração
Estádios
Voz
Dados
Multimédia
Tipo de Informação
Elementos de RedeRede
NegócioServiço
Nível
VPNs
WANsRedes Empresariais
MANsLANs
Tipo de rede
Arquitectura de um sistema de gestão• Quais os componentes do processo ?
– Quem gere ? O gestor (um humano)– O que se gere ? A rede– Como se gere ? Através de um sistema de gestão
• Quais os intervenientes do processo ?– O Gestor: conjunto de programas de aplicação que centralizam a
informação de gestão (Entidades Gestoras) e fazem a interface com oOperador de Rede (Aplicação de Gestão)
– O Agente: programa responsável pela recolha e processamento local dainformação de gestão de cada recurso a gerir.
– A MIB: repositório de informação de gestão, que contém um conjunto deObjectos Geridos (OG), que representam um Recurso Gerido (ou conjuntode recursos) na perspectiva de gestão (ex., equipamento, programas).
– O Transporte de Informação: protocolo de comunicação e serviçosnecessários à transferência de informação de gestão, entre o Gestor e osAgentes associados.
Componentes dum sistema de gestão
Rede
Agente
Gestor
Protocolode Gestão MIB
SistemaDe
Gestão
Comandos Respostas ou Alarmes
Modelo Gestor-Agente
RespostasouEventos
Protocolo de Gestão
Comandos
Interface Gestor-Agente
Mapeamento localInterface de
acesso à MIB
RecursosGeridos
MIB
EntidadeGerida /Agente
Objecto Gerido (OG)
Interface Utilizador(Interface Homem-Máquina)
EntidadeGestoraGestor
Aplicaçãode Gestão /Operador
MIB
EntidadeGerida(Agente)
EntidadeGestora(Gestor)
Operador de Redeou Aplicação
de Gestão
Arquitectura de um sistema de gestãoAs funcionalidades do sistema:
• Monitorização:
– Observar e analisar o estado dosistema em rede.
– Gestão de Falhas, Desempenho eContabilidade.
• Controlo:
– Modificar parâmetros e executaracções.
– Gestão de Configuração eSegurança.
Tipo de Informação transferida:• Estática:
– Caracteriza a configuração actual dosistema gerido.
• Dinâmica:– Caracteriza o estado dos elementos de
rede e contém informação sobre aconte-cimentos que tenham sido detectados.
• Estatística:– Caracteriza o sistema ao longo do tempo,
efectuando medidas agregadas a partir dainformação dinâmica.
Modo de transferência de informação:– Polling: Sequência periódica de
Comandos (Gestor) e Respostas (Agente).– Reporte de Eventos: Agente toma a
iniciativa de enviar uma mensagem aoGestor
“Arquitectura(s)” de gestão IETF• As “arquitecturas” definidas pelo IETF para a gestão de redes assentes
no protocolo IP, possuem a seguinte característica geral: simplicidade• Motivações para a gestão na Internet
– O crescimento da Internet em número e diversidade
• Alguma da evolução histórica– 1960-70: ICMP- Internet Control Message Protocol
• Protocolo mais de monitorização que propriamente gestão– 1987: SGMP (Simple Gateway Monitoring Protocol)
• Monitorização de Gateways– HMP (Host Monitoring Protocol)
• Monitorização de estações terminais (hosts)– HEMS (High-level Entity Management System)
• Generalização do HMP
– SNMPv2 Simple Network Management Protocol Version 2– SNMPv3 Simple Network Management Protocol Version 3
– 1990: CMOT- CMIP Over TCP/IP• Adaptação do CMIP para a pilhaprotocolar TCP/IP
– 1990: SNMP- Simple NetworkManagement Protocol• Versão melhorada do SGMP
Modelo de Organização IETF para gestão
Gestor
Ex: Router
Agente
MIB
SNMP
SNMP
Ex: Servidor
Agente
MIB
Ex: PC
Agente
MIB
Gestor
SNMP
SNMP
Características:– Arquitectura Cliente-Servidor.– Gestor contém as aplicações de gestão e
faz a interface com o utilizador.– Agente é responsável por um conjunto
de recursos geridos.– O Gestor pode monitorizar ou controlar
os recursos através de Agentes,mantendo uma base de dados com ainformação relevante sobre a rede
– O Agente estrutura a informação degestão numa MIB.(MIB - Modelo de Informação)
• RFC 1157 Simple Network ManagementProtocol – SNMP• define o protocolo usado para gerir os
objectos. (SNMP - Modelo de Comunicação)
Modelo de Informação IETF para gestãoCaracterísticas:
– Os objectos da MIB são definidos de acordo com a SIB (sintaxe e semântica)– Cada objecto da MIB é um objecto escalar (tabelas definidas à custa de escalares),
pelo que não há os conceitos de classes, herança, encapsulamento, …– As MIBs Internet definem a estrutura, o significado e a identificação dos recursos que
podem fazer parte da MIB dum Agente para a Internet.– A MIB dum Agente contém apenas os tipos dos objectos geridos que podem ser
instanciados nos equipamentos que gere.– A Identificação de objectos é efectuada através da Árvore de Registo Internet (ARI)
• RFC 1155 Structure and Identification of Management Information for TCP/IP-based networks• SMI: descreve como os objectos contidos na MIB são definidos
• RFC 1213 Management Information Base for Network Management of TCP-IPbased Internets– MIB-II: descreve os objectos de gestão contidos na MIB– possibilidade adição de sub-árvores:
• RFC 1212 Concise MIB Definition– definição do formato para a produção de módulos MIB
• Exemplos:– RFC 1643 Definition of managed Objects for Ethernet-like Interface Types– RFC 1757 - Remote Network Monitoring Management Information Base
Modelo de Informação IETF para gestãoDefinição e utilização de MIBs proprietárias:• Possibilitam gerir aspectos específicos dos produtos
• Possibilidade de registar os objectos proprietários na ARI de formanão ambígua
• Problema: Um gestor não é capaz de gerir o que não conhece– Sintaxe (pode ser resolvido)
• Procedimento:1. O Agente desenvolve uma descrição textual e uma descrição formal da MIB
proprietária2. O Gestor carrega e compila a descrição forma a incluí-la na sua biblioteca• Diferentes Modelos de Informação nas diferentes versões do SNMP
dificultam esta operação.
– Semântica (de difícil resolução)• Algumas estratégias relacionadas com web ervices ontologias
Modelo de Informação:Árvore de Registo na Internet
root
itu-t (0) iso (1) join iso/itu-t (2)
org (3)
dod (6)
internet (1)
mib -2 (1) ATM (41) X.25 (44)
recursos nós (36)
IBM (2) HP (11)
dir- (1) mgmt (2) exper. (3) priv.(4)
empresas (1)
1.3.6.1.2.1iso.org.dod.internet,mgmt.mib-2
(tipo OBJECT-IDENTIFIER do ASN.1)
Árvore apenas de Registo• Não existe o conceito de
herança
MIBs privadas/proprietárias
Modelo de informação: exemplo de ramo da ARI
mib- 21.3.6.1.2.1
ip 1.3.6.1.2.1.4
iplnReceives1.3.6.1.2.1.4.3
ipRouteTable1.3.6.1.2.1.4.21
ipRouteEntry1.3.6.1.2.1.4.21.1
ipRouteNextHop1.3.6.1.2.1.4.21.1.7
ipRouteDest1.3.6.1.2.1.4.21.1.1
ObjectoEscalar
Tabela
Modelo de informação: exemplo de objecto MIB
SNMP
GestorAcessos internos
iplnReceives 25
Counter Value
Agente
ipRouteDest … ipRouteNextHop …
9.1.2.3 … 99.0.0.3 …
10.0.0.51 … 89.1.1.42 …
10.0.0.77 … 89.1.1.42 ...
MIB do Agente
mib- 2
ip
iplnReceives ipRouteTable
ipRouteEntry
ipRouteNextHopipRouteDest
MIB
Grupo
Tabela
Linha
Variável
Instância = tipo de objecto + valor
ipInReceives OBJECT TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION ´The total number of input datagrams received from
interfaces… .´::= {ip 3}
Modelo de informação:definição de objectos escalares (SMIv1)
MACRO OBJECT-TYPE: • Nome e Identificador• Sintaxe • Tipo de acesso• Estado• Descrição informal
•Localização do ramo na ARI
Modelo de informação: Sintaxe dos ObjectosSintaxe dos objectos no SMI (RFC 1155): tipos de dados pré-definidos
• Dependentes da aplicação:Network Address
IpAddress
Time tick
Gauge
Counter
Opaque
• Independentes da aplicação:– Tipos primitivos
INTEGER
OCTECT STRING
OBJECT IDENTIFIER
NULL
– ConstrutoresSEQUENCE
SEQUENCE OF
• Time tick tempo em centésimos de segundo
• Gauge contador up-down de 32 bits, números positivos, que bloqueia quando atinge o valor máximo, até que seja feito o reset.
• Counter contador circular de 32 bits, números positivos
• Opaque transferência de qualquer tipo de dados
Modelo de informação:definição de tabelas (SMIv1)
• Modelo de Informação SMI suporta apenas tabelas bidimensionais.• As entradas da tabela são objectos escalares.• A definição de tabelas envolve :
– a utilização dos construtores SEQUENCE e SEQUENCE-OF– a utilização dum novo campo na macro OBJECT-TYPE: o campo INDEX-PART
Modelo de informação:exemplo de definição de tabelas (ipRoute)
ipRouteTable OBJECT-TYPESYNTAX SEQUENCE OF IpRouteEntryACCESS not-accessibleSTATUS mandatoryDESCRIPTION<<Tabela de encaminhamento IP>>
::= { ip 21}
IpRouteEntry OBJECT-TYPESYNTAX IpRouteEntryACCESS not-accessibleSTATUS mandatoryDESCRIPTION<<Rota para um dado destino>>INDEX {ipRouteDest }
::= { ipRouteTable 1}
IpRouteEntry ::= SEQUENCE {ipRouteDest IpAddress, ...ipRouteNextHop IpAddres, ..
}
ipRouteDest OBJECT-TYPESYNTAX IpAddressACCESS read-writeSTATUS mandatoryDESCRIPTION<<Endereço de destino da rota>>
::= {ipRouteEntry 1}
ipRouteNextHop OBJECT-TYPESYNTAX IpAddressACCESS read-writeSTATUS mandatoryDESCRIPTION<<Endereço seguinte da rota>>
::= {ipRouteEntry 7}
Modelo de informação:codificação da informação
Componentede AplicaçãoMIB
Componentede Aplicação MIB
Componente de
transferência de dados
Componente de
transferência de dados
MapeamentoLocal
MapeamentoLocal
Sintaxe
Abstracta(ASN.1)
Sintaxe de
Transferência(SNMP)
Regras de Codificação Regras de Codificação
Modelo de informação: conclusões• Simplicidade de conceitos
– Modelo de Informação orientado a tipos de dados.• - Objectos Geridos são folhas da ARI.• - Acesso a OGs através do Identificador do Objecto na ARI.
• Desenvolvimento rápido de produtos• Modelo não orientado-a-objectos:
– - não há reutilização– - não há herança.
• Estrutura da ARI:– - não há inclusão– - elevado nº de MIBs– - informação relacionada em várias sub-árvores
Modelo de comunicação: SNMP• RFC 1157 Simple Network Management Protocol – SNMP (Versão 1)• RFC 3416 Simple Network Management Protocol – SNMP (Versão 2)
Get
Nex
tReq
ues
t
Set
Req
ues
t
Get
Nex
tReq
ues
t
Set
Req
ues
t
Get
Req
ues
t
Get
Req
ues
t
Res
po
nse
Res
po
nse
Tra
p
Tra
p
GESTOR
Aplicação de Gestão
Gestor SNMP
UDP
IP
Protocolos dependentes da rede
AGENTE
Agente SNMP (deamon)
UDP
IP
Protocolos dependentes da rede
Objectos SNMP
Recursos geridos
REDE
Aplicação gere os objectos
Mensagens(PDU) SNMP
Get
Bu
lkR
equ
est
Get
Bu
lkR
equ
est
Modelo de comunicação: SNMPv1• Formato das mensagens
VersionNumber
CommunityString
PDU-SNMP ou Trap-PDU
Variable bindingsErrorIndex
PDUs: GetRequest, GetNextRequest, Response
PDU: Trap
name1:value1 name2:value2 nameN:valueN
Variable binding
PDUType
RequestID
ErrorStatus
Variable bindingsTimeStamp
AgentAddress
GenericTrap
SpecificTrap
Trap Entreprise
...
Modelo de comunicação: SNMPv2• Formato das mensagens
VersionNumber
CommunityString
PDU-SNMP ou Trap-PDU
Variable bindingsErrorIndex
PDUs: GetRequest, GetNextRequest, GetBulkRequest, Response
PDU: Trap
name1:value1 name2:value2 nameN:valueN
Variable binding
PDUType
RequestID
ErrorStatus
Variable bindingsTimeStamp
AgentAddress
GenericTrap
SpecificTrap
Trap Entreprise
...
Modelo de comunicação:manipulação de objectos escalares
GetRequest (ipInReceives.0) Response (ipInReceives.0 = 25)
iplnReceives 25
Counter Value
Leitura
SetRequest (ifAdminStatus.0 = ´Testing´) Response (ifAdminStatus.0 = ´Testing´)
ifAdminStatus Testing
OctectString Value
EscritaQuando se obtêm sucesso o valor de Response é omesmo que o colocado em SetRequest
Modelo de comunicação:monitorização (leitura) de tabelas
Leitur
a
tabela
GetRequest (ipRouteDest.9.1.2.3, ipRouteNextHop.9.1.2.3)Response ((ipRouteDest.9.1.2.3 = 9.1.2.3), (ipRouteNextHop.9.1.2.3 = 99.0.0.3))
ipRouteDest … ipRouteNextHop …
9.1.2.3 … 99.0.0.3 …
10.0.0.51 … 89.1.1.42 …
10.0.0.77 … 89.1.1.42 ...
INDEX
Modelo de comunicação:monitorização (leitura) de tabelas (2)
Leitur
a
tabela
GetNextRequest (ipRouteDest, ipRouteNextHop)
Response ((ipRouteDest.9.1.2.3 = 9.1.2.3), (ipRouteNextHop.9.1.2.3 = 99.0.0.3))GetNextRequest (ipRouteDest.9.1.2.3, ipRouteNextHop.9.1.2.3)Response ((ipRouteDest.10.0.0.51 = 10.0.0.51), (ipRouteNextHop.10.0.0.51 =89.1.1.42))…
GetNextRequest (ipRouteDest.10.0.0.77, ipRouteNextHop.10.0.0.77)Response ((ipRouteNextHop.9.1.2.3 = 99.0.0.3), (ipNetToMediaIfIndex.1.3 =1))
ipRouteDest … ipRouteNextHop …
9.1.2.3 … 99.0.0.3 …
10.0.0.51 … 89.1.1.42 …
10.0.0.77 … 89.1.1.42 ...
Modelo de comunicação:leitura de blocos de dados (SNMPv2)
GetBulkRequest (non-repeaters=1, max-repeats=2,
ipInReceives,
ipRouteDest, ipRouteNextHop)
Response((ipInReceives.0 = 25), (ipRouteDest.9.1.2.3 = 9.1.2.3),(ipRouteNextHop.9.1.2.3 = 99.0.0.3))(ipRouteDest.10.0.0.51 = 10.0.0.51),(ipRouteNextHop.10.0.0.51 = 89.1.1.42))
ipRouteDest … ipRouteNextHop …
9.1.2.3 … 99.0.0.3 …
10.0.0.51 … 89.1.1.42 …
10.0.0.77 … 89.1.1.42 ...
iplnReceives 25
getBulkRequest permite a transferência de grandes volumes de informação,o gestor pode indicar quantos objectos do mesmo tipo (linhas) pretende receber.
Modelo de comunicação: controlo - inserção de linhas em tabelas
ipRouteDest … ipRouteNextHop …
9.1.2.3 … 99.0.0.3 …
10.0.0.51 … 89.1.1.42 …
10.0.0.77 … 89.1.1.42 ...
SetRequest ((ipRouteDest.10.0.0.77 = 10.0.0.77), (ipRouteNextHop.10.0.0.77 = 89.1.1.42))Response((ipRouteDest.10.0.0.77 = 10.0.0.77), (ipRouteNextHop.10.0.0.77 = 89.1.1.42))
Inserçãode linha
SNMPv1: Mecanismos de segurança
Definida no Agente• Identificação através de nome• Engloba:
• Autenticação• Controlo de acesso• Característica do proxy
Gestor
Gestor
Agente Comunidade
Agente
Agente
Autenticação: garantir a proveniência correcta⇒ nome da comunidadeControlo de acesso: diferenciar o acesso à MIB⇒ Perfil da comunidade - visão da MIB (objectos visíveis) - modo de acesso a cada elementoCaracterísticas do proxy de cada dispositivo⇒ visão da MIB e modo de acesso
Modelo de comunicação: conclusões– Operações simples
– Desenvolvimento produtos:rápido, realizável em recursos simples
– Divulgação generalizada
– Autenticação trivial
– Ineficiência na transmissão de grandes volumes de informação
– Informação tem de ser sempre requisitada pelo Gestor
– Eventos assíncronos pré-definidos e em nº limitado
– Suporte em UDP
Avaliação e necessidade de evolução do SNMPCaracterísticas (resumo):• Modelo Organização:
– Arquitectura Gestor-Agente– Transferencia de Informação por “polling”
• Modelo Informação:– Informação de Gestão organizada em MIBs– A MIB contém variáveis simples (mesmo as tabelas) e não objectos
• Modelo Comunicação:– Protocolo de gestão SNMP a correr sobre UDP
+ :SimplicidadeAceitação pelos fabricantesPossibilidade de MIBs proprietárias
- (i.e., problemas):Dimensão da redeVolume da informaçãoSegurança
Melhorar o SNMP Evoluir para o CMOTou
Possibilidades de evolução do SNMP• Características “evoluir para CMOT” (ao tempo da decisão):
– Normas OSI ainda em desenvolvimento– Falta de produtos de gestão OSI no mercado– Modelo de informação SNMP é incompatível com a Gestão OSI
• Características “melhorar SNMP”:– SNMP Seguro: resolve os problemas de segurança– SMP: Facilitar a transferência de informação entre recursos
arbitrários• Transferência de Informação em bloco• Compatibilidade (backward) com SMNP• Mecanismos de segurança de SNMP seguro
Melhoria do SNMP (Versões 2 e 3)
• Características SNMPv2– 1993: SNMPv2
• A elevada aceitação do SNMPv1 condicionou o SNMPv2• Os mecanismos de segurança propostos eram demasiado complexos
– 1994/95: o SNMPv2 é revisto:• As tentativas de simplificação dos mecanismos de segurança são abandonados por
falta de consenso.• Surgem duas versões:
– SNMPv2p: com segurança– SNMPv2c: sem segurança
• Características SNMPv3– Compatibilização com as versões anteriores– Novos mecanismos de segurança
SNMP versão 2: Modificações• Modificações ao Modelo de Informação:
– Novos Grupos na Árvore de Registo Internet– Inserção de novos objectos em grupos da MIB-II– Conceitos fundamentais:
• Definição de objectos,• Tabelas conceptuais,• Definição de notificações,• Módulos de Informação
• Modelo de Comunicação:– Já presentes no SNMPv1, mas melhorada a eficiência
• Comunicação Gestor Agente de tipo pedido-resposta– Respostas em massa, operações GetRequest não-atómicas
• Comunicação Agente Gestor (não confirmada)
– Novo no SNMPv2• Comunicação Gestor Gestor do tipo pedido-resposta
– Modificações ao nível da segurança, embora não tenham sido totalmentenormalizados devido à falta de consenso
SNMP versão 2: Novos grupos na ARI
root
itu-t (0) iso (1) join iso/itu-t (2)
org (3)
dod (6)
internet (1)
mib -2 (1) ATM (41) X.25 (44)
recursos nós (36)
IBM (2) HP (11)
dir- (1) mgmt (2) exper. (3) priv.(4)
empresas (1)
1.3.6.1.2..1
security.(5) mail (7)
domínios(1) proxys (2) módulos (3)
snmpv2 (6)
snmpMIB(1)
snmp M2M (2)
Party MIB (3)
SNMP versão 2: Definição de novos objectos• Novos tipos ASN.1
• Unsigned32, Counter64, endereços OSI (NSAP), tipos enumerados• Estes novos tipos aparecem no campo SYNTAX
• Novos campos na definição de objectos• Unit Parts: unidades (ex: segundos)• MAX_ACCESS: not-accessible, accessible-for-notify,
read-only, read-write e read-create• STATUS: current, deprecated, obsolete• ReferPart: referências textuais a outros módulos• IndexPart: manipulação flexível de tabelas• DefValPart: valor por omissão
SNMP versão 2: Manipulação de tabelas• Inserção de colunas
– Index definição da tabela conceptual de base– Augment definição da extensão à tabela
• A extensão pode existir noutro grupo da MIB• Funcionalmente a extensão não se distingue da tabela de base.
• Inserção/Remoção de linhas– Utilização conjunta com os valores por defeito (DEFVAL)– RowStatus
• Uma linha pode estar num estado “ainda não disponível” (not ready)
– Read-create• Possibilidade de criar de forma “automática” este elemento
– CreateAndWait e CreateAndGo• Dois métodos diferentes para lidar com os objectos para os quais não há
valores por defeito na sua definição
SNMP versão 2: Exemplo inserção de colunas
ipForwardDest ... ipForwardNextHop
ipDelayMetric ipQueueLenMetric
private
Empresa X
internet
ip
Mib-2
Mgmt
IpForwardTable OBJECT-TYPE SYNTAX SEQUENCE OF IpForwardEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION << Tabela de encaminhamento IP >>
::= { ip 21} IpForwardEntry OBJECT-TYPE
SYNTAX IpForwardEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION << Rota para um dado destino >> INDEX {ipForwardDest, ipForwardNextHop }
::= { ipForwardTable 1} IpForwardEntry ::=
SEQUENCE { ipForwardDest IpAddress, ... ipForwardNextHop IpAddres, ..
} ipForwardDest OBJECT-TYPE
SYNTAX IpAddress MAX-ACCESS read-write STATUS current DESCRIPTION << Endereço de destino da rota >>
::= {ipForwardEntry 1} … ipForwardNextHop OBJECT-TYPE
SYNTAX IpAddress MAX-ACCESS read-write STATUS current DESCRIPTION << Endereço seguinte da rota >>
::={ipForwardEntry7}
moreIpForwardTable OBJECT-TYPESYNTAX SEQUENCE OF moreEntryMAX-ACCESS not-accessibleSTATUS currentDESCRIPTION << Extensão a ipForwardTable >>
::= {B}
moreEntry OBJECT-TYPESYNTAX moreEntryMAX-ACCESS not-accessibleSTATUS currentDESCRIPTION << Adição de novas colunas a
ipForwardTable >>AUGMENTS {ipForwardEntry}
::= {moreIpForwardTable 1}
moreEntry :==SEQUENCE {ipDelayMetric, ipQueueLenMetric}
ipDelayMetric OBJECT-TYPESYNTAX INTEGERMAX-ACCESS read-writeSTATUS currentDESCRIPTION << Metrica de atraso >>
::= {moreEntry 1}
ipQueueLenMetric OBJECT-TYPESYNTAX INTEGERMAX-ACCESS read-writeSTATUS currentDESCRIPTION << Metrica de tamanho da fila de saída >>
::= {moreEntry 2}
SNMP versão 2: Definição de notificações
• Em SNMPv2 passou a existir uma MACRO para definir a informaçãoenviada por uma entidade quando uma situação de excepção existe -notificação
• Exemplo:
linkUp NOTIFICATION-TYPE OBJECTS (ifIndex,ifAdminStatus, ifOperStatus) STATUS current DESCRIPTION ´A link~Up trap signifies that the SNMPv2 entity, acting in the agent role, has detected that the ifOperStatus object for one of its communication links has transitioned
out of the down state´::= { snmpTraps 4}
SNMP versão 2: Módulos de informação
• O SNMPv2 introduz o conceito de módulo de informação que servepara especificar um grupo de definições relacionadas
• Existem três tipos de módulos:– Módulos das MIBs, que contêm MACROS de definição de objectos e de
notificações– Especificação de compatibilidade para módulos da MIB, que utilizam as
MACROS MODULE-COMPLIANCE, OBJECT-GROUP e NOTIFICATION-GROUP.– Especificação de capacidades de implementação de um Agente que
utilizam a AGENT-CAPABILITIES MACRO
SNMP versão 2: Modelo de comunicaçãoFormato das mensagens
VersionNumber
CommunityString
PDU SNMPv2
Variable bindingsErrorIndexMax-rep
PDUs: GetRequest, GetNextRequest, SetRequest, Response,SNMPv2Trap, GetBulkRequest, InformRequest
name1:value1 name2:value2 nameN:valueN
Variable binding
PDUType
RequestID
ErrorStatus
Non-repeaters
...
Modelo de comunicação: (SNMPv2)
GetBulkRequest (non-repeaters=1, max-repeats=2,
ipInReceives,
ipRouteDest, ipRouteNextHop)
Response((ipInReceives.0 = 25), (ipRouteDest.9.1.2.3 = 9.1.2.3),(ipRouteNextHop.9.1.2.3 = 99.0.0.3))(ipRouteDest.10.0.0.51 = 10.0.0.51),(ipRouteNextHop.10.0.0.51 = 89.1.1.42))
ipRouteDest … ipRouteNextHop …
9.1.2.3 … 99.0.0.3 …
10.0.0.51 … 89.1.1.42 …
10.0.0.77 … 89.1.1.42 ...
iplnReceives 25
getBulkRequest permite a transferência de grandes volumes de informação,o gestor pode indicar quantos objectos do mesmo tipo (linhas) pretende receber.
Mensagens do tipo: InformRequestUsadas para a comunicação entre Gestores (ex., troca de informação de uma Trap).
SNMP versão 2: Segurança• Autenticidade da origem e do conteúdo, assinar a mensagem usando o MD5, a
mensagem é enviada entre o destino e a origem a chave é conhecida porambos.
• Confidencialidade: cifrar a mensagem usando DES (Data Encription Standard)e o CBC (Cipher Block Chaining)
• Não duplicação (validade) da Informação: adição de uma Marca temporal -TimeStamp - que permite detectar sequências for de ordem delimitar ointervalo de vida da mensagem.
SNMP versão 3: Princípios gerais
• Usar como base o trabalho existente (SNMPv2)• Colmatar a deficiência de segurança das versões anteriores, que
impossibilitava a utilização de configuração por mensagens SetRequest– bloqueada pela maioria dos gestores
• Conceber uma arquitectura modular, adaptável quer a sistemas simples quera complexos capazes de gerir redes de grandes dimensões.
• Permitir que essa arquitectura fosse utilizada sem interferência do processode normalização. Permitir que fosse progressivamente normalizada, podendoas partes normalizadas serem usadas.
• Permitir a utilização de modelos alternativos de segurança.• Continuar a manter o SNMP o mais simples possível.
SNMP versão 3: Opções gerais
• Arquitectura, definida com base em limites conceptuais, que se traduzemdirectamente nos documentos de especificação.– Sub-sistemas que descrevem os serviços por partes especificas da arquitectura– Interfaces entre os serviços definidas através de primitivas de serviços
• Documentos auto-suficientes, cada parte deve ser contida num documentoúnico, que inclui as funções as variáveis, etc..
• Configuração remota, chaves secretas configuradas remotamente.
• Complexidade controlada,– equipamentos simples => recursos SNMP reduzidos– configurações complexas => recursos SNMP mais alargados
• Ataques à segurança, o sub-sistema de segurança deve ser capaz deproteger o sistema de gestão contra os principais ataques.
SNMP versão 3: Ataques à segurançacontemplados• Modificação de informação:
– Alteração de uma mensagens em trânsito• EX: Alteração de informação de configuração ou de contabilização de recursos
• Ataque à privacidade (Disclosure)– Observação de trocas de informação Gestor - Agente
• Ex: Observação de um comando de alteração de password
• Alteração da sequência de mensagens– Duplicação, atraso ou reordenação de mensagens
• EX: Duplicação uma mensagem de reboot
• Ataque à autenticação (Masquerade)– Realização de operações não permitidas a uma entidade através da
adopção de uma entidade falsa, que tenha privilégios para as executar.
SNMP versão 3: Ataques à segurançanão-contemplados• Negação de serviço
– Evitar a comunicação Gestor - Agente• Situação análoga à que se verifica quando há falha de comunicação• Quando ocorre afecta todas as comunicações pelo que deverá ser
resolvido no âmbito geral das comunicações, e não específico dagestão.
• Análise de tráfego– Observação do padrão de tráfego gerado Gestor - Agente
• Padrão de tráfego previsível, pelo que não há vantagem em proteger asua observação
SNMP versão 3: Pricípios fundamentais• Conceito de entidade
– A arquitectura de Gestão SNMP é constituída por um conjunto deentidades SNMP distribuídas, que cooperam entre si.
• Cada entidade implementa uma parte da arquitectura SNMP, podendofuncionar como Agente, Gestor ou ambos em simultâneo.
• Conceito de módulo– Cada entidade é constituída por um conjunto de módulos que
interagem entre si para providenciar serviços.– As interacções são modeladas através dum conjunto de primitivas
abstractas e parâmetros.
SNMP versão 3: EntidadeEntidade SNMP
Gerador deComandos
Gerador deRespostas
Gerador deNotificações
Receptor deNotifcações
ProxyForwarder
Outros
Aplicações
DespachoSubsistema deProcessamentode Mensagens
Subsistema deSegurança
Subsistema deControlo de
Acessos
Máquina SNMP
SNMP versão 3: Aplicações• Gerador de Comandos
– Envia mensagens Get, GetNext, GetBulk e SetRequest– Processa mensagens Response recebidas como resposta a pedidos enviados
• Gerador de Respostas– Recebe e Processa as mensagens Get, GetNext, GetBulk e SetRequest– Utiliza o Controlo de Acessos e executa a acção adequada– Envia mensagem Response
• Gerador de Notificações– Monitoriza um sistema e gera Traps ou InformRequest com base em
eventos ou condições– Selecciona o destino das Notificações, versão do SNMP e parâmetros de
segurança.
• Receptor de Notificações– Espera e recebe Traps ou InformRequest– Gera uma resposta quando recebe InformRequest
• Proxy Forwarder– Envia mensagens SNMP– Opcional
SNMP versão 3: Máquina
• Despacho– Coordena a transferência de PDUs entre a rede e as aplicações
• Sub-sistema de Processamento de Mensagens– Conversão PDUs <-> mensagens SNMP
• Sub-sistema de Segurança– Serviços de segurança– Ex: autenticação e confidencialidade
• Sub-Sistema de Controlo de Acesso– Serviços de autorização que uma aplicação necessita para a
verificação de privilégios
SNMP versão 3: Estrutura geral de um gestor
Gerador deComandos
Gerador deNotificações
Receptor deNotifcações
Despachode PDU
Despachode Msg.
Mapeamentode Transporte
Des
pac
ho
Outro
Segurança
Baseado em
Utilizador
v1MP
v2cMP
v3MP
Outro
Processamentode Mensagens
UDP IPX Outros
Rede
SNMP versão 3: Estrutura geral de um agente
Despachode PDU
Despachode Msg.
Mapeamentode Transporte
Des
pac
ho
Outro
Segurança
Baseado em
Utilizador
Gerador deRespostas
Gerador deNotificações
ProxyForwarder
UDP IPX Outros
Rede
Outro
Controlo de Acessos
Baseadoem
Views
Manipulação da MIB
v1MP
v2cMP
v3MP
Outro
Processamentode Mensagens
SNMP versão 3: Segurança• Os mecanismos de segurança e controlo de acessos podem ser
utilizados de forma flexível adaptando-se a cada sistema.
• Autenticidade da origem e do conteúdo, assinar a mensagem usandoo MD5, a mensagem é enviada entre o destino e a origem a chave éconhecida por ambos.
• Confidencialidade: cifrar a mensagem usando DES (Data EncriptionStandard) e o CBC (Cipher Block Chaning)
• Validade da Informação: adição de uma Marca temporal - Time Stampque permite detectar sequências for de ordem delimitar o intervalode vida da mensagem.
Recommended