A apresentação está carregando. Por favor, espere

A apresentação está carregando. Por favor, espere

QUESTÕES PRÁTICAS EM MEDIÇÕES DA INTERNET Capítulo 4 Crovella, M, Krishnamurthy, B. Internet Measurement: infrastructure, traffic & applications. John.

Apresentações semelhantes


Apresentação em tema: "QUESTÕES PRÁTICAS EM MEDIÇÕES DA INTERNET Capítulo 4 Crovella, M, Krishnamurthy, B. Internet Measurement: infrastructure, traffic & applications. John."— Transcrição da apresentação:

1 QUESTÕES PRÁTICAS EM MEDIÇÕES DA INTERNET Capítulo 4 Crovella, M, Krishnamurthy, B. Internet Measurement: infrastructure, traffic & applications. John Wiley & Sons,

2 Roteiro 2 Onde podem ser realizadas as medições? Papel do Tempo Papel de Diretórios da Internet e Bases de Dados Medições nas Diversas Camadas de Protocolos

3 Onde Podem ser Realizadas as Medições? 3

4 Locais de Medições em um ISP 4

5 Locais das Medições: LAN Medições em LANs são normalmente efetuadas em redes experimentais (testbeds) e normalmente não têm interesse em medições da Internet. No entanto, medições de latência local e relacionadas a hardware são tipicamente realizadas em LANs. Nelas é mais fácil ter controle completo sobre o que está sendo medido. São realizadas também medições relacionadas às camadas mais altas. Há interesse crescente sobretudo em medições em redes sem fio. 5

6 Locais das Medições: Rede Troncal Normalmente são realizadas medições mesmo que os dados obtidos não sejam disponibilizados. Objetivo principal: planejamento de capacidade Técnicas: SNMP (Mais comum): perda de pacotes, atraso e vazão. Rastreamento de pacotes (com marcas de tempo de alta precisão) 6

7 Rede Troncal: Roteiro 7 Alocação de Largura de Banda Medições dentro da Rede Identificação de Ataques Disponibilidade (Resiliência)

8 Rede Troncal: Alocação de Largura de Banda 8 Alocação de largura de banda nos links internos (provisionamento) é uma das atividades principais dos ISPs. Aplicações diferentes têm graus variados de sensibilidade à latência, de modo que a utilização dos links deve ser ajustada de modo a satisfazer requisitos como atraso de modo a limitar o atraso fim-a-fim. A composição real do tráfego deve ser medida dentro da rede para se fazer o provisionamento adequado. Mesmo que o ISP use sobreprovisionamento o grau adequado deve ser calculado.

9 Rede Troncal: Medições dentro da Rede 9 Os ISPs podem usar informações de longo prazo da utilização dos links para identificar PoPs que necessitam de uma maior capacidade. Diversos monitores de alta velocidade foram construídos para monitorar os enlaces. Medições dentro da rede troncal provê uma visão em profundidade de todo o tráfego associado a um conjunto de usuários. Verificação dos SLAs assinados pelo ISP. Requer medição do atraso dos pacotes.

10 Rede Troncal: Medições dentro da Rede 10 Dado que o tráfego sensível a atrasos pode ocorrer entre qualquer par origem-destino, deve ser monitorado o tráfego entre todos os pares. A modelagem baseada em medições tem auxiliado no provisionamento adequado de largura de banda.

11 Rede Troncal: Medições dentro da Rede 11 Podem ainda ser monitorados os diversos links dentro da rede junto com informações de roteamento para se ter uma visão completa. No nível macro, mudanças de tráfego podem ser observadas através de amostras de medições dentro da rede. Diversas matrizes de tráfego são criadas para capturar o tráfego entre prefixos, cidades ou usuários arbitrários. Num nível micro, as medições na rede permitem ajustar os pesos dos protocolos de roteamento internos (IGP) para balancear o tráfego entre diversos links Necessitam de grande capacidade de armazenamento e devem lidar com uma rede que está mudando constantemente.

12 Rede Troncal: Idenficação de ataques 12 A monitoração da rede buscando crescimentos repentinos podem ajudar a identificar potenciais ataques. As técnicas de detecção de anomalias podem ser reforçadas observando mudanças significativas dos padrões de tráfego entre pontos de presença. Ex.: observação periódica da utilização dos links.

