2006, edgard jamhour gerência de redes (snmp) serviços de diretório (ldap) policy based...

2006, Edgard Jamhour

Gerência de Redes (SNMP)

Serviços de Diretório (LDAP)

Policy Based Networking (PBNM)

Edgard JamhourMauro FonsecaCarlos Maziero

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.

Áreas funcionais de gerência

• Configuração

• Falha

• Desempenho

• Segurança

• Contabilidade

Gerência de configuração• Inventory: conjunto de dispositivos na rede, do

software e hardware presente nesses dispositivose sua informação estática.

• Configuration: mapa indicando as conexões entre componentes do inventário.

• Provisioning: parâmetros operacionais modificáveisque especificam o comportamento de cada dispositivo.

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

Gerência de desempenho

• Assegurar uma capacidade de tráfego mínima na rede.

• Assegurar que os dispositivos podemtratar 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

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

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.

Modelo de gerência

• Baseado em uma estrutura cliente/servidor

– agente: age como servidor de informações de gerência

– gerente: consulta os agentespara obter informações

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

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

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 dadoscoletados para delinear o problema.

• Ação: controle sobre os recursos gerenciadospara corrigir o problema.

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

Uma arquitetura de gerência

Management protocol Managementagent

Managed objects

Management entity

eventsoperations

Managementdatabase

requests

responses

notifications

Managementapplication

Ferramentas de gerência

• Arquitetura de gerência OSI

• Gerência usando SNMP

• Gerência via Web

• Gerência com objetos CORBA

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

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

MIB-II - Estrutura geral

iso(1)

org(3)

dod(6)

internet(1)

directory(1)

mgmt(2)

mib-2(1)

system(1)

interfaces(1)

tcp(6)

udp(7)

Object ID is 1.3.6.1.2.1.7

udpInDatagramsudpNoPortsudpInErrorsudpOutDatagrams

• 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

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

Estrutura de gerência OSIArquitetura 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

Arquitetura OSI

security configurationfault performanceaccounting

Specific Management Functional Areas

relationship Event-reportstate alarmobject

System Management Functions

security

access accountingworkload test summarization

action event-reportset createget

CMISE Services

delete

Managed node

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

Estrutura geral do sistema

Request

Response

Protocol

Managementinformation

SNMP agent

SNMP manager

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

Árvore MIB

• Object IDentifier (OID)

- Exemple .1.3.6.1.2.1.1

- iso(1) org(3) dod(6) internet(1) mgmt(2)

mib-2(1) system(1)

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.

iso(1)

org(3)

dod(6)

internet(1)

directory(1)

mgmt(2) experimental(3)

private(4)

mib-2(1)

system(1)

interfaces(2) ip(4)

tcp(6)

A MIB versão 2

1.3.6.1. iso.org.dod.internet

1. directory2. mgmt3. experimental4. private5. security6. snmpV27. mail

1. enterprises

1. system2. interfaces3. address translation4. ip5. icmp6. tcp7. udp8. egp9. oim10. transmission11. snmp

1. mib-2

objeto1.3.6.1.2.1.1

Objeto MIB

• Definido em ANS.1

- 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-TYPESYNTAX Time-Ticks

ACCESS read-onlySTATUS mandatoryDESCRIPTION

“Time since the network management portion of the system was last re-initialised.

::= {system 3}

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

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)

Sub-tipagem

INTEGERINTEGER (-127..128)INTEGER (1..10)INTEGER (0 | 2 | 4 | 6 | 8)INTEGER (0..2 | 20)INTEGER (-127..-1 | 1..128)INTEGER (1)

Enumeração usando inteirosBoolean ::= INTEGER { true (1), false (2)}

Alarm-level ::= INTEGER { critical (1), major (2), minor (3), warning (4), informational (10) }

Campo ACCESS

• Define a acessibilidade do objeto

• Valores possíveis em SNMPv1:

– read-only– read-write– write-only– not-accessible

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

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

Tabela de conexões TCPtcpConnTable OBJECT-TYPE SYNTAX SEQUENCE OF TcpConnEntry ACCESS not-accessible STATUS mandatory DESCRIPTION “A table containing TCP connection-specific information.” ::= {tcp 13}

Uma conexão TCP na tabelatcpConnEntry OBJECT-TYPE SYNTAX TcpConnEntry ACCESS not-accessible STATUS mandatory DESCRIPTION “Information about a particular

