LUÍS ALBERTO MOREIRA

Orientador: Carlos Frederico M. C. Cavalcanti

ANÁLISE E CARACTERIZAÇÃO DE TRÁFEGO EM

REDES MUNI-WI

Ouro Preto

Novembro de 2010

Universidade Federal de Ouro Preto

Instituto de Ciências ExatasBacharelado em Ciência da Computação

ANÁLISE E CARACTERIZAÇÃO DE TRÁFEGO EM

REDES MUNI-WI

Monogra�a apresentada ao Curso de Bachare-lado em Ciência da Computação da Universi-dade Federal de Ouro Preto como requisito par-cial para a obtenção do grau de Bacharel emCiência da Computação.

LUÍS ALBERTO MOREIRA

Ouro Preto

Novembro de 2010

UNIVERSIDADE FEDERAL DE OURO PRETO

FOLHA DE APROVAÇÃO

Análise e Caracterização de Tráfego em Redes Muni-Wi

LUÍS ALBERTO MOREIRA

Monogra�a defendida e aprovada pela banca examinadora constituída por:

Dr. Carlos Frederico Marcelo da Cunha Cavalcanti � OrientadorUniversidade Federal de Ouro Preto

Dr. Álvaro Rodrigues Pereira Jr.Universidade Federal de Ouro Preto

Bel. Hugo Machado FalcãoNTI - Universidade Federal de Ouro Preto

Ouro Preto, Novembro de 2010

Resumo

O projeto de Cidades Digitais proposto tem o objetivo de estabelecer referenciais teóricos e

operacionais na implantação de uma cidade digital. O estabelecimento de referenciais teóricos

e operacionais para a implementação de projetos de Cidades Digitais no LAC através de

pilotos é de fundamental importância para aceleração da expansão das redes de banda larga

na região. Projetos pilotos possibilitam testes de modelos de tal forma que, sistematizados,

possam ser replicáveis e servirem de referência para novas implementações. Testes pilotos

também permitem identi�car as necessidades de estabelecimento de políticas públicas para

fomentar ou sustentar uma cidade digital, bem como veri�car o impacto e e�cácia da banda

larga como ferramenta de inclusão e de desenvolvimento social e econômico. Este projeto tem

o objetivo de prover as bases para a caracterização de tráfego em uma rede de banda larga

aberta ao público dentro do paradigma de Cidades Digitais, especialmente nas providas por

backbone wireless, conhecida como Muni-Wi, abreviatura de "Municipal Wireless Networks".

Tal desa�o pode ser separado em três níveis de problema: fundamentação teórica das

propostas de análise e caracterização de tráfego, Proposta da metodologia para aplicação em

cidades digitais e �nalmente, aplicação da mesma em um caso real.

Palavras-chave: Redes de banda larga. wireless. medição de rede. muni-wi. cidade digital.

Análise de tráfego

i

Abstract

The Digital Cities project proposed aims to establish theoretical and operational deployment

of a digital city. The establishment of theoretical and operational frameworks for the imple-

mentation of Digital City projects in LAC by pilots is critical for accelerating the expansion

of broadband networks in the region. Pilot projects will allow testing of models such that,

systematized, might be replicable and serve as a reference for new deployments. Pilot tests

also help identify the needs for establishing public policies to promote or sustain a digital

city, as well as verify the impact and e�ectiveness of broadband as a tool of inclusion and

social and economic development. This project aims to provide the basis for characterization

of tra�c in a broadband network open to the public within the paradigm of Digital Cities,

especially provided by the wireless backbone, known as Muni-Wi, shorthand for "Municipal

Wireless Networks". This challenge can be separated into three levels of problems: theoretical

analysis and proposals for tra�c characterization, Proposal of methodology for application in

digital cities and �nally applying it in a real case.

Keywords: Broadband Networks. wireless. measurement network. muni-wi. digital city.

Tra�c Analysis

ii

Dedico este trabalho à minha esposa Ediméia pelo incansável apoio, paciência e compreen-

são nos momentos mais difíceis.

iii

iv

Agradecimentos

Agradeço primeiramente a Deus pois sem ele nada seria possível. Ao Prof. Carlos Frederico

pelos ensinamentos repassados e toda paciência e dedicação na orientação do trabalho. À

minha esposa Ediméia e a toda minha família pelo apoio. E a todos que contribuíram direta

ou indiretamente para este trabalho.

v

Sumário

1 Introdução 1

2 Justi�cativa 4

3 Objetivos 5

3.1 Objetivo geral . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

3.2 Objetivos especí�cos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

4 Redes Muni-Wi 7

5 Trabalhos relacionados 10

6 Monitorando tráfego de rede 12

6.1 Tcpdump e Libpcap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

6.2 Wireshark . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

6.3 Tra�c Analyzer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

6.4 P-cube . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

7 Metodologia 23

8 Conclusões 38

9 Glossário 39

Referências Bibliográ�cas 41

vi

Lista de Figuras

4.1 Exemplo ilustrativo de uma rede Muni-Wi . . . . . . . . . . . . . . . . . . . . . . . 8

4.2 Exemplo de utilização tecnologia Wireless Mesh . . . . . . . . . . . . . . . . . . . . 8

4.3 Distribuição dos Access Points na rede da cidade de Tiradentes-MG [da C. Caval-

canti et al. (2006)] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

4.4 Topologia da rede da Cidade de Tiradentes-MG [da C. Cavalcanti et al. (2006)] . . 9

5.1 Caracterização hierárquica em 3 níveis proposta por [Marques-Neto et al. (2009)] . 11

6.1 Tela de saida do Tcpdump . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

6.2 Flow of packets through the system [Dabir e Matrawy (2007)] . . . . . . . . . . . . 16

6.3 Tela do Wireshark . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

6.4 Tela de execução do Tra�c Analyzer. . . . . . . . . . . . . . . . . . . . . . . . . . . 18

6.5 Cisco SCE 1000, equipamento utilizado para medição e controle de tráfego. . . . . 19

6.6 Bump-in-the-Wire Installation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

6.7 External Splitting Topology. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

6.8 Cisco SCE 1000 com Cisco SCA . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

6.9 P-cube Service Control MIB Structure . . . . . . . . . . . . . . . . . . . . . . . . . 22

7.1 Localização das antenas no início da segunda fase do projeto . . . . . . . . . . . . 23

7.2 Topologia de rede no início da segunda fase do projeto . . . . . . . . . . . . . . . . 24

7.3 Usuários simultâneos em função do tempo no início da segunda fase do projeto . . 24

7.4 Utilização do Link de 2 Mbps por uma semana após a liberação da banda para a

rede "Convidados" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

7.5 Grá�co de utilização do rádio da Prefeitura (802.11 a) . . . . . . . . . . . . . . . . 26

7.6 Grá�co de utilização do rádio da Rodoviária (802.11 a) . . . . . . . . . . . . . . . . 26

7.7 Grá�co de utilização do rádio da Igreja Matriz (802.11 a) . . . . . . . . . . . . . . 26

7.8 Grá�co de utilização do rádio da Escola Estadual Basílio da Gama (802.11 a) . . . 27

7.9 Grá�co de utilização do rádio da Prefeitura (802.11 b/g) . . . . . . . . . . . . . . . 27

7.10 Grá�co de utilização do rádio da Rodoviária (802.11 b/g) . . . . . . . . . . . . . . 27

7.11 Grá�co de utilização do rádio da Igreja Matriz (802.11 b/g) . . . . . . . . . . . . . 28

7.12 Grá�co de utilização do rádio da Escola Estadual Basílio da Gama (802.11 b/g) . . 28

vii

7.13 Tráfego HTTP da Interface FastEthernet0/0 CKT INTERNET NLA/BF/00005 . . 29

7.14 Tráfego HTTPS da Interface FastEthernet0/0 CKT INTERNET NLA/BF/00005 . 29

7.15 Tráfego SMTP da Interface FastEthernet0/0 CKT INTERNET NLA/BF/00005 . . 29

7.16 Tráfego IPSEC da Interface FastEthernet0/0 CKT INTERNET NLA/BF/00005 . 30

7.17 Clientes simultâneos por tempo após a expansão da rede . . . . . . . . . . . . . . . 31

7.18 Uso da Banda por Tipo de Serviço . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

7.19 Infra-estrutura da rede usada na simulação . . . . . . . . . . . . . . . . . . . . . . 33

7.20 Fotos do ambiente de simulação. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

viii

Lista de Tabelas

ix

Capítulo 1

Introdução

Projetos denominados de "Cidades Digitais"(DCP - Digital City Projects) foram implemen-

tados em vários pontos do mundo. Apesar disto, podemos constatar que existem diferentes

abordagens, nomenclaturas e motivações para a implementação de cidades digitais (CD).

Inicialmente, o conceito de Cidade Digital foi associado com projetos de infra-estrutura para

aumentar a conectividade com o objetivo de levar, para a população de um município, acesso

à Internet a um custo zero ou baixo custo e geralmente em banda larga . Estes projetos

focaram na construção de infra-estrutura de rede e foram chamados de Cidade Digitais.

Outros, por sua vez, objetivaram prover um conjunto de serviços para a população em uma

