Gerência de Redes (SNMP)
Serviços de Diretório (LDAP)
Policy Based Networking (PBNM)
Edgard Jamhour
Mauro Fonseca
Carlos Maziero
2006, Edgard Jamhour
Definições básicas
• Gerência de redes:
– conjunto de ferramentas, procedimentos e políticas
usadas para manter o funcionamento e eficiência de uma rede,
independente de seu tamanho ou finalidade.
• Gerência integrada:
– ferramentas e procedimentos que podem cooperar
entre si, possibilitando a definição de políticas homogêneas em
um ambiente heterogêneo.
2006, Edgard Jamhour
Áreas funcionais de gerência
• Configuração
• Falha
• Desempenho
• Segurança
• Contabilidade
2006, Edgard Jamhour
Gerência de configuração
• Inventory: conjunto de dispositivos na rede, do
software e hardware presente nesses dispositivos
e sua informação estática.
• Configuration: mapa indicando as conexões entre componentes do
inventário.
• Provisioning: parâmetros operacionais modificáveis
que especificam o comportamento de cada dispositivo.
2006, Edgard Jamhour
Gerência de falha
• Detectar e resolver rapidamente situações que
degradam o funcionamento da rede:
–
–
–
–
Determinar a origem da falha
Isolar a falha do restante da rede
reconfigurar a rede para diminuir impacto da falha
reparar ou trocar componentes com falha
2006, Edgard Jamhour
Gerência de desempenho
• Assegurar uma capacidade de tráfego mínima
na rede.
• Assegurar que os dispositivos podem
tratar o tráfego presente na rede.
• Baseia-se em dados colhidos da rede:
– erros de CRC, time-outs, retransmissões
• Dados históricos podem ser importantes
2006, Edgard Jamhour
Gerência de segurança
• Proteção das informações
• Controle de acesso ao sistema
• Monitorar uso dos recursos
• Criar, manter e examinar “log-files”
• Muito importante em sistemas abertos
• Essencial em hosts conectados à Internet
2006, Edgard Jamhour
Gerência de contabilização
• Ter uma idéia clara do uso dos recursos
– cobrar pelos serviços utilizados
– planejar crescimento da rede
– detectar abusos no uso dos recursos
• Informação de contabilização deve ter acesso
restrito.
2006, Edgard Jamhour
Modelo de gerência
• Baseado em uma estrutura cliente/servidor
– agente: age como servidor de informações de
gerência
– gerente: consulta os agentes
para obter informações
2006, Edgard Jamhour
Servidor: Agente
• Agente: Network Management Entity
– executa um processo agente
– interage com os dispositivos físicos
– coleta, mantém e oferece informações
de gerência
– responde a pedidos de informação
e comandos
2006, Edgard Jamhour
Cliente: Gerente
• Gerente: Network Management Application
– consultas e ações sobre os agentes
– executa um software de gerência
– interage com o operador do sistema
2006, Edgard Jamhour
O ciclo de gerência
• As atividades de gerência compõe um ciclo:
• Coleta de dados: monitoração (automática)
dos recursos gerenciados.
• Diagnóstico: tratamento e análise dos dados
coletados para delinear o problema.
• Ação: controle sobre os recursos gerenciados
para corrigir o problema.
2006, Edgard Jamhour
Transferência da informação
• Dados fluem dos agentes ao gerentes
• Pooling:
• interações tipo “pedido/resposta”
• iniciadas pelo gerente, solicitando dados
• podem ser específicas ou genéricas
• Event reporting:
• indicações de ocorrência de eventos importantes
• iniciadas pelo agente
• podem ser periódicas ou ocasionais
2006, Edgard Jamhour
Uma arquitetura de gerência
Management entity
requests
Managed objects
responses
notifications
Management
application
events
operations
Management protocol
Management
agent
MIB
Management
database
2006, Edgard Jamhour
Ferramentas de gerência
• Arquitetura de gerência OSI
• Gerência usando SNMP
• Gerência via Web
• Gerência com objetos CORBA
2006, Edgard Jamhour
Protocolos de gerência
• SNMP
•
•
•
•
Simple Network Management Protocol
Criado pela IETF em 1988
Projetado para monitorar redes simples
Dominante em redes TCP/IP
• CMIP
•
•
•
•
Common Management Information Protocol
Proposto pela ISO no início dos anos 90
Controle (complexo) de redes complexas
Muito presente em redes de telefonia
2006, Edgard Jamhour
Informações de gerência
• MIB
• Management Information Base
• Dados mantidos pelos elementos gerenciados
• Informação com estrutura hierárquica
• SMI
• Structure of Management Information
• Define notações, formatos, tipos, nomes, ...
• Usa como base a notação formal ASN.1
2006, Edgard Jamhour
MIB-II - Estrutura geral
iso(1)
org(3)
dod(6)
internet(1)
Object ID is
1.3.6.1.2.1.7
directory(1)
mgmt(2)
mib-2(1)
system(1)
interfaces(1)
tcp(6)
udpInDatagrams
udpNoPorts
udpInErrors
udpOutDatagrams
udp(7)
2006, Edgard Jamhour
SNMP
• Voltado à monitoração de redes simples
• Pode ser embutido em hardware simples
• Muito usado em redes TCP/IP
• Comandos e tipos de dados fixos
• Poucos tipos de mensagens
• estrutura bastante simples
• Usa UDP/IP
• baixo nível de tráfego de gerência
• protocolo de transporte sem conexão
• não confiável (perda de pacotes)
• Comandos e respostas assíncronas
2006, Edgard Jamhour
Extensões de SNMP
• RMON - Remote Network Monitoring
• extensão da MIB-II para gerência
• Facilidades para monitoração e coleta
• “Remendo” sobre SNMP e MIB
• RMON-2
• Coleta de informações mais abrangente
• SNMP-V2
• estrutura de segurança melhorada
• comunicação entre gerentes (método inform)
• MIB e SMI aumentadas: novos tipos de dados
2006, Edgard Jamhour
Estrutura de gerência OSI
Arquitetura em camadas de serviços:
• SMFA
• System Management Functional Areas: faltas, contabilidade,
configuração, desempenho, segurança
• SMF
• System Management Functions
• CMISE
• CMIS: Common Management Information Services
• CMIP: Common Management Information Protocol
2006, Edgard Jamhour
Arquitetura OSI
Specific Management Functional Areas
accounting
fault
security
performance
configuration
System Management Functions
object
log
state
workload
relationship
test
alarm
summarization
security
access
Event-report
accounting
CMISE Services
get
set
action
create
delete
event-report
CMIP
Managed node
2006, Edgard Jamhour
O que é SNMP ?
• Padrão para gerência na Internet
– simples de implementar
– amplamente difundido
• Composto de:
– protocolo para trocas de mensagens
– padrões para estruturar a informação
• Evolutivo: SNMPv2, SNMPv3, RMON, ...
2006, Edgard Jamhour
Estrutura geral do sistema
Protocol
SNMP manager
MIB
Request
SNMP agent
Response
MIB
Management
information
2006, Edgard Jamhour
Informações de gerência
• Definidas através da SMI
– Structure of Management Information
– Define como criar a MIB
• Endereçada através de MIBs
– Management Information Bases
– Uma MIB é uma coleção de objetos
– Cada objeto representa uma parâmetro de gerência
• Transportadas através do SNMP
– Single Network Management Protocol
2006, Edgard Jamhour
Árvore MIB
• Object IDentifier (OID)
iso(1)
1
org(3)
- Exemple .1.3.6.1.2.1.1
3
dod(6)
- iso(1) org(3) dod(6) internet(1)
mgmt(2)
mib-2(1)
system(1)
6
internet(1)
1
directory(1)
4
1
mgmt(2)
experimental(3)
2
Notas:
- .1.3.6.1 ~100% present.
- os ramos mgmt e private são os mais usados.
- MIB-2 é uma estrutura padrão que deve ser
suportada por nós TCP/IP.
private(4)
3
mib-2(1)
1
tcp(6)
system(1)
6
1
interfaces(2)
2
ip(4)
4
2006, Edgard Jamhour
A MIB versão 2
objeto
1.3.6.1.2.1.1
1.3.6.1. iso.org.dod.internet
1. directory
2. mgmt
3. experimental
4. private
5. security
6. snmpV2
7. mail
1. mib-2
1. enterprises
1. system
2. interfaces
3. address translation
4. ip
5. icmp
6. tcp
7. udp
8. egp
9. oim
10. transmission
11. snmp
2006, Edgard Jamhour
Objeto MIB
• Definido em ANS.1
-
OBJECT-TYPE
-
-
SYNTAX
-
-
READ-ONLY, READ-WRITE.
STATUS
-
-
Define o tipo de informação
representada pelo objeto MIB.
ACCESS
-
-
Descreve o objeto MIB.
Object IDentifier (OID).
Estado do objeto em relação a
comunidade SNMP.
DESCRIPTION
-
Significado da informação representada
pelo objeto MIB.
Standard MIB Object:
sysUpTime OBJECT-TYPE
SYNTAX Time-Ticks
ACCESS read-only
STATUS mandatory
DESCRIPTION
“Time since the
network management
portion of the system
was last re-initialised.
::= {system 3}
2006, Edgard Jamhour
ASN.1
Abstract Syntax Notation One
•
•
•
•
•
Linguagem de descrição de dados da ISO
Definição em formato texto não ambíguo
Permite definir modelos de dados
Formato independente de máquina
Implementação dos dados não é considerada
2006, Edgard Jamhour
Campo SYNTAX
• Define o conteúdo do objeto
–
–
–
–
INTEGER: inteiros de 32 bits
INTEGER (1..100): sub-tipo inteiro
OCTET STRING: string de bytes
OBJECT IDENTIFIER: localização de outro objeto na MIB
• Aceita alguns tipos específicos de aplicação:
–
–
–
–
IpAddress: OCTET STRING com 4 bytes
Counter: inteiro 32 bits monotônico crescente
Gauge: inteiro 32 bits limitado no mínimo e no máximo
TimeTicks: inteiro 32 bits (1/100 de segundo)
2006, Edgard Jamhour
Sub-tipagem
INTEGER
INTEGER
INTEGER
INTEGER
INTEGER
INTEGER
INTEGER
(-127..128)
(1..10)
(0 | 2 | 4 | 6 | 8)
(0..2 | 20)
(-127..-1 | 1..128)
(1)
2006, Edgard Jamhour
Enumeração usando inteiros
Boolean ::= INTEGER
{ true (1), false (2)}
Alarm-level ::= INTEGER
{ critical
(1),
major
(2),
minor
(3),
warning
(4),
informational (10)
}
2006, Edgard Jamhour
Campo ACCESS
• Define a acessibilidade do objeto
• Valores possíveis em SNMPv1:
–
–
–
–
read-only
read-write
write-only
not-accessible
2006, Edgard Jamhour
Campo STATUS
• Situação do objeto na MIB
– Mandatory
• Devem ser implementados por todos os agentes
• Valores contidos devem ser válidos
– Optional
• Pode ou não ser implementado
– Deprecated
• Foi substituido por novo objeto, mas ainda é valido
• Se tornará obsoleto mais tarde
– Obsolete
• Não deve ser considerado
2006, Edgard Jamhour
Valores escalares e vetoriais
• Valores escalares:
• uma só instância por variável
• OID deve ser completado por “.0”
• Exemplo: ....mib-2.ip.ipForwarding: 1.3.6.1.2.1.4.1.0
• Valores vetoriais:
•
•
•
•
para construir listas e tabelas
usam os construtores SEQUENCE e SEQUENCE OF
Convenção de tabela: xxxTable
Convenção de linha na tabela: xxxEntry
2006, Edgard Jamhour
Tabela de conexões TCP
tcpConnTable OBJECT-TYPE
SYNTAX SEQUENCE OF TcpConnEntry
ACCESS not-accessible
STATUS mandatory
DESCRIPTION
“A table containing TCP
connection-specific information.”
::= {tcp 13}
2006, Edgard Jamhour
Uma conexão TCP na tabela
tcpConnEntry OBJECT-TYPE
SYNTAX TcpConnEntry
ACCESS not-accessible
STATUS mandatory
DESCRIPTION
“Information about a particular
current TCP connection. ...”
INDEX {
tcpConnLocalAddress, tcpConnLocalPort,
tcpConnRemAddress,
tcpConnRemPort
}
::= {tcpConnTable 1}
2006, Edgard Jamhour
Uma conexão TCP na tabela (2)
TcpConnEntry ::=
SEQUENCE {
tcpConnState
INTEGER,
tcpConnLocalAddress IpAddress,
tcpConnLocalPort INTEGER (0..65535),
tcpConnRemAddress IpAddress,
tcpConnRemPort
INTEGER (0..65535),
}
2006, Edgard Jamhour
BER
• Basic Encoding Rules
• Codificação dos dados para transferência
• Usa formato TLV: Type-Length-Value
• Type: tipo ASN.1 e infos complementares
• Length: tamanho da representação dos dados
• Value: string de octetos contendo o valor do dado
• A estrutura de codificação é recursiva
2006, Edgard Jamhour
A arquitetura SNMP
Managed system
Management
system
management
application
SNMP manager
UDP
IP
link
resources
management actions
SNMP messages
MIB objects
SNMP agent
UDP
IP
link
2006, Edgard Jamhour
O protocolo SNMP
• Veicula informações de gerência
• transporte de valores das MIBs
• Interações sem conexão
• Mensagens em UDP/IP
• portas 161 e 162
• pacotes de tamanho variável
• Mensagens auto-contidas
• formato Type - Length - Value
2006, Edgard Jamhour
Histórico do SNMP
• 1989: SNMP v1
• 1992: Remote Monitoring - RMON
• 1993: SNMP v2
• 1996: SNMP v2c (Community Security)
• 1996: MIB RMON v2
• 1998: SNMP v3 (User Security Model)
2006, Edgard Jamhour
Operações básicas SNMP
• GET
• GET-NEXT
• gerente busca informações dos agentes
• acessos em leitura às MIBs
• SET
• gerente modifica informações dos agentes
• acessos em escrita às MIBs
• TRAP
• agentes enviam informações não solicitadas aos gerentes,
informado eventos importantes
2006, Edgard Jamhour
Exemplo de uso
Get (Nome)
SNMP Agent MIB
manager
Response (‘João’)
GetNext (Nome)
pessoa.nome = João
pessoa.idade = 35
pessoa.sexo = masc
Response (35)
Set (sexo, fem)
Response (Erro)
2006, Edgard Jamhour
Restrições das operações
• Permitem somente inspeção
e/ou alteração de variáveis
• A estrutura da MIB não pode
ser alterada pelas operações
• Somente podem ser acessados
valores escalares em cada operação
2006, Edgard Jamhour
Limitações de SNMP
•
Falta de segurança
– esquema de autenticação trivial
– limitações no uso do método SET
•
Ineficiência
– esquema de eventos limitado e fixo
– operação baseada em pooling
– comandos transportam poucos dados
•
Falta de funções específicas
– MIB com estrutura fixa
– Falta de comandos de controle
– Falta de comunicação entre gerenciadores
•
Não confiável
– baseado em UDP/IP
– traps sem reconhecimento
2006, Edgard Jamhour
Modelo de segurança SNMP
• Modelo mais comum: SNMP V2c
• Baseado no conceito de comunidade
• Uma comunidade define:
• método para autenticar acesso (senha)
• visibilidade da MIB
• privilégios de acesso à MIB
• Cada dispositivo implementa
uma ou mais comunidades
• Comunidade default: “public”
2006, Edgard Jamhour
Exemplo de comunidades
admin
public
ensino
network
2006, Edgard Jamhour
Uma mensagem SNMP
• Conteúdo codificado via BER
• Geralmente limitada a < 484 bytes
preâmbulo
msg length
2 bytes
protocol version
1 byte
community string
até 128 bytes
PDU header
PDU SNMP
PDU
body
2006, Edgard Jamhour
Estrutura das PDUs SNMP
Get & Set
Trap
msg length
msg length
protocol version
preamble
protocol version
community string
community string
PDU type
PDU type
PDU length
PDU length
Request ID
Error Status
Enterprises OID
SNMP
header
Agent IP address
Error Index
Standard trap type
Variable bindings
Specific trap type
Time stamp
Variable bindings
SNMP
body
Variable bindings
Variable bindings
2006, Edgard Jamhour
Preâmbulo e cabeçalho
• Versão
0: SNMPv1, 1: SNMPv2, ...
• Tipo de PDU
0: getRequest
1: getNextRequest
2: getResponse
3: setRequest
4: trap
• Request ID
• valor numérico usado para casar pedidos e respostas
2006, Edgard Jamhour
Códigos de erro
• Error Status:
0: noError:
sucesso na operação
1: tooBig:
resposta muito grande para enviar
2: noSuchName: OID não suportado pelo agente
3: badValue:
valor incorreto para operação set
4: readOnly:
tentativa de escrita inválida
5: genErr:
erro não relacionado ao protocolo
• Error index:
• indica qual variável listada na PDU causou o erro.
2006, Edgard Jamhour
Conteúdo das mensagens
var list size
41
varbind length
23
variable OID
variable type
variable value
1.3.6.1.2.1.1.2.0
2
1.3.6.1.4.1.311.1.1.3.2
varbind length
14
1.3.6.1.2.1.7.4.0
65
250
variable OID
variable type
variable value
...
2006, Edgard Jamhour
A operação GetNext
• Busca próximo elemento na MIB
– Usa ordem lexicográfica
• 1.3.6.1.2.1.1.4
• 1.3.6.1.2.1.1.4.0
• 1.3.6.1.2.1.1.5.0
• ...
• Serve para:
• passear na MIB (descoberta da estrutura)
• buscar dados em tabelas
2006, Edgard Jamhour
Exemplo de passeio na MIB
• snmpgetnext -v1 localhost -c public system
– SNMPv2-MIB::sysDescr.0 = STRING: Linux espec.ppgia.pucpr.br 2.6.171.2142_FC4smp #1 SMP Tue Jul 11 22:59:20 EDT 2006 x86_64
• snmpget -v1 localhost -c public -O n system.sysDescr.0
– .1.3.6.1.2.1.1.1.0 = STRING: Linux espec.ppgia.pucpr.br 2.6.171.2142_FC4smp #1 SMP Tue Jul 11 22:59:20 EDT 2006 x86_64
• snmpgetnext -v1 localhost -c public -O n .1.3.6.1.2.1.1.1.0
– .1.3.6.1.2.1.1.2.0 = OID: .1.3.6.1.4.1.8072.3.2.10
• snmpgetnext -v1 localhost -c public -O n .1.3.6.1.2.1.1.2.0
– .1.3.6.1.2.1.1.3.0 = Timeticks: (523160) 1:27:11.60
• snmpget -v1 localhost -c public .1.3.6.1.2.1.1.3.0
– SNMPv2-MIB::sysUpTime.0 = Timeticks: (527855) 1:27:58.55
2006, Edgard Jamhour
Percurso seqüencial
coluna 1
1
linha 1
myVar1.1
2
linha 2
myVar1.2
3
linha 3
myVar1.3
4
linha 4
myVar1.4
coluna 2
5
coluna 3
9
myVar2.1
6
myVar2.2
7
myVar2.3
8
myVar2.4
myVar3.1
10
myVar3.2
11
myVar3.3
12
myVar3.4
13
2006, Edgard Jamhour
Traps em SNMP
• Mensagens enviadas pelo agente
• Não são respostas a pedidos
• Representam eventos anormais
• Classificam-se em:
• genéricos: presentes na MIB padrão
• específicos: definidos na MIB “enterprises”
2006, Edgard Jamhour
Traps genéricos
• coldStart:
• o dispositivo foi ligado
• configuração local pode ter sido alterada
• informa ao gerente sobre sua existência
• warmStart:
• o dispositivo foi reinicializado
• configuração local não foi alterada
• linkDown:
• link ou porta de comunicação ligada ao nó falhou
2006, Edgard Jamhour
Traps genéricos (2)
• linkUp:
• link ou porta local foi (re)ativada.
• authenticationFailure:
• o dispositivo recebeu msg SNMP não autorizada
• comunidade não reconhecida
• número IP de gerente inválido
• egpNeighborLoss:
• Exterior Gateway Protocol falhou no nó
• normalmente usado em roteadores
2006, Edgard Jamhour
Serviço de Diretório
• Defini-se um serviço de diretório como sendo um "banco de
dados" especializado para informações de gerenciamento.
• Exemplos bem conhecidos de serviços de diretório são:
– Especificação LDAP
– Especificação X500
– Especificação DNS (Nomes de Domínio)
• Serviços de diretório são utilizados para oferecer um
repositório "logicamente" centralizado com as informações
de gerenciamento.
2006, Edgard Jamhour
Modelos de Serviço de Diretório
• Um serviço de diretório deve ser capaz de:
– Armazenar qualquer tipo de objeto
• DNS, por exemplo, só armazena registros que relacionam nomes
com endereços.
– Oferecer mecanismos flexíveis de consulta
• por exemplo, localizar o email de uma pessoa pela departamento
onde trabalha e cargo que ocupa.
– Armazenar as informações numa arquitetura decentralizada
• Serviço de Diretório = Banco de Dados Distribuído.
– Utilizar um mecanismo para nomear os objetos independente do seu
tipo.
2006, Edgard Jamhour
Serviço de Diretório X500
• X500 é um protocolo CCITT projetado para construir um
serviço de diretório distribuído de alcance global.
• Ele oferece as seguintes características:
– Escalabilidade
• Sistema de Banco de Dados Distribuído
– Mecanismos de Procura Flexíveis
• Linguagem de consulta orientada a objetos
– Espaço de Nomes Homogêneo
• Mesma notação para qualquer objeto.
– Serviço padronizado e aberto.
• Definido por normas CCITT
2006, Edgard Jamhour
Modelo Funcional X500
(Banco de Dados Distribuído)
DUA
(Directory User Agent)
DAP
(Directory Access Protocol)
DSP
(Directory Service
Protocol).
DUA
DAP
DSA
DSP
DSP
DSA
DSA
DAP
DSP
DUA
Diretório
X500
DSA
(Directory System Agent)
2006, Edgard Jamhour
Modelo Funcional X500
• DSP (Directory Service Protocol). Protocolo que padroniza a
comunicação entre servidores. Essa comunicação ocorre quando
uma consulta não pode ser satisfeita pelo servidor local.
• DAP (Directory Access Protocol). Protocolo de acesso, que
padroniza a comunicação entre o cliente e o servidor de diretório.
• DUA (Directory User Agent) é o nome dado a parte do software do
cliente que interage diretamente com o servidor de diretório.
– O desenvolvimento de aplicações que interagem com o diretório é feita
através de um conjunto de API's padronizadas pelo protocolo de
acesso.
• DSA (Directory System Agent) é a denominação dada a porção do
software do servidor responsável por atender as requisições dos
clientes.
2006, Edgard Jamhour
Serviço de Diretório X500
prenome=edgard?email?
[email protected]
SERVIÇO DE
DIRETÓRIO
Login
Bypass.
Login+senha
senha
OK
Políticas IPsec para
o IP de destino
200.10.0.1?
2006, Edgard Jamhour
Estrutura do X500
• As informações de diretório do X500 estão armazenadas
no DIB - Directory Information Base
– cada entrada do diretório aponta para um objeto
Objeto: Usuário
nome:
sobrenome:
email:
Entrada
Edgard
Jamhour
[email protected]
Atributos
Objeto
Atributo 1 (tipo, valores)
Atributo 2 (tipo, valores)
....
Atributo n (tipo,valores)
2006, Edgard Jamhour
Objetos do X500
RDN: Relative Distiguished Name
objetos
estrutura genérica
de uma classe
atributo 1: tipo
atributo 2: tipo
atributo 3: tipo
…
atributo N: tipo
classe Pessoa
nome: string
sobrenome: string
nc: string
passord: string
email: string
nascimento: data
uid: string
objectclass: Pessoa
nome: Albert
sobrenome: Einstein
nc: aeinstein
passord: 1B5A324AB3
email: [email protected]
nascimento: 01/08/1908
objectclass: Pessoa
nome: Issac
sobrenome: Newton
nc: inewton
passord: 2A2A324ZC3
email: [email protected]
nascimento: 03/09/1803
2006, Edgard Jamhour
X500: Esquema de Classes
• Algumas classes LDAP são derivados do X500 e
definidas na RFC 2256.
– objectclass: person (derivada de top)
• atributos obrigatórios: sn, cn
• atributos opcionais: description, seeAlso,
telephoneNumber, userPassword
– objectclass: organizationalperson (derivada de person)
• atributos opcionais: facsimileTelephoneNumber,
postOfficeBox, postalAddress , postalCode,
preferredDeliveryMethod , etc.
– objectclass: inetOrgPerson
• atributos opcionais: businessCategory, departmentNumber,
employeeType, employeeNumber, homePhone,
homePostalAddress, initials, manager, mobile, pager,
preferredLanguage, mail, o, roomNumber, secretary, uid
2006, Edgard Jamhour
Estrutura em Árvore
• Os objetos podem conter outros objetos constituindo uma
estrutura hierárquica em forma de árvore.
Objetos que contém
outros objetos são ditos
containers.
Uma rede de
computadores ou
domínio pode ser
representado como uma
sub-árvore no diretório.
Objetos que não contém
outros objetos são ditos
leaf.
2006, Edgard Jamhour
Esquema de Nomes X500
Classe
(RDN)
RDN=
DN =
DN: Distiguished Name
Raiz
()
País
(P)
RDN: P=br
RDN: P=fr
Organização
(O)
DN: P=br
RDN: O=cefetpr
RDN: O=pucpr
DN: O=pucpr, P=br
RDN: UO=ppgia
Unidade Organizacional
(UO)
Pessoa
(NC)
RDN: UO=ccet
RDN: NC=inewton
RDN: UO=ppgia, O=pucpr, P=br
RDN: NC=aeinstein
DN: NC=aeinstein, UO=ppgia, O=pucpr, P=br
2006, Edgard Jamhour
Nomes
• Um nome é utilizado para identificar cada objeto no
diretório. Existem dois tipos de nomes:
• Relative Distinguished Name (RDN):
– Nome Característico Relativo
– identifica o objeto através de um atributo
• cn=ejamhour
• Distinguished Name (DN):
– Nome Característico
– identifica o objeto pelo seu caminho completo a partir da raiz.
• cn=ejamhour,ou=Funcionarios,ou=ppgia,o=pucpr.br
2006, Edgard Jamhour
LDAP
(Lightweight Directory Access Protocol)
• Criado como uma alternativa mais simples ao protocolo
padrão do X500.
– DAP: Directory Access Protocol
• Desenvolvido pela Universidade de Michigan em conjunto com
o Internet Engineerig Task Force (ETF)
• O LDAP está atualmente na versão 3: LDAP v3
• Diversas normas descrevem o funcionamento do LDAP:
–
–
–
–
–
RFC 1777 - Protocolo
RFC 1779 - Modelo de Nomes
RFC 1823 - API
RFC 1959 - formato URL
RFC 2044 - conjunto de caracteres internacionais UTF-8
2006, Edgard Jamhour
LDAP
• Trabalha numa arquitetura cliente-servidor:
– clientes LDAP se conectam a um ou mais
servidores LDAP para atualizarem e obterem
informações sobre o diretório.
• Define um conjunto de primitivas para
manipular objetos de diretório:
– Bind, search, modify, delete, etc.
• LDAP inclui suporte para autenticação
– Simples (clear text), Kerberos e SSL são
utilizados.
2006, Edgard Jamhour
Servidor LDAP:
• A arquitetura LDAP segue o padrão
cliente-servidor.
• O servidor LDAP pode ser de dois
tipos:
– Fazer uma ponte com outro servidor de
diretório (e.g. X500)
– Ser um servidor stand-alone.
2006, Edgard Jamhour
Servidor LDAP como Ponte para X500
DAP
LDAP
cliente
LDAP
servidor
X500
servidor
LDAP
DAP
servidor
X500
2006, Edgard Jamhour
Stand-alone LDAP
servidor
LDAP
LDAP
cliente
LDAP
servidor
LDAP
LDAP
2006, Edgard Jamhour
Sintaxe de uma Consulta LDAP
• ldap[s]://<host>:<porta>/<base_dn>?<atributos>?<escopo>?<filtro>
• ldap://ppgia.pucpr.br/o=pucpr,c=br?email?sub?(sn=Joa*)
c=br
o=pucpr
o=ufpr
escopo sub
c=br
c=br
o=pucpr
o=pucpr
o=ufpr
escopo one
o=ufpr
escopo base
2006, Edgard Jamhour
Directory Enable Networks
• Criação:
– Criado pelo DMTF(Distribute Engineering Task Force)
• www.dmtf.org
• DMTF: Reuni os principais fabricantes de produtos
de hardware e software pare rede: Cisco, 3Com,
Microsoft, Sun, Novel, IBM, etc.
• Objetivo:
– Criar um formato padrão para armazenar informações
de rede em um diretório LDAP, de maneira que este
possa ser compartilhado por várias aplicações.
2006, Edgard Jamhour
CIM - Common Information Model
• Os esquemas de diretório propostos pelo DMTF
já estão implementados nas versões atuais de
Solaris e Windows 2000 sob a denominação
CIM:
– Common Information Model
• Recentemente, o DMTF juntou esforços com o IETF e
criou o PCIM:
– PCIM: Police Core Information Model
(RFC3060)
2006, Edgard Jamhour
CIM: Common Information Model
Core model
Application
System
Network
Physical
Device
Network Foundation
QoS
model
IPsec
model
BGP
model
Bridge
model
VLAN
model
2006, Edgard Jamhour
CIM: Common Information Model
X500_Top
Group
(X500)
ManagedSystemElement
(CIM)
Person
(X500)
Organization
(X500)
Configuration
(CIM)
Application
(CIM)
Protocol
(CIM)
Service
(CIM)
Profile
(DEN)
Policy
(DEN)
2006, Edgard Jamhour
Directory Enable Networks
Futuras
Aplicações
que usam Diretório
Aplicações de
Gerenciamento
Existentes
Futuras
Aplicações
de Gerenciamento
Protocolos de Gerenciamento Existentes
hubs
switches
roteadores
DIRECTORY
ENABLE
NETWORKS
ESQUEMA
e
INTERFACES
DIRETÓRIO
computadores
2006, Edgard Jamhour
Gerência de Redes Baseada em Políticas
• A configuração e gerência de redes possui
características que podem ser melhor descritas
através de políticas.
• Exemplo:
– Políticas de operação normal, grande volume ou
emergenciais.
– Para atender essas políticas a rede precisa ser
configurada, e não cada equipamento individualmente.
– Políticas devem permitir mapear processos de negócio
para as aplicações que utilizam a rede.
2006, Edgard Jamhour
PCIM
• Policy Core Information Model
– Resultado entre um trabalho conjunto entre o DMTP e o IETF.
• As seguintes RFC´s são atualmente publicadas pelo
IETF:
– Policy Core Information Model - Version 1 Specification (RFC
3060)
– Terminology for Policy-Based Management (RFC 3198)
• Os seguintes trabalhos estão no formato de Draft:
– Policy Core LDAP Schema
– Policy Framework QoS Information Model
– Information Model for Describing Network Device QoS Datapath
Mechanisms
– Policy Core Information Model Extensions
2006, Edgard Jamhour
O que é o PCIM?
• PCIM é um modelo genérico:
– Define um conjunto de classes e relacionamentos de
maneira extensível.
– Políticas para o controle de objetos gerenciáveis são
definidas pela extensão desse modelo.
• Princípios:
– PCIM representa a estrutura e não o conteúdo de uma
política.
– O conteúdo deve ser definido para herança das
classes genéricas do PCIM de maneira a criar
estrutura de políticas especializadas para áreas de
aplicação e produtos específicos.
2006, Edgard Jamhour
Máquina de Estados
• O gerenciamento baseado em políticas presume
que a rede é modelada como uma máquina de
estados.
• As classes e relacionamentos do PCIM são
usadas para modelar:
– O estado de uma entidade
– As ações para manter a entidade num dado estado ou
movê-la para outro estado.
– A configuração a ser aplicada numa entidade para
mantê-la ou movê-la para outro estado.
2006, Edgard Jamhour
Políticas = Conjunto de Regras
• Uma política PCIM é formada por um conjunto de regras.
Cada regra é definida por um conjunto de condições e um
conjunto de ações.
• As regras podem ser priorizadas e agrupadas para
modelar uma hierarquia administrativa.
Política
Regra 1
Condição 1
…
Condição N
Ação
…
Açaõ N
Regra 2
…
Regra N
2006, Edgard Jamhour
Principais Classes do PCIM
2006, Edgard Jamhour
PCIMe
2006, Edgard Jamhour
Condições
2006, Edgard Jamhour
Mapeamento de Políticas no
Dispositivo
2006, Edgard Jamhour
QPIM: Policy Quality of Service
Information Model
2006, Edgard Jamhour
Policy Based Networking
• PDP: Policy Decision Point
• PEP: Policy Enforcement Point
Policy Management
Tool
request
aplicativo
PEP
COPS
decision
PDP
request
dispositivo
PEP
Policy
Repository
LDAP
COPS
decision
Base de
Estados
2006, Edgard Jamhour
COPS
• Common Open Policy Services Protocol
– RFC 2748:
• The COPS (Common Open Policy Service) Protocol
(Janeiro 2000)
– RFC 2749:
• COPS usage for RSVP (Janeiro 2000)
– RFC 2753:
• A Framework for Policy-based Admission Control
(Janeiro 2000)
– RFC 3084:
• COPS Usage for Policy Provisioning (COPS-PR)
(Março 2001)
2006, Edgard Jamhour
COPS
•
Protocolo simples, extensível, baseado em TCP.
– A conexão TCP é permanente
•
As mensagens COPS são transmitidas como objetos independentes e
flexíveis
– novos objetos podem ser criados
•
A segurança pode ser implementada por IPsec ou TLS.
PEP
PDP
Open Client Type
Connection
PEP
PDP
Request
Decision
Client Connection
Accept
Report
2006, Edgard Jamhour
Princípio
• O PDP é stateful.
– As requisições feitas pelos PEPs são “lembradas” pelo PDP até
que sejam explicitamente apagadas pelo PEP.
• As mensagens COPS são enviadas através de conexões
TCP iniciadas sempre pelo PEP.
– Na inicialização o PEP solicita a carga de uma configuração
inicial.
– Mas o PDP pode enviar mensagens não solicitadas ao PEP
através dessas conexões.
• As decisões tomadas pelo PDP são assíncronas.
– O PDP pode carregar novas configurações no PEP.
– O PDP pode remover certas configurações no PEP quando elas
não forem mais necessárias.
2006, Edgard Jamhour
Modelo Básico
• LPDP: Local Policy Decision Point
– Permite ao PEP tomar decisões na ausência do PDP.
• O LDPD não é um substituto do PDP.
– O PDP central é autoritário sobre o LPDP.
– Todas as decisões importantes devem ser enviadas ao PDP
central.
Nó de Rede
PDP
PEP
COPS
LPDP
2006, Edgard Jamhour
Funcionamento
• 1) O PEP faz uma conexão TCP no PDP.
• 2) O PEP envia uma mensagem de “Request”
identificando o tipo de política desejada .
• 3) O PDP envia para o PEP as configurações através de
mensagens “Decision”.
• 4) O PEP instala as configurações e quando estiver
pronto envia a mensagem “Report”.
• 5) O PDP pode enviar uma mensagem “Decision” não
solicitada para o PEP para anular uma requisição já
concedida.
• 6) O PEP deve responder a essa mensagem com
“Report”.
2006, Edgard Jamhour
Mensagens COPS
• As mensagens COPS são formadas por um cabeçalho fixo, seguido
por um número variável de objetos.
– Version:
• atualmente 1
– Flags:
• Apenas o flag “Solicited Message Flag” está definido
– Op Code:
• Mensagem COPS
– Client Type:
• Identifica o tipo de cliente (para receber a política)
– Message Length
• Tamanha da mensagem em bytes (inclui o cabeçalho)
1 byte
version
flags
1 byte
op code
2 bytes
Client Type
Message Length
2006, Edgard Jamhour
Op Code
•
•
•
•
•
•
•
•
•
•
1 = Request (REQ)
2 = Decision (DEC)
3 = Report State (RPT)
4 = Delete Request State (DRQ)
5 = Synchronize State Req (SSQ)
6 = Client-Open (OPN)
7 = Client-Accept (CAT)
8 = Client-Close (CC)
9 = Keep-Alive (KA)
10= Synchronize Complete (SSC)
2006, Edgard Jamhour
Objetos COPS
•
C-Num
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
1 = Handle
2 = Context
3 = In Interface
4 = Out Interface
5 = Reason code
6 = Decision
7 = LPDP Decision
8 = Error
9 = Client Specific Info
10 = Keep-Alive Timer
11 = PEP Identification
12 = Report Type
13 = PDP Redirect Address
14 = Last PDP Address
15 = Accounting Timer
16 = Message Integrity
•
C-Type
–
–
Depende de C-Num
Indica o subtipo ou versão da
informação transportada pelo
objeto.
2 byte
1 byte
Length
C-Num
1 byte
C-Type
Object Contents
2006, Edgard Jamhour
Escalabilidade
Repositório de
Políticas
PDP
PDP
COPS
PEP
COPS
PEP
PEP
PEP
PEP
PEP
PEP
2006, Edgard Jamhour
Modelos de PDP/PEP
• O COPs pode ser utilizado em duas estratégias
diferentes:
– Outsourcing:
• Poucas informações são armazenadas no
dispositivo gerenciado (PEP).
• O PEP consulta ao PDP para tomar decisões
relativas aos eventos do dispotivo.
– Provisioning:
• A maioria das informações de configuração é
armazenada no PEP na inicialização do dispositivo.
• O PEP toma a maioria das decisões localmente.
2006, Edgard Jamhour
Modelo Outsourcing
• Cada evento no PEP dispara uma consulta ao
PDP.
2006, Edgard Jamhour
Modelo Provisioning
• O PEP tem autonomia para tomar decisões
localmente.
2006, Edgard Jamhour
PIB - Policy Information Base
• Similar a MIB, utilizada pelo SNMP, uma PIB é
uma árvore lógica que permite representar
políticas na forma de variáveis unicamente
identificadas.
PRC - Provisioning Classes
PRI - Provisioning Instances
2006, Edgard Jamhour
Tipos de Classes PIB
• 1) Notify: PEP  PDP
– os valores dos atributos destas classes são
definidos pelo próprio dispositivo (PEP).
• 2) Install: PDP  PEP
– os valores dos atributos destas classes são
preenchidos de acordo com a decisão do PDP.
• 3) Notify / Install : PDP  PEP
– as classes deste tipo combinam as características dos
dois ítens acima,
2006, Edgard Jamhour
Exemplo: Diffserv PIB
• O IETF definiu algumas PIBs padronizadas,
como para os casos do IPsec e do Diffserv.
2006, Edgard Jamhour
Exemplo: Diffserv PIB
B
B
1
2006, Edgard Jamhour
Representação OID
2006, Edgard Jamhour
Exemplo: CIM X QPIM X PIB
2006, Edgard Jamhour
Princípios do Modelo Provisioning
2006, Edgard Jamhour
Feedback do uso de políticas
• O feedback do uso de políticas pode ser:
– Periódico ou solicitado
• As políticas solicitadas definem as características
a serem monitoradas e o intervalo para envio de
relatórios.
• O feedback é enviado pelo PEP pela mensagem
de Report
• O feedback pode ser utilizado para implementar
políticas dinâmicas e mecanismos de
contabilização.
2006, Edgard Jamhour
Failover
• Se a conexão TCP com o PDP cair o PEP usa as
políticas guardadas em cache.
• No restabelecimento da conexão, o PDP envia
uma mensagem de re-sincronização para as
políticas guardadas em cache.
2006, Edgard Jamhour
Conclusão
• Policy Based Networking é uma nova abordagem
amplamente adotada pelo DMTF e o IETF.
• A arquitetura de Policy Based Networking é
baseada no framework:
– PDP, PEP e COPS.
• Sua aplicabilidade inicial é para gerenciar
políticas de QoS e Segurança em dispositivos de
rede.
• Todavia, o modelo PCIM pode ser adaptado para
qualquer outra área de configuração e
contabilização de dados.
2006, Edgard Jamhour
ANEXOS A
RMON
2006, Edgard Jamhour
Monitoração de redes
• SNMP e MIBs em agentes só permitem
analisar valores isolados (nos agentes)
• Como medir o tráfego na rede ?
tráfego = 137 kbps
tráfego = 55 kbps
tráfego = ?
2006, Edgard Jamhour
Monitores de rede
• Ouvem a rede continuamente
• Podem ouvir várias redes
• Não interferem nas redes monitoradas
monitor
2006, Edgard Jamhour
Informações monitoradas
• Todos os pacotes são ouvidos
• Podem ser aplicadas filtragens
• tipo de pacote, protocolo, origem, destino, ...
• Produção de dados estatísticos
• distribuição por tipo de pacote
• percentual de colisões
• taxas de transferência
• Armazenagem de pacotes para análise
2006, Edgard Jamhour
Monitorando múltiplas redes
• Um monitor para cada sub-rede
• Monitores devem ser acessíveis pelo gerente
monitores
gerente
router
2006, Edgard Jamhour
Definindo um monitor
• Definir a informação a armazenar
• significado dos dados
• tipos dos dados
• estrutura geral da informação
• Definir formas de acesso
• leitura/escrita
• configuração
• relatar eventos
• Implementar
• como um dispositivo dedicado
• serviço adicionado a um elemento da rede
2006, Edgard Jamhour
RMON
• RMON: Remote Monitoring
•
•
•
•
•
Norma para monitores de redes
Define uma (imensa) MIB
Dados são acessados via SNMP
Efetua a monitoração contínua de redes
Versões:
• RMON v1: monitoração MAC (ethernet, token ring, ...)
• RMON v2: monitora camadas mais elevadas
• Monitor: agente RMON ou sonda RMON
2006, Edgard Jamhour
Objetivos de RMON
• Operação off-line
• autônoma (independe do gerente)
• diminui o tráfego de rede
• Monitoração pró-ativa
• diagnósticos contínuos
• monitoração de desempenho
• pode gerar alarmes enviados ao gerente
2006, Edgard Jamhour
Objetivos de RMON (2)
• Informações de valor agregado
• dados estatísticos
• informações históricas
• Acesso por múltiplos gerentes
• diferentes objetivos de gerência
• tolerância a falhas
• Compatibilidade com padrões
• informação na forma de MIBs
• acesso via protocolo SNMP
2006, Edgard Jamhour
Controle da sonda RMON
• Monitor é acessado remotamente para:
• configuração geral
• invocação de ações
• Configuração:
• indicar tipo e forma dos dados a coletar
• manipulação de tabelas de controle
• Ações:
• leitura e escrita de valores
• invocação de “value triggered commands”
2006, Edgard Jamhour
Organização da MIB RMON
• Cada grupo consiste de:
• uma ou mais tabelas de dados (read-only)
• uma ou mais tabelas de controle (read-write)
• Tabelas de dados:
• valores coletados da rede e processados
• Tabelas de controle
• indicam que dados devem ser coletados
• cada linha representa uma função de coleta
• Podem ser fundidas em uma só tabela
2006, Edgard Jamhour
Múltiplos gerentes
• Vários gerentes podem acessar uma sonda
• acessos concorrentes podem saturar a sonda
• um gerente pode monopolizar a sonda
• Para o controle de múltiplos gerentes:
•
•
•
•
cada linha da tabela de controle possui um owner
propriedade: IP do gerente, localização, telefone, ...
informação de propriedade não limita o acesso
o monitor pode ser proprietário de algumas linhas
2006, Edgard Jamhour
Gerência de tabelas
• Complexo e pouco claro (Stallings 96 !)
• Inserção e remoção de linhas nas tabelas de controle
• Cada linha de tabela de controle possui:
• OwnerString: o proprietário da linha de controle
• EntryStatus: situação daquela linha:
–
–
–
–
valid
create request
under creation
invalid
• Demais informações
2006, Edgard Jamhour
Indexação de tabelas
xyzControlTable
xyzControlIndex
xyzControlParameter
xyzControlOwner
xyzControlStatus
1
5
Monitor
Valid(1)
2
26
Manager alpha
Valid(1)
3
19
Manager gamma
Valid(1)
xyzDataTable
XyzDataControlIndex
XyzDataIndex
xyzDataValue
1
1
46
2
2
1
2
96
85
2
3
77
2
2
4
5
27
92
3
1
86
3
2
26
2006, Edgard Jamhour
Inserção de linhas
• Através do método SNMP set:
set [index, (tipo, valor), (tipo, valor), ...]
• erro badValue em caso de dado inválido
ou impossibilidade de criação
• tratamento de conflitos em acessos simultâneos
torna-se necessário
2006, Edgard Jamhour
Passos para a criação de linhas
• Seqüência de passos para criar linhas:
1. se a linha solicitada não existe (índice inexistente),
ela é criada e seu status recebe o valor “createRequest”;
2. imediatamente após a criação o monitor muda o status da
linha para “underCreation”;
3. as novas linhas permanecem nesse estado até o gerente
terminar de criar todas a linhas desejadas;
4. ao final o gerente seta o campo de status das linhas criadas
por ele para o valor “valid”;
5. tentativas de criar linhas cujos índices já existem
resultam em erro.
2006, Edgard Jamhour
A MIB RMON
rmon (16)
statistics (1)
mib-2
history (2)
alarm (3)
host (4)
hostTopN (5)
matrix (6)
filter (7)
capture (8)
event (9)
tokenRing (10)
2006, Edgard Jamhour
Grupo statistics
• Uma tabela para cada sub-rede monitorada
• sub-rede referenciada por sua interface
• Informações mais importantes:
• carga da sub-rede
• saúde da sub-rede (erros, colisões)
• pacotes fora de tamanho (undersize, oversize)
• Mais detalhado que mib-2.interfaces
2006, Edgard Jamhour
Grupo history
• Amostragens do tráfego nas interfaces
ao longo do tempo de operação
• Cada linha da tabela de controle
define um conjunto de amostras
• Cada linha da tabela de dados
corresponde a uma amostra
• Defaults:
• cada amostra dura 1800 segundos
• as 50 últimas amostras são mantidas
2006, Edgard Jamhour
Outros grupos
• hosts
• estatísticas sobre hosts na sub-rede
• hostTopN
• estatísticas sobre hosts segundo algum critério
• armazena dados sobre os N primeiros hosts
em termos de tráfego, erros, tipos de pacotes, etc.
• matrix
• armazenar dados sobre tráfego entre pares de hosts
• tokenRing
• suporte a informações de redes token-ring
2006, Edgard Jamhour
Alarmes
• Alarmes são registrados na MIB
• gerados pelo grupo alarm
• tratados pelo grupo event
• podem ser enviados ao gerente via traps
• Cada entrada da tabela contém:
• OID da variável a ser monitorada
• intervalo de amostragem
• parâmetros de limiar (threshold)
• Um exemplo:
• + de 500 erros CRC nos últimos 5 minutos
2006, Edgard Jamhour
O ciclo de histerese
• Pequenas flutuações no valor monitorado poderiam
gerar alarmes
• excesso de alarmes sem utilidade
• Usa dois limiares de disparo do alarme:
• inferior: valor mínimo em condições normais
• superior: valor máximo em condições normais
• Gerar alarmes somente quando:
• valor ultrapassar o limite superior
• valor descer abaixo do limite inferior
• de forma alternada !
2006, Edgard Jamhour
O ciclo de histerese
estado do
alarme
disparo do
alarme inferior
disparo do
alarme superior
alarme
superior
alarme
inferior
valor monitorado
2006, Edgard Jamhour
Geração de alarmes
• Alarme é gerado quando:
• valor maior que o limiar superior
(risingThreshold)
• valor menor que o limiar inferior
(fallingThreshold)
disparos
valor
lim sup
lim inf
tempo
2006, Edgard Jamhour
O grupo filter
• Permite regras de filtragem dos pacotes
– dois tipos de filtros:
• data filter: padrões de bits nos pacotes
• status filter: status dos pacotes (válido, erro de CRC, ...)
– filtros podem ser combinados
• operações lógicas AND, OR, seqüências
• Os pacotes filtrados:
• constituem um fluxo chamado canal (channel)
• podem disparar eventos
• podem ser armazenados no grupo capture
2006, Edgard Jamhour
Considerações práticas
• Uso correto da sonda e do gerente
•
•
•
•
evitar uso abusivo de alarmes e eventos
uso inteligente de filtros e captura
risco de saturar a sonda e a rede
poder de processamento da sonda é limitada
• Problemas de interoperabilidade
• discrepância entre MIBs de fabricantes distintos
• muitas funções são parcialmente implementadas
2006, Edgard Jamhour
RMON v2
• RMON v1:
• limitado à camada MAC
• ethernet e token-ring
• poucos recursos de configuração
• RMON v2:
•
•
•
•
suporte às demais camadas (3 a 7)
monitoração de protocolos de aplicação
visibilidade de tráfego vindo de fora (IP)
tabelas replicadas para cada protocolo
• Outras inovações
• grupo MIB de configuração da sonda
2006, Edgard Jamhour
ANEXOS B
SNMPv2
2006, Edgard Jamhour
SNMPv2
• Definido em 1993 (RFC)
• Suporte flexível:
– gerência centralizada
– gerência distribuída
• Modificações mais significativas:
– estrutura de informação (SMI)
– interações “gerente a gerente”
– operações do protocolo
2006, Edgard Jamhour
SMI em SNMPv2
• Super-conjunto da SMI em SNMPv1
• Especificação e documentação mais elaboradas
dos objetos da MIB
• Novos conceitos:
–
–
–
–
definições de novos objetos
tabelas conceituais
novas definições de notificações
módulos de informação
2006, Edgard Jamhour
Definições de objetos
• Melhor definição de OBJECT-TYPE
• Novos tipos de dados:
– Counter32
– Unsigned64
• Remoção de ambigüidades de SNMPv1
• Novas interpretações de alguns tipos:
– Gauge32
– Counter64
2006, Edgard Jamhour
Cláusula MAX ACCESS
• Similar a ACCESS, enfatizando que o acesso
não pode ser modificado por configuração do
agente
• Níveis de acesso:
–
–
–
–
–
not accessible
accessible for notify
read only
read-write
read-create (tabelas conceituais)
2006, Edgard Jamhour
Cláusula STATUS
• Novos status:
– current
– deprecated
– obsolete
• Desaparecem:
– mandatory
– optional
2006, Edgard Jamhour
Tabelas
• Duas categorias de tabelas:
– estrutura fixa
– estrutura alterável
• Criação/deleção de linhas
– operações pelo gerente, via SNMP
– extremamente complexo e controverso
– segue o modelo adotado em RMON
2006, Edgard Jamhour
O protocolo SNMPv2
• Três formas de interação
– manager to agent, request/response
– agent to manager, unconfirmed
– manager to manager, request/response
• o último é definido em SNMPv2
2006, Edgard Jamhour
PDUs SNMPv2
• GetRequest, GetNextRequest
– similar à de SNMPv1
– resposta não é mais atômica
• SetRequest
– idem
• GetBulkRequest
– busca de grandes blocos de dados
– equivale a um GetNextRequest múltiplo
2006, Edgard Jamhour
PDUs SNMPv2
• InformRequest
– comunicação entre gerentes
– enviado pelo gerente que deseja enviar a informação
– resposta ResponsePDU sem conteúdo.
• ReportPDU
– não utilizada (abandonada nas RFCs)
2006, Edgard Jamhour
ANEXOS C
LDAP
2006, Edgard Jamhour
Raizes de Árvore no Servidor
Raiz do diretório
ou=Groups
o=ppgia.pucpr.br
ou=People
389
Servidor
LDAP
o=NetscapeRoot
2006, Edgard Jamhour
Exemplo
o=ppgia.pucpr.br
ou=Exemplo
ou=Funcionarios
cn=ejamhour
Objectclass = organization
Objectclass=organizationalUnit
ou=Grupos
ou=analistas
Objectclass =organizationalUnit
Objectclass =groupOfNames
cn=acalsavara
Objectclass =inetOrgPerson
2006, Edgard Jamhour
Parâmetros do LDAP
• <host>
– Nome (ou endereço IP) do servidor LDAP (por exemplo,
ldap.ppgia.pucpr.br ou 200.17.98.174).
• <porta>
– Porta do servidor LDAP. Se nenhuma porta for especificada,
assume-se a porta padrão 389.
• <base_dn>
– dn do ponto de início da procura.
• <atributos>
– indica quais atributos do objeto serão retornados.
• <escopo>
– define como efetuar a procura.
• <filtro>
– define os critérios da procura.
2006, Edgard Jamhour
Exemplos de Consulta LDAP em URL
• ldap://servidorLDAP/ou=RSD,o=ppgia.pucpr.br
• Solicita o todos os campos do objeto RSD
• ldap://servidorLDAP /ou=RSD,o=ppgia.pucpr.br?
endereço
• Solicita apenas o campo endereço do objeto
PUCPR.
• ldap://servidorLDAP / ou=RSD,o=ppgia.pucpr.br?
email?sub?(cn=Alc*)
• Solicita todos os emails da PUCPR pertencentes a
usuários que tem o nome começando por Alc.
2006, Edgard Jamhour
Comandos para localizar o usuário
• Procura todas as pessoas em ppgia.pucpr.br:
–
–
–
–
Servidor: ldap://icaro.ppgia.pucpr.br/
Search Root: o=ppgia.pucpr.br
Escopo: sub
Filtro: (objectclass=Person)
• Procura as pessoas em sua_Unidade
–
–
–
–
Servidor: ldap://icaro.ppgia.pucpr.br/
Search Root: ou=sua_Unidade,o=ppgia.pucpr.br
Escopo: sub
Filtro: (objectclass=Person)
• Procura as pessoas em Curitiba
–
–
–
–
Servidor: ldap://icaro.ppgia.pucpr.br/
Search Root: ou=Curitiba,ou=sua_Unidade,o=ppgia.pucpr.br
Escopo: sub
Filtro: (objectclass=Person)
2006, Edgard Jamhour
Procura por Atributos
• Atributos disponíveis para Person:
– telephoneNumber, seeAlso, userPassword,
description
• Atributos para organizationalperson:
– title, street, ou, postalAddress, postalCode
• Exemplo de Consulta:
– Filtro: title=Professor)
– Filtro: (title=Prof*)
2006, Edgard Jamhour
Filtros LDAP
• a) Especifica objetos do tipo carro
– (objectClass=carro)
• b) especifica carros da marca Golf ou Vectra
– ( &(objectClass=carro)
( |(marca=Golf)(marca=Audi)))
• c) especifica carros da marca Golf ou Vectra mas não
importados.
– ( &(objectClass=carro)
(|(marca=Golf)(marca=Audi))
(!(origem=importado)))
2006, Edgard Jamhour
Servidores LDAP Stand Alone e
Referral
• Quando um servidor LDAP não conhece a resposta a
uma pergunta do cliente, e pelo indicar um outro servidor
LDAP (chamado referral) ou uma lista de servidores
LDAP para o cliente consultar.
LDAP
LDAP
Servidor LDAP
CLIENTE
LDAP
Servidor LDAP
LDAP
Servidor LDAP
2006, Edgard Jamhour
Diretório Distribuído: Smart Referral
icaro.ppgia.pucpr.br
o=ppgia.pucpr.br
hal2002.ppgia.pucpr.br
ou=Exemplo
o=ppgia.pucpr.br
ou=São Paulo
ou=Curitiba
ou=Exemplo
ou=Persons
ref=xxxx
ou=Curitiba
cn=George Bush
Objectclass =
referral
ou=Persons
cn=Bill Gates
2006, Edgard Jamhour
Sintaxe
• O objeto referral deve ter um link para o servidor
para o qual se deseja redirecionar as consultas:
• No exemplo anterior:
– No servidor icaro deve ser criado
• A) Um objeto vazio do tipo unidade organizacional:
– ou=Curitiba
– Este objeto deve ser derivado de:
» organizatinalunit
» refferal
• B) O atributo refferal permite redirecionar as
consultas:
– ref = ldap://hal2002.pucpr.br/ou=Curitiba,ou=Exemplo,
o=ppgia.pucpr.br
2006, Edgard Jamhour
Exemplo
• O arquivo LDIF que cria um entrada de referral é ilustrado
abaixo:
–
–
–
–
–
–
–
–
–
–
dn: uid=ACalsavara, ou=people, dc=pucpr,dc=br
objectclass: top
objectclass: person
objectclass: organizationalperson
objectclass: inetOrgPerson
objectclass: referral
cn: Alcides Calsavara
sn: Calsavara
uid: ACalsavara
ref: ldap://10.32.1.253/cn=Alcides%20Calsavara,ou=people,
l=europe,dc=pucpr,dc=br
2006, Edgard Jamhour
Diretório Distribuído: Smart Referral
hal2002.ppgia.pucpr.br
o=ppgia.pucpr.br
ou=Exemplo
icaro.ppgia.pucpr.br
o=ppgia.pucpr.br
ou=Curitiba
ou=São Paulo
ou=Exemplo
ou=Persons
cn=George Bush
ref=xxxx
Objectclass =
referral
ou=São Paulo
ou=Curitiba
ou=Persons
ref=yyyy
cn=Bill Gates
2006, Edgard Jamhour