current TCP connection. ...” INDEX {

tcpConnLocalAddress, tcpConnLocalPort, tcpConnRemAddress, tcpConnRemPort

} ::= {tcpConnTable 1}

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

• 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

A arquitetura SNMP

management application

SNMP managerUDP

IPlink

SNMP agentUDP

IPlink

MIB objects

SNMP messages

management actions

resourcesManagement

system

Managed system

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

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)

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

Exemplo de uso

Response (‘João’)SNMP Agent MIB

pessoa.nome = Joãopessoa.idade = 35pessoa.sexo = masc

Get (Nome)

Response (35)

GetNext (Nome)

Response (Erro)

Set (sexo, fem)

Restrições das operações

• Permitem somente inspeçãoe/ou alteração de variáveis

• A estrutura da MIB não podeser alterada pelas operações

• Somente podem ser acessadosvalores escalares em cada operação

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

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 implementauma ou mais comunidades

• Comunidade default: “public”

Exemplo de comunidades

public

ensino

network

Uma mensagem SNMP

• Conteúdo codificado via BER• Geralmente limitada a < 484 bytes

msg length

protocol version

community string

PDU header

PDUbody

2 bytes

1 byte

até 128 bytes

preâmbulo

PDU SNMP

Estrutura das PDUs SNMP

preamble

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

Variable bindings

Get & Set Trap

SNMPheader

SNMPbody

Preâmbulo e cabeçalho

• Versão0: SNMPv1, 1: SNMPv2, ...

• Tipo de PDU0: getRequest1: getNextRequest2: getResponse3: setRequest4: trap

• Request ID• valor numérico usado para casar pedidos e respostas

Códigos de erro

• Error Status:0: noError: sucesso na operação1: tooBig: resposta muito grande para enviar2: noSuchName: OID não suportado pelo agente3: badValue: valor incorreto para operação set4: readOnly: tentativa de escrita inválida5: genErr: erro não relacionado ao protocolo

• Error index:• indica qual variável listada na PDU causou o erro.

Conteúdo das mensagens

varbind lengthvariable OIDvariable typevariable value

var list size 41

231.3.6.1.2.1.1.2.021.3.6.1.4.1.311.1.1.3.2

141.3.6.1.2.1.7.4.065250

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

Exemplo de passeio na MIB• snmpgetnext -v1 localhost -c public system

– SNMPv2-MIB::sysDescr.0 = STRING: Linux espec.ppgia.pucpr.br 2.6.17-1.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.17-

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

Percurso seqüencial

myVar1.1

myVar1.2

myVar1.3

myVar1.4

myVar2.1

myVar2.2

myVar2.3

myVar2.4

myVar3.1

myVar3.2

myVar3.3

myVar3.4

coluna 1 coluna 2 coluna 3

linha 1

linha 2

linha 3

linha 4

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”

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

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

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.

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.

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

Modelo Funcional X500(Banco de Dados Distribuído)

DAPDSP

DSP DSP

DiretórioX500

DUA(Directory User Agent)

DSA(Directory System Agent)

DAP(Directory Access Protocol)

DSP(Directory ServiceProtocol).

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.

Serviço de Diretório X500

SERVIÇO DE DIRETÓRIO

prenome=edgard?email?

Login+senha

Políticas IPsec para o IP de destino

200.10.0.1?

email=jamhour@ppgia.pucpr.br

Bypass.

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: Edgardsobrenome: Jamhouremail: jamhour@ccet.pucpr.br

Atributos

Entrada

ObjetoAtributo 1 (tipo, valores)Atributo 2 (tipo, valores)....Atributo n (tipo,valores)

Objetos do X500

atributo 1: tipoatributo 2: tipoatributo 3: tipo…atributo N: tipo

estrutura genéricade uma classe

nome: stringsobrenome: stringnc: stringpassord: stringemail: stringnascimento: datauid: string

objectclass: Pessoanome: Albertsobrenome: Einsteinnc: aeinsteinpassord: 1B5A324AB3email: aeinstein@pucpr.brnascimento: 01/08/1908

objectclass: Pessoanome: Issacsobrenome: Newtonnc: inewtonpassord: 2A2A324ZC3email: inewton@pucpr.brnascimento: 03/09/1803

classe Pessoa

objetos

RDN: Relative Distiguished Name

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

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.

Objetos que não contém outros objetos são ditos leaf.

