SIMET Sistema de Medições de Tráfego IP. Fabrício Tamusiunas NIC.BR Milton Kaoru Kashiwakura NIC.BR - PDF
Download "SIMET Sistema de Medições de Tráfego IP. Fabrício Tamusiunas NIC.BR Milton Kaoru Kashiwakura NIC.BR"
Yago Brezinski Bentes
1 SIMET Sistema de Medições de Tráfego IP Fabrício Tamusiunas NIC.BR Milton Kaoru Kashiwakura NIC.BR
2 Questões sobre conectividade Internet O que você realmente sabe sobre sua conectividade com o resto da Internet? Você pode realmente diagnosticar problemas envolvendo outras redes? Você pode ver tendências de longo prazo em sua rede?
3 Importância de uma análise de tráfego Conectividade entre backbones Qualidade da conectividade Diferentes Serviços Diferentes Horários Conectividade de última milha Capacidade máxima da conectividade Qualidade da conectividade Diferentes Serviços Diferentes Horários
4 RIPE - TTM Test Traffic Measurements Service Desde outubro/2000 Permite monitorar a conectividade de sua rede com o resto da Internet Permite aos NOCs obter informações, investigar problemas e preveni-los no futuro
5 TTM - Características Atraso entre dois hosts (latência) Perda de pacotes Informações sobre o caminho (traceroute) Variação do atraso (Jitter) Todos os resultados mostrados através de gráficos Utilização de GPS para sincronismo de horário
6 SIMET SIMET Sistema para Medição de Tráfego de Última Milha Características gerais Permite a medição, armazenamento e visualização sobre testes realizados na última milha
7 SIMET Descoberta e medição de dados de última milha Cliente 90% escrito Java (Applet) Utiliza bibliotecas padrão Xerces (tratamento de XML) Jdic (tratamento de UPnP) 10% escrito em C++ (baseado no Iperf)
8 SIMET
9 Teste de portas Teste de viabilidade de utilização de serviços existentes na Internet Testados os principais serviços hoje disponíveis Testes realizados em ambos os sentidos Todos os serviços testados têm os resultados mostrados e em caso de problemas, eles são mostrados
10 Teste de Portas como é feito Portas ficam abertas no servidor Controle das portas é feito por conexão TCP Espera 5 segundos pelo estabelecimento de conexões locais Espera 5 segundos pelo estabelecimento de conexões remotas
11 Teste de Portas Serviços Testados H.323 / SIP Net2Phone Skype Yahoo Messenger MSN Messenger Google Talk / Jabber ICQ Windows Media Quicktime Real Media WWW FTP Gnutella MS Terminal Service
12 Teste de Portas
13 Teste de banda máxima (TCP) Utiliza o algoritmo de Nagle Pode ser desabilitado o algoritmo de Nagle Utiliza tráfego comprimido para o teste Evita problemas com V.44, aceleradores de conexão ou outro tipo de informação. Método de compressão usado: bzip2
14 Algoritmo de Nagle s Criado por John Nagle RFC 896 Procura minimizar o número de pacotes enviados na rede com o maior número possível de dados por pacote
15 Teste de banda máxima (TCP)
16 Testes UDP Total de banda a ser usada pode ser escolhida pelo usuário São usadas velocidades familiares aos usuários Se não escolhida a velocidade são usados 128 kbps como banda.
17 Testes UDP
18 Envio de dados compactados Diferença é muito significativa nos casos abaixo V.44 (acesso dial-up) Aceleradores Proxys com suporte a compressão Junto com a Applet é enviado um arquivo comprimido a ser utilizado para a transmissão
19 Tratamento de firewall Capacidade de descobrir automaticamente a existência de firewalls Testada disponibilidade de portas específicas para os testes Portas em uso Portas filtradas Testas até cinco portas para os testes de banda, para a utilização de uma específica
20 UPnP Permite que se configure automaticamente uma firewall para utilização de determinadas portas Utiliza XML e HTTP para configuração Muitos dos Access Points fabricados desde 2004 tem suporte (Linksys, Cisco, etc). UpnP fórum
21 UPnP <?xml version="1.0"?> <root xmlns="urn:schemas-upnp-org:device-1-0"> <specversion> <major>1</major> <minor>0</minor> </specversion> <URLBase> <device> <devicetype>urn:schemas-upnporg:device:internetgatewaydevice:1</devicetype> <friendlyname>linux Internet Gateway Device</friendlyName> <manufacturer>linux UPnP IGD Project</manufacturer> <manufacturerurl> <modelname>igd Version 0.92</modelName> <UDN>uuid: bccb-40e7-8e6c-fa095ecce13e</UDN>
22 UPnP
23 Direção do tráfego Teste pode ser realizado em duas maneiras Unilateral Apenas upload Feito automaticamente no caso de firewall bloqueando portas Bilateral Upload/download Quando não existe firewall ou caso firewall suporte UPnP
24 Cálculo de Jitter A variação da latência (Jitter) é medido através do teste UDP Utiliza RTP para o envio de pacotes Pacotes são enviados com intervalo fixo e com data/hora internamente O receptor abre os pacotes RTP e analisa a deferença entre o tempo de chegada de dois pacotes e
25 Cálculo de Jitter
26 Datagramas perdidos Utilizando os números sequenciais enviados dentro dos pacotes RTP, é possível descobrir o total de datagramas perdidos A contabilidade é sempre feita do lado do servidor
27 Datagramas desordenados Como no caso dos datagramas perdidos, através do protocolo RTP, é possível calcular a quantidade de datagramas desordenados que chegam ao receptor Este tipo de informação é útil no caso de redes que possuam balanceamento para acesso a Internet
28 Testes avançados Além dos teste padrão, é possível configurar dados específicos para os testes realizados Permite personalizar parâmetros para adequação do teste as necessidades
29 Testes avançados
30 Servidor Sistema baseado em Linux com kernel 2.6 Geração e recebimento de tráfego escrito em C++ Baseado no Iperf Geração dos Gráficos feita em PHP/gdlib Sistema para teste de portas escrito em Java Sistema para processamento dos dados recebidos escrito em Perl
31 Segurança nas medições Todos os testes não podem ser feitos duas vezes seguidas pelo mesmo endereço de origem 1º teste liberado 2º teste somente após 30 segundos do primeiro 3º teste somente após 5 minutos do segundo 4º teste somente após 30 minutos do primeiro 5º teste somente após 2 horas do quarto 6º teste somente após 24 horas Após 24 horas o tempo é zerado Exceções podem ser configuradas
32 Balanceamento da carga Cada servidor chega até 80% de carga máxima Acima deste valor, é redirecionado a um outro servidor da mesma rede ou feito agendamento Se banda escolhida for maior que isto, o teste pode ser feito em múltiplos servidores que tenham banda disponível simultaneamente
33 Distribuição dos servidores Cliente procura sempre servidor mais próximo Consulta base de dados central para descobrir qual o servidor mais próximo Servidor mais próximo é o do ASN onde está o endereço IP do participante Podem ser configuradas faixas de endereços IP caso a caso
34 Clientes - desempenho Desempenhos equivalentes para implementações Threads POSIX em Linux Threads WIN32 para Windows Em Pentium IV 1.6 Ghz fica em 10% uso de CPU durante testes para 100 Mbps Quando usado CYGWIN para rodar Threads POSIX em Windows, desempenho cai cerca de 25%
35 Visualização de histórico Esta sendo desenvolvida solução para visualização de histórico Poderá ser informado o endereço IP para verificar histórico ou utilizadas cookies para saber os testes feitos por um determinado computador Deverá ser informado o período para visualização
36 Trabalhos em andamento Marcação de pacotes para testes de QoS Possibilidade de testes em portas específicas Geração de relatórios em diversos formatos CSV PDF... Agendamento de testes pelo cliente
37 Perguntas, questões,... para contato Criação de lista será feita esta semana para interessados em testar a versão alpha