Aluno: Fabrício
Vertamatti
Empresa: Rede ANSP (an
Academic Network at São Paulo)
Supervisor: Jorge Yamamoto
Orientador: Prof. Arnaldo Mandel
Esta é a monografia sobre meu estágio na Rede ANSP. Ela esta dividida da seguinte forma:
Primeiramente vou dar uma pequena idéia sobre a empresa em que estagio, a Rede ANSP. A Rede ANSP é um projeto antes vinculado à Fundação de Amparo à Pesquisa do Estado de São Paulo - FAPESP, que agora está vinculado ao Instituto UNIEMP. Sua principal função é a administração e controle da rede acadêmica do estado, mas com o passar do tempo ela está indo além disso. Hoje a Rede ANSP já abriga o Ponto de Troca de Tráfego (PTT) da internet brasileira em São Paulo e vem se tornando também o berço da internet2 no Brasil através do seu principal projeto, AdvancedANSP.
Dentre as atividades realizadas, destacam-se o estudo sobre o tráfego napster na rede acadêmica e o tráfego na rede interna da Fapesp; a experiência para descobrir a fonte de problemas que ocorreram com alguns equipamentos da rede; a implementação do Monitor, um conjunto de scripts e páginas php para o acompanhamento de informações sobre toda a rede; a identificação dos endereços de serviços de chat na rede interna para fim de bloqueio; e a transmissão de eventos do GTER realizados no auditório da FAPESP.
Foi realizada uma pesquisa
nos Estados Unidos que verificou que cerca de 50% do tráfego da
rede entre as universidades americanas eram oriundos de
aplicações napster. Preocupado com essa alta porcentagem, foi
solicitado a mim e ao Antonio, outro estagiário que trabalha
comigo, que realizássemos um estudo no tráfego da nossa rede a
fim de verificar se seria preciso bloquear tal tráfego tal como
seria feito nos EUA.
A partir de então, passei a aprender bastante e a me aprofundar
em ferramentas chamadas sniffers, que realizam dump de tráfego
de rede. No inicio usamos o tcpdump, mas logo passamos
a usar seu
parente com interface gráfica, o Ethereal. Essas
ferramentas nos
acompanham até hoje quando realizamos alguma atividade
relacionada a análise de tráfego de redes.
Para descobrir como o protocolo napster funcionava, e assim
podermos descobrir a forma de medi-lo, montamos um experimento da
seguinte forma: instalamos o cliente napster em duas máquinas e
passamos a executar downloads uma da outra e verificar o tráfego
entre elas com os sniffers. Facilmente identificamos os pacotes
da comunicação dos clientes com o servidor napster. O protocolo
napster funciona de forma bem simples: o cliente requisitante
procura a música comunicando-se com o servidor napster e este
retorna o endereço do cliente que possui o arquivo. Após isso a
comunicação é direta entre os clientes. Porém o que
precisávamos era descobrir como a informação do cliente
possuidor da música era enviada no pacote ao cliente
requisitante. Para descobrir isso, mudamos algumas vezes os ips
das máquinas e verificamos que apenas uma parte do pacote
mudava. Logo descobrimos que era ali que as informações que
procurávamos estava.
Agora tínhamos que medir o tráfego napster e já sabíamos como
o protocolo funcionava e como se apresentavam os pacotes.
Editamos então o fonte do tcpdump para que o mesmo devolvesse a
porcentagem para nós. Felizmente o resultado obtido foi de
apenas 5% (ps.: geralmente era o ip de uma mesma máquina da
unicamp, o que mostra que alguém por lá não estava muito
interessado na faculdade, hehehe) e sendo assim, não houve
necessidade de bloqueio. Mesmo sem a necessidade de bloqueio
devido aos baixos resultados da medição, preparamos uma página
na internet com informações de como se bloquear tráfego
napster. essa página seria passada às universidades para que
cada uma bloqueasse esse tipo de tráfego se fosse preciso.
As disciplinas que tivemos no IME que mais foram úteis nessa
atividade foi Estrutura de Dados pois quando editamos o tcpdump,
contruímos uma árvore binária para guardar os endereços de
tráfego napster e também Redes de Computadores que nos deu
bastante conhecimento sobre estrutura de redes e pacotes de dados
em transmissões.
O Monitor é um conjunto de
scripts e páginas de internet na qual pode-se encontrar todas as
informações sobre a rede inteira conectada na Rede ANSP. As
páginas são geradas automaticamente e os operadores podem
alterar informações, inserir ou remover links e reportar
problemas em cada ponto da rede. Todas as informações sobre a
rede estão num banco de dados SOLID que os scripts e as páginas
do Monitor consultam e atualizam.
As páginas estão disponíveis com todas as funcionalidades
apenas para a rede interna, porém, uma versão aberta somente
com o tráfego de uma parte da rede pode ser acessada
externamente.
As páginas do monitor mostram os links de cada parte da rede
identificados com uma cor de acordo com seu estado. O estado dos
links podem ser diversos, como down, up, saturado, baixo, etc. e
são obtido a partir do programa snmpget. Além disso, o usuário
tem diversas opções disponíveis para cada link como gráficos
do tráfego do link, dos erros e dos drops, informações dos
links e logs. Apenas as estatísticas do tráfego estão
disponíveis nas páginas de abertas ao acesso externo.
Os gráficos de tráfego, drops e erros, são gerados pelo
conjunto de dois programas, o rrdtoole o nrg. O rrdtool
mantém
um arquivo em um formato específico que é a base de dados com
os valores do tráfego de cada link em cada instante e o nrg é
responsável pela geração dos gráficos a partir dessa base de
dados. São páginas em perl cgi que buscam as informações das
bases de dados rrdtool e geram a página. Esses são mais dois
aplicativos que eu tive bastante contato, pois já havia mexido
neles quando a página de gráfico do link internacional
disponível na página da rede ANSP teve seu aplicativo o mrtg
migrado para o nrg.
O nrg a princípio não faz o que nós precisamos em alguns
links, a soma de interfaces de roteadores diferentes. Assim
sendo, entrei em contato com o cara que fez o programa para ver
se ele dava alguma dica. Infelizmente ele não pode ajudar já
que estava muito ocupado e não iria implementar tal
funcionalidade o que nos fez apelar para alguns ajustes em
arquivos .cgi com as páginas dos gráfico na mão mesmo. Deu
certo e hoje sabemos como fazer o que o nrg não faz!
Para gerar todas essas páginas, implementamos uma série de
scripts em perl que consultam o banco de dados e geram as
páginas e geram os arquivos de configuração do rrdtool e do
nrg.
Todos esses scripts estão rodando no crontab periodicamente para
que se tenha as informações da rede constantemente online.
Vocês podem consultar a parte aberta do monitor clicando aqui.
Este projeto foi o que durou mais (ou está durando), quase 6
meses, em todo o tempo que estou na ANSP. Principalmente por ter
ocorrido uma série de pequenas alterações nos objetivos das
páginas, e principalmente algumas mudanças até na estrutura do
banco de dados que atrasou a conclusão do Monitor. Atualmente
ele está pronto, necessitando apenas de eventuais correções
aqui e ali.
As disciplinas que mais se relacionaram com esse projeto foram
Banco de Dados já que tivemos que criar um para armazenar as
iformaçÕes do monitor, Laboratório de Programação II pois a
linguagem utilizada para fazer os scripts foi Perl e
Administração de Sistemas Unix, pois utilizamos diversos
conhecimentos obtidos em tal matéria por exemplo mensagens snmp
usadas pra obter informaçóes dos roteadores.
Outro estudo que fizemos
com análise de tráfego, foi sobre os endereços de serviços de
bate papo na www (chats). Fomos encarregados de descobrir os
principais endereços para que fosse possível bloquear os ips
correspondentes e assim acabar com o bate-papo na rede interna da
Fapesp. Após algumas análises com o Ethereal, os principais
endereços de bate papo tinham sido identificados e foram
posteriormente bloqueados no firewall. Se tinha alguém que
ficava muito no bate-papo, teve que trabalhar mais, hehehe.
Transmissões das reuniões do GT-ER
O Grupo de Trabalho de
Engenharia e Operação de Redes (GT-ER) é um dos grupos
montados sob a égide do Comitê Gestor Internet do Brasil.
Todo ano acontecem reuniões do GT-ER e nas duas últimas
edições, ela ocorreu no auditório da fapesp. Eu e o Antonio
fomos os encarregados da transmissão do evento para o público de
internet no Brasil e no mundo. Para isso, contamos com a
presença de uma equipe de vídeo e áudio responsáveis pelas
filmagens e som que mandariam os sinais de áudio e vídeo pra
nós. Já a gente se encarregou de preparar as máquinas para as
transmissões em multicast e em real player.
Para a transmissão multicast preparamos uma máquina com um
túnel multicast para nossa rede (para podermos transmitir pro
resto do backbone) e criamos uma sessão de vídeo conferência.
Já para o real player, adquirimos uma licensa simples do server
e colocamos ele pra receber conexões da internet.
Mais uma vez a disciplina Laboratório de Programação II foi
bastante útil, já que fizemos uma pequena interface gráfica em
perl/TK para rodar o encoder de imagem.
Foi identificado um
problema com a configuração de equipamentos (2 Netcaches e 1
ServerIron) da nossa rede. Ao se efetuar o download de arquivos
extensos (aproximadamente 20Mb), o donwload parava depois de
algum tempo (geralmente após cerca de 20% de download
concluído).
Nossa rede esta conectada a um ServerIron por onde passa todo
trafego e neste ServerIron estão conectados nossos 2
NetCaches.
Aparentemente o problema estava na configuração de IP spoofing
pois quando essa opção não era setada no ServerIron, tudo
ocorria normalmente.
Para tentarmos identificar
o problema, montamos um experimento com nossos equipamentos, como
segue o esquema ilustrado adiante, e analisamos o tráfego em
alguns pontos.
O experimento montado foi o seguinte: introduzimos um ServerIron
intermediário (ilustrado com ServerIronTeste no esquema abaixo)
entre um micro cliente e o nosso ServerIron e conectamos um dos
NetCaches (que será ilustrado e referido por NetCache2) neste
ServerIronTeste.
Deste modo temos isolados um micro que serviria de cliente, um
ServerIron (o ServerIronTeste no esquema) e um NetCache
(NetCache2 no esquema), tudo isso conectado ao nosso ServerIron
da rede.
O ServerIron da rede deixa passar todo o tráfego deste ambiente
de teste para a Internet.
Observe o seguinte esquema para entender nosso experimento:
Passamos então a analisar tráfegos entre os ServerIrons's e entre o ServerironTeste e o NetCache2 ao realizarmos diversas tentativas de download de um determinado arquivo, um documento da página www.marconi.com.
O que deveria ocorrer para
o download do arquivo seria:
- o computador (ilustrado como microcliente) manda a requisição
para o ServerIronTeste e este manda para o NetCache2. O NetCache2
verifica se possui o arquivo cacheado nele e caso não o tenha,
busca o arquivo no WebServer, passando de volta pelo
ServerIronTeste, deste para o ServerIron da Rede e, por fim,
deste para o webserver de onde queremos baixar o arquivo.
Analisamos o tráfego em
alguns pontos do experimento mais uma vez usando o aplicativo
Ethereal e com bases nos resultados, elaboramos um report para
ser mandado para o suporte das fabricantes dos equipamentos.
Mesmo após algum diálogo com o fabricante, passando todas as
informações solicitadas, eles não conseguiram reproduzir o
problema. Então um dos técnicos do fabricante marcou um
horário com a gente para reproduzirmos o problema. Feito isso,
ele tinha todas as informações necessárias para corrigir o que
estava errado com o equipamento.
Alguns dias depois recebemos um novo release para o software do
equipamento e corrigimos o problema.
A disciplina PCS210 - Redes de Computadores foi muito importante
nessa atividade pois muitas conceitos sobre equipamentos e redes
que utilizamos para realizar o experimento, foram obtidos no
curso de PCS210.
A primeira coisa com que tive contato na ANSP foi com Multicast. Aqui darei uma breve explicação sobre o protocolo Multicast e suas aplicações.
MBone ("Internet Multicast Backbone") é o nome dado à rede virtual que é implementada sobre a rede física da Internet e utiliza transmissão IP Multicast. O MBone é constituído de "hosts" (microcomputadores, estações de trabalho, roteadores, etc.), capazes de transmitir IP Multicast e a principal vantagem é a economia na largura de banda das linhas de comunicação de dados da rede Internet. O IP Multicast difere no intervalo de endereço IP utilizado; em vez de utilizar endereços IP classe A, B ou C, utiliza o classe D (endereços IP de 224.0.0.0 a 239.255.255.55). Esta distinção de endereço permite que um "host" envie pacotes para um subconjunto de todos os "hosts" (transmissão para grupo), em contraste com o IP tradicional que utiliza transmissão "unicast", transmitindo pacotes para um único "host", ou transmissão "broadcast", transmitindo para todos os "hosts".
Unicast
Multicast
A transmissão em IP Multicast, possibilita a distribuição eficiente de pacotes de dados, minimizando a probabilidade de ocorrencia de congestionamento na linha devido à multiplicação de dados repetidos, como ocorre na transmissão de um programa de vídeo ou audio em IP "unicast". Em outras palavras, em vez de transmitir várias cópias de um programa de vídeo ou audio para vários destinatários, o MBone trabalha no esquema "take one and pass it along", ou seja, se no final de uma linha dedicada, há vários usuários querendo a mesma programação, por ela só passará uma única cópia desta programação e n o final da linha, esta cópia será replicada para os vários usuários solicitantes.
O
MBone atualmente é formado de várias ilhas, isto é, redes que
utilizam IP Multicast, unidas através de túneis lógicos pela
Internet. Os túneis são utilizados para que os pacotes
multicast possam passar através de redes que fazem o roteamento
multicast. Isso é feito com o encapsulamento do pacote com um
cabeçalho IP, endereçado ao outro lado do túnel. Durante o
caminho, esse pacote é tratado como um pacote unicast. Quando
chegar ao roteador multicast no destino, o cabeçalho IP
adicional é retirado, restando apenas o pacote multicast
original.
Protocolos de roteamento multicast
Como o uso de multicast não é compreendido em todos os roteadores na Internet, a topologia do MBone difere da topologia da Internet. Com isso, os roteadores multicast precisam executar um protocolo de roteamento multicast para descobrir para onde enviar os datagramas. O protocolo mais utilizado no MBone é o Distance Vector Multicasting Routing (DVMRP). Porém, outros são também utilizados, como o Multicast Open Shortest Path First (MSOPF) e o Protocol Independent Multicast (PIM), que interoperam com os roteadores DVMRP.
Distance Vector Multicasting Routing Protocol (DVMRP)
O roteador multicast baseado no DVMRP mantém o conhecimento topológico através de um protocolo de roteamento de vetor de distâncias, sobre o qual é implementado um algoritmo de transmissão multicast chamado Truncated Reverse Path Broadcasting.
Os roteadores DVMRP tratam a topologia do Mbone como um domínio único. Cada roteador mantém uma entrada na tabela de roteamento para cada subrede no Mbone e troca mensagens de roteamento periodicamente com cada um de seus vizinhos identificando todas as subredes.
Multicast Open Shortest Path First (MOSPF)
A extensão multicast para o protocolo de roteamento IP Open Shortest Path First (OSPF) é denominada Multicast Open Shortest Path First (MOSPF). O protocolo OSPF é baseado no estado dos enlaces, diferente do RIP, que é baseado na contagem dos nodos. Uma rede de roteadores utilizando MOSPF pode enviar pacotes multicast diretamente, enviando não mais que uma cópia por cada enlace, e sem a necessidade de túneis.
O MOSPF transmite os datagramas IP multicast da origem para os vários membros do grupo sem formar laços, gerando uma árvore. Esta árvore tem como raiz o nodo origem do datagrama, e todos os “braços” terminam em membros do grupo. Seguindo a filosofia multicast, o datagrama é replicado apenas quando surge uma divisão, um braço, na árvore. Este esquema de roteamento, onde o caminho dos datagramas depende da origem e dos destinos, já que a árvore possui raiz na origem, é denominado source/destination routing. Ele é diferente da maioria dos algoritmos de roteamento unicast, incluindo o OSPF, que se baseiam somente no destino do datagrama ao fazer o roteamento. A necessidade de considerar a origem para tomar as decisões do roteamento causa maior quantidade de cálculos de roteamento, porém resulta em melhores caminhos em termos de utilização da rede e atraso para membros individuais do grupo.
Protocol Independent Multicast (PIM)
Quando membros de um grupo e transmissores para este grupo estão distribuídos esparsamente numa ampla área, o esquema utilizado pelo DVMRP e pelo MOSPF não são muito eficientes. O tráfego de dados multicast (no DVMRP) ou o relatório de informação dos membros do grupo (no MOSPF) são periodicamente enviados sobre muitos enlaces que não conduzem a clientes do grupo. Além disso, estes esquemas de roteamento foram desenvolvidos para uso dentro de regiões onde um grupo é amplamente representado, ou vasta largura de banda é disponível. Existe um protocolo que foi desenvolvido com o objetivo de estar apto para rotear pacotes multicast sem ser dependente dos esquemas de roteamento IP unicast básicos como o DVMRP (baseado no RIP) e o MOSPF (baseado no OSPF): o Protocol Independent Multicasting (PIM).
O PIM trata também algumas das questões de escalabilidade relacionadas à distribuição esparsa de amplas áreas usado no MBone. Ele possui dois modos: o Sparse Mode PIM, um protocolo de difusão seletiva que é otimizado para um grupo que está distribuído em diferentes regiões da Internet, e o Dense Mode PIM, que é otimizado para grupos com membros próximos.
Para que sua rede esteja no backbone multicast, é preciso que o roteador multicast, mrouted, esteja rodando em algum micro da rede e que este possua um túnel com a rede com quem voce quer se comunicar via este protocolo. O mrouted é free e pode ser facilmente instalado em quaquer máquina UNIX.
A principal aplicação de Multicast é a realização de vídeo-conferências. Alguns aplicativos utilizados para este fim são o vic, sdr e rat. O sdr é responsável pela administração das ses´ões de vídeo-conferência e o vic e o rat tratam da transmissão de vídeo e áudio respectivamente.
Chegamos a fazer uma página sobre o Multicast. Você pode dar uma olhada nela aqui.
Ao final do ano passado, participei de um curso técnico na UNICAMP sobre o funcionamento e implementação de VLANs (Virtual LANs) no switch 8274 da IBM. O curso foi realizado durante o VI Seminário de Capacitação Interna da RNP (rede Nacional de Pesquisa) e foi ministrado por Luis Eduardo Souza Coelho com carga horária de 14 horas.
Esse curso foi bastante importante para mim pois temos na nossa rede um switch desse modelo e com o treinamento, pude aprender bastante como mexer no equipamento. Algumas das atividades que realizei com o Antonio necessitou justamente que operássemos o 8274.
Forma de organização da equipe de trabalho e atribuição de responsabilidades; e acompanhamento por parte dos supervisores
Bem, na Rede ANSP, não há uma atribuição específica de trabalho bem definida. Eu e o Antonio normalmente trabalhamos juntos em quase tudo, dividindo assim nós mesmos o que cada um faz, como foi o caso do projeto do Monitor. Mas às vezes, é solicitado para a gente que realizemos pequenas tarefas individualmente também.
Tratando-se do pessoal que trabalha comigo, diria que todos são super atenciosos e procuram passar o máximo de ajuda e informações para mim e para o Antonio. Sempre que preciso eu pergunto para algum dos outros funcionários e eles me esclarecem todas as vezes, indicando a forma de fazer algo ou como alguma coisa funciona.
O nosso supervisor (chefe) no estágio agora é o professor Jorge Yamamoto que assumiu o cargo deixado pelo professor Milton que foi quem nos contratou e deixou a empresa alguns meses atrás. Ambos foram muito atenciosos, sempre procurando ensinar muito no que era necessário. Quando o professor Jorge começou a trabalhar na ANSP, ele solicitou que apresentássemos um seminário sobre todas as atividades que já havíamos realizado para que ele pudesse estar a par de nosso trabalho na ANSP.
Desafios e frustrações encontrados
Sem dúvida o meu principal desafio na ANSP foi o projeto do monitor. Eu e o Antonio fizemos tudo, sempre com a orientação de outros funcionários para que o monitor viesse a ter a funcionalidade necessária.
Não creio que haja alguma frustração no meu estágio. Talvez o fato de que em algumas oportunidades, ficamos sem nada pra fazer por alguns dias. Quando isso acontece, eu procuro ler alguns artigos relacionados com o nosso serviço, principalmente multicast e UNIX.
Ferramentas e técnicas utilizadas
As ferramentas que mais utilizamos foi sniffers. Sniffer é um aplicativo capaz de mostrar o tráfego ethernet passando pelo micro. No começo usávamos o tcpdump, porém depois passamos a utilizar o Ethereal, que possui interface gráfica. Todos as atividades que necessitavam de análise de tráfego foram realizadas com o uso de um desses dois aplicativos.
Para implementação de código, usei principalmente Perl. Além do que aprendi no IME, muito importante também foi observar e entender os scripts que já haviam sido implementados pelo pessoal anteriormente na ANSP. Algumas técnicas de programação em Perl eu aprendi desse modo.
Outros aplicativos que usei bastante foram aplicativos baseado em snmp, dentre eles as ferramentas que constroem gráficos de acordo com informações obtidas através de snmp, como por exemplo rrdtool e seu frontend nrg. Diria que já domino esses dois aplicativos, sendo que tive inclusive contato com seus donos.
Conceitos estudados no IME e disciplinas aplicadas ao estágio
Como já procurei frisar anteriormente, as disciplinas mais utilizadas foram as relacionadas a redes de computadores, banco de dados e estruturas de dados e linguagem de programação perl. Porém, creio que quase todas as outras disciplinas, de alguma forma, foram úteis como por exemplo Grafos e Otimização Combinatória que se aplicam nos protocolos multicast.
Futuro
Pretendo continuar na empresa por mais alguns anos ainda até que o projeto da Advanced ANSP de implementação da internet2 no Brasil se conclua. Com isso terei bastante experiência em redes de alta velocidade e internet e terminarei o meu curso de mestrado. Após isso, tenho a idéia de ir para o exterior e possivelmente seguir para outra área provavelmente ligada a otimização.