abordagem de e-governament e e-learning. Outras, focadas em uma visão de futuro, idealizam

uma cidade Digital onde dispositivos computacionais integram o dia-a-dia das pessoas em um

abordagem ubíqua . Independentemente das diferenças é de fácil constatação que projetos

desta natureza tem um impacto na comunidade e é um fator de desenvolvimento econômico

e social.

Clarke e Wallsten (2006), em um estudo de 27 países desenvolvidos e 66 em desenvolvi-

mento, constatou que um aumento de 1% no número de usuários da Internet está relacionada

com um aumento nas exportações de 4,3%. Comunidades locais em todo o mundo têm tido

consideráveis ganhos econômicos e novas oportunidades através dos serviços de banda larga.

Estudos apartir do Canadá, Reino Unido e os Estados Unidos descobriram que conectividade

de banda larga tem um impacto econômico positivo na criação de emprego, retenção da

comunidade, vendas no varejo, e receitas �scais [ic4 (2009)].

Relatório do banco Mundial de 2009 [WB], numa análise de 120 paises, para cada 10% de

penetração de serviços de banda larga, existe um crescimento econômico de 1,3% [Qiang et al.

(2009)].

Como as redes de banda larga tem o potencial de contribuir muito para o desenvolvimento

econômico, elas devem ser amplamente disponíveis a preços acessíveis e devem tornar-se parte

1

1. Introdução 2

integrante das estratégias de desenvolvimento nacional.

Por causa do rápido crescimento do tráfego em aplicações de tempo real, as redes de

computadores requerem mais funções do que anteriormente oferecidas no passado. Identi-

�car quais (e de que forma) as aplicações são usadas em uma projeto de Cidade Digital e

quais os impactos no crescimento econômico é um desa�o que necessita ser vencido por etapas.

Existem diversos estudos na literatura sobre Internet que apresentam caracterizações de

cargas de trabalho. Alguns analisam cargas de trabalho tradicionais, compostas por acessos

a documentos, imagens e domínios presentes na Web, enquanto outros caracterizam cargas

de trabalho de serviços mais especí�cos, tais como, distribuição de mídia sob-demanda e ao

vivo, sistemas P2P, Web Proxy e, mais recentemente, IPTV. Entretanto, estudos recentes

com uma caracterização do tráfego geral da Internet banda larga ainda são escassos na

literatura. O trabalho de [Dischinger et al. (2007)] analisa algumas características do serviço

oferecido por provedores de banda larga na América do Norte e na Europa. Apesar dos

autores apresentarem medições de propriedades, tais como, capacidade da conexão, tempo de

round-trip (RTT) e jitter dos pacotes, taxa de perda de pacotes, tamanho da �la e políticas de

descarte de pacotes de 1.894 usuários residenciais de banda larga, o estudo não caracteriza as

sessões desses usuários por não disporem de dados de tráfego reais coletados da infra-estrutura

de um provedor de acesso a Internet (ISP). A partir da caracterização do comportamento dos

usuários da Internet de banda larga passa a ser possível propor mecanismos mais justos de

controle de tráfego que promovam o bem-estar coletivo no contexto do provedor de acesso e

melhorar métricas para avaliação da qualidade do serviço percebido pelo usuário, tais como,

desempenho, disponibilidade de acesso, segurança e custo [Marques-Neto et al. (2009)].

Entender as características da carga de trabalho de uma rede é uma tarefa fundamental

para o administrador da rede melhorar o gerenciamento da sua infra-estrutura a�m de

oferecer um serviço de qualidade a seus usuários.

Este trabalho propõe apresentar uma metodologia para a análise e caracterização de

tráfego em redes Muni-Wi com objetivo de prover as bases para a caracterização do tráfego

e do comportamento de usuários em uma rede de banda larga aberta ao público dentro

do paradigma de Cidades Digitais, especialmente nas providas por backbone wireless,

conhecida como Muni-Wi, abreviatura de "Municipal Wireless Networks", quanti�cando e

principalmente quali�cando a carga de trabalho gerada na rede.

Tal desa�o pode ser separado em três níveis de problema: fundamentação teórica das

propostas de análise e caracterização de tráfego, proposta da metodologia para aplicação em

1. Introdução 3

cidades digitais e �nalmente, aplicação da mesma em um caso real.

O trabalho está organizado em oito seções. Na seção 2 são apresentados as justi�cativas

e relevância que motivaram este trabalho. Na 3, os objetivos a serem alcançados. O estado

da arte em Redes Muni-Wi é descrito na seção 4. Na seção 5 discutimos alguns trabalhos

relacionados e, na seção 6 é feita uma abordagem teórica sobre monitoramento de tráfego de

rede e descrevemos algumas ferramentas utilizadas para análsie. Nossa metodologia adotada

para análise e caracterização de tráfego é descrita na seção 7. E, �nalmente, na seção 8 nossas

conclusões e trabalhos futuros são apresentados.

Capítulo 2

Justi�cativa

• É de conhecimento que banda larga gera desenvolvimento econômico.

• Porém, não existe estudo que associei quais os serviços que alavancam o desenvolvimento

econômico.

• Não existem metodologias que analisam e caracterizam uma rede banda larga que possam

traçar um paralelo entre serviços da rede e desenvolvimento econômico.

• Tão importante quanto prover acesso à rede é fornecer subsídios para o melhor gerenci-

amento possível a�m de otimizar os recursos da mesma.

• Importância para alocação e otimização de recursos tecnológicos e humanos , como

banda, número equipamentos, número de pessoas atendidas, qualidade de serviço, etc.

• relevância é propor e testar em redes Muni-Wi que são relevantes no contexto brasileiro,

principalmente no âmbito dos projetos PNBL (Programa nacional de banda larga) e

Cidades Digitais.

4

Capítulo 3

Objetivos

3.1 Objetivo geral

• De�nir uma metodologia para análise e caracterização do tráfego das redes Muni-Wi,

de forma a permitir um melhor gerenciamento e otimização do uso dos recursos dessas

redes.

3.2 Objetivos especí�cos

• Levantar o estado da arte das abordagens conceituais de analise e caracterização de

tráfego.

• Levantar o estado da arte das redes Muni-Wi

• Estabelecer uma metodologia para análise e caracterização de tráfego adequada para

redes Muni-Wi.

• De�nir critérios e aspectos a serem analisados.

• Fazer um teste piloto em planta em cidades ou redes disponíveis para uso pela UFOP.

• Coleta, análise e manipulação dos dados com base nos critérios adotados.

• Difundir o trabalho através de artigos e disponibilização na rede Internet.

• Iniciar o discente em Projetos Cientí�cos (Iniciação cienti�ca).

• Expô-lo à grupos de pesquisa no pais e no exterior, através de discussão sobre o assunto

em listas de discussão.

• Gerar um ambiente experimental no Departamento de Computação da UFOP de tal

forma que as idéias geradas podem ser testadas.

5

3. Objetivos 6

• Análise e apresentação dos resultados obtidos.

Capítulo 4

Redes Muni-Wi

Existem diferentes pontos de vista em torno da de�nição de "Cidades Digitais". Uns consid-

eram que se trata de uma rede de abrangência municipal que conecta órgãos públicos, escolas,

tele-centros e terminais de acesso, ou seja, uma rede própria que independe de provedor

de acesso. Nesse aspecto a rede pode propiciar, dentre outros fatores, melhoria na gestão

pública, disponibilização eletrônica de serviços do governo (e-governament), inclusão digital

e social, e desenvolvimento socio-econômico. Outros consideram Cidade Digital como sendo

a disponibilização de pontos de acesso à Internet em locais públicos de forma a obter uma

cobertura municipal e assim prover acesso à grande rede de forma livre e gratuita, podendo

propiciar neste caso, dentre outras coisas a inclusão digital e social, e o desenvolvimento

sócio-econômico. E, há também, quem considere Cidade Digital como sendo a junção desses

dois pontos de vista [gcd (2010)], [chs (2010)].

Existem ainda quatro modelos básicos que podem também de�nir uma Cidade Digital do

ponto de vista de provedor de serviços, são eles :

• O governo é proprietário da rede que é para seu uso exclusivo.

• O governo é proprietário da rede que é para seu uso (do governo) e também de uso

público.

• O governo é proprietário da rede e um provedor controla o acesso a ela.

• Um provedor é proprietário e administrador da rede, provendo serviços ao governo e/ou

público.

As redes Muni-Wi ou Municipal Wireless Networks estão inseridas no contexto de Cidades

Digitais, mas de uma forma menos abrangente no que diz respeito à arquitetura de rede

utilizada, neste caso, concentrando apenas na tecnologia wireless como meio de conexão de

seus equipamentos e provimento de acesso(veja exemplo ilustrativo na �gura 7.1).

7

4. Redes Muni-Wi 8

Figura 4.1: Exemplo ilustrativo de uma rede Muni-Wi

Grande parte das redes Muni-Wi utilizam tecnologia Wireless Mesh para conectar seus

equipamentos em uma área de cobertura delimitada, provendo acesso ao usuário (veja ilus-

tração de exemplo de uso dessa tecnologia na �gura 7.2). Dentre várias vantagens do uso