13 Rede Troncal: Disponibilidade (Resiliência) 13 Podem ocorrer também falhas que não estejam relacionadas a ataques mas que também devem ser monitoradas para garantir a disponibilidade. Apesar do usuário ter múltiplas conexões IP, se houver compartilhamento de rede física, pode não obter a disponibilidade desejada. As rotas podem ser recuperadas se houver rotas alternativas pré-computadas. Para uma recuperação rápida pode ser atribuída uma maior prioridade às mensagens de atualização de rotas.

14 Locais das Medições: Entrada da Rede Roteador Gateway Roteador de Peering Roteador de Acesso 14

15 Entrada da Rede: Roteador Gateway 15 Controle de acesso Estatísticas globais Exportação de resumos de tráfego por fluxo Através da ferramenta netflow Informações sobre os instantes de início e fim do fluxo Duração Endereços IP da origem e destino Número de portas Sistemas autônomos, Etc. Informação suficiente para: Construir relatórios de agregados de tráfego por usuário. Aprender que fração do tráfego é destinado a usuários da rede e quanto está apenas transitando através da rede.

16 Entrada da Rede: Roteador de Peering 16 Roteadores que falam BGP para trocar informação de roteamento. O peering pode ser público ou privado, em função da disponibilidade dos dados trocados. Objetivo da medição neste nível: Conectividade inter-domínio. Desejo de balancear o tráfego para não gerar dívida. Dados agregados do netflow são frequentemente uma fonte para a geração de tráfego para estas finalidades.

17 Entrada da Rede: Roteador de Peering 17 Exame do BGP para examinar convergência de fluxo, anúncios incorretos ou repetidos, etc. Laços de roteamento em BGP (transiente ou persistente) são causados por anúncios ou saídas incorretas de ASes externos. Uma forma de identificar estes laços é examinar os traços de pacotes e verificar se o pacote cruza o mesmo ponto de monitoração com a mesma carga, variando apenas o campo do TTL. Pode ser necessário monitorar também as rotas internas a um AS (iBGP).

18 Entrada da Rede: Roteador de Peering 18 Podem ser injetadas falhas deliberadamente para examinar seus impactos: Quanto tempo demora antes que a rota seja reparada, ou que seja encontrada um melhor caminho Examinar a diferença entre a reação de diversos ISPs. Medições ativas podem participar de sessões de trocas BGP remotas para examinar: Taxa de falhas dos roteadores que fazem o peering Frequência com que ocorrem estas falhas. A instabilidade de roteamento é frequentemente o resultado de poucos caminhos de rede na Internet.

19 Entrada da Rede: Roteador de Acesso 19 Roteadores de acesso dos usuários Para os usuários uma questão chave é a disponibilidade. Portanto, são realizadas medições rotineiras para garantir que a taxa de falhas seja muito baixa ou nula. Deve ser garantida a SLA com grandes usuários comerciais. Para aplicações de tempo real os requisitos da SLA podem ir além da disponibilidade, baixo atraso e baixa perda de pacotes. Pode ser solicitada a filtragem de pacotes a partir apenas de certos endereços, limitação do número de pacotes em um certo intervalo de tempo, marcação de pacotes (QoS), verificação proativa de possíveis ataques, etc.

20 Locais das Medições: PTT Um ponto de troca de tráfego permite que diversos ISPs troquem tráfego em pontos determinados. Os custos são divididos em função do tráfego trocado em cada direção. Este é um ponto privilegiado de observação para o tráfego que é trocado entre os ISPs. Finalidade principal: Manter o tráfego local – transferir o tráfego entre dois participantes sem ter que roteá-los através de rotas mais longas. Estas medições permitem ter uma ideia geral das alterações nos padrões de tráfego. 20

21 Locais das Medições: WAN Medições em diversos locais da rede: Pontos mencionados anteriormente em diversos PoPs. Medições multi-sítios de forma coordenada. Requer: sincronização de relógios, serialização da execução, mecanismo de comando e controle capaz e lidar com questões de controle de acesso e de recursos. O potencial de problemas é ampliado devido à diversidade de locais. Há também questões de segurança no uso dos recursos e dos dados. Exemplos: NIMI, PlanetLab e perfSONAR 21

22 Locais das Medições: WAN Representatividade das medições: Requer que estejam bem representadas: população de usuários, escolha de clientes, servidores, etc. Problemas com a relutância por parte dos administradores de rede em compartilhar os seus dados devido a questões de privacidade e competitividade. 22