Uma rede de computadores ou domínio pode ser representado como uma sub-árvore no diretório.

Esquema de Nomes X500RDN=DN =

Raiz()

País(P)

Organização(O)

Unidade Organizacional(UO)

Pessoa(NC)

RDN: P=br

Classe(RDN)

RDN: P=fr

RDN: O=pucprRDN: O=cefetpr

RDN: UO=ppgia

RDN: UO=ccet

RDN: NC=inewton RDN: NC=aeinstein

DN: P=br

DN: O=pucpr, P=br

RDN: UO=ppgia, O=pucpr, P=br

DN: Distiguished NameDN: Distiguished Name

DN: NC=aeinstein, UO=ppgia, O=pucpr, P=brDN: NC=aeinstein, UO=ppgia, O=pucpr, P=br

• 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

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

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

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.

Servidor LDAP como Ponte para X500

clienteLDAP

servidorLDAP

servidorX500

LDAPDAP

Stand-alone LDAP

clienteLDAP

servidorLDAP

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

o=ufpr

o=pucpr

c=br c=brc=br

escopo sub escopo one escopo base

o=ufpr

o=pucpro=ufpr

o=pucpr

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.

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)

CIM: Common Information Model

Core model

Application System Network Physical Device

Network Foundation

QoS model

IPsec model

BGP model

Bridge model

VLAN model

CIM: Common Information Model X500_Top

ManagedSystemElement (CIM)

Configuration (CIM)

Application (CIM)

Protocol (CIM)

Service (CIM)

Group (X500)

Person (X500)

Organization (X500)

Profile (DEN)

Policy (DEN)

Directory Enable Networks

DIRETÓRIODIRETÓRIO

DIRECTORY ENABLE

NETWORKS

ESQUEMAe

INTERFACES

Futuras Aplicações

que usam Diretório

Futuras Aplicações

de Gerenciamento

Aplicações de Gerenciamento

Existentes

Protocolos de Gerenciamento Existentes

hubs switches roteadores computadores

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.

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

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.

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.

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íticaRegra 1

Regra 2

Regra N…

Condição 1 Condição N…

Ação Açaõ N…

Principais Classes do PCIM

Condições

Mapeamento de Políticas no Dispositivo

QPIM: Policy Quality of Service Information Model

Policy Based Networking

• PDP: Policy Decision Point• PEP: Policy Enforcement Point

aplicativo

dispositivo

PEPPEP

PDPPDP

request

decision

LDAPrequest

decision

PolicyRepository

Base de Estados

Policy ManagementTool

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

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

Request

Decision

Report

PEP PDP

Open Client TypeConnection

Client Connection Accept

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.

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

PDPCOPS

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

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)

version flags op code Client Type

1 byte 1 byte 2 bytes

Message Length

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)

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

Length C-Num C-Type

2 byte 1 byte

Object Contents

1 byte

• C-Type– Depende de C-Num– Indica o subtipo ou versão da

informação transportada pelo objeto.

Escalabilidade

Repositório de Políticas

PEPPEP PEP

COPS COPSPEP

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.

Modelo Outsourcing

• Cada evento no PEP dispara uma consulta ao PDP.

Modelo Provisioning

• O PEP tem autonomia para tomar decisões localmente.

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 ClassesPRI - Provisioning Instances

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,

Exemplo: Diffserv PIB

• O IETF definiu algumas PIBs padronizadas, como para os casos do IPsec e do Diffserv.

Exemplo: Diffserv PIB

Representação OID

Exemplo: CIM X QPIM X PIB

Princípios do Modelo Provisioning

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.

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.

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.

ANEXOS A

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 kbpstráfego = 55 kbps

tráfego = ?

Monitores de rede

• Ouvem a rede continuamente• Podem ouvir várias redes• Não interferem nas redes monitoradas

monitor

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

Monitorando múltiplas redes

• Um monitor para cada sub-rede• Monitores devem ser acessíveis pelo gerente

gerente

monitores

router

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

• 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

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

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

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”

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

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

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

Indexação de tabelas

xyzControlIndex xyzControlParameter xyzControlOwner xyzControlStatus

1 5 Monitor Valid(1)

2 26 Manager alpha Valid(1)

3 19 Manager gamma Valid(1)

XyzDataControlIndex XyzDataIndex xyzDataValue1 1 462 1 962 2 852 3 772 4 272 5 923 1 863 2 26