dessa tecnologia nesse tipo de rede, pode-se destacar o roteamento dinâmico, o que permite

que a informação chegue ao nó principal da rede caso haja falha em algum nó intermediário,

através de rotas alternativas, pois todos o nós da rede estão conectados entre si; permite

também a mobilidade do usuário dentro da área de cobertura da rede sem que sua conexão

seja perdida, onde um AP (Access Point) assume a conexão do AP anterior ao qual o usuário

estava conectado, mantendo assim a conexão ativa.

Figura 4.2: Exemplo de utilização tecnologia Wireless Mesh

As �guras 7.3 e 7.4 a seguir mostram respectivamente a distribuição dos AP's e a

topologia da rede na cidade de Tiradentes - MG que foi escolhida para projeto piloto de

Cidade Digital devido a vários fatores como : grande limitação física na instalação de

equipamentos, cabos e outros, devido ao seu conjunto arquitetônico e patrimonial; limitação

4. Redes Muni-Wi 9

física também devido à topogra�a e relevo da cidade; pequeno número de habitantes; cidade

mundialmente conhecida, referencial e que recebe milhares de turistas anualmente; dentre

outros fatores.

Figura 4.3: Distribuição dos Access Points na rede da cidade de Tiradentes-MG [da C. Cav-alcanti et al. (2006)]

Figura 4.4: Topologia da rede da Cidade de Tiradentes-MG [da C. Cavalcanti et al. (2006)]

Capítulo 5

Trabalhos relacionados

Dentre alguns trabalhos recentes pesquisados, dois foram considerados bases relevantes para

este trabalho : [Marques-Neto et al. (2009)] e [Dischinger et al. (2007)] ; sobre análise e

caracterização de tráfego em redes de banda larga. Ambos analisam aspectos diferentes para

se obter a caracterização do tráfego de rede. Em [Marques-Neto et al. (2009)] a análise ocorre

em nível de aplicação, mais especi�camente sob tráfego tipo "par-a-par", também conhecido

como P2P, anacronismo da expressão americana peer-to-peer. que resume o termo, e no outro

[Dischinger et al. (2007)] ocorre a nível de propriedades de rede do enlace de dados de banda

larga.

[Marques-Neto et al. (2009)], propôs uma caracterização hierárquica (ver �gura 5.1) com

o objetivo de caracterizar o comportamento dos usuários de sistemas P2P usando acesso

à Internet de banda larga. A hierarquia adotada é representada em três níveis: todas as

sessões, sessões não P2P versus sessões P2P e sessões light-P2P versus sessões heavy-P2P.

Neste estudo são analisados setes aspectos chaves : 1-Processo de chegada das sessões dos

usuários à infra-estrutura do provedor de acesso, 2-Processo de saída das sessões, 3-Duração

das sessões, 4-Bytes recebidos durante as sessões, 5-Bytes enviados, 6-Principais serviços,

7-Atividades de comércio eletrônico utilizadas. Foram utilizadas as seguintes fontes de dados :

1-Log de tráfego de um provedor de internet banda larga coletado por equipamentos p-Cube,

hoje conhecidos como CISCO SCE e contém amostras dos �uxos das transações geradas por

aplicações / protocolos. Os principais campos que foram considerados em cada transação

são: data/hora inicial, duração, serviço (http, smtp, pop3, voip, bittorrent, etc), protocolo,

volume de bytes recebidos e enviados e os endereços IP's envolvidos. 2-Log do serviço DHCP

prestado pelo provedor: utilizado para identi�car os usuários do ISP por meio do MAC

address do seu equipamento.

Já [Dischinger et al. (2007)], em seu estudo, propõe uma análise focada nas propriedades da

rede de banda larga para a caracterização do tráfego de usuários residenciais. As propriedades

10

5. Trabalhos relacionados 11

Figura 5.1: Caracterização hierárquica em 3 níveis proposta por [Marques-Neto et al. (2009)]

do enlace caracterizadas foram os seguinte parâmetros: largura de banda, latência e taxa de

perda de pacotes. Medições de outras propriedades do enlace como jitter, tamanho das �las

e políticas de descarte de pacotes foram também realizadas. O trabalho ocorreu em grande

escala, utilizando 1894 hosts (computadores) clientes de 11 provedores na América do Norte

e Europa. A metodologia utilizada baseia-se no envio de pacotes de vários tipos, tamanhos e

a diferentes taxas, partindo de hosts conectados à quatro redes acadêmicas dispersas geogra�-

camente (três na América do Norte e uma na Europa) para hosts residenciais usando conexão

em banda larga, que deveriam responder aos pacotes enviados. Diferentemente de estudos

anteriores, o experimento foi em larga escala pois requer o mínimo de cooperação de hosts

remotos. Sem necessidade de conexão TCP aberta, os hosts devem apenas responder a ICMP

echo request com um ICMP echo response, e um TCP RST quando receberem um TCP ACK.

Capítulo 6

Monitorando tráfego de rede

Para se obter uma análise e por conseqüência uma caracterização ampla e precisa dos

dados que trafegam por uma rede, é importante o uso de ferramentas adequadas e de poder

computacional que provêem o monitoramento e a coleta dos dados que trafegam pela rede.

A seguir, apresentamos uma visão geral em torno de algumas das ferramentas hoje

existentes para �ns de monitoramento e coleta de dados em uma rede TCP/IP:

6.1 Tcpdump e Libpcap

O programa Tcpdump [tcp (2010)] é um analisador de tráfego desenvolvido em código livre

utilizando a linguagem de programação "C"e está disponível para os sistemas operacionais

UNIX/Linux é um de rede que ganhou popularidade sendo disponibilizado em código aberto.

Tcpdump captura e �ltragem de pacotes que trafegam pela rede através de uma interface

de rede colocada em modo promíscuo, ou seja, a interface "escuta"todo o tráfego da rede

à qual está conectada, situação que não é interessante do ponto de vista de segurança da

informação. Tcpdump permite visualizar informações de todos os pacotes que trafegam em

uma determinada interface de rede, com a possibilidade de selecionar o tipo de pacote que se

deseja visualizar. Por exemplo Tcpdump permite selecionar pacotes com determinado tipo de

protocolo de rede, endereço fonte, endereço destino, porta fonte, porta destino, dentre várias

opções de �ltro. Este programa foi desenvolvido a partir de uma biblioteca de funções para

captura de pacotes chamada "Libpcap", Library Packet Capture que também foi desenvolvida

utilizando a linguagem "C".

O Tcpdump não tem uma interface grá�ca e que seja agradável ao usuário. Ele é executado

em linha de comando dentro do ambiente UNIX/Linux e fornece como saída informações em

texto puro (�gura 7.1). O programa permite gravar em arquivo as informações coletadas

12

6. Monitorando tráfego de rede 13

durante o processo de captura dos pacotes da rede, para que esse arquivo possa ser lido por

outras ferramentas analisadoras de tráfego, como também permite ler arquivos gerados por

essas outras ferramentas. Mas é claro que esses arquivos devem conter um formato especí�co

.pcap (gerado pela libpcap). Há também uma versão de tcpdump para o Windows chamada

Windump; que utiliza a Winpcap, que é uma libpcap para o Windows [de O. Ru�no (2005)].

Figura 6.1: Tela de saida do Tcpdump

Quando um processo da camada de usuário como o tcpdump tenta recuperar pacotes em

estado bruto a partir do kernel, ele recebe os pacotes com seus cabeçalhos Ethernet. Se isso

requer informação MAC de baixo nível, então ele pode obter os cabeçalhos MAC através de

uma comunicação Kernel - camada de usuário. Observe que o tcpdump atualmente usa a

libpcap para extrair os pacotes. No entanto, o uso popular da libpcap, juntamente com o

tcpdump faz deles sinônimos. Como processo na camada de usuário (�gura 7.2), o tcpdump

obtem os pacotes que têm os cabeçalhos 802.3 quando ele recebe esses pacotes do kernel

(núcleo do sistema operacional). Por isso, é incapaz de fazer a �ltragem de pacotes em

qualquer outro esquema (como 802.11), exceto o que está presente no cabeçalho MAC 802.3,

além das camadas superiores [Bagri et al. (2007)].

Libpcap é a biblioteca usada pelo tcpdump para captura de pacotes em nível de usuário.

Quando a interface Ethernet captura o pacote da rede, ela o leva para o kernel. O Kernel,

a �m de determinar o tipo de pacote, retira o cabeçalho Ethernet do pacote e olha para

a próxima camada. A remoção de cabeçalho pelo kernel continua para cada camada até

a última, para a aplicação que está sobre o kernel. A captura de pacotes do libpcap nos

permite interceptar qualquer pacote como ele é recebido pela interface de rede, juntamente

com todos os seus cabeçalhos, independentemente se o pacote tenha sido enviado pelo próprio

computador.

6. Monitorando tráfego de rede 14

Libpcap recebe comando do tcpdump para obter pacotes do kernel que obedece um

determinado �ltro. Este �ltro é passado para a libpcap pelo tcpdump e para o tcpdump pelo

usuário. O usuário de�ne o �ltro no tcpdump em texto puro como um argumento para a