23 Papel do Tempo 23

24 Papel do Tempo 24 Muitas medições requerem uma medição precisa do tempo: Medição de tempo de ida e volta dos pacotes Medição do atraso sofrido pelos pacotes ao passar por roteadores e links Produção de uma visão ordenada no tempo de medições realizadas em diferentes partes da rede. Medição do desempenho (tempo de resposta e vazão) de componentes da Internet.

25 Relógios 25

26 Relógios 26

27 Relógios 27 A acurácia é um requisito mais exigente do que skew zero e, portanto, é mais difícil de ser atingido. Um relógio que tenha um grande offset (e, portanto, é inacurado) mas que tenha skew zero ainda é útil para certo tipos de medição. Exemplos: Tempos de ida e volta dos pacotes Intervalos entre chegadas de pacotes Medições de tempo de resposta de servidor. Por outro lado, há medições que requerem offset zero: Atraso de pacotes em um sentido Ordenação no tempo de eventos ocorridos em diversos locais da rede.

28 Escalas de tempo 28 Atrasos de pacotes em um sentido têm frequentemente magnitudes na escala de dezenas ou centenas de milissegundos. São aceitáveis: resoluções e offsets na ordem de milissegundos e um pequeno skew. Intervalos de tempo entre chegada de pacotes em um link de alta velocidade pode estar na escala de microssegundos. O relógio pode ter qualquer offset, mas a resolução deve ser da ordem de nanossegundos e o skew deve ser próximo a zero.

29 Requisitos de Resolução 29 Os requisitos de resolução normalmente diminuem ao subir na pilha de protocolos. Tempos de resposta típicos: um quarto de segundo para o DNS Poucos segundos para o HTTP Poucos minutos para aplicações P2P

30 Fontes de Informação de Tempo 30 Fontes de tempo externas: Serviços de rádio do NIST GPS: Constelação de 32 satélites em órbitas de 12 horas Precisão da ordem de centenas de nanossegundos a microssegundos As antenas devem ter pelo menos uma visão parcial do céu. Sistemas CDMA: GPS indireto (as estações base obtêm o tempo a partir do GPS) Precisão menor do que 10 microsegundos Receptor pode ser instalado dentro de prédios Necessita que a área seja servida por rede CDMA

31 Fontes de Informação de Tempo 31 Relógios baseados em PCs: Relógio de hardware: mantém informação do tempo enquanto o computador está desligado Relógio de software: Lido usando gettimeofday() no Linux e GetSistemTime() no Windows Implementado com uma interrupção de alta prioridade gerada por um oscilador de cristal Precisão determinada pelo período da interrupção, tipicamente 10 ms. O skew depende das propriedades do oscilador ( 50PPM), portanto o relógio precisa ser corrigido de forma regular

32 Fontes de Informação de Tempo 32 Relógios baseados em PCs (cont.): Registrador TSC (Time Stamp Counter): Disponível em processadores Intel (a partir do Pentium) Incrementado a cada ciclo do processador Resolução melhor do que 1 s Em sistemas Linux ele é usado para interpolar entre valores fornecidos pelo relógio de software O skew pode ser tão baixo como 0,1 PPM

33 Sincronização do Tempo 33 Relógios sincronizados: NTP – Network Time Protocol Organizado em redes de sincronização – conjunto hierárquico de servidores de tempo e clientes Um nível é chamado de estrato (stratum) Os servidores stratum 1 são sincronizados por padrões de rádio, satélite, ou modem. Provê serviço preciso e confiável usando servidores redundantes em diferentes caminhos de rede.

34 Sincronização do Tempo 34 Relógios sincronizados: NTP – Network Time Protocol (cont.) Em intervalos determinados, um cliente envia um pedido para cada servidor configurado e obtém uma resposta Os pedidos e as respostas recebem um carimbo de tempo na partida e na chegada: 4 carimbos. Usa estes carimbos para estimar o offset do relógio e o atraso de ida e volta para cada servidor. Abordagem geral: limite superior no erro do offset é metade do tempo de ida e volta Estimativas do offset são filtradas para remover pontos fora da curva. Constrói estimativas da precisão de cada servidor (dispersão) Organiza a subrede de sincronização em uma árvore de expansão de caminho mais curto.

