Edgard Jamhour Mauro Fonseca Carlos Maziero

Apresentação em tema: "Edgard Jamhour Mauro Fonseca Carlos Maziero"— Transcrição da apresentação:

1 Edgard Jamhour Mauro Fonseca Carlos Maziero
Gerência de Redes (SNMP) Serviços de Diretório (LDAP) Policy Based Networking (PBNM) Edgard Jamhour Mauro Fonseca Carlos Maziero

2 Definições básicas Gerência de redes: Gerência integrada:
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.

3 Áreas funcionais de gerência
Configuração Falha Desempenho Segurança Contabilidade

4 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.

5 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

6 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

7 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

8 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.

9 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

10 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

11 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

12 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.

13 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

14 Uma arquitetura de gerência
Management entity requests Managed objects responses notifications events operations Management application Management protocol Management agent MIB Management database

15 Ferramentas de gerência
Arquitetura de gerência OSI Gerência usando SNMP Gerência via Web Gerência com objetos CORBA

16 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

17 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

18 MIB-II - Estrutura geral
iso(1) org(3) dod(6) Object ID is internet(1) directory(1) mgmt(2) mib-2(1) udpInDatagrams udpNoPorts udpInErrors udpOutDatagrams system(1) interfaces(1) tcp(6) udp(7)

19 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

20 Extensões de SNMP RMON - Remote Network Monitoring RMON-2 SNMP-V2
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

21 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

22 Specific Management Functional Areas System Management Functions
Arquitetura OSI security configuration fault performance accounting Specific Management Functional Areas relationship Event-report state alarm object System Management Functions log security access accounting workload test summarization action event-report set create get CMISE Services delete CMIP Managed node

23 O que é SNMP ? Padrão para gerência na Internet Composto de:
simples de implementar amplamente difundido Composto de: protocolo para trocas de mensagens padrões para estruturar a informação Evolutivo: SNMPv2, SNMPv3, RMON, ...

24 Estrutura geral do sistema
Protocol Request SNMP manager MIB SNMP agent MIB Response Management information

25 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

26 Árvore MIB Object IDentifier (OID) - Exemple .1.3.6.1.2.1.1 Notas:
- iso(1) org(3) dod(6) internet(1) mgmt(2) mib-2(1) system(1) Notas: ~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. iso(1) 1 org(3) 3 dod(6) 6 internet(1) 1 private(4) directory(1) 4 1 mgmt(2) experimental(3) 2 3 mib-2(1) 1 tcp(6) system(1) 6 1 interfaces(2) ip(4) 2 4

27 A MIB versão 2 1.3.6.1. iso.org.dod.internet objeto 1.3.6.1.2.1.1
1. system 2. interfaces 3. address translation 4. ip 5. icmp 6. tcp 7. udp 8. egp 9. oim 10. transmission 11. snmp 1. directory 2. mgmt 3. experimental 4. private 5. security 6. snmpV2 7. mail 1. mib-2 1. enterprises

28 Objeto MIB Definido em ANS.1 Standard MIB Object:
OBJECT-TYPE Descreve o objeto MIB. Object IDentifier (OID). SYNTAX Define o tipo de informação representada pelo objeto MIB. ACCESS READ-ONLY, READ-WRITE. STATUS 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}

29 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

30 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)

31 Sub-tipagem INTEGER INTEGER (-127..128) INTEGER (1..10)

32 Enumeração usando inteiros
Boolean ::= INTEGER { true (1), false (2)} Alarm-level ::= INTEGER { critical (1), major (2), minor (3), warning (4), informational (10) }

33 Campo ACCESS Define a acessibilidade do objeto
Valores possíveis em SNMPv1: read-only read-write write-only not-accessible

34 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

35 Valores escalares e vetoriais
uma só instância por variável OID deve ser completado por “.0” Exemplo: ....mib-2.ip.ipForwarding: 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

36 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}

37 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}