chamada ao tcpdump. O tcpdump analisa esse �ltro em texto e o converte em um código

BPF (Berkeley Packet Filter) correspondente. Este código BPF é passado para a libpcap

pelo tcpdump. A libpcap tenta primeiro de�nir este �ltro no kernel para que somente os

pacotes �ltrados passem do Kernel para a camada de usuário. Copiar um pacote do kernel

para a camada do usuário é uma operação custosa. Portanto, é preferível que apenas os

pacotes �ltrados passem do kernel para a camada do usuário. Se tentamos anexar um �ltro

"pesado"ou múltiplos �ltros para um único socket, o kernel do Linux rejeita todos os �ltros

permitindo que todos os pacotes passem do kernel para a camada do usuário e chegem à

libpcap. Em tal situação, a libpcap então �ltra os pacotes na camada do usuário e os passa

para o tcpdump ou para o programa que acionou a libpcap. Para cada pacote recebido pela

libpcap após passar pelo �ltro, a libpcap faz um ioctl para o kernel para obter o timestamp

atual. Então a libpcap associa essa informação de timestamp com o pacote e de�ne este como

o tempo de chegada do pacote. Note que este timestamp claramente não é a hora exata de

chegada do pacote ao kernel, ou ao nó da rede, e sim é o tempo que o pacote chega à libpcap

[Bagri et al. (2007)].

Aplicações podem ser desenvolvidas utilizando a libpcap ou WinPcap, para ser capaz de

capturar o tráfego de rede e analisá-lo, ou ler uma captura salva e analisá-la, utilizando o

mesmo código de análise.

6.2 Wireshark

O Wireshark é um popular analisador de pacotes de rede gratuito e de código aberto.

Originalmente chamado de Ethereal, em maio de 2006, o projeto foi rebatizado Wireshark

devido a problemas de marca registrada. É um software multi-plataforma que utiliza o

GTK (GIMP - GNU Image Manipulation Program - Tool Kit) para implementar a sua

interface grá�ca com o usuário, e utiliza a biblioteca pcap (Libpcap) para capturar pacotes

que trafegam pela rede. Ele pode ser executado em vários sistemas operacionais baseados em

Unix, incluindo Linux, Mac OS X, BSD e Solaris, e também em Windows. Há também uma

versão baseada em terminal (não dispondo de interface grá�ca) chamada TShark [wik (2010a)].

O Wireshark é muito similar ao tcpdump, mas tem uma interface grá�ca, e muito

mais opções de classi�cação e �ltragem de informações (embora a classi�cação e �ltragem

6. Monitorando tráfego de rede 15

semelhantes podem ser conseguidas na linha de comando do tcpdump, combinando-o com

grep, sort, etc). Wireshark permite ao usuário ver todo o tráfego que está passando pela rede

(normalmente uma rede Ethernet, mas está sendo adicionado suporte para outras tecnologias

de rede), colocando a interface de rede em modo promíscuo.

O formato de arquivo de rastreamento de rede nativo do Wireshark é o formato libpcap

suportado também pela biblioteca Winpcap. Então ele pode ler arquivos de captura gerados

apartir de outros aplicativos analisadores de pacotes como o tcpdump, que usam esse formato,

e suas capturas salvas em arquivo podem ser lidas por esses mesmos aplicativos que usam a

libpcap ou a Winpcap para ler arquivos de captura.

Para ser capaz de analisar, por exemplo, os pontos de estrangulamento de uma rede

envolvidos na captura de pacotes com Wireshark, é importante entender a estrutura da

aplicação, e também como os pacotes recebidos são manipulados por diferentes camadas de

um sistema operacional. As limitações impostas pelos componentes físicos do computador

também devem ser levadas em consideração.

A aplicação Wireshark é o executável principal apresentado em GUI (interface grá�ca de

usuário) e vem com vários executáveis junto. Um desses arquivos executáveis é o Dumpcap,

que é o utilitário de linha de comando que captura os pacotes e os carrega diretamente para

o disco sem fazer qualquer tratamento. Quando uma sessão de captura é iniciada na GUI

Wireshark, ele inicia uma instância do Dumpcap no console para realizar a real captura

de pacotes. O Dumpcap informa o GUI Wireshark do arquivo em que está escrevendo os

pacotes. A GUI Wireshark lê os recém-capturados pacotes do arquivo que o Dumpcap está

escrevendo, analisa-os, e os informa para o usuário. O Wireshark utiliza a biblioteca libpcap

para realizar o trabalho de baixo nível de captura de pacotes. O diagrama na �gura 4 mostra

o �uxo normal dos pacotes que chegam a partir da rede até o ponto onde eles estão gravados

no disco. Um sistema como o mostrado na �gura 7.2 usa o que é chamado de processo

"2-copy". Os pacotes que chegam ao NIC (interface de rede) são copiados para a memória do

driver de dispositivo. Se os pacotes precisam ser copiados mais uma vez antes da aplicação

do usuário poder acessá-los, então um processo "1-copy"é obtido. Normalmente, esta cópia

seria em um bu�er de kernel que a aplicação do usuário também pode acessar. A maioria

das aplicações utilizam um processo de duas cópias, onde os pacotes são copiados do bu�er

de kernel em um bu�er do usuário para a aplicação acessar. Nos kernels Linux 2.2.X e,

posteriores, como o Kernel do Fedora Core 6, a libpcap usa um socket "PF_PACKET"que

ignora a maioria dos pacotes de protocolo sendo processados pelo Kernel. Cada socket tem

dois bu�ers de Kernel associados a ele para ler e escrever[Dabir e Matrawy (2007)].

6. Monitorando tráfego de rede 16

Figura 6.2: Flow of packets through the system [Dabir e Matrawy (2007)]

Por padrão no Fedora Core 6, o tamanho de cada bu�er é de 109.568 bytes. O WinPcap,

a parte da libpcap para Windows, permite que o tamanho do bu�er de kernel associado ao

socket de captura, seja alterado pelo usuário. A libpcap não fornece essa funcionalidade,

embora no Linux a função setsockopt() pode ser usada para conseguir isso. Uma vez que a

libpcap tem total controle sobre o socket aberto, somente ela pode modi�car o tamanho do

bu�er e, portanto, não é possível para aplicações baseadas na libpcap manipular o tamanho

do bu�er de kernel do socket diretamente. No Wireshark e sni�ers (analisadores de redes)

semelhantes, a nível do usuário, os pacotes são copiados do bu�er do kernel em um bu�er

criado pela libpcap quando uma sessão de captura ativa é iniciada. Este bu�er apenas

mantém um único pacote por um tempo para a aplicação processar antes que o próximo

pacote seja copiado para ele. Se a aplicação escolhe escrever o pacote em disco usando

a função "fwrite"da biblioteca C padrão, o pacote é copiado para outro bu�er que deve

ser preenchido antes da "stdio"fazer uma chamada ao sistema para gravar seus dados em

disco. Este processo de bu�erização é feito para aumentar a e�ciência de escrita do disco,

escrevendo uma série de dados, em vez de, possivelmente, muitos pequenos pedaços de cada

vez. O tamanho padrão para esse bu�er é de 8192 bytes e ele é criado quando um arquivo

é criado/aberto para escrita usando a biblioteca C padrão. Finalmente, o próprio sistema

operacional pode impor um outro nível de bu�erização ao nível do sistema de arquivos para

gravação de dados em disco. O projeto da GUI Wireshark é tal que, enquanto o Dumpcap está

escrevendo pacotes no disco, o componente GUI simultaneamente lê os pacotes armazenados

no disco para processar e exibir as estatísticas para o usuário. Esta não é claramente uma

abordagem desejável quando se trata de taxas elevadas de pacotes[Dabir e Matrawy (2007)],

[wir (2010)].

Abaixo, �gura 7.3, tela capturada do Wireshark em execução.

6. Monitorando tráfego de rede 17

Figura 6.3: Tela do Wireshark

6.3 Tra�c Analyzer

O Tra�c Analyzer [Ângelo Magno de Jesus et al. (2009)] é uma ferramenta desenvolvida no

Departamento de Ciência da Computação da Universidade Federal de Ouro Preto, usada para

análise de tráfego em redes IP. É uma ferramenta integrada, composta por dois módulos: um

que gera tráfego com opções de qualidade de serviço e outro que captura, identi�ca e analisa

o trafego gerado em um ponto da rede.

O software possui o tipo de arquitetura cliente/servidor, nesse caso, é caracterizada

por dois módulos básicos: o gerador (servidor), com o objetivo de geração de tráfego, e

o analisador (cliente) com objetivo de captura de tráfego. A geração de tráfego é feita

com marcação de qualidade de serviço especi�cada, marcando os pacotes, montando seus

cabeçalhos e os enviando para a rede. Isto é, a marcação é feita montando-se o pacote IP.

O analisador recebe os pacotes da rede para, através deles, calcular as estatísticas mais

determinantes na avaliação da qualidade de serviço.

O Tra�c Analyzer foi desenvolvido na linguagem de programação C++, para ser

executado na plataforma Windows. Para geração de tráfego foi utilizada a biblioteca Libnet