xyzControlTable

xyzDataTable

Inserção de linhas

• Através do método SNMP set:

set [index, (tipo, valor), (tipo, valor), ...]

• erro badValue em caso de dado inválidoou impossibilidade de criação

• tratamento de conflitos em acessos simultâneos torna-se necessário

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.

A MIB RMON

rmon (16)

host (4)

statistics (1)

history (2)

alarm (3)

hostTopN (5)

matrix (6)

filter (7)

capture (8)

event (9)

tokenRing (10)

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

Grupo history

• Amostragens do tráfego nas interfacesao longo do tempo de operação

• Cada linha da tabela de controledefine um conjunto de amostras

• Cada linha da tabela de dadoscorresponde a uma amostra

• Defaults:• cada amostra dura 1800 segundos• as 50 últimas amostras são mantidas

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

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

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 !

O ciclo de histerese

estado doalarme

alarmesuperior

alarmeinferior

valor monitorado

disparo doalarme superior

disparo doalarme inferior

Geração de alarmes

• Alarme é gerado quando:• valor maior que o limiar superior

(risingThreshold)• valor menor que o limiar inferior

(fallingThreshold)

lim sup

lim inf

disparos

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

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

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

ANEXOS B

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

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

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

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)

Cláusula STATUS

• Novos status:– current– deprecated– obsolete

• Desaparecem:– mandatory– optional

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

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

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

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)

ANEXOS C

Raizes de Árvore no Servidor

o=ppgia.pucpr.br

ServidorServidor LDAPLDAP

389389

ou=Groups

ou=People

o=NetscapeRoot

Raiz do diretório

Exemplo

o=ppgia.pucpr.br

ou=Funcionarios

cn=acalsavara

ou=Grupos

cn=ejamhour ou=analistas

Objectclass = organization

Objectclass=organizationalUnit

Objectclass =organizationalUnit

Objectclass =groupOfNames

ou=Exemplo

Objectclass =inetOrgPerson

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.

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.

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)

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

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

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.

CLIENTE LDAP

Servidor LDAP

Diretório Distribuído: Smart Referral

o=ppgia.pucpr.br

ou=Exemplo

ou=Curitiba

cn=George Bush

ou=São Paulo

cn=Bill Gates

ou=Persons

icaro.ppgia.pucpr.br

hal2002.ppgia.pucpr.br

ou=Curitiba

ref=xxxx

o=ppgia.pucpr.br

ou=Exemplo

Objectclass = referral

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

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

Diretório Distribuído: Smart Referral

o=ppgia.pucpr.br

ou=Exemplo

ou=Curitiba

cn=George Bushou=São Paulo

cn=Bill Gates

ou=Persons

icaro.ppgia.pucpr.br

hal2002.ppgia.pucpr.br

ou=São Paulo

ref=xxxx

o=ppgia.pucpr.br

ou=Exemplo

Objectclass = referral

ou=Curitiba

ref=yyyy

2006, edgard jamhour gerência de redes (snmp) serviços de diretório (ldap) policy based...

Documents

2001, edgard jamhour professor edgard jamhour criptografia,...

comunicação sem fio wlan (802.11) edgard jamhour

redes tcp/ip csma/cd prof. edgard jamhour email:...

2010, edgard jamhour ipv6 (parte 2: mecanismos de...

2005, edgard jamhour mobile ip edgard jamhour puc-pr

2008, edgard jamhour ipv6 (parte 1: protocolo e serviços...

mecanismos de qos em linux tc – traffic control edgard...

qualidade de serviço em switches ethernet edgard jamhour

2002, edgard jamhour firewalls edgard jamhour. 2002, edgard...

2006, edgard jamhour professor edgard jamhour vpn

2002, edgard jamhour parte 1 – protocolo e serviços...

sistemas autônomos e roteamento na internet edgard jamhour

2001, edgard jamhour professor edgard jamhour vpn – redes...

2008, edgard jamhour ipv6 internet protocol – versão 6...

2007, edgard jamhour ipv6 (parte 1: protocolo e serviços...

2013 edgard jamhour professor edgard jamhour criptografia...

2001, edgard jamhour frame-relay e atm edgard jamhour

mestrado tópicos anvançados em redes de computadores redes...

edgard jamhour modelo em camadas arquitetura tcp/ip/ethernet

2004, edgard jamhour professor edgard jamhour segurança em...