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.