e para captura de tráfego foi utilizada a biblioteca Winpcap. A �gura 7.4 exibe a tela de

execução do Tra�c Analyzer, nela o usuário tem a opção de executar a ferramenta no modo

"Analisador"ou então "Gerador".

6. Monitorando tráfego de rede 18

Figura 6.4: Tela de execução do Tra�c Analyzer.

Através do gerador pode-se gerar o tráfego marcado e do analisador (máquina-destino)

pode-se obter as seguintes informações calculadas de acordo com os pacotes fornecidos pelo

gerador: vazão, que constitui uma métrica indicativa da taxa de transferência normalmente

representada em Kbps (Kilobits por segundo); atraso(delay) que indica o acúmulo de vários

atrasos inerentes ao percurso de um pacote na rede; jitter (variação do atraso); e perda

de pacotes, que é a quantidade de pacotes que foram perdidos durante o percurso na rede,

geralmente representada por percentual do valor total de pacotes, calculados de acordo com

os pacotes fornecidos pelo gerador.

O software ainda implementa duas funcionalidades : Sni�er e NetMap (Mapeamento da

rede). O Sni�er, ou capturador de tráfego na rede, permite visualizar todo o �uxo de dados

na rede em tempo real. Pode-se utilizar �ltros (de endereço IP, protocolos e outros) para

�ltrar o tráfego. Já o mapeamento exibe os endereços IP dos computadores presentes na rede

com seus respectivos endereços físicos.

6.4 P-cube

P-Cube foi uma solução incorporada pela Cisco Systems em agosto de 2004, quando adquiriu

uma empresa de mesmo nome da aplicação (P-Cube Inc.) e que na ocasião era líder no

desenvolvimento de plataformas de controle e gerenciamento de serviços IP. As soluções da

P-Cube permitem que provedores de serviços gerenciem e controlem serviços de internet

avançados como voz sobre IP (VoIP), jogos interativos, vídeo sob demanda e peer-to-peer,

entre outros. Os administradores podem identi�car assinantes, classi�car aplicações e até

realizar melhorias na performance da rede.

6. Monitorando tráfego de rede 19

Soluções tecnológicas para aplicações e informações de clientes como o P-Cube proveem a

capacidade de diferenciar e controlar novos serviços de dados baseados em conteúdo, trazendo

serviço de inteligência em redes de dados IP. Hoje, milhões de assinantes se conectam a uma

variedade de serviços de dados através de uma ampla gama de meios de acesso, inclusive com

e sem �o. Os provedores estão exigindo uma maior �exibilidade na sua infra-estrutura de

rede, que só pode ser obtida implementando-se serviço de inteligência. Soluções de controle

de serviços do P-Cube acrescentam inteligência adicional e controle a nível de aplicativo para

as redes IP - permitindo aos provedores de serviços a análise, controle e medição de aplicações

e serviços baseados no conteúdo.

A tecnologia do P-Cube oferece uma capacidade de inspeção detalhada de pacotes,

enquanto a qualidade de serviço é mantida através do controle de aplicações de tempo real.

A natureza programável da plataforma ainda garante que as operadoras podem estender

rapidamente sua infra-estrutura para suportar as novas exigências e demandas do cliente à

medida que evoluem.

O p-cube e o SCE da Cisco

O SCE Cisco R© série 1000 Service Control Engine (�gura 7.5), da família de produtos

Cisco SCE, é um elemento de rede projetado especi�camente para implementações a nível de

operadora, que exige aplicação de alta capacidade e de classi�cação baseada em sessão, bem

como provê o controle de tráfego IP por assinante(usuário do provedor de acesso à Internet)

a nível de aplicação.

Figura 6.5: Cisco SCE 1000, equipamento utilizado para medição e controle de tráfego.

Os provedores de acesso têm uma necessidade cada vez maior de rastrear padrões de

tráfego de seus assinantes, gerir os recursos de largura de banda da rede e expandir a sua

diferenciação de serviço.

O Cisco SCE 1000 Series possui uma arquitetura patenteada que emprega a aceleração

de hardware e múltiplos processadores RISC (Reduced Instruction Set Computer). Ele é um

componente chave da solução tecnológica Cisco Service Control. É um dispositivo com alto

6. Monitorando tráfego de rede 20

desempenho de controle e medição de tráfego, e com um núcleo altamente programável que

pode controlar e gerenciar até 2 milhões de �uxos unidirecionais simultâneos de aplicações

em uma rede IP. Este elemento de rede extensível é projetado especi�camente para o controle

escalável dos �uxos de aplicações.

Operadoras e provedores de serviço implantam o Cisco SCE 1000 Series em redes MAN's

(Metropolitan Area Network), cabo, DSL, móveis ou redes Wi-Fi, de alto desempenho,

para fornecer funções avançadas a nível de aplicação como otimização da largura de banda,

gerenciamento e controle de serviços. O Cisco SCE 1000 Series é instalado na borda da rede,

onde os dispositivos de acesso se conectam à infra-estrutura de backbone da Internet.

Existem dois tipos de instalação física do Cisco SCE 1000 na rede :

• Bump-in-the-wire (Inline) : Permite a leitura e controle do tráfego da rede ( 7.6)

• External Splitting (Parallel : Permite apenas a leitura do tráfego da rede ( 7.7)

Figura 6.6: Bump-in-the-Wire Installation.

Figura 6.7: External Splitting Topology.

6. Monitorando tráfego de rede 21

O Cisco SCE 1000 funcionando em conjunto com o Cisco Service Control Application

for BroadBand (Cisco SCA) (ver �gura 7.8) , suporta classi�cação de tráfego IP a nível

de aplicação para o controle em tempo real de serviços baseados no conteúdo de um

assinante ou grupo. Essa solução oferece monitoramento de protocolo baseado em estado

que permite a detecção e controle de praticamente qualquer aplicação de rede, incluindo a

navegação Web, VoIP, jogos, streaming de multimídia e P2P. O resultado é o controle geral

de congestionamento de rede, otimizando o tráfego a nível de aplicação, eliminando o uso

dispendioso do link de rede e melhorias na infra-estrutura.

Figura 6.8: Cisco SCE 1000 com Cisco SCA

O p-cube é uma MIB proprietária do Cisco SCE 1000, ela permite que os sistemas externos

de gerenciamento possam obter informações gerais sobre o estado de funcionamento do SCE

1000 e a utilização de recursos como, extrair medições de utilização da largura de banda em

tempo real e estatísticas da rede, e receber noti�cações de eventos críticos e alarmes.

A plataforma de controle de serviço do Cisco SCE 1000 suporta tanto o MIB-II (default)

quanto um MIB proprietário (de alguma outra empresa). O MIB proprietário p-cube permite,

além dos recursos citados acima, que o sistema externo de gerenciamento realize operações

de con�guração, performance, solução de problemas e alertas, especí�cas para a plataforma

SCE e, portanto, não fornecidos pelo MIB padrão [cis (2010)].

A �gura 7.9 apresenta a estrutura da MIB de controle de serviço p-cube, que obedece a

seguinte hierarquia na estrutura da árvore para o objeto SNMP encontrado no Cisco SCE

1000 : iso.org.dod.internet.private.enterprise.pcube.. A estrutura completa da árvore pode

ser acessada em http://tools.cisco.com/Support/SNMP/do/BrowseOID.do?local=en.

A descrição completa de cada um dos objetos bem como das variáveis da MIB p-cube pode ser

acessada em http://www.cisco.com/application/pdf/en/us/guest/products/ps6150/c1626/

ccmigration_09186a00804e628d.pdf

6. Monitorando tráfego de rede 22

Figura 6.9: P-cube Service Control MIB Structure

Capítulo 7

Metodologia

Conforme consta no relatório técnico do projeto "Tiradentes Cidade Digital"elaborado por

[da C. Cavalcanti et al. (2006)], a rede foi implantada em duas fases.

Na primeira fase a rede teve uma cobertura limitada, contemplando apenas o centro histórico

da cidade com uma infra-estrutura de quatro pontos de acesso de rede sem �o conectada à

Internet por meio de um link dedicado de 2 MBps, conforme pode ser visto na �gura 7.1.

Já na Figura 7.2 temos uma visão da topologia da rede e a distribuição dos equipamentos.

Podemos ver que o "núcleo"ou a infra-estrutura principal da rede está instalada no prédio da

Prefeitura Municipal, é lá que temos os equipamentos que permitem o controle e gerencia-

mento da rede, e é de lá que parte o link com a Internet.

Figura 7.1: Localização das antenas no início da segunda fase do projeto

Com a rede já em funcionamento foram feitas as primeiras medições e detectadas algumas

limitações e necessidades de gerenciamento da largura de banda da rede tanto no que diz

respeito à infra-estrutura interna quanto ao link externo :

23

7. Metodologia 24

Figura 7.2: Topologia de rede no início da segunda fase do projeto

Medição 1 : Número de usuários simultâneos na rede.

Com relação ao grá�co da �gura 7.3, podemos perceber picos de 60 a 70 usuários

simultâneos ao longo de 7 dias, bem como uma média de 30 a 40 usuários.

Figura 7.3: Usuários simultâneos em função do tempo no início da segunda fase do projeto

Medição 2 : Utilização da largura de banda do link externo.

O link tinha a seguinte con�guração inicial : 2 MBps divididos em duas redes virtuais

(VLANS) sendo 1 MBps destinado à rede "convidados"(moradores e turistas) e 1 MBps

destinado à rede "escolas"(escolas e órgãos públicos). Já nos primeiros dias de utilização

percebeu-se um congestionamento na rede "convidados", ou seja, a mesma estava operando na

maior parte do tempo com 100% de utilização da sua capacidade total (1 MBps). Decidiu-se

então liberar o uso total do link (2 MBps) para a rede "convidados", de forma provisória, a

7. Metodologia 25

�m de se veri�car o nível de utilização.

Com o uso da ferramenta MRTG foi gerado o grá�co (�gura 7.4) onde podemos ver que

a rede "convidados"continua utilizando na maior parte do tempo, quase os 100% do link

destinado a ela, ou seja, agora um link de 2 MBps, principalmente, para o tráfego de entrada.

O grá�co mostra o tráfego relativo a cada dia da semana durante uma semana, tanto para

download (IN) quanto para upload (OUT).

Figura 7.4: Utilização do Link de 2 Mbps por uma semana após a liberação da banda para arede "Convidados"

Medição 3 : Utilização da largura de banda dos links internos.

Foram feitos dois tipos de medições : a) Links entre os rádios (pontos de acesso), b) Links