35 Sincronização do Tempo 35 Relógios sincronizados: NTP – Network Time Protocol (cont.) Precisão: Stratum 1: faixa de 10 s Stratum 2 na Ethernet: em torno de 1 ms Stratum 2 na WAN: 10 a 100 ms O NTP encontra-se atualmente na sua versão 4 [RFCs 5905 a 5908 de Junho 2010]: Projetado para precisão da ordem de microsegundos.

36 Sincronização do Tempo 36 Sincronização Tempos medidos após a medição: Inferência a partir de uma série de medições do deslocamento relativo e do skew relativo dos dois relógios envolvidos.

37 Papel de Diretórios da Internet e Bases de Dados 37

38 Papel de Diretórios e Base de Dados 38 Registros de endereços Registros regionais: ex.: LACNIC Registros nacionais: ex.: NIC.br Servidores DNS Problemas com bancos de dados desatualizados

39 39 Distribuição de Endereços P: Como um provedor IP consegue um bloco de endereços? R: ICANN: Internet Corporation for Assigned Names and Numbers (www.icann.org.br) aloca endereços gerencia DNS aloca nomes de domínio, resolve disputas Através da IANA (Internet Assigned Numbers Authority)

40 Distribuição de Endereços 40 LACNIC é a instituição responsável para a América Latina e o Caribe.

41 Distribuição de Endereços 41 Ex.: Nic.br IANA = Internet Assigned Numbers Authority No Brasil, estas funções foram delegadas ao NIC.br (nic.br) pelo Comitê Gestor da Internet BR –

42 Registro de Roteamento Internet (IRR) 42 Criado em 1995 com o objetivo de ajudar na engenharia de endereçamento e roteamento. Colaboração de diversas organizações de rede Objetivo: Mapear e verificar a corretude de questões de roteamento interdomínio. Mapeamento de um AS para uma lista de redes internas ao AS. Permite que um operador de rede verifique se a informação que está sendo trocada numa sessão BGP está correta.

43 Banco de Dados de Ativos de Roteamento (RADb) 43 Registro de informações de roteamento onde políticas e anúncios das redes participantes estão presentes para ajudar a resolver problemas relacionados a roteamento. Pode estar desatualizado pois as redes podem não submeter as suas atualizações prontamente.

44 Base de Dados Hierárquica e Distribuída 44 Cliente quer IP para 1 a aprox: Cliente consulta um servidor raiz para encontrar um servidor DNS.com Cliente consulta servidor DNS.com para obter o servidor DNS para o domínio amazon.com Cliente consulta servidor DNS do domínio amazon.com para obter endereço IP de Root DNS Servers com DNS servers org DNS serversedu DNS servers poly.edu DNS servers umass.edu DNS servers yahoo.com DNS servers amazon.com DNS servers pbs.org DNS servers

45 45 DNS: Servidores raiz procurado por servidor local que não consegue resolver o nome servidor raiz: procura servidor oficial se mapeamento desconhecido obtém tradução devolve mapeamento ao servidor local 13 servidores de nome raiz em todo o mundo a Verisign, Dulles, VA c Cogent, Herndon, VA (also Los Angeles) d U Maryland College Park, MD g US DoD Vienna, VA h ARL Aberdeen, MD j Verisign, ( 11 locations) b USC-ISI Marina del Rey, CA l ICANN Los Angeles, CA e NASA Mt View, CA f Internet Software C. Palo Alto, CA (and 17 other locations) i Autonomica, Stockholm (plus 3 other locations) k RIPE London (also Amsterdam, Frankfurt) m WIDE Tokyo

46 Servidores TLD e Oficiais 46 Servidores Top-level domain (TLD) : servidores DNS responsáveis por domínios com, org, net, edu, etc, e todos os domínios de países como br, uk, fr, ca, jp. Network Solutions mantém servidores para domínio.com NIC.br (Registro.br) para domínio.br Servidores oficiais: servidores DNS das organizações, provendo mapeamentos oficiais entre nomes de hospedeiros e endereços IP para os servidores da organização (e.x., Web e correio). Podem ser mantidos pelas organizações ou pelo provedor de acesso

47 47 Servidor de Nomes Local Não pertence necessariamente à hierarquia Cada ISP (ISP residencial, companhia, universidade) possui um. Também chamada do servidor de nomes default Quanto um hospedeiro faz uma consulta DNS, a mesma é enviada para o seu servidor DNS local Atua como um intermediário, enviando consultas para a hierarquia.