38 Uma conexão TCP na tabela (2)
TcpConnEntry ::= SEQUENCE { tcpConnState INTEGER, tcpConnLocalAddress IpAddress, tcpConnLocalPort INTEGER ( ), tcpConnRemAddress IpAddress, tcpConnRemPort INTEGER ( ), }

39 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

40 management application
A arquitetura SNMP Managed system Management system resources management application management actions MIB objects SNMP messages SNMP manager SNMP agent UDP UDP IP IP link link

41 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

42 Histórico do SNMP 1989: SNMP v1 1992: Remote Monitoring - RMON
1996: SNMP v2c (Community Security) 1996: MIB RMON v2 1998: SNMP v3 (User Security Model)

43 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

44 Exemplo de uso manager SNMP Agent MIB Get (Nome) Response (‘João’)
pessoa.nome = João pessoa.idade = 35 pessoa.sexo = masc Response (‘João’) GetNext (Nome) Response (35) Set (sexo, fem) Response (Erro)

45 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

46 Limitações de SNMP Falta de segurança Ineficiência
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

47 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”

48 Exemplo de comunidades
admin public ensino network

49 Uma mensagem SNMP Conteúdo codificado via BER
Geralmente limitada a < 484 bytes msg length 2 bytes preâmbulo protocol version 1 byte community string até 128 bytes PDU header PDU SNMP PDU body

50 Estrutura das PDUs SNMP
Get & Set Trap msg length protocol version community string PDU type PDU length Request ID Error Status Error Index Variable bindings msg length protocol version community string PDU type PDU length Enterprises OID Agent IP address Standard trap type Variable bindings Specific trap type Time stamp preamble SNMP header SNMP body

51 Preâmbulo e cabeçalho Versão Tipo de PDU Request ID
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

52 Códigos de erro Error Status: Error index:
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.

53 Conteúdo das mensagens
varbind length variable OID variable type variable value ... var list size 41 23 2 14 65 250

54 A operação GetNext Busca próximo elemento na MIB Serve para:
Usa ordem lexicográfica ... Serve para: passear na MIB (descoberta da estrutura) buscar dados em tabelas

55 Exemplo de passeio na MIB
snmpgetnext -v1 localhost -c public system SNMPv2-MIB::sysDescr.0 = STRING: Linux espec.ppgia.pucpr.br _FC4smp #1 SMP Tue Jul 11 22:59:20 EDT 2006 x86_64 snmpget -v1 localhost -c public -O n system.sysDescr.0 = STRING: Linux espec.ppgia.pucpr.br _FC4smp #1 SMP Tue Jul 11 22:59:20 EDT 2006 x86_64 snmpgetnext -v1 localhost -c public -O n = OID: snmpgetnext -v1 localhost -c public -O n = Timeticks: (523160) 1:27:11.60 snmpget -v1 localhost -c public SNMPv2-MIB::sysUpTime.0 = Timeticks: (527855) 1:27:58.55

56 Percurso seqüencial myVar1.1 myVar2.1 myVar3.1 myVar1.2 myVar2.2
coluna 1 coluna 2 coluna 3 1 5 9 linha 1 myVar1.1 myVar2.1 myVar3.1 2 6 10 linha 2 myVar1.2 myVar2.2 myVar3.2 3 7 11 linha 3 myVar1.3 myVar2.3 myVar3.3 4 8 12 linha 4 myVar1.4 myVar2.4 myVar3.4 13

57 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”

58 Traps genéricos coldStart: warmStart: linkDown:
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

59 Traps genéricos (2) linkUp: authenticationFailure: egpNeighborLoss:
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

60 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.

61 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 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.

62 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

63 Modelo Funcional X500 (Banco de Dados Distribuído)

64 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.

65 Políticas IPsec para o IP de destino 200.10.0.1?
Serviço de Diretório X500 prenome=edgard? ? SERVIÇO DE DIRETÓRIO Login Bypass. Login+senha Políticas IPsec para o IP de destino ? senha OK