entre os clientes e os rádios.

O objetivo dessa medição foi tentar diagnosticar o motivo da utilização de quase 100% do

link por parte da rede "convidados", causando congestionamento na rede.

Medição a) : Os links entre os rádios operam conforme o padrão Ethernet 802.11a, a

uma freqüência de 5.8 GHz e um throughput de 18 MBps. Na topologia apresentada havia

link entre todos os rádios em uma con�guração full-mesh. O percentual médio de utilização

medido para cada rádio durante o período de 7 dias foi : 7% - Prefeitura, 6% - Rodoviária,

1% - Igreja Matriz, 1% - EE Basílio da Gama (o rádio Aimorés não foi avaliado). Nesta

sequência são apresentados os grá�cos nas �guras 7.5, 7.6, 7.7 e 7.8 respectivamente. O

ponto de acesso da prefeitura apresentou maior percentual de utilização por ser o nó central

da rede e também de conexão com a Internet.

Medição b) : Já os links entre os clientes e os rádios operam conforme o padrão Ethernet

802.11b/g, a uma freqüência de 2.4 GHz e o througput varia de 1 MBps a 54 MBps. O

percentual médio de utilização medido para cada rádio durante o período de 7 dias foi :

17% - Prefeitura, 20% - Rodoviária, 21% - Igreja Matriz, 9% - EE Basílio da Gama (o rádio

Aimorés não foi avaliado). Nesta sequência são apresentados os grá�cos nas �guras 7.9,

7.10, 7.11 e 7.12 respectivamente.

7. Metodologia 26

Figura 7.5: Grá�co de utilização do rádio da Prefeitura (802.11 a)

Figura 7.6: Grá�co de utilização do rádio da Rodoviária (802.11 a)

Figura 7.7: Grá�co de utilização do rádio da Igreja Matriz (802.11 a)

7. Metodologia 27

Figura 7.8: Grá�co de utilização do rádio da Escola Estadual Basílio da Gama (802.11 a)

Figura 7.9: Grá�co de utilização do rádio da Prefeitura (802.11 b/g)

Figura 7.10: Grá�co de utilização do rádio da Rodoviária (802.11 b/g)

Com base nesses dois tipos de medições constatou-se não haver grandes anormalidades

nos links internos da rede. Observou-se também que os clientes normalmente se distribuíam

da seguinte forma : 41% se conectavam no rádio da Matriz, 31% no da Prefeitura, 21%

no da Rodoviária e 7% no da Escola Basílio da Gama. Além disso, 96% dos clientes

da rede utilizavam a Vlan "Convidados", 2% a Vlan "Escolas"e os outros 2% a Vlan de

7. Metodologia 28

Figura 7.11: Grá�co de utilização do rádio da Igreja Matriz (802.11 b/g)

Figura 7.12: Grá�co de utilização do rádio da Escola Estadual Basílio da Gama (802.11 b/g)

"Vídeo"(Utilizada por câmeras IPs espalhadas pela cidade para monitoramento), posterior-

mente criada.

Medição 4 : Volume de tráfego por aplicação.

Com o uso da ferramenta MRTG veri�cou-se que as aplicações que apresentaram maior

volume de tráfego foram : HTTP, HTTPS, SMTP e IPsec. Seguem nas �guras 7.13, 7.14,

7.15 e 7.16 os grá�cos correspondentes ao tráfego por aplicação.

Feitas as medições, foram tomadas algumas providências no intuito de tentar resolver

o problema de congestionamento no link principal de 2 MBps. Usando o Clean Access

(equipamento que permite o controle de acesso à rede) a larga de banda por usuário foi

limitada inicialmente a 64 KBps (Download e upload) na rede "convidados". Isso resolveu

o problema de congestionamento no link de saída para a Internet mas os usuários �caram

insatisfeitos com o desempenho da rede. Com isso limitou-se a largura de banda por usuário

7. Metodologia 29

Figura 7.13: Tráfego HTTP da Interface FastEthernet0/0 CKT INTERNET NLA/BF/00005

Figura 7.14: Tráfego HTTPS da Interface FastEthernet0/0 CKT INTERNET NLA/BF/00005

Figura 7.15: Tráfego SMTP da Interface FastEthernet0/0 CKT INTERNET NLA/BF/00005

7. Metodologia 30

Figura 7.16: Tráfego IPSEC da Interface FastEthernet0/0 CKT INTERNET NLA/BF/00005

da rede "convidados"a 100KBps, reduzindo o uso da banda a 70% do link, o que ainda não

resolveria o problema do congestionamento uma vez que a rede "escolas"não tinha limitação

e poderia ocupar toda larga de banda do link principal. Após vários testes conclui-se que a

limitação da banda para as duas redes ("convidados"e "escolas") em 100 KBps de download

e 64 Kbps de upload resolveria o problema de congestionamento e não prejudicaria tanto

a performance da rede, satisfazendo os anseios dos usuários. Com isso o tráfego upload

foi reduzido, o que mostra grande utilização de aplicativos do tipo P2P por parte dos usuários.

Na segunda fase do projeto, deu-se a expansão da rede. O objetivo era ampliar a área

de cobertura de forma a atender toda extensão do município de Tiradentes. De imediato

foi instalado um segundo link com Internet de 2 MBps provido por uma outra operadora

e conectado a um segundo roteador de borda, independentes do link original também de 2

MBps, resultando assim num link de 4 MBps com a Internet. Foi também instalado mais um

AP (Access Point) chamado de AP root, ao qual os outros AP's da rede se conectam. Todos

esses equipamentos foram instalados no nó central da rede (no prédio da prefeitura), onde se

concentram os equipamentos de controle e gerencia da rede e de onde parte o link da Internet.

Essa nova topologia de rede (�gura 4.2) proporcionou uma divisão das conexões na rede

interna, bem como uma solução de contingência. A distribuição dos pontos contemplados por

essa expansão por ser vista na �gura 4.1.

Com a expansão da rede o número de usuários simultâneos aumentou consideravelmente, o

que pode ser visto no grá�co da �gura 7.17. E com isso, potenciais problemas poderiam

surgir. Um deles, segundo [da C. Cavalcanti et al. (2006)], já era motivo de preocupação, e se

tratava dos links das operadoras que constantemente trabalhavam em carga máxima, como

pode ser visto pelo grá�co na �gura 7.18, gerado pelo Cisco SCE 1000 (descrito na seção

6.3). O grá�co apresenta os tipos de serviços mais utilizados em função da largura de banda.

7. Metodologia 31

Figura 7.17: Clientes simultâneos por tempo após a expansão da rede

Figura 7.18: Uso da Banda por Tipo de Serviço

Segundo [da C. Cavalcanti et al. (2006)], o Cisco SCE foi uma solução incluída ao projeto

para permitir aos administradores da rede conhecer melhor os tipos de tráfego e de protocolos

que trafegam pela rede, além de permitir também a implantação de políticas de customização e

controle de tráfego, a nível de aplicação, o que não se conseguia com as ferramentas disponíveis.

A seguir descrevemos nossa metodologia para coleta dos dados, análise e caracterização

do tráfego da rede de Tiradentes com o uso do equipamento Cisco SCE 1000. O objetivo

é dar continuidade ao trabalho de medição e controle de tráfego da rede realizado por

[da C. Cavalcanti et al. (2006)], de forma a explorar todos os recursos que o equipamento

oferece. Desta forma, de posse dos dados resultantes da caracterização do tráfego da rede,

será possível tornar a rede "inteligente", otimizando seus recursos e ao mesmo tempo

solucionando o problema de congestionamento no link de saída para a Internet que surgiu

após a expansão da rede. Pois o Cisco SCE 1000 possibilita não somente a análise do tráfego

da rede, mas também permite a aplicação de políticas de customização e controle do tráfego