48 48 solicitante cis.poly.edu gaia.cs.umass.edu servidor raiz servidor local dns.poly.edu servidor oficial dns.cs.umass.edu 7 8 servidor TLD Exemplo de resolução de nome pelo DNS Hospedeiro em cis.poly.edu quer endereço IP para gaia.cs.umass.edu consulta interativa: servidor consultado responde com o nome de um servidor de contato Não conheço este nome, mas pergunte para esse servidor

49 49 consulta recursiva: transfere a responsabilidade de resolução do nome para o servidor de nomes contatado carga pesada? solicitante cis.poly.edu gaia.cs.umass.edu servidor DNS raiz servidor DNS local dns.poly.edu servidor DNS oficial dns.cs.umass.edu 7 8 servidor TLD 3 Exemplo de resolução de nome pelo DNS

50 DNS: uso de cache, atualização de dados 50 uma vez que um servidor qualquer aprende um mapeamento, ele o coloca numa cache local entradas na cache são sujeitas a temporização (desaparecem depois de um certo tempo) Servidores TLD tipicamente armazenados no cache dos servidores de nomes locais Servidores raiz acabam não sendo visitados com muita frequência estão sendo projetados pela IETF mecanismos de atualização/notificação dos dados RFCs 2136, 3007, 4033/4/5

51 51 Registros DNS DNS: BD distribuído contendo registros de recursos (RR) Tipo=NS nome é domínio (p.ex. foo.com.br) valor é endereço IP de servidor oficial de nomes para este domínio formato RR: (nome, valor, tipo, sobrevida) r Tipo=A nome é nome de hospedeiro valor é o seu endereço IP r Tipo=CNAME nome é nome alternativo (alias) para algum nome canônico (verdadeiro) valor é o nome canônico r Tipo=MX nome é domínio valor é nome do servidor de correio para este domínio

52 Questões Relacionadas a Medições 52 Problema de desatualização das bases de dados. As informações são cacheada em diversos locais e o cache pode estar congelado (por exemplo ignorando o TTL). As informações podem estar incompletas ou serem acessíveis apenas a usuários autorizados. Inferências realizadas a partir de medições podem ser suspeitas como resultado deste problemas.

53 Medições nas diversas Camadas de Protocolos 53

54 Eixos 54 Diferenças na captura de dados nas diversas camadas. Mudanças necessárias na infraestrutura e na instrumentação em cada uma das camadas de coleta de dados. Contraste entre a coleta de dados local, remota e distribuída.

55 Captura de Dados 55 Protocolos de níveis mais baixos (roteamento e enlace) Traços de Pacotes e de Fluxos Camada de Aplicação

56 Protocolos de níveis mais baixos 56 Camadas de Roteamento e Enlace Quantidade de dados a serem examinados Consultas periódicas (como no SNMP) Necessidade de realizar a coleta em pontos próximos às entidades monitoradas

57 Traços de Pacotes e de Fluxos: 57

58 Camada de Aplicação: 58 Escalas de tempo de seres humanos Registros (logs)

59 Mudanças na Infraestrutura/Instrumentação 59 Medições não foram previstas inicialmente. Formas como as medições podem ser realizadas: Amostragem periódica (ex. SNMP): requer instrumentação mas não mudança na infraestrutura. Cartões especiais de coleta tornam complicada qualquer mudança e têm que ser adaptada para a mesma família de roteador a cada nova geração de roteadores. Na camada de aplicação é mais fácil mudar o software para adaptar a protocolos alternativos

60 Coleta de Dados Local x Remoto x Distribuído 60 Coleta de dados nas camadas inferiores: Normalmente realizada apenas localmente devido a restrições de acesso remoto. Traços de Pacotes: Podem ser realizados em diversos pontos da rede Não são disparados remotamente Camada de Aplicação: Podem ser realizadas medições remotas ou distribuídas Não tem normalmente preocupações com impacto no desempenho que ocorre nas camadas inferiores.


Carregar ppt "QUESTÕES PRÁTICAS EM MEDIÇÕES DA INTERNET Capítulo 4 Crovella, M, Krishnamurthy, B. Internet Measurement: infrastructure, traffic & applications. John."

Apresentações semelhantes


Anúncios Google