66 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: Edgard sobrenome: Jamhour Atributos Objeto Atributo 1 (tipo, valores) Atributo 2 (tipo, valores) .... Atributo n (tipo,valores) Entrada

67 Objetos do X500

68 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

69 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.

70 DN: NC=aeinstein, UO=ppgia, O=pucpr, P=br
Esquema de Nomes X500 DN: Distiguished Name DN: NC=aeinstein, UO=ppgia, O=pucpr, P=br

71 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

72 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 Protocolo RFC Modelo de Nomes RFC API RFC formato URL RFC conjunto de caracteres internacionais UTF-8

73 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.

74 A arquitetura LDAP segue o padrão cliente-servidor.
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.

75 Servidor LDAP como Ponte para X500

76 Stand-alone LDAP

77 Sintaxe de uma Consulta LDAP
ldap[s]://<host>:<porta>/<base_dn>?<atributos>?<escopo>?<filtro> ldap://ppgia.pucpr.br/o=pucpr,c=br? ?sub?(sn=Joa*) c=br c=br c=br o=pucpr o=pucpr o=pucpr o=ufpr o=ufpr o=ufpr escopo sub escopo one escopo base

78 Directory Enable Networks
Criação: Criado pelo DMTF(Distribute Engineering Task Force) 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.

79 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)

80 CIM: Common Information Model

81 CIM: Common Information Model

82 Directory Enable Networks
ESQUEMA e INTERFACES Futuras Aplicações que usam Diretório Aplicações de Gerenciamento Existentes Futuras Aplicações de Gerenciamento Protocolos de Gerenciamento Existentes DIRETÓRIO hubs switches roteadores computadores

83 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.

84 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

85 O que é o PCIM? PCIM é um modelo genérico: Princípios:
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.

86 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.

87 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. Condição 1 … Condição N Política Regra 1 Ação … Açaõ N Regra 2 … Regra N

88 Principais Classes do PCIM

89 PCIMe

90 Condições

91 Mapeamento de Políticas no Dispositivo

92 QPIM: Policy Quality of Service Information Model

93 Policy Based Networking
PDP: Policy Decision Point PEP: Policy Enforcement Point Policy Management Tool request PDP aplicativo PEP COPS decision LDAP Policy request Repository dispositivo PEP COPS decision Base de Estados

94 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)

95 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 PEP PDP Request Open Client Type Connection Decision Client Connection Accept Report

96 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.

97 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 PEP PDP COPS LPDP

98 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”.

99 Mensagens COPS version flags op code Client Type 1 byte 2 bytes
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) version flags op code Client Type 1 byte 2 bytes Message Length

100 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)

101 Objetos COPS 2 byte 1 byte 1 byte Length C-Num C-Type Object Contents
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 1 byte Length C-Num C-Type Object Contents

102 Escalabilidade Repositório de Políticas PDP COPS PEP
COPS is an emerging IETF protocol. Quick background, COPS does Policy Control of IP. Today, one of the most pressing issues with the traffic convergence at the IP layer is providing adequate QoS. IP is best effort delivery, but certain applications such as VoIP require QoS to solve the voice clipping that occurs in a congested IP best effort environment. The IETF Policy Framework is a client service model, where the Policy Decision Point, PDP controls the policy and the Policy Enforcement Point PEP, which is generally a router or switching element enforces the policy. Our sister organization, vBNS did early research in the area of providing QoS for IP traffic. They have a Reserved Bandwidth Service which uses COPS - for controlling RSVP signals. vBNS decided that the ENSD MSCP and our work with policy control of ATM SVC’s was a good fit for their Reserved Bandwidth Service and they had us develop a COPS-RSVP PDP which is called the RBS.

103 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.

104 Modelo Outsourcing Cada evento no PEP dispara uma consulta ao PDP.

105 Modelo Provisioning O PEP tem autonomia para tomar decisões localmente.