a nível de aplicação, além de possuir total integração com servidores AAA (Authentication,

Authorization, Accounting), possibilitando o controle de tráfego a nível de usuário.

7. Metodologia 32

Este trabalho se torna necessário visto que a idéia do projeto "Tiradentes Cidade

Digital"não se restringe a apenas prover acesso público à Internet de forma gratuita (ou a

baixo custo) aos usuários e/ou órgãos públicos, mas sim prover um acesso de qualidade à

rede mundial fazendo com que a rede tenha uma boa performance sem que seja necessário

muitos investimentos em sua infra-estrutura. A intenção do projeto também é que a rede

deve possibilitar a disponibilização de serviços para acesso do usuário e gestão dos órgãos

públicos, serviços como e-cidade (software público de gestão municipal), i-educar (software

público de gestão escolar), dentre outros serviços.

Os resultados das medições realizadas por [da C. Cavalcanti et al. (2006)] já apresentadas

nesta seção e seus relatórios; o arquivo de log e relatórios gerados pelo Cisco SCE; e os

relatórios gerados pelo Tra�c Analyzer, sendo esses dois últimos realizados em laboratório

de simulação, compoem a fonte de dados necessária para estabelecer uma metodologia

abrangente na análise e caracterização do tráfego de rede. O objetivo principal dessa

metodologia é delinear um processo sistemático para caracterização de padrões de rede,

especialmente redes Muni-Wi.

O trabalho foi dividido em 4 etapas :

Etapa 1 : Montagem do laboratório de simulação na UFOP.

A simulação em laboratório é necessária uma vez que os testes e medições iniciais

realizados na própria rede da cidade de Tiradentes, antes mesmo da de�nição de uma

metodologia para tal, poderiam comprometer o funcionamento da mesma. É fato também

que a manipulação de uma massa menor de dados em laboratório possibilita melhores resulta-

dos nas medições do tráfego de rede, e com isso uma melhor de�nição em torno das métricas e

parâmetros que devem fazer parte da metodologia, que será futuramente aplicada ao caso real.

Para a montagem do laboratório foi instalada uma sub-rede dentro da rede da UFOP. A

infra-estrutura dessa sub-rede (ou rede local) é mostrada na �gura 7.19, bem como as fotos

do ambiente podem ser vistas na �gura 7.20.

O ambiente de simulação é composto por :

• Um equipamento Cisco SCE (Service Control Engine) 1000, conectado no modo "In-

Line"na rede (ou seja, interligando os dois segmentos da rede), com a MIB p-cube

instalada.

7. Metodologia 33

• Um servidor DELL com sistema operacional UBUNTU Server, rodando VMWare Server

com duas máquinas virtuais :

Windows XP, rodando o Cisco SCA (Service Control Application).

Red Hat Entreprise Linux rodando o Cisco CM (Collection Manager) e o Banco de

dados Sybase).

• Um PC com sistema operacional UBUNTU Server, funcionando como gate-

way/�rewall/NAT conectando a rede local com a rede da UFOP, via duas interfaces

de rede Gigabit Ethernet

• Um notebook e um PC (máquinas clientes).

• Dois switches gerenciáveis 3COM 4500, com quatro interfaces Gigabit Ethernet.

• Dois transceivers do tipo 1000BaseTX/1000BaseFX.

O Cisco SCE 1000 conecta os dois lados da rede (cliente e provedor) por meio de duas portas

GBE (Gigabit Ethernet) para conexões em �bra óptica usando conectores do tipo SC. Por

isso a necessidade de utilização de transceivers Gigabit para converter conexões do tipo par

trançado em conexões de �bra óptica, como também é necessário o uso das interfaces de rede

Gigabit tanto nos switches quanto no gateway da rede local.

Figura 7.19: Infra-estrutura da rede usada na simulação

Etapa 2 : Metodologia proposta para análise dos dados e caracterização do tráfego da

rede.

A metodologia proposta contempla a análise de vários parâmetros classi�cados segundo

um grau de importância, e agrupados em quatro aspectos que são: 1) Vazão, 2) Sessão, 3)

Tipo de tráfego (camada 4) e 4) Tipo de tráfego (camada de aplicação).

A seguir são apresentados os parâmetros a serem analisados, bem como o grau de importância

7. Metodologia 34

Figura 7.20: Fotos do ambiente de simulação.

((I) Essencial, (II) Importante, (III) Desejável) de cada um deles dentro do contexto deste

trabalho :

• Vazão (bps) :

Vazão instantânea (por hora), downstream/upstream (I)

Vazão média (por dia/semana), downstream/upstream (II)

Atraso (delay) (II)

Variação do atraso (Jitter) (III)

Taxa de perda de pacotes (II)

• Sessão :

No de sessões instantâneas (por segundo) (I)

No de sessões instantâneas (por segundo) por usuário (I)

No médio de sessões (por dia/semana) (II)

No médio de sessões (por dia/semana) por usuário (II)

Tamanho médio das sessões (em bytes) (I)

Tamanho médio das sessões (em bytes) por usuário(II)

Tempo médio das sessões (em minutos) (I)

Tempo médio das sessões (em minutos) por usuário(II)

• Tipo de tráfego (camada 4) (TCP/UDP/ICMP) :

No de pacotes (I)

7. Metodologia 35

Bytes enviados/recebidos (I)

Vazão instantânea (por hora) (bps) (II)

• Tipo de tráfego (camada aplicação) (HTTP,POP3,P2P,VOIP...):

No de pacotes (I)

Bytes enviados/recebidos (I)

Vazão instantânea (por hora) (bps) (II)

Etapa 3 : Coleta e análise dos dados.

Para realizar a análise dos dados coletados do tráfego da rede foram utilizadas duas fontes

de dados : 1) Relatórios gerados pelo software Tra�c Analyzer, e 2) Log de tráfego gerado

pelo equipamento Cisco SCE 1000.

Os relatórios do Tra�c Analyzer são úteis para analisar as características físicas do link como

: Atraso (delay), variação do atraso (Jitter) e perda de pacotes.

Já o log do equipamento Cisco permite que sejam analisadas sessões de usuário, protocolos

e aplicações/serviços. Este log é formado basicamente por processos dos �uxos gerados por

aplicações/protocolos. Os principais campos de cada processo são :

- Data/hora de início;

- Duração;

- Endereços IP's envolvidos;

- Protocolo;

- Aplicação;

- Volume de bytes recebidos e enviados.

O Cisco SCE também fornece informações sobre a taxa de utilização da largura de banda

do link, ou seja, a vazão.

Na análise do log, os processos são agrupados em sessões. Uma sessão pode ser de�nida

como sendo um conjunto (ou sequência) de processos (ou pacotes, considerando que cada

processo gera um pacote) de rede que caracterize a troca de informações entre dois hosts com

diferentes endereços IP's, para uma determinada aplicação/protocolo, cuja transação tenha

início, meio e �m, e cujo período de inatividade seja inferior à uma hora.

Etapa 4 : Caracterização do tráfego de rede.

7. Metodologia 36

A partir da análise dos parâmetros acima descritos é possível caracterizar o tráfego de

uma rede e classi�cá-la, por exemplo, como :

- Corporativa empresarial

- Provedor comercial

- Cidade digital

- Ensino/pesquisa

Como por exemplo, [Benson et al. (2010)] em seu trabalho recente onde analisou aspectos

especí�cos como : topologia da rede, �uxo de tráfego de aplicações e pacotes, utilização do

link; descreve o seguinte :

Redes de Universidades : Atendem aos alunos e pessoal administrativo da universidade

em questão. Elas oferecem uma variedade de serviços, que vão do sistema de backups à

hospedagem de sistemas de arquivos distribuídos, servidores de e-mail, serviços da Web (sites

e portais web administrativas para alunos e professores) e streams de vídeo multicast.

Empresas Privadas de TI : Atendem aos usuários corporativos, desenvolvedores, e

um pequeno número de clientes. Ao contrário de redes de universidade, a empresa privada

da suporte a um número signi�cativo de aplicativos personalizados, além de serviços de

hospedagem tradicionais como o e-mail, armazenamento e serviços web. Sua infraestrurura

de rede é projetada especi�camente para atender à demanda da empresa. Por exemplo, uma

empresa foi projetada principalmente para dar suporte a aplicativos personalizados de linha

de negócios e fornecer servidores de login para usuários remotos.

Data-centers comerciais em nuvem : Ao contrário das duas primeiras classes, os

provedores comerciais atendem a usuários externos e oferecem suporte para uma ampla gama

de serviços voltados para a Internet, incluindo: Instant Messaging, Webmail, busca, indexação

e vídeo. Além disso, esses provedores hospedam grandes sistemas internos que suportam os

serviços visíveis externamente, como por exemplo, mineração de dados, armazenamento e

bancos de dados relacionais (por exemplo, para listas de amigos). Estes centros de dados são

muitas vezes propositadamente construído com uma topologia particular para suportar um

conjunto especí�co de aplicações.

Porém, como já mencionado anteriormente, a proposta do nosso trabalho é prover, através

de uma metodologia especí�ca, as bases para uma caracterização do tráfego de rede de forma

mais abrangente envolvendo características físicas do link, utilização / carga de trabalho,