106 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

107 Tipos de Classes PIB 1) Notify: PEP  PDP 2) Install: PDP  PEP
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,

108 Exemplo: Diffserv PIB O IETF definiu algumas PIBs padronizadas, como para os casos do IPsec e do Diffserv.

109 Exemplo: Diffserv PIB B B 1

110 Representação OID

111 Exemplo: CIM X QPIM X PIB

112 Princípios do Modelo Provisioning

113 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.

114 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.

115 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.

116 ANEXOS A RMON

117 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 = ?

118 Monitores de rede Ouvem a rede continuamente Podem ouvir várias redes
Não interferem nas redes monitoradas monitor

119 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

120 Monitorando múltiplas redes
Um monitor para cada sub-rede Monitores devem ser acessíveis pelo gerente monitores gerente router

121 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

122 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

123 Objetivos de RMON Operação off-line Monitoração pró-ativa
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

124 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

125 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”

126 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

127 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

128 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

129 Indexação de tabelas xyzControlTable xyzDataTable

130 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

131 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.

132 A MIB RMON rmon (16) mib-2 statistics (1) history (2) alarm (3)
host (4) hostTopN (5) matrix (6) filter (7) capture (8) event (9) tokenRing (10)

133 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

134 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

135 Outros grupos hosts hostTopN matrix tokenRing
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

136 Alarmes Alarmes são registrados na MIB Cada entrada da tabela contém:
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

137 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 !

138 O ciclo de histerese disparo do alarme inferior
disparo do alarme superior estado do alarme alarme superior alarme inferior valor monitorado

139 Geração de alarmes Alarme é gerado quando:
valor maior que o limiar superior (risingThreshold) valor menor que o limiar inferior (fallingThreshold) valor lim sup lim inf tempo disparos

140 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

141 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

142 RMON v2 RMON v1: RMON v2: Outras inovações 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

143 ANEXOS B SNMPv2

144 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

145 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

146 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

147 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)

148 Cláusula STATUS Novos status: Desaparecem: current deprecated obsolete
mandatory optional

149 Tabelas Duas categorias de tabelas: Criação/deleção de linhas
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

150 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

151 PDUs SNMPv2 GetRequest, GetNextRequest SetRequest GetBulkRequest
similar à de SNMPv1 resposta não é mais atômica SetRequest idem GetBulkRequest busca de grandes blocos de dados equivale a um GetNextRequest múltiplo

152 PDUs SNMPv2 InformRequest ReportPDU 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)

153 ANEXOS C LDAP

154 Raizes de Árvore no Servidor
Raiz do diretório ou=Groups o=ppgia.pucpr.br Servidor LDAP ou=People 389 o=NetscapeRoot

155 Exemplo o=ppgia.pucpr.br Objectclass = organization ou=Exemplo
Objectclass=organizationalUnit ou=Funcionarios ou=Grupos Objectclass =organizationalUnit cn=ejamhour ou=analistas Objectclass =groupOfNames cn=acalsavara Objectclass =inetOrgPerson

156 Parâmetros do LDAP <host> <porta> <base_dn>
Nome (ou endereço IP) do servidor LDAP (por exemplo, ldap.ppgia.pucpr.br ou ). <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.

157 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? ?sub?(cn=Alc*) Solicita todos os s da PUCPR pertencentes a usuários que tem o nome começando por Alc.

158 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 Search Root: ou=sua_Unidade,o=ppgia.pucpr.br Procura as pessoas em Curitiba Search Root: ou=Curitiba,ou=sua_Unidade,o=ppgia.pucpr.br

159 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*)

160 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)))

161 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

162 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

163 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

164 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:// /cn=Alcides%20Calsavara,ou=people, l=europe,dc=pucpr,dc=br

165 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 ref=xxxx ou=São Paulo ou=Curitiba cn=George Bush Objectclass = referral ou=Persons ref=yyyy cn=Bill Gates