per�l de usuário e de aplicação.

7. Metodologia 37

É possível também comparar padrões de tráfego e padrões de utilização encontrados,

entre diferentes redes ou até mesmo a própria rede que tenha passado por um processo de

mudança ou reestruturação ou alguma in�uência externa. Para esse tipo de comparação

uma sugestão é utilizar distribuições estatísticas dos parâmetros medidos e tentar visualizar

através dos grá�cos, ou ainda, para obter uma comparação ou análise mais precisa, aplicar

o princípio least-square às distribuições encontradas e obter uma resposta aproximada (ou

resposta global).

Capítulo 8

Conclusões

Quando se tem um "gargalo"na rede, ou seja, na maior parte do tempo a rede tem uma taxa

de utilização equivalente à sua capacidade total de link, a caracterização do tráfego dessa

rede pode ser comprometida, pois as características de uma rede saturada são ditas por suas

políticas de tratamento de �las.

A caracterização do tráfego em redes de comunicação de dados para uso genérico como os

usados em projetos de Cidades Digitais e, mais especi�camente, os que usam infra-estrutura

de redes sem �o, também conhecidos como Muni-Wi, são básicos para o dimensionamento e

avaliação tanto da rede como infra-estrutura, como provedora de serviços e seu impacto na

sociedade.

Alguns mecanismos de caracterização de rede foram mostrados neste trabalho, focado em

prover respostas para adequar uma proposta de provimento de acesso genérico com o objetivo

de uma rede aberta e com limitados recursos principalmente a de conexão com a rede

Internet. A partir desta observação, foi de�nida uma determinada metodologia que, baseado

em parâmetros clássicos, responde as questões hoje postuladas.

Como trabalho futuro, faz-se necessário aplicar a metodologia em outros tipos de redes

com o objetivo de encontrar padrões de tráfego. Isto permitirá que, comparando o trafego

de uma rede Muni-Wi qualquer, poder-se-á identi�car o padrão da mesma e assim, como a

mesma está sendo usada. Por exemplo, como a de um provedor comercial de metrópole, de

uma rede de ensino, ou de pesquisa, de uma rede baseada em redes sociais, dentre outras.

38

Capítulo 9

Glossário

AAA : Em segurança da informação, o termo protocolos AAA é uma referência aos protocolos

relacionados com os procedimentos de autenticação, autorização e accounting. A autenticação

veri�ca a identidade digital do usuário de um sistema, a autorização garante que um usuário

autenticado somente tenha acesso aos recursos autorizados e, por �m, a accounting refere-se a

coleta de informações sobre o uso dos recursos de um sistema pelos seus usuários[wik (2010b)].

HTTP (HyperText Transfer Protocol) : é um protocolo de comunicação utilizado

para sistemas de informação de hipermídia distribuídos e colaborativos)[wik (2010b)].

HTTPS (HyperText Transfer Protocol Secure) : é uma implementação do

protocolo HTTP sobre uma camada SSL ou TLS).

IOCTL : abreviação de controle de entrada / saída, é uma chamada de sistema para

operações especí�cas do dispositivo e outras operações que não podem ser expressas por

chamadas do sistema regular. É preciso um parâmetro que especi�ca um código de requisição,

o efeito de uma chamada depende completamente do código da requisição. Os códigos de

requisição são muitas vezes especí�cos do dispositivo. Por exemplo, um driver de CD-ROM

que pode obter um dispositivo físico para ejetar o disco iria fornecer um código de requisição

ioctl para fazer isso. Códigos de requisição independente de dispositivos são algumas vezes

utilizados para dar acesso à camada de usuário para as funções do kernel que são usados

apenas pelo software do sistema central ou ainda em desenvolvimento. A chamada de sistema

"ioctl"apareceu pela primeira vez na versão 7 do Unix sob esse nome. É suportado pela

maioria dos sistemas Unix, Linux e Mac OS X, embora os códigos de requisição disponíveis

diferem de sistema para sistema. O Microsoft Windows fornece uma função semelhante,

chamada "DeviceIoControl", em sua API Win32[wik (2010b)].

MAC (Medium Access Control) : Subcamada da camada de enlace de dados do

39

9. Glossário 40

modelo de referência OSI [Tanenbaum (2006)].

MIB : O conjunto de todos os objetos SNMP (Simple Network Management Protocol) é

coletivamente conhecido como MIB (do inglês: Management Information Base). O standard

SNMP não de�ne o MIB, mas apenas o formato e o tipo de codi�cação das mensagens. A

especi�cação das variáveis MIB, assim como o signi�cado das operações GET e SET em cada

variável, são especi�cados por um padrão próprio[wik (2010b)].

MRTG (Multi Router Tra�c Grapher) : é uma ferramenta de monitoração que

gera páginas HTML com grá�cos de dados coletados a partir de SNMP ou scripts externos.

É conhecido principalmente pelo seu uso na monitoração de tráfego de rede, mas pode

monitorar qualquer coisa desde que o host forneça os dados via SNMP ou script [Tanenbaum

(2006)].

SMTP (Simple Mail Transfer Protocol) : é o protocolo padrão para envio de e-mails

através da Internet.

SOCKET : pode ser usado em ligações de redes de computadores para um �m de um

elo bidirecional de comunicação entre dois programas. A interface padronizada de sockets

surgiu originalmente no sistema operacional Unix BSD (Berkeley Software Distribution);

portanto, eles são muitas vezes chamados de Berkeley Sockets. É também uma abstração

computacional que mapeia diretamente a uma porta de transporte (TCP ou UDP) e mais

um endereço de rede. Com esse conceito, é possível identi�car unicamente um aplicativo

ou servidor na rede de comunicação IP. Em documentos de RFC (Request for Comments)

relacionado a TCP ou UDP, um socket em um computador é de�nido como a combinação de

um endereço IP, um protocolo, e o número da porta do protocolo[wik (2010b)].

TIMESTAMP : é uma seqüência de caracteres indicando a data e / ou horário em que

um determinado evento ocorreu. Um timestamp é a hora em que um evento é registrado

por um computador, e não o tempo do evento em si. Em muitos casos, a diferença pode ser

inconsequente: o momento em que um evento é registrado por um timestamp (por exemplo,

entrou em um arquivo de log) deve ser muito, muito perto do momento da ocorrência do

evento registrado[Tanenbaum (2006)].

Referências Bibliográ�cas

(2009). Information and communications for development : Overview.

http://blogs.worldbank.org/ic4d/.

(2010). Cisco's site. http://www.cisco.com.

(2010). Computer how stu� works. http://computer.howstu�works.com/municipal-wi�.htm.

(2010). Guia das cidades digitais. http://www.guiadascidadesdigitais.com.br/site/.

(2010). Tcpdump/libpcap public repository. http://www.tcpdump.org/.

(2010a). Wikipedia. http://en.wikipedia.org/wiki/Wireshark.

(2010b). Wikipedia. http://en.wikipedia.org.

(2010). Wireshark site. http://www.wireshark.org.

Bagri, A.; Mundhra, M.; Pathak, A. e Raman, B. (2007). Wi�dump - a novel architecture

for wireless network debugging. Communication Systems Software and Middleware.2nd

International Conference, pp. 1�8.

Benson, T.; Akella, A. e Maltz, D. A. (2010). Network tra�c characteristics of data centers

in the wild. ACM, IMC'10.

da C. Cavalcanti, C. F. M.; Falcão, H. M.; Barbosa, C. E. e do C. Oliveira, A. (2006).

Tiradentes digital: Redes em malha sem �o (wmn). Technical report, Universidade Federal

de Ouro Preto.

Dabir, A. e Matrawy, A. (2007). Bottleneck analysis of tra�c monitoring using wireshark.

Innovations in Information Technology.4th International Conference, pp. 158�162.

de O. Ru�no, N. M. (2005). Segurança Nacional Técnicas e Ferramentas de Ataque e Defesa

de Redes de Computadores. Editora Novatec.

Dischinger, M.; Haeberlen, A.; Gummadi, K. P. e Saroiu, S. (2007). Characterizing residential

broadband networks. 7th ACM SIGCOMM conference on Internet measurement, New York,

USA, pp. 43�56.

41

Referências Bibliográficas 42

Marques-Neto, H. T.; do Valle, E. V.; Castilho, L. H.; Almeida, J. M. e Almeida, V. A. F.

(2009). Caracterização hierárquica do comportamento dos usuários de sistemas par-a-par

na internet de banda larga. Anais 27o SBRC, pp. 61�74.

Ângelo Magno de Jesus; da Cunha Cavalcanti, C. F. M.; Ribeiro, F. N. e Falcão, H. M. (2009).

Desenvolvimento de uma ferramenta para análise de tráfegos em redes ip com qualidade de

serviço. Revista de Ciência e Tecnologia do Vale do Mucuri, (1).

Qiang; Zhen-Wei, C. e Rossotto, C. M. (2009). Economic impacts of broadband. Information

and Communications for Development:Extending Reach and Increasing Impact,World Bank,

Washington, DC, pp. 35�50.

Tanenbaum, A. S. (2006). Redes de Computadores. Editora Campus, 4 edição.