MINISTÉRIO DA DEFESA
EXÉRCITO BRASILEIRO
DEPARTAMENTO DE CIÊNCIA E TECNOLOGIA
INSTITUTO MILITAR DE ENGENHARIA
SEÇÃO DE ENGENHARIA DE COMPUTAÇÃO
DIEGO NASCIMENTO MAIA
IMPLEMENTAÇÃO DE UM SIMULADOR DE ROTEADOR UTILIZANDO MÁQUINAS VIRTUAIS
Rio de Janeiro
2010
2
INSTITUTO MILITAR DE ENGENHARIA
DIEGO NASCIMENTO MAIA
IMPLEMENTAÇÃO DE UM SIMULADOR DE ROTEADOR UTILIZANDO MÁQUINAS VIRTUAIS
Monografia de Projeto de Fim de Curso apresentada ao
Curso de Engenharia de Computação do Instituto Militar
de Engenharia, como requisito parcial para obtenção do
grau final da disciplina de Projeto de Fim de Curso.
Orientador: Maj Sérgio dos Santos Cardoso Silva – M. Sc.
Rio de Janeiro
2010
3
INSTITUTO MILITAR DE ENGENHARIA
Praça General Tibúrcio, 80 – Praia Vermelha
Rio de Janeiro – RJ CEP 22290-270
Este exemplar é de propriedade do Instituto Militar de Engenharia, que poderá incluí-lo em
base de dados, armazenar em computador, microfilmar ou adotar qualquer forma de
arquivamento.
É permitida a menção, reprodução parcial ou integral e a transmissão entre bibliotecas deste
trabalho, sem modificação de seu texto, em qualquer meio que esteja ou venha a ser fixado,
para pesquisa acadêmica, comentários e citações, desde que sem finalidade comercial e que
seja feita a referência bibliográfica completa.
Os conceitos expressos neste trabalho são de responsabilidade dos autores e do orientador.
M217i Maia, Diego Nascimento.
Implementação de um simulador de roteador utilizando máquinas
virtuais/ Diego Nascimento Maia – Rio de Janeiro: Instituto Militar de
Engenharia, 2010.
83 p. : il.
Monografia de Projeto de Fim de Curso – Instituto Militar de
Engenharia, 2010.
1. Engenharia de computação – projeto de fim de curso. 2. Redes de
computadores. I. Implementação de um simulador de roteador utilizando
máquinas virtuais. II. Instituto Militar de Engenharia.
CDD 004.6
4
INSTITUTO MILITAR DE ENGENHARIA
DIEGO NASCIMENTO MAIA
IMPLEMENTAÇÃO DE UM SIMULADOR DE ROTEADOR
UTILIZANDO MÁQUINAS VIRTUAIS
Monografia de Projeto de Fim de Curso apresentada ao Curso de Engenharia de
Computação do Instituto Militar de Engenharia.
Orientador: Maj Sergio dos Santos Cardoso Silva – M. Sc.
Aprovada em 13 de agosto de 2010 pela seguinte Banca Examinadora:
______________________________________________________________
Maj Sergio dos Santos Cardoso Silva – M. Sc. - Presidente
______________________________________________________________
Cap Anderson Fernandes Pereira dos Santos – D. Sc.
______________________________________________________________
Maj Ronaldo Moreira Salles – Ph.D.
Rio de Janeiro
2010
5
Dedico este trabalho aos meus pais Edvar e Rosenilde,
pelo exemplo e valor aos estudos e ao trabalho, e a
minha namorada Juliana, por sua compreensão e apoio
para obtenção de um resultado positivo.
6
AGRADECIMENTOS
Aos amigos e companheiros de estudo de Projeto de Fim de Curso, Bruno Fraga e
Ranmsés, por compartilharem conhecimento para o desenvolvimento deste trabalho.
Aos professores, especialmente ao Maj Sérgio Cardoso, pela exemplar contribuição e
orientação para o desenvolvimento desta monografia, permitindo a obtenção de resultados
positivos.
Ao amigo Marcelo Salhab, pela orientação para o desenvolvimento da interface web.
À todos aqueles que, direta ou indiretamente, colaboraram para que este trabalho
atingisse os objetivos propostos.
7
“Eu acredito, eu luto até o fim: não há como perder,
não há como não vencer.”
OLEG TAKTAROV
8
SUMÁRIO
AGRADECIMENTOS ............................................................................................................. 6
SUMÁRIO ................................................................................................................................. 8
LISTA DE ILUSTRAÇÕES .................................................................................................. 12
LISTA DE TABELAS ............................................................................................................ 13
LISTA DE SIGLAS ................................................................................................................ 14
RESUMO ................................................................................................................................ 15
ABSTRACT ............................................................................................................................ 16
1 INTRODUÇÃO .......................................................................................................... 17
1.1 FINALIDADE .............................................................................................................. 17
1.2 OBJETIVOS ................................................................................................................. 18
2 VIRTUALIZAÇÃO ................................................................................................... 19
2.1 TÉCNICAS DE VIRTUALIZAÇÃO .......................................................................... 20
2.1.1 Virtualização total ........................................................................................................ 20
2.1.2 Paravirtualização .......................................................................................................... 22
2.2 VANTAGENS E DESVANTAGENS DA VIRTUALIZAÇÃO ................................. 24
2.2.1 Vantagens ..................................................................................................................... 24
2.2.2 Desvantagens ................................................................................................................ 25
2.3 VIRTUALIZAÇÃO DA INFRA-ESTRUTURA DE REDE ....................................... 25
2.4 FERRAMENTAS DE VIRTUALIZAÇÃO ................................................................. 26
2.4.1 VMware ........................................................................................................................ 26
2.4.1.1 Adaptadores de rede no VMware ................................................................................. 27
2.4.1.1.1 Brigded ...................................................................................................................... 28
2.4.1.1.2 NAT ........................................................................................................................... 28
2.4.1.1.3 Host-only ................................................................................................................... 28
2.4.1.2 Outros Produtos da VMware ........................................................................................ 28
9
2.4.2 Xen ............................................................................................................................ 29
2.4.3 QEMU .......................................................................................................................... 29
2.4.4 KVM ............................................................................................................................ 30
2.4.5 Hyper-V ........................................................................................................................ 31
2.4.6 VirtualBox .................................................................................................................... 31
3 PROTOCOLOS DE ROTEAMENTO ..................................................................... 32
3.1 ALGORITMOS DE ROTEAMENTO ......................................................................... 32
3.2 TERMOS E DEFINIÇÕES .......................................................................................... 33
3.3 ROUTING INFORMATION PROTOCOL (RIP) ......................................................... 33
3.3.1 Funcionamento ............................................................................................................. 33
3.3.2 RIPv1 ............................................................................................................................ 34
3.3.3 RIPv2 ............................................................................................................................ 34
3.3.4 Problemas do roteamento por vetor distância .............................................................. 35
3.4 OPEN SHORTEST PATH FIRST (OSPF) ................................................................... 36
3.4.1 Funcionamento ............................................................................................................. 36
3.4.2 Tipos de mensagem ...................................................................................................... 38
3.5 BORDER GATEWAY PROTOCOL (BGP) .................................................................. 39
3.5.1 Características .............................................................................................................. 40
3.5.2 Tipos de mensagem ...................................................................................................... 40
4 SOFTWARES DE ROTEAMENTO ........................................................................ 42
4.1 CISCO IOS ................................................................................................................... 42
4.1.1 Características .............................................................................................................. 42
4.1.2 Vantagens ..................................................................................................................... 44
4.1.3 Desvantagens ................................................................................................................ 44
4.2 QUAGGA ..................................................................................................................... 45
5 ESTUDO DE CASO ................................................................................................... 48
5.1 OBJETIVO ................................................................................................................... 48
5.2 AMBIENTE ................................................................................................................. 48
5.3 TESTES ........................................................................................................................ 49
5.3.1 Configuração da rede ................................................................................................... 49
5.3.1.1 Rotas estáticas .............................................................................................................. 49
10
5.3.1.2 RIP ............................................................................................................................ 52
5.3.1.3 OSPF ............................................................................................................................ 54
5.4 SIMULAÇÃO .............................................................................................................. 55
5.4.1 Interfaces de rede ......................................................................................................... 55
5.4.2 Análises de mensagens ................................................................................................. 55
5.4.2.1 Desligamento de interface ............................................................................................ 56
5.4.2.2 Atribuição de endereço a uma nova interface .............................................................. 57
5.5 ROTEADOR FÍSICO E VIRTUAL EM UMA MESMA REDE ................................ 58
5.6 CONSIDERAÇÕES ..................................................................................................... 59
5.6.1 Conseqüências da cópia de máquina virtual ................................................................ 59
5.5.1.1 Traceroute ..................................................................................................................... 60
5.5.1.2 PING ............................................................................................................................ 60
5.6.2 Quagga VS. Cisco IOS ................................................................................................. 60
6 INTERFACE WEB .................................................................................................... 62
6.1 FRAMEWORK DJANGO ........................................................................................... 62
6.2 FUNCIONAMENTO ................................................................................................... 63
6.3 PÁGINAS WEB ........................................................................................................... 63
6.3.1 Primeiro grupo de páginas ............................................................................................ 64
6.3.1.1 PING ............................................................................................................................ 64
6.3.1.2 Traceroute ..................................................................................................................... 65
6.3.1.3 Route ............................................................................................................................ 65
6.3.2 Segundo grupo de páginas ............................................................................................ 65
6.3.2.1 Enable Mode ................................................................................................................ 65
6.3.2.2 Config Int ..................................................................................................................... 66
6.3.2.3 Config Router ............................................................................................................... 66
7 CONCLUSÃO ............................................................................................................ 67
8 REFERÊNCIAS BIBLIOGRÁFICAS ..................................................................... 68
9 APÊNDICES ............................................................................................................... 71
9.1 APÊNDICE 1: DESCRIÇÃO DE TOPOLOGIAS ...................................................... 71
9.1.1 FIG. 5.3 ........................................................................................................................ 71
9.1.2 FIG. 5.4 ........................................................................................................................ 72
11
9.1.3 FIG. 5.5 ........................................................................................................................ 73
9.2 APÊNDICE 2: COMANDOS ...................................................................................... 75
9.2.1 tshark ............................................................................................................................ 75
9.2.2 Autenticação remota sem senha ................................................................................... 76
10 ANEXOS ..................................................................................................................... 77
10.1 ANEXO 1:MENSAGENS OSPF ................................................................................. 77
10.1.1 Cabeçalho OSPF .......................................................................................................... 77
10.1.2 HELLO ......................................................................................................................... 77
10.1.3 DATABASE DESCRIPTION...................................................................................... 78
10.1.4 LINK STATE UPDATE .............................................................................................. 78
10.1.5 Formato do cabeçalho para anúncios de estados de enlace .......................................... 78
10.2 ANEXO 2: ARQUIVOS .............................................................................................. 79
10.2.1 Desligamento de interface ............................................................................................ 79
10.2.2 Reativação de interface ................................................................................................ 79
10.2.3 Pacotes HELLO ............................................................................................................ 79
10.2.4 Outros anúncios ............................................................................................................ 79
10.2.5 Pacote de descrição de banco de dados ........................................................................ 79
10.3 ANEXO 3: MANUAL QUAGGA ............................................................................... 79
10.4 ANEXO 4: CÓDIGO-FONTE DA INTERFACE WEB ............................................. 79
10.5 ANEXO 5: PAGINA WEB .......................................................................................... 80
10.5.1 Página Ping ................................................................................................................... 80
10.5.2 Página Traceroute ......................................................................................................... 81
10.5.3 Página Route ................................................................................................................ 81
10.5.4 Página Enable Mode ..................................................................................................... 82
10.5.5 Página Config Int ......................................................................................................... 83
10.5.6 Página Config Router ................................................................................................... 83
12
LISTA DE ILUSTRAÇÕES
FIG. 2.1 Esquema de paginação, com p sendo o número de páginas a percorrer na tabela de
página, d o deslocamento de página e f o endereço base da página na memória física ........... 22
FIG. 2.2 Um MMV controlando uma virtualização total e uma paravirtualização ................. 23
FIG. 3.1 Problema da contagem até infinito ............................................................................ 35
FIG. 3.2 Analogia entre a topologia de rede em estrela (a) e o roteamento entre áreas (b) ..... 37
FIG. 3.3 Relação entre SAs, backbones e áreas no OSPF ....................................................... 38
FIG. 4.1 Modos de operação no Cisco IOS .............................................................................. 44
FIG. 4.2 Funcionamento do protocolo TELNET ..................................................................... 46
FIG. 4.3 Arquitetura do Quagga ............................................................................................... 46
FIG. 5.1 Topologia da rede para testes com rotas estáticas ..................................................... 50
FIG. 5.2 Representação de uma rede conectada a interface “eth2” dos roteadores da FIG 5.1 51
FIG. 5.3 Topologia para primeira etapa de testes com RIP ..................................................... 53
FIG. 5.4 Topologia para segunda etapa de teste com RIP ....................................................... 53
FIG. 5.5 Topologia do Laboratório de Redes do Instituto Militar de Engenharia ................... 56
FIG. 5.6 Representação do teste envolvendo roteador físico e virtual ..................................... 58
FIG. 10.1 Página Ping .............................................................................................................. 80
FIG. 10.2 Página Traceroute .................................................................................................... 81
FIG. 10.3 Página Route ............................................................................................................ 81
FIG. 10.4 Página Enable Mode ................................................................................................ 82
FIG. 10.5 Página Config Int ..................................................................................................... 83
FIG. 10.6 Página Config Router ............................................................................................... 83
13
LISTA DE TABELAS
TAB. 3.1 Características das versões do protocolo RIP .......................................................... 34
TAB. 3.2 Tipos de mensagens OSPF ....................................................................................... 39
TAB. 3.3 Tipos de mensagens básicas definidas pelo BGP ..................................................... 41
TAB. 4.1 Linhas adicionadas no arquivo /etc/services ............................................................ 47
TAB. 5.1 Resultado do teste entre um roteador físico e um virtual ......................................... 58
TAB. 5.2 Exemplo de uma traceroute executado a partir de uma máquina-roteador .............. 60
TAB. 5.3 Exemplo de uma traceroute executado a partir de uma máquina-roteador logo após
o exemplo de TAB. 5.2 ............................................................................................................ 60
TAB. 5.4 Exemplos de comandos que não disponíveis no Quagga ......................................... 61
TAB. 9.1 Comandos para captura de pacotes através do tshark .............................................. 75
TAB. 10.1 Formato do cabeçalho OSPF .................................................................................. 77
TAB. 10.2 Formato da mensagem HELLO OSPF ................................................................... 77
TAB. 10.3 Formato da mensagem DATABASE DESCRIPTION OSPF ................................ 78
TAB. 10.4 Formato da mensagem LINK STATE UPDATE OSPF ........................................ 78
TAB. 10.5 Formato do cabeçalho para anúncios de estados de enlace .................................... 78
14
LISTA DE SIGLAS
API Application Programming Interface
BGP Border Gateway Protocol
EGP Exterior Gateway Protocol
IGP Interior Gateway Protocol
IME Instituto Militar de Engenharia
IOS Internetwork Operating System
IP Internet Protocol
MMV Monitor de Máquina Virtual
OSPF Open Shotest Path First
RIP Routing Internet Protocol
SA Sistema Autônomo
SO Sistema Operacional
TI Tecnologia da Informação
TCP Transmission Control Protocol
VTY Virtual TeletYpe
15
RESUMO
O estudo prático de roteamento em redes de computadores requer uma infra-estrutura de
rede, formada por roteadores e switches. Principal componente para formar essa infra-
estrutura, o roteador é um equipamento de alta complexidade, responsável por definir como
informação se comportará em uma rede. Tal complexidade acarreta em um elevado custo
deste equipamento.
Neste contexto, este trabalho propõe uma nova abordagem para a infra-estrutura de rede.
Esta abordagem consiste na substituição de um roteador por uma máquina virtual com um
software de roteamento instalado. Este software mantém a tabela de roteamento do núcleo do
sistema operacional atualizada através de uma interface de linha de comando semelhante à
oferecida pelos roteadores da CISCO Systems Inc., empresa dominante do mercado mundial
de roteadores. Desta forma, uma infra-estrutura de rede composta por roteadores físicos pode
ser substituída por uma formada por máquinas virtuais, proporcionando redução de gastos
relacionados à manutenção dos roteadores.
Para verificação da viabilidade do objetivo deste trabalho, testes foram realizados
aplicando protocolos de roteamento (RIP e OSPF) em topologias de rede composta por
máquinas virtuais. Em seguida, foi realizada uma simulação da topologia do Laboratório de
Redes do Instituto Militar de Engenharia, com objetivo de analisar do comportamento de cada
roteador e o conteúdo das informações trocadas pelos roteadores. Por fim, um teste foi
realizado com intuito de verificar o comportamento de um roteador físico e um roteador
virtual em uma mesma topologia.
Uma interface web foi elaborada para este fim com intuito de proporcionar ao
administrador da rede uma melhor opção para gerenciar a rede.
16
ABSTRACT
The routing practical study on network computer requires a network infrastructure,
consisted of routers and switches. The main component to build this infrastructure, the routers
is a high complex equipment, responsible for define the information’s behavior. This
complexity justifies the high cost of this equipment.
In this context, this work proposes a new approach for a network infrastructure. This
approach consists on replacing a router for a virtual machine with a software routing suite.
This software keeps the kernel routing table updated through of the operating system
command line interface similar to routers of the CISCO Systems Inc., the most prominent
router manufacturer. Therefore, a network infrastructure with physical routers can be replaced
for one with virtual machines, providing cost cutting related to maintenance of routers.
To verify the feasibility of this work, tests were done applying some routing protocols
(RIP and OSPF) in network topologies formed by virtual machines. Then, it was performed a
simulation of the Networks Laboratory of the Military Institute of Engineering aiming the
behavior’s analysis of each router and the content of information exchanged by the routers.
Ultimately, a test was performed in order to validate the behavior of the physical router and
the virtual router in the same topology.
A web interface was prepared for this purpose in order to afford to network administrator
one better option to manage the network.
17
1 INTRODUÇÃO
1.1 FINALIDADE
É comum uma organização ou empresa estar interessada em otimizar seus recursos
visando economia ou mais investimento para crescimento. Existem empresas que adotam a
política de possuir um serviço por máquina, seria interessante disponibilizar para os usuários
dos sistemas da empresa serviços, como email, servidor web ou banco de dados
compartilhando uma única máquina.
Através da técnica de virtualização, é possível um melhor aproveitamento das máquinas
em termos de processamento, uma vez que haverá desperdício de processamento caso haja
apenas um serviço por máquina. Uma máquina real poderá suportar algumas máquinas
virtuais, com configurações de hardware idênticas a da máquina real, com a peculiaridade de
todas as máquinas virtuais compartilharem os recursos da máquina real. Com isso, os recursos
da máquina física poderão ser empregados por completo.
Empresas atuantes na área de redes de computadores que disponibilizam serviços de
internet, como acesso à Internet e serviços de email, e que possuem roteadores que
encaminham informações para o destino adequado, podem aliar a virtualização a um software
de roteamento para Linux, que uma vez instalado e devidamente configurado, a máquina
passará a ter características similares a de um roteador. Essa união mostra-se um meio
interessante para a validação de novas aplicações a serem inseridas na topologia de uma
empresa com esse perfil.
Além do meio empresarial, esse recurso de virtualização com roteamento pode ser
aplicado em escolas e universidades. Tendo em vista o alto custo de roteadores, a
virtualização permite que instituições de ensino possuam uma estrutura virtual de redes,
fornecendo aos alunos a possibilidade de estudos em redes de computadores sem necessidade
de aquisição de roteadores por parte da instituição.
Também pode ser citado como redução de custo ao utilizar-se esse recurso os gastos
referentes à energia elétrica, cabeamento, espaço físico, além de responsáveis por realizar
suportes às máquinas e administradores de rede.
18
1.2 OBJETIVOS
Este projeto tem como objetivo implementar a simulação de roteadores em máquinas
virtuais. Desta maneira, será possível simular um laboratório de redes para testes de
roteamento, além de auxiliar em práticas de ensino em redes de computadores.
Para se obter sucesso nesta empreitada, os seguintes objetivos específicos serão atingidos:
• Estudar virtualização, abrangendo técnicas, formas, ferramentas disponíveis no
mercado, vantagens e desvantagens da opção de se utilizar máquinas virtuais;
• Instalar e configurar ferramentas de virtualização adequadas para o projeto;
• Instalar e configurar máquinas virtuais;
• Preparar ambiente para roteamento através da instalação do software livre
Quagga;
• Estudar software de roteamento Quagga;
• Configurar roteadores para realizar testes de roteamento;
• Simular roteamento com roteadores virtuais;
• Estudar framework web Django para monitoramento de redes que envolvam os
roteadores virtuais;
• Instalar e configurar o Django para monitoramento de redes;
• Desenvolver uma interface web para permitir ao administrador da rede possa
visualizar e editar as configurações do roteador.
19
2 VIRTUALIZAÇÃO
O conceito de máquina virtual pode ser visto de duas maneiras: como uma camada de
software situada entre o hardware da máquina física e o sistema operacional (SO), conhecido
como monitor de máquina virtual (MMV) (Smith e Nair, 2005), que proporciona um
ambiente completo semelhante à máquina física, possuindo cada máquina virtual seu próprio
SO, bibliotecas e aplicativos; ou podem funcionar como uma aplicação sendo executada em
modo usuário, conhecida como máquina virtual de processo.
Apesar de o conceito de virtualização ter sido desenvolvido no início dos anos 70, este
tem sido tema de destaque no mundo da tecnologia da informação (TI). Com objetivo de
executar um software legado1 (Sommerville, 2007) em um computador (mainframe), que já
possuía um SO de fábrica. A empresa multinacional IBM (International Business Machine)
começou a utilizar essa abordagem com sucesso através da linha mainframe 370 e em seus
sucessores, essa linha fornecia máquina virtual para diversos ambientes computacionais
(plataformas), através das quais as aplicações poderiam ser executadas.
Com o tempo, a virtualização deixou de ser interessante, uma vez que os computadores se
popularizaram. Cada SO possuía um público-alvo e aplicativos específicos. Entretanto, o
poder de processamento dos computadores atuais somada ao desenvolvimento do conceito de
sistemas distribuídos em alta e a evolução das redes de computadores geraram um novo
interesse pelo tema virtualização.
No início do século XXI, a maioria dos sistemas computacionais está interligada através
de uma rede, e essa interligação proporciona aos administradores de sistemas a manutenção
de uma gama de servidores heterogêneos, com suas respectivas aplicações, podendo ser
acessadas por diferentes clientes.
É normal encontrarmos infra-estruturas de rede que adotam a política de ter um servidor
por serviço, utilizada por facilidade de suporte, segurança relacionada à diversidade de
clientes, entre outras. Adotando essa política, o serviço costuma não aproveitar toda a
capacidade do processador, ocasionando uma perda do investimento. Este também é um dos
motivos pelo qual a virtualização voltou a ser considerada como uma opção interessante,
tendo em vista que ela soluciona problemas relacionados a desperdício.
1 Software legado – Programa antigo que possui importância na atualidade.
20
Ambientes com diversidade de plataformas de software podem ser beneficiados pela
virtualização, sem a necessidade de várias máquinas físicas. Isso permite que cada aplicação
possa ser executada em uma máquina virtual própria. Desta maneira, a virtualização oferece
portabilidade e flexibilidade, proporcionando que aplicações, de sistemas operacionais
distintos, sejam executadas em uma única máquina. Percebe-se o conceito da consolidação de
servidores, que ocorre quando executamos múltiplas instâncias de máquinas virtuais em uma
única máquina real, utilizando de maneira eficiente o poder de processamento do hardware.
A partir da flexibilidade e da portabilidade citada anteriormente, pode-se desenvolver
softwares destinados a diversos sistemas operacionais sem a utilização de uma máquina física
para desenvolver e testar cada um deles. Com isso, ambientes de desenvolvimento e de teste
são utilizados sem afetar a máquina física, caracterizando o isolamento das máquinas virtuais
em relação à máquina em que ela está instalada.
Percebendo a importância da virtualização, os fabricantes de processadores têm inserido
em seus projetos tecnologia destinadas especialmente para dar suporte a virtualização com o
intuito de não perder mercado, sabendo que as organizações estão investindo continuamente
em virtualização de máquinas. Este investimento pode ser notado quando são utilizados
ferramentas de virtualização que necessitam de características específicas do processador.
Um dos problemas da virtualização reside no fato de as máquinas virtuais serem
simuladas em outro ambiente computacional. Portanto, sua utilização incorre em queda de
desempenho.
2.1 TÉCNICAS DE VIRTUALIZAÇÃO
Existem duas técnicas de virtualização: a virtualização total e a paravirtualização. Em
ambas as técnicas, o SO que será instalado sobre o MMV é denominado de SO hóspede. Na
virtualização total, o SO sobre o hardware é denominado SO hospedeiro.
2.1.1 Virtualização total
Nesta técnica, o MMV proporciona a máquina virtual uma abstração idêntica ao hardware
subjacente, ou seja, o sistema operacional hóspede estará sendo executado como se estivesse
em uma infra-estrutura de hardware real. O software de virtualização é o responsável por
instalar no sistema operacional hóspede os dispositivos necessários para que as máquinas
21
virtuais possam interagir com os dispositivos físicos da máquina. Dessa maneira, o sistema
operacional hóspede não precisa ser alterado.
O fato de não precisar alterar o SO hóspede ocasiona alguns inconvenientes. O primeiro
deles é que por haver uma tentativa de fazer com que o SO hóspede pareça estar diretamente
sobre o hardware do SO hospedeiro, há a necessidade também de implementar o
comportamento exato de cada dispositivo. Assim, seria necessário que o MMV fosse capaz de
suportar esses diferentes tipos de dispositivos.
A solução para esse problema consiste em deixar o MMV hábil para suportar uma classe
genérica de dispositivos. Normalmente, cada MMV possui os seguintes dispositivos: teclado,
mouse PS/2, unidades floppy, controladores IDE, cd-rom, portas seriais e paralelas, uma placa
gráfica padrão e as placas de redes comuns para computadores.
Um segundo problema é que as instruções sensíveis (Tanembaum, 2009) executadas pelo
SO hóspede devem ser testadas pelo MMV para verificar se a instrução veio do SO hóspede
ou de algum programa de usuário local antes de serem executadas diretamente no hardware.
Este teste representa um custo de processamento.
O terceiro e último inconveniente reside no fato de a MMV ter que resolver problemas
técnicos por causa da implementação dos SOs, como memória virtual. Ela é implementada
através da paginação2 (Silberschatz, 2000), que utiliza políticas de acessos às páginas. A FIG.
2.1 ilustra o esquema de paginação de um processo do processador (CPU).
Em um SO que não utiliza o recurso de virtualização, apenas esse SO teria a necessidade
de converter o endereço virtual em endereço físico. Com a virtualização, o MMV terá que
gerenciar uma maior quantidade de SO na conversão para um endereço real, ou seja, na
conversão do espaço de endereço do SO hóspede, disputando recursos com outros hóspedes.
Esta gerência também acarreta em uma queda de desempenho.
2 Paginação – Esquema de gerenciamento de memória que utiliza blocos de tamanhos iguais chamados de página. Quando um processo é executado, o processador irá, através do endereço virtual referente ao processo, acessar uma página em uma tabela que formará o endereço físico. A memória física, assim, será acessada através deste.
FIG. 2.1 Esquema de paginação, com p sendo o número de páginas a percorrer na tabela
de página, d o deslocamento de página e f o endereço base da página na memória física
2.1.2 Paravirtualização
Esta técnica de virtualização modifica o código
vez de executar instruções sensíveis, que poderiam levar a alguma falha do SO hospedeiro,
ele faz chamadas ao MMV. Nesse caso, o SO hóspede atua como um programa do usuário
quando faz chamadas ao SO.
O MMV define uma interface composta por um conjunto de chamadas aos procedimentos
que o SO possa utilizar, conhecida como
Na virtualização total, quando ocorre uma instrução sensível, o
interrupção para o MMV que emula a instrução e retorna o resultado. Já na paravirtualização,
em vez de ocorrer uma instrução sensível, quando é necessária a execução de uma operação
de entrada e saída, por exemplo, o SO faz uma chamada ao MMV par
realizada, como um programa aplicativo que realiza chamada ao SO.
22
Esquema de paginação, com p sendo o número de páginas a percorrer na tabela
de página, d o deslocamento de página e f o endereço base da página na memória física
ização modifica o código-fonte do SO hóspede de maneira que, em
vez de executar instruções sensíveis, que poderiam levar a alguma falha do SO hospedeiro,
ele faz chamadas ao MMV. Nesse caso, o SO hóspede atua como um programa do usuário
O MMV define uma interface composta por um conjunto de chamadas aos procedimentos
que o SO possa utilizar, conhecida como API (Application Programming Interface).
Na virtualização total, quando ocorre uma instrução sensível, o hardware
interrupção para o MMV que emula a instrução e retorna o resultado. Já na paravirtualização,
em vez de ocorrer uma instrução sensível, quando é necessária a execução de uma operação
de entrada e saída, por exemplo, o SO faz uma chamada ao MMV para que a operação seja
realizada, como um programa aplicativo que realiza chamada ao SO.
Esquema de paginação, com p sendo o número de páginas a percorrer na tabela
de página, d o deslocamento de página e f o endereço base da página na memória física
fonte do SO hóspede de maneira que, em
vez de executar instruções sensíveis, que poderiam levar a alguma falha do SO hospedeiro,
ele faz chamadas ao MMV. Nesse caso, o SO hóspede atua como um programa do usuário
O MMV define uma interface composta por um conjunto de chamadas aos procedimentos
Application Programming Interface).
hardware cria uma
interrupção para o MMV que emula a instrução e retorna o resultado. Já na paravirtualização,
em vez de ocorrer uma instrução sensível, quando é necessária a execução de uma operação
a que a operação seja
Esta técnica modifica o núcleo
necessário executar uma instrução sensível do SO hóspede, uma vez que o
não compreende essas chamadas. Esses procedimentos, chamados de
Interface) compõem uma camada de baixo nível que faz a interface entre o
o MMV.
Na FIG.2.2 é apresentado um caso em que um MMV controla tanto uma vi
total com uma paravirtualização. Neste caso, existe apenas um programa em execução no
hardware. A parte da esquerda da FIG.
pelo SO não modificado e tratá
oferece serviços básicos do núcleo, é responsável por receber chamadas geradas pelo MMV
com um SO modificado.
FIG. 2.2 Um MMV controlando uma virtualização total e uma paravirtualização
Quando executado em um MMV, o SO hóspede está ligado a sua respectiva biblioteca
que faz chamadas ao MMV. (Tanenbaum
3 Núcleo – Centro das atividades realizadas pelo sistema operacional. Está entre o SO e o hardware da máquina. É composto por arquivos em linguagens de programação C e Assembly. Controla os dispositivos e periféricos do sistema.
23
Esta técnica modifica o núcleo3 do SO para chamar procedimentos especiais quando for
necessário executar uma instrução sensível do SO hóspede, uma vez que o
não compreende essas chamadas. Esses procedimentos, chamados de VMI
) compõem uma camada de baixo nível que faz a interface entre o
é apresentado um caso em que um MMV controla tanto uma vi
total com uma paravirtualização. Neste caso, existe apenas um programa em execução no
. A parte da esquerda da FIG. 2.2 trata de interpretar as instruções sensíveis geradas
pelo SO não modificado e tratá-las. Na parte da direita, o denominado micronúcleo, que
oferece serviços básicos do núcleo, é responsável por receber chamadas geradas pelo MMV
Um MMV controlando uma virtualização total e uma paravirtualização
Quando executado em um MMV, o SO hóspede está ligado a sua respectiva biblioteca
Tanenbaum, 2009)
Centro das atividades realizadas pelo sistema operacional. Está entre o SO e o hardware da máquina. o por arquivos em linguagens de programação C e Assembly. Controla os dispositivos e periféricos do
do SO para chamar procedimentos especiais quando for
necessário executar uma instrução sensível do SO hóspede, uma vez que o hardware nativo
VMI (Virtual Machine
) compõem uma camada de baixo nível que faz a interface entre o hardware ou com
é apresentado um caso em que um MMV controla tanto uma virtualização
total com uma paravirtualização. Neste caso, existe apenas um programa em execução no
trata de interpretar as instruções sensíveis geradas
minado micronúcleo, que
oferece serviços básicos do núcleo, é responsável por receber chamadas geradas pelo MMV
Um MMV controlando uma virtualização total e uma paravirtualização
Quando executado em um MMV, o SO hóspede está ligado a sua respectiva biblioteca
Centro das atividades realizadas pelo sistema operacional. Está entre o SO e o hardware da máquina. o por arquivos em linguagens de programação C e Assembly. Controla os dispositivos e periféricos do
24
2.2 VANTAGENS E DESVANTAGENS DA VIRTUALIZAÇÃO
2.2.1 Vantagens
É comum uma organização possuir um servidor de Internet, um de arquivos, um de
correio eletrônico, todos funcionando em máquinas diferentes, conectados por uma rede de
alta velocidade. Um dos motivos para isso ocorrer é a confiança nas máquinas. Se um
servidor falhar, os outros não seriam afetados. Ainda que essa escolha seja uma solução de
tolerância à falhas, ela custa e possui complicações de gerenciamento por conta de se tratar de
um número alto de máquinas.
A utilização de máquinas virtuais adotando a política de um serviço por máquina é uma
boa solução para o caso descrito anteriormente, caracterizando a característica de isolamento
das máquinas virtuais. Nessa abordagem, a falha em uma das máquinas virtuais não provoca a
queda das outras.
Além do isolamento, as máquinas virtuais possuem outras vantagens, como as descritas a
seguir. (MENASCÉ, 2005)
Segurança: Dividir ambientes com diferentes requisitos de segurança em máquinas
virtuais distintas permite a seleção de um SO hóspede e de ferramentas que são mais
adequadas para cada ambiente. Ademais, as máquinas virtuais estão isoladas uma as outras,
portanto, um ataque a segurança em uma máquina virtual não compromete as outras.
Confiança e disponibilidade: Uma falha provocada por um software em uma máquina
virtual não afeta as outras máquinas virtuais. Assim, estas não terão sua disponibilidade
afetada.
Custo: É possível obter reduções de custos consolidando pequenos servidores em
servidores mais poderosos. Isto deriva de reduções em termos de pessoal, de licença de
softwares, além das já citadas anteriormente referente à diminuição de máquinas físicas.
Balanceamento de Carga: Estando a máquina virtual totalmente encapsulada pelo
MMV, é relativamente fácil migrar as máquinas virtuais para outras plataformas, a fim de
melhorar o desempenho.
Suporte a aplicações legadas: Se uma organização decidir migrar para um SO diferente,
é possível executar os aplicativos antigos em uma máquina virtual com o SO antigo,
reduzindo o custo de migração.
25
2.2.2 Desvantagens
A virtualização também possui o seu lado negativo. Como as máquinas virtuais estão em
uma máquina física hospedeira, aquelas estarão totalmente dependentes desta. Se a máquina
física falhar, as máquinas virtuais instaladas nelas poderão ser danificadas. Além disso, outras
desvantagens podem ser observadas.
Gerenciamento: Os ambientes com a tecnologia de virtualização necessitam ser
constantemente instanciados, monitorados, configurados e salvos. Para isso, é necessário um
investimento em produtos de virtualização.
Desempenho: Ao inserirmos uma camada de software, o MMV, entre o hardware e o
SO, gerará um custo de processamento maior ao que se teria se não houvesse virtualização.
Há de se destacar também que não há certeza com relação a quantas máquinas virtuais podem
ser executadas por processador sem que haja perda da qualidade do serviço.
Pelo o que foi mencionado, as vantagens citadas superam as desvantagens,
principalmente pelo custo, verificando a validade deste trabalho.
2.3 VIRTUALIZAÇÃO DA INFRA-ESTRUTURA DE REDE
Podemos estender o conceito de máquina virtual para equipamentos de interconexão e de
interligação entre redes. Se percebermos atentamente, uma máquina virtual se comporta com
relação à interconexão à rede como um sistema real, pode-se fazer a ligação a switches e
roteadores como se fossem máquinas físicas diferentes. Isso se justifica pelo fato de as
interfaces de redes virtuais se comportarem como interfaces reais com endereços físicos
diferentes, além de possuir endereços IP distintos.
Em se tratando de virtualização de infra-estrutura de rede, há necessidade de fazer
referência ao par TUN/TAP, que são drivers de dispositivos virtuais disponíveis nos diversos
SOs. O conceito desse par aparece normalmente no contexto de redes privadas virtuais (VPN
–Virtual Private Network) ou junto ao conceito de acesso remoto.
26
A função do par TUN/TAP é simular o comportamento da camada de rede e de enlace4.
O TAP simula um dispositivo Ethernet5 para que informações sejam trafegadas enquanto o
TUN executa o roteamento, portanto uma aplicação pode utilizar o TUN/TAP para enviar e
receber dados.
No envio, os dados são encaminhados para uma pilha de protocolos de rede como se eles
fossem advindos de uma fonte externa. A recepção é semelhante. Quaisquer pares de
aplicações podem enviar e receber dados utilizando drivers TUN/TAP como se estivessem
tratando com um dispositivo externo.
Equipamentos de interconexão de redes, como os roteadores, não fazem parte das
máquinas virtuais, mas podem ser simulados. Através do software de roteamento Quagga para
Linux, será possível proporcionar essa simulação. A seção 4.2 descreve este software.
(CARISSIMI, 2008)
2.4 FERRAMENTAS DE VIRTUALIZAÇÃO
Existem diversas ferramentas que podem ser utilizadas como MMV. As principais serão
listadas a seguir, dando uma maior ênfase àquela utilizada por este projeto, o VMware.
2.4.1 VMware
Esta ferramenta possui uma estrutura de virtualização completa, com produtos
compreendendo desde desktops a data-centers organizados em categorias como gestão e
automatização, virtualização de plataformas e infra-estrutura virtual. Cada uma dessas
categorias possui um conjunto específico de produtos com diferentes finalidades.
O VMware atua como uma aplicação do SO hospedeiro, portanto podem funcionar como
máquina virtual de processo. O suporte necessário para os diferentes tipos de dispositivos de
entrada e saída é fornecido pelo SO hóspede, solução conhecida como Hosted Virtual
Machine Architecture.
O VMware instala um driver de dispositivo específico (VMDriver) propiciando com que
as máquinas virtuais acessem os drivers de dispositivo do SO hóspede. Através de uma
bridged ethernet virtual, todos os quadros ethernet são recebidos e reencaminhados para o SO
hóspede.
4 Enlace – Ligação entre dois elementos de uma rede.
5 Ethernet - Tecnologia utilizada na interconexão em redes locais.
27
Esta ferramenta permite que o usuário escolha um adaptador apropriado para cada
máquina virtual, podendo ser bridged, NAT ou host-only, que serão apresentadas na seção
2.4.1.1. Cada máquina virtual criada no VMware Server possui no mínimo um adaptador de
rede, que inicia-se como brigded. Como, possivelmente, as máquinas-roteadores utilizadas no
presente trabalho se comunicarão com mais de uma máquina, quer seja uma máquina
caracterizada por ser roteador quer não, devem ser incluídos adaptadores de redes de acordo
com a quantidade de interfaces desejadas.
Os adaptadores podem ser configurados através do Manage Virtual Networks, para
Windows, ou para Linux com o script /usr/bin/vmware-config.pl.
O VMware disponibiliza um servidor DHCP interno que fornece endereço IP para as
máquinas virtuais que utilizam adaptador de rede Host-Only ou NAT.
No caso do SO hóspede ser Windows, o Manage Virtual Network do VMware permite
adicionar ou remover e configurar os adaptadores de rede virtuais, configurar o NAT e
configurar DHCP6 para cada um destes. Sendo Linux, a configuração do servidor DHCP de
um adaptador vmneti deve ser realizada através do arquivo
/etc/vmware/vmneti/dhcpd/dhcpd.conf.
2.4.1.1 Adaptadores de rede no VMware
O VMware disponibiliza três tipos de conexões entre a máquina hóspede e a hospedeira,
são elas: bridged, NAT e host-only.
Componentes de uma rede virtual, os adaptadores de rede funcionam como um switch
virtual, que, como um switch físico, permite a comunicação com outros componentes da rede.
O VMware Server, MMV utilizado para este projeto, permite que haja até dez adaptadores de
rede, no caso do SO hóspede for Windows. No caso de ser Linux, é possível ter um total de
255 destes. Estes adaptadores são denominados pelo VMware de vmneti, sendo que i varia de
acordo o SO iniciando em zero.
Mais de uma máquina virtual pode ser conectada em cada adaptador. Para SO hóspede
Windows, não há limitação de conexões, ou seja, o switch virtual possuirá infinitas portas
disponíveis para se ligar com máquinas virtuais. Sendo Linux, há a limitação de 32 portas
disponíveis.
6 DHCP - Dynamic Host Configuration Protocol, protocolo que pode ser implementado, seguindo o modelo
cliente-servidor, para obtenção de endereço IP para o cliente através de trocas de mensagens com servidor.
28
Segue uma breve apresentação dos adaptadores de rede citados:
2.4.1.1.1 Brigded
Conecta a máquina virtual a rede utilizando o adaptador da máquina hospedeira. Caso a
máquina hospedeira esteja numa rede Ethernet, a máquina virtual consegue acesso a essa
rede.
Ela torna visível a máquina virtual aos outros computadores da rede e eles podem se
comunicar diretamente com a máquina virtual.
Como padrão do VMware, a primeira interface virtual, ou adaptador de rede, denominada
vmnet0 é classificada como bridged.
2.4.1.1.2 NAT
Através deste adaptador de rede, um conjunto de máquinas virtuais poderá acessar a rede
externa utilizando apenas um endereço. E evitará que máquinas de uma rede externa realizem
conexões com alguma máquina virtual. Este adaptador é uma interessante opção para
proporcionar segurança ao SO da máquina virtual, caso este não tenha software de proteção.
2.4.1.1.3 Host-only
Cria uma rede inteiramente contida dentro da máquina hospedeira. Este tipo de adaptador
permite que uma conexão de rede entre a máquina virtual e a máquina hospedeira, utilizando
um adaptador visível do sistema operacional da máquina hospedeira.
2.4.1.2 Outros Produtos da VMware
Produtos relacionados à gestão e automatização permitem uma gerência automatizada e
centralizada a todos os recursos da infra-estrutura virtual, garantindo o monitoramento do
sistema.
Produtos de infra-estrutura virtual auxiliam a monitoração e gerenciam como os recursos
serão alocados entre as máquinas virtuais de maneira a atender os requisitos.
29
Os produtos de virtualização de plataforma têm a finalidade de criar a máquina virtual.
Podemos citar como exemplos de produtos desta categoria o VMware ESX Server 3, o
VMware ESX Server 3i, VMware Virtual SMP, VMware VMFS, VMware Server, VMware
Workstation, VMware Fusion e o VMware Player. É importante salientar que tanto o
VMware Server como o VMware Player são gratuitos e o produto que será adotado no
presente trabalho será o Server 2.0.1.(Vmware, 2009)
2.4.2 Xen
Esta ferramenta se originou no Laboratório de Computação da Universidade de
Cambridge como parte do projeto XenoServer em 2001. O objetivo deste projeto seria criar
uma infra-estrutura pública para computação distribuída, além de criar um sistema onde
plataformas de execução do XenoServer estariam distribuídas por diferentes partes do planeta
para uso de qualquer membro do público-alvo.
Quando o projeto XenoServer fosse concluído, seus usuários enviariam um código para
ser executado e seriam taxados pelos recursos utilizados durante a execução.
Em 2004, a empresa XenSource é fundada para promover o MMV de código aberto Xen
no meio empresarial. No fim deste ano surge o Xen 2.0 com boa flexibilidade na configuração
de dispositivos virtuais de entrada e saída dos SO hóspede.
O Xen 3.0, em 2006, introduziu uma camada de abstração para tecnologias de
virtualização de hardware oferecidas pela Intel e AMD. Em 2007, a empresa Citrix System
Inc. adquiriu a XenSource.
Em sua origem, utilizava a técnica de paravirtualização, a partir da versão 3.0, esta
ferramenta passou a oferecer a técnica de virtualização total. (Xen, 2010)
2.4.3 QEMU
Este software de código aberto pode funcionar como emulador ou virtualizador.
Utilizando-o como emulador, ele faz com que aplicativos específicos para alguns SOs sejam
executados em outros. O QEMU possui um bom desempenho por utilizar uma técnica
denominada tradução dinâmica, que converte partes do código para que o processador execute
em um conjunto de instruções.
Como emulador, o QEMU pode funcionar em dois modos:
30
• Emulação total do sistema: Emula todo o SO, inclusive o processador e
periféricos. Sendo possível emular diversos SO em um SO hospedeiro.
• Emulação no modo de usuário: Opção disponível apenas para SO Linux. Neste
modo, o emulador pode executar processos em outra plataforma, além da que ele é
compilado
Quando usado como virtualizador, ele possui um bom desempenho por utilizar o
driver KQEMU, que permite que as instruções da máquina virtual sejam executadas
diretamente sobre o processador da máquina física. (QEMU, 2010)
2.4.4 KVM
O KVM (Kernel-based Virtual Machine) é uma versão modificada do QEMU, ou seja,
também é um software livre para Linux. Essa modificação possui o intuito de aumentar a
velocidade de virtualização, se comunicando diretamente com processador.
Com arquitetura x86 contendo extensões de virtualização (Intel VT ou AMD-V), esta
ferramenta necessita de alguns módulos para suportar a virtualização total, dois deles são para
processadores Intel e AMD, o kvm-intel.ko7 e kvm-amd.ko, respectivamente. É composto de
um módulo de núcleo carregável, kvm.ko, que fornece a infra-estrutura de virtualização e
junto com o módulo do processador específico citado anteriormente. (KVM, 2010)
A vantagem desta ferramenta consiste em aproveitar das características do processador
apresenta, pois comunicação direta com o núcleo acelera o tempo de resposta do processador.
Entretanto, é necessária a verificação da compatibilidade da máquina para suportar o
KVM, através do comando “egrep '(vmx|svm)' --color=always /proc/cpuinfo”. O processador da
máquina deve possuir extensões de virtualização x86. Para o caso de máquinas Intel, a flag8
vmx deve estar presente. A flag svm deve estar entre as flags das máquinas com processadores
AMD.
7 .ko – kernel object, representa um módulo do núcleo. Normalmente, o nome do módulo indica o dispositivo a
que se oferece suporte. 8 Flag – Representação binária com a função de sinalizar determinadas condições produzidas pela execução de
instruções, além de controlar execuções realizadas pelo processador.
31
2.4.5 Hyper-V
O Windows 2008 Server Hyper-V é a evolução do Microsoft Virtual Server 2005 para
atender a novas demandas e explorar a arquitetura de 64 bits, processadores com mais de um
núcleo e meios de armazenamento. Entre suas principais características estão as ferramentas
para automatizar o processo de virtualização, como o Manager Physical-to-Virtual (P2V),
que auxilia na conversão de servidores físicos para virtuais. (Hyper-V, 2010)
2.4.6 VirtualBox
Ferramenta de código aberto desenvolvido pela Sun Microsystems que permite
virtualização em arquiteturas x86. O VirtualBox pode ser utilizado em ambiente Linux,
Windows, OpenSolaris e Macintosh. Assim como o VMware, o software possui suporte a
pastas compartilhadas, permitindo que pastas da máquina hospedeira sejam compartilhadas
com a máquina hóspede, facilitando a troca de arquivos entre elas.
A instalação e configuração são realizadas através do VBoxManage, ferramenta
disponibilizada pelo VirtualBox, para o gerenciamento das máquinas virtuais. No caso de
servidores, deve-se utilizar o VBoxHeadless para inicialização. Deste modo, inicia-se uma
sessão em que a máquina virtual pode ser acessada remotamente. (VirtualBox, 2010)
32
3 PROTOCOLOS DE ROTEAMENTO
Os protocolos de roteamento são utilizados para determinar a melhor rota entre as
disponíveis para um destino. Esta escolha é realizada por meio da combinação de
características da rede com os algoritmos de roteamento, que juntos decidem por qual
caminho a informação seguirá.
3.1 ALGORITMOS DE ROTEAMENTO
Os algoritmos de roteamento podem ser estáticos ou dinâmicos (TANENBAUM, 2003).
São exemplos do tipo estático:
• Roteamento pelo caminho mais curto: simples e prático, possui a idéia de criar
um grafo9 da sub-rede, com cada roteador sendo representado por um nó do grafo e cada
arco indicando uma linha de comunicação. A rota escolhida entre um determinado par de
roteadores seria o caminho mais curto entre eles no grafo;
• Inundação: envia a informação por todas as rotas possíveis. Isso gera um alto
fluxo de pacotes na rede, acarretando em pacotes duplicados. Existem medidas para
evitar este problema como um contador para cada transição entre roteadores. Este
algoritmo escolhe sempre o caminho mais curto, tendo em vista que todos os caminhos
possíveis são selecionados em paralelo.
São exemplos de algoritmos de roteamento dinâmico:
• Roteamento com vetor distância: mantém um vetor com a melhor distância
conhecida até cada roteador e determina para qual caminho deve ser seguido para atingir
o destino. Esse vetor é atualizado através da troca de informações com os roteadores
vizinhos;
• Roteamento por estado de enlace: cada roteador é considerado capaz de
descobrir o estado de enlace até seus vizinhos (ativo ou inativo) e o custo de cada enlace
(alguma métrica definida, como retardo ou distância física), ou seja, o roteador toma
conhecimento das características do enlace.
9 Grafo – Estrutura composta por um conjunto finito não-vazio de vértices (nós) e um conjunto de pares não-ordenados de arestas.
33
• Roteamento hierárquico: roteadores são divididos em regiões, sendo que cada
um sabe em detalhes como enviar pacotes para roteadores dentro de sua região, contudo
sem possuir informações sobre a estrutura interna das outras regiões.
3.2 TERMOS E DEFINIÇÕES
Antes de descrever os principais protocolos, serão apresentadas algumas definições
importantes para compreensão dos protocolos.
• Sistema autônomo (SA) - É um grupo de redes e roteadores gerenciados por
uma única autoridade administrativa, em termos de roteamento;
• Broadcast – Processo de difusão de informação em que todas as máquinas da
rede receberão as informações enviadas;
• Multicast – Entrega de informação para um grupo de destinatários;
• Salto – Considera-se um salto a transição entre roteadores.
Os protocolos de roteamento podem classificados em duas categorias, pode ser um
Interior Gateway Protocol (IGP), protocolo de roteamento utilizado para comunicação
interna em um sistema autônomo; ou um Exterior Gateway Protocol (EGP), que provem
informações de alcançabilidade entre dois ou mais sistemas autônomos.
3.3 ROUTING INFORMATION PROTOCOL (RIP)
O RIP é um protocolo IGP com implementação do roteamento por vetor de distâncias.
3.3.1 Funcionamento
Utilizando o algoritmo de roteamento por vetor de distâncias, este protocolo fornece a
menor distância até cada destino e especifica qual caminho para se chegar até lá. As entradas
deste vetor contêm informações referentes ao caminho preferencial a ser utilizado para atingir
o destino e outra com a distância até o destino.
O protocolo RIP utiliza o número de saltos como métrica para a distância, com uma
limitação de 15 saltos para essa métrica. Essa limitação apresenta uma desvantagem
relacionada ao tamanho da rede.
34
Inicialmente as entradas desse vetor são as redes diretamente conectadas. Com o tempo,
ao trocarem mensagens RIP, os roteadores irão atualizar a tabela de roteamento e novas
entradas serão acrescidas na tabela.
As mensagens RIP são trocadas com os vizinhos, aproximadamente, a cada 30 segundos.
Caso um roteador não receba mensagens de um roteador vizinho durante 180 segundos, este
será considerado inatingível. Esses valores são padrões, mas podem ser alterados.
A vantagem deste protocolo reside na simplicidade de configuração e na sua
implementação.
3.3.2 RIPv1
O RIP possui duas versões. O RIPv1 realiza anúncios na rede através de broadcast, ou
seja, todos os roteadores receberão os pacotes RIP, não apenas os roteadores habilitados com
RIP. Trata-se de um inconveniente uma vez que insere muito tráfego na rede. Além disso,
essa versão não implementa o envio da máscara de sub-rede juntamente com as rotas. Outra
característica desta versão consiste na inexistência de proteção contra a inserção de roteadores
não autorizados, em outras palavras, não há mecanismo de autenticação.
3.3.3 RIPv2
No RIPv2, para evitar o aumento desnecessário do processamento dos hosts, os anúncios
da rede são realizados por multicast. Outra alteração ocorre no suporte a máscara de sub-rede.
Em termos de segurança, esta versão implementa um mecanismo de autenticação que permite
que somente roteadores identificados são capazes de anunciar as respectivas informações. Na
TAB 3.1 são sumarizadas as características citadas.
TAB. 3.1 Características das versões do protocolo RIP
RIP v1 RIP v2
Anúncios Através de broadcast Efetua multicast
Máscara de sub-rede Não envia Envia
Mecanismo de autenticação de
roteadores
Não possui Possui
3.3.4 Problemas do roteamento por vetor distância
O protocolo RIP precisa manipular três tipos de erros causados pelo algoritmo de
roteamento por vetor distância. O primeiro o
de encaminhamento explicitamente, o RIP precisa considerar que os envolvidos podem ser
confiáveis ou tomar precauções para evitar esses ciclos.
Em segundo, este tipo de roteamento usado pelo RIP pode criar
convergência lenta ou contagem para o infinito, em que surgem inconsistências posto que as
mensagens de atualização de roteamento se propagam lentamente através da rede. Escolher
um número pequeno como infinito, como os 16 citados anteriorm
convergência lenta, mas não elimina. E
FIG. 3
O problema da convergência lenta pode ocorrer com qualquer protocolo que utilize o
algoritmo de roteamento com vetor de distância em que as mensagens de atualização são
enviadas aos pares de rede de destino e a distância para essa rede.
Este problema ocorre, por exemplo, quando uma conexão falha a um destino específico
através de um roteador. Antes que este roteador propague aquele destino como inatingível,
outros roteadores têm conhecimento de uma rota para atingir o destino. Aqui se inicia um
ciclo que levará a contagem de saltos até o máximo possível.
No caso da FIG. 3.1, C, D e E sabem que deve passar pro B para atingir A. Se A falhar, B
vai verificar que C conhece uma rota para A, que
contagem até o infinito.
35
do roteamento por vetor distância
O protocolo RIP precisa manipular três tipos de erros causados pelo algoritmo de
roteamento por vetor distância. O primeiro ocorre uma vez que o algoritmo não detecta ciclos
de encaminhamento explicitamente, o RIP precisa considerar que os envolvidos podem ser
confiáveis ou tomar precauções para evitar esses ciclos.
Em segundo, este tipo de roteamento usado pelo RIP pode criar
convergência lenta ou contagem para o infinito, em que surgem inconsistências posto que as
mensagens de atualização de roteamento se propagam lentamente através da rede. Escolher
um número pequeno como infinito, como os 16 citados anteriormente, ajuda a limitar a
convergência lenta, mas não elimina. Esse problema é mostrado na FIG 3.1
3.1 Problema da contagem até infinito
O problema da convergência lenta pode ocorrer com qualquer protocolo que utilize o
algoritmo de roteamento com vetor de distância em que as mensagens de atualização são
enviadas aos pares de rede de destino e a distância para essa rede.
re, por exemplo, quando uma conexão falha a um destino específico
através de um roteador. Antes que este roteador propague aquele destino como inatingível,
outros roteadores têm conhecimento de uma rota para atingir o destino. Aqui se inicia um
evará a contagem de saltos até o máximo possível.
, C, D e E sabem que deve passar pro B para atingir A. Se A falhar, B
vai verificar que C conhece uma rota para A, que, entretanto é por B. Desta forma se inicia a
O protocolo RIP precisa manipular três tipos de erros causados pelo algoritmo de
corre uma vez que o algoritmo não detecta ciclos
de encaminhamento explicitamente, o RIP precisa considerar que os envolvidos podem ser
Em segundo, este tipo de roteamento usado pelo RIP pode criar um problema de
convergência lenta ou contagem para o infinito, em que surgem inconsistências posto que as
mensagens de atualização de roteamento se propagam lentamente através da rede. Escolher
ente, ajuda a limitar a
sse problema é mostrado na FIG 3.1.
O problema da convergência lenta pode ocorrer com qualquer protocolo que utilize o
algoritmo de roteamento com vetor de distância em que as mensagens de atualização são
re, por exemplo, quando uma conexão falha a um destino específico
através de um roteador. Antes que este roteador propague aquele destino como inatingível,
outros roteadores têm conhecimento de uma rota para atingir o destino. Aqui se inicia um
, C, D e E sabem que deve passar pro B para atingir A. Se A falhar, B
é por B. Desta forma se inicia a
36
O problema da convergência lenta pode ser resolvido através de uma técnica conhecida
como atualização do horizonte dividido. Ao utilizar o horizonte dividido, o roteador não
propaga informações sobre a rota pela mesma interface da qual a rota chegou.
3.4 OPEN SHORTEST PATH FIRST (OSPF)
OSPF é um protocolo de roteamento IGP que surgiu para substituir o RIP. Projetado pelo
grupo Internet Engineering Task Force (IETF), o OSPF possui importantes metas como
(COMER, 2006):
• Ter uma literatura especializada, divulgada para quem desejar implementar
sem precisar pagar taxas de licença;
• Admitir algumas unidades de medida distância;
• Aceitar roteamento baseado no tipo de serviço, proporcionando ao
administrador múltiplas rotas para um destino, um para cada serviço;
• Ser um algoritmo dinâmico, devendo se adaptar rápida e automaticamente a
alterações de topologia;
• Fornecer balanceamento de carga, distribuindo o tráfego de acordo com o custo
até o destino;
• Permitir que sistemas autônomos sejam divididos em sub-redes denominadas
áreas. A topologia de uma área fica oculta para as outras, não havendo a necessidade do
roteador conhecer toda a topologia do sistema;
• Garantir nível de segurança através mensagens autenticadas entre roteadores.
3.4.1 Funcionamento
A idéia básica do OSPF consiste em cada roteador ter a capacidade para montar um mapa
completo da rede. Isto se torna possível uma vez que cada um sabe como alcançar seus
vizinhos conectados diretamente e divulga essas informações aos outros. O roteador
permanece continuamente testando a acessibilidade para aqueles que estão em uma rede
comum e, concomitantemente, envia informações das suas interconexões. Caso o roteador
receba uma informação nova sobre a rede, ele recalcula as rotas aplicando um algoritmo de
caminho mais curto, como por exemplo, o algoritmo de
e Davie, 2004)
O primeiro passo para o OSPF atingir essas metas é obter a representação da rede real em
um grafo orientado no qual se define um custo para cada arco. Com base nos
o OSPF calcula o menor caminho.
Seguindo a linha de uma das metas propostas pelo OSPF, cada SA possui uma área
principal, chamada de área 0 ou
possibilitando a ida para outra área passando pelo
facilita a gerência SAs grandes.
Cada roteador conectado a duas ou mais áreas pertence ao
outras áreas, a topologia do backbone
Durante a operação do OSPF, até três tipos de rotas são necessárias: entre áreas, na
mesma área e entre SAs. Em uma área, os roteadores compartilham as informações do estado
de enlace, com caminho mais curto até cada roteador, obtido por meio do algoritmo referente.
O roteamento entre as áreas de um SA se faz em três etapas: 1) percorre da origem ao
backbone; 2) vai do backbone
etapas uma configuração em estrela (FIG.
áreas sendo os raios. A FIG 3.3
FIG. 3.2 Analogia entre a topologia de rede em estrela (a) e o roteamento entre áreas (b)
37
por exemplo, o algoritmo de Dijkstra, na rede resultante.
O primeiro passo para o OSPF atingir essas metas é obter a representação da rede real em
um grafo orientado no qual se define um custo para cada arco. Com base nos
o OSPF calcula o menor caminho.
Seguindo a linha de uma das metas propostas pelo OSPF, cada SA possui uma área
principal, chamada de área 0 ou backbone. Todas as áreas estão conectadas a ela,
possibilitando a ida para outra área passando pelo backbone. A utilização de áreas numeradas
facilita a gerência SAs grandes.
Cada roteador conectado a duas ou mais áreas pertence ao backbone
backbone não pode ser vista fora dele.
Durante a operação do OSPF, até três tipos de rotas são necessárias: entre áreas, na
mesma área e entre SAs. Em uma área, os roteadores compartilham as informações do estado
nho mais curto até cada roteador, obtido por meio do algoritmo referente.
O roteamento entre as áreas de um SA se faz em três etapas: 1) percorre da origem ao
backbone para a área do destino; 3) chega ao destino. Percebe
as uma configuração em estrela (FIG. 3.2) no OSPF, com o backbone
A FIG 3.3 ilustra a relação entre SAs, backbones e áreas no OSPF.
Analogia entre a topologia de rede em estrela (a) e o roteamento entre áreas (b)
na rede resultante. (Peterson
O primeiro passo para o OSPF atingir essas metas é obter a representação da rede real em
um grafo orientado no qual se define um custo para cada arco. Com base nos pesos dos arcos,
Seguindo a linha de uma das metas propostas pelo OSPF, cada SA possui uma área
. Todas as áreas estão conectadas a ela,
. A utilização de áreas numeradas
backbone. Como ocorre nas
Durante a operação do OSPF, até três tipos de rotas são necessárias: entre áreas, na
mesma área e entre SAs. Em uma área, os roteadores compartilham as informações do estado
nho mais curto até cada roteador, obtido por meio do algoritmo referente.
O roteamento entre as áreas de um SA se faz em três etapas: 1) percorre da origem ao
para a área do destino; 3) chega ao destino. Percebe-se nessas
backbone sendo o hub e as
áreas no OSPF.
Analogia entre a topologia de rede em estrela (a) e o roteamento entre áreas (b)
FIG. 3.3 Relação entre SAs,
Este protocolo diferencia os roteadores em quatro categorias:
• Roteadores internos, que se localizam na parte interna de uma área;
• Roteadores de borda de área, que conectam duas ou mais áreas;
• Roteadores de backbone
• Roteadores de fronteira do SA, que se comunicam com outros SAs. Essas
categorias podem se sobrepor.
3.4.2 Tipos de mensagem
A TAB 3.2 apresenta os tipos de mensagens que um roteador OSPF pode enviar, todas
essas mensagens possuem um cabeçalho comum. (ver ANEXO
Em funcionamento, o roteador envia mensagens HELLO para estabelecer e testar a
acessibilidade de seus vizinhos, com as respostas, ele descobre quem os são. Roteadores em
uma mesma área são considerados vizinhos e, com este protocolo, eles trocam informaçõe
38
Relação entre SAs, backbones e áreas no OSPF
Este protocolo diferencia os roteadores em quatro categorias:
es internos, que se localizam na parte interna de uma área;
Roteadores de borda de área, que conectam duas ou mais áreas;
backbone, que se localizam no backbone;
Roteadores de fronteira do SA, que se comunicam com outros SAs. Essas
categorias podem se sobrepor.
os tipos de mensagens que um roteador OSPF pode enviar, todas
essas mensagens possuem um cabeçalho comum. (ver ANEXO 1)
Em funcionamento, o roteador envia mensagens HELLO para estabelecer e testar a
acessibilidade de seus vizinhos, com as respostas, ele descobre quem os são. Roteadores em
uma mesma área são considerados vizinhos e, com este protocolo, eles trocam informaçõe
e áreas no OSPF
es internos, que se localizam na parte interna de uma área;
Roteadores de borda de área, que conectam duas ou mais áreas;
Roteadores de fronteira do SA, que se comunicam com outros SAs. Essas
os tipos de mensagens que um roteador OSPF pode enviar, todas
Em funcionamento, o roteador envia mensagens HELLO para estabelecer e testar a
acessibilidade de seus vizinhos, com as respostas, ele descobre quem os são. Roteadores em
uma mesma área são considerados vizinhos e, com este protocolo, eles trocam informações
39
apenas com os roteadores adjacentes (ligados diretamente), ou seja, não haverá troca de
mensagens se forem vizinhos e não adjacentes.
É estabelecido um roteador que será adjacente a todos os roteadores da área e uma
reserva para o caso de quando aquele falhar.
TAB. 3.2 Tipos de mensagens OSPF
Tipo de mensagem Função
HELLO Para descobrir os vizinhos
DATABASE DESCRIPTION Anunciar quais são atualizações do transmissor
LINK STATE REQUEST Solicitar informações
LINK STATE UPDATE Prover os custos do transmissor a seus vizinhos
LINK STATE ACK Confirmar a atualização do estado de enlace
As mensagens DATABASE DESCRIPTION são trocadas com a descrição do banco de
dados OSPF. A troca é realizada entre um roteador mestre, que envia a mensagem, e um
roteador escravo, que recebe.
Após a troca de mensagens de descrição de banco de dados com um roteador vizinho, um
roteador pode verificar que suas informações estão desatualizadas. Com intuito de requisitar
que o vizinho forneça informações atualizadas, o roteador envia uma mensagem de requisição
de estado de enlace, ou LINK STATE REQUEST.
Através da mensagem de atualização de estado de enlace (LINK STATE UPDATE), os
roteadores difundem o estado dos enlaces. Cada anúncio de estado de enlace possui um
formato de cabeçalho único, os valores em cada campo são iguais aos da mensagem de
descrição de banco de dados. O formato de seus campos são apresentados no ANEXO 1.
Através das trocas de mensagens, cada roteador fica capacitado de construir um grafo
para a(s) sua(s) área(s) e de calcular o percurso menos custoso.
3.5 BORDER GATEWAY PROTOCOL (BGP)
O BGP é um protocolo EGP, que de maneira contrária a um IGP, que necessita apenas
movimentar os pacotes de forma eficiente dentro de um AS. O BGP possui como principal
característica é permitir que um SA se comunique com outro.
40
3.5.1 Características
Importantes características inerentes ao BGP podem ser citadas:
• Divulgação de informações de alcançabilidade: permite que um SA divulgue
destinos que são acessíveis nele ou através dele, e aprenda essas informações de outro;
• Suporte a política: pode implementar políticas de acordo com a administração
local, como diferenciar um conjunto de destinos acessíveis por máquinas dentro do
próprio SA e um conjunto de destino anunciados a outros SAs;
• Confiabilidade na troca de informações: utilização do TCP para qualquer
troca de informação de roteamento;
• Informações de caminho: através de informações de caminho, os anúncios
BGP permitem a um receptor ter conhecimento de diversos SAs através de um caminho
até o destino e evitar ciclos;
• Atualizações incrementais: o BGP não transmite mensagens completas em
cada mensagem de atualização para liberar a largura de banda da rede. A mensagem
completa é enviada na primeira comunicação e as atualizações são transmitidas através de
mensagens sucessivas com alterações incrementais;
• Autenticação: permite que um receptor identifique a identidade do emissor;
• Agregação de rota: preserva largura de banda consentindo que um emissor
reúna informações de roteamento em uma única mensagem e envie para representar
diversos destinos.
3.5.2 Tipos de mensagem
Quando um par de SAs estão em acordo para trocar informações de roteamento, cada um
nomeia um roteador como representante do SA. Estes roteadores, dessa maneira, se tornam
peers de BGP um do outro. Os peers BGP possuem três funções básicas. A primeira delas
consiste na aquisição e autenticação inicial do peer, ou seja, estes concordam em se
comunicar estabelecendo uma conexão entre eles e realizando troca de mensagens.
A segunda consiste em cada um anunciar destinos alcançáveis disponibilizando o
próximo roteador que a informação deve seguir para atingir, ou anunciar como inalcançáveis
41
destinos anteriormente anunciados. A terceira função está relacionada à constante verificação
se os peers e as conexões de rede estão funcionando corretamente.
Para que essas funções sejam manipuladas, cinco tipos de mensagens básicas são
definidos pelo protocolo BGP, apresentadas na TAB 3.3. Cada mensagem BGP inicia com um
cabeçalho que identifica o tipo de mensagem.
TAB. 3.3 Tipos de mensagens básicas definidas pelo BGP
Tipo de mensagem Função
OPEN Inicializa comunicação
UPDATE Anuncia ou retira rotas
NOTIFICATION Resposta a uma mensagem incorreta
KEEP ALIVE Testa ativamente a conectividade do peer
REFRESH Requisita novo anúncio do peer
42
4 SOFTWARES DE ROTEAMENTO
Este projeto foi desenvolvido em Linux devido às diversas características positivas que
este SO possui em relação ao Windows. Entre as vantagens, podemos citar como a mais
interessante para este projeto o fato de suas ferramentas e softwares serem de código aberto e
de livre distribuição, portanto, sem custos para um desenvolvedor em Linux.
Complementando, por ser de código aberto, o desenvolvedor pode aprimorar a ferramenta ou
software.
Com o intuito deste trabalho consiste na simulação de roteadores, é indispensável o
conhecimento sobre o sistema em operação nos equipamentos a serem simulados. Como a
Cisco System Inc. é a empresa líder nessa área, o sistema em operação em seus roteadores, o
Cisco IOS será apresentado. Posteriormente, será introduzido o software de roteamento
utilizado por este projeto na simulação, o Quagga.
4.1 CISCO IOS
A Cisco é a maior produtora de roteadores do mundo (Boney, 2002), sustentando a maior
parte do mercado, garantida com anos de qualidade em produtos de tecnologia. Produz desde
pequenas unidades para utilização em residências até equipamentos que podem custar por
volta dos cem mil dólares. Os seus roteadores, não importando o tamanho ou preço, executam
em sistema, o Internetwork Operating System (IOS). Os conjuntos de comandos, a interface
com o usuário e as técnicas de configuração são idênticas para todos os roteadores Cisco.
Cisco IOS é um poderoso e complexo sistema operacional com uma linguagem de
configuração igualmente complexa.
4.1.1 Características
Além dos recursos comuns de SOs, o Cisco IOS fornece serviços de rede, como:
• Funções de roteamento;
• Acesso seguro e confiável aos recursos da rede;
• Escalabilidade, ou seja, permitir a rede uma capacidade de crescimento
evitando alteração do software.
43
A escalabilidade proporciona flexibilidade para uma organização enfrentar questões de
rede. O software utiliza protocolos de roteamento que podem ser modificados caso a rede
aumente de tamanho, evitando que ela fique congestionada. Além disso, ele supera limitações
inerentes dos protocolos e ignora obstáculos resultantes de características complexas que uma
rede pode vir a possuir.
Existem dois modos de operação no Cisco IOS, o modo de usuário e o modo com
privilégios. Ao se conectar com o roteador, o usuário estará no modo usuário. Este modo
possui limitações, uma vez que estando nele não é possível visualizar ou alterar
configurações. Para modificar configurações é necessário estar no modo com privilégios para
acessar ao sub-modo para acessar a configuração do roteador.
O modo com privilégios possui alguns sub-modos de configuração:
• Modo global de configuração: É possível, a partir deste, ter acesso a outros
sub-modos;
• Modo de configuração de interface: Permite que se realizem comandos
específicos de interface;
• Modo de configuração de linha de comando: Define as configurações de acesso
aos diferentes modos no terminal;
• Modo de configuração de roteador: Estabelece configurações de roteamento.
Estes sub-modos de configuração fornece um ambiente em que alguns comandos podem
ser realizados, outros não. Desta forma, o Cisco IOS previne o usuário de cometer enganos. A
FIG 4.1 ilustra os modos de operação no Cisco IOS com os comandos para as transições entre
os modos.
O Cisco IOS possui uma facilidade ao usuário de completar comandos, ou seja, se a partir
de um determinado número de caracteres o comando for único, não é necessário digitar por
completo o nome do comando. Esta característica também é apresentada na FIG 4.1,
configure terminal foi reduzido para conf term, que ainda pode ser abreviado para conf t.
Como em outros roteadores, o SO dos roteadores Cisco disponibiliza aos usuários a
funcionalidade do ponto de interrogação (“?”) que apresenta os sub-comandos de um certo
comando. Fornecendo ao usuário um ambiente amigável com as opções de comandos
possíveis em cada modo de operação.
FIG.
4.1.2 Vantagens
Para aliar a gerência da rede com a gerência dos equipamentos responsáveis pelo
funcionamento da infra-estrutura de rede, o Cisco IOS permite que a funcionalidade
(Simple Network Management Protocol
seja habilitada. Por meio desta, podem ser coletadas diversas informações do roteador, desde
o tempo em que ele está ligado até informações de roteamento através de comandos remotos.
4.1.3 Desvantagens
Por ser um software é executado em equipamentos Cisco, a utilização do IOS incorre na
necessidade de utilizar-se estes equipamentos, que possuem alto custo. Além disso, por
possuir diversas versões, a utilização deste
inicialmente deseja-se apenas realizar o roteamento simples, se adquire uma versão. Caso haja
necessidade do emprego de um protocolo mais complexo como o BGP (
Protocol), uma nova versão do
44
FIG. 4.1 Modos de operação no Cisco IOS
Para aliar a gerência da rede com a gerência dos equipamentos responsáveis pelo
estrutura de rede, o Cisco IOS permite que a funcionalidade
Simple Network Management Protocol, ou Protocolo Simples de Gerenciamento de Rede)
seja habilitada. Por meio desta, podem ser coletadas diversas informações do roteador, desde
o tempo em que ele está ligado até informações de roteamento através de comandos remotos.
executado em equipamentos Cisco, a utilização do IOS incorre na
se estes equipamentos, que possuem alto custo. Além disso, por
possuir diversas versões, a utilização deste software fica limitada ao objetivo de aplicação. Se
se apenas realizar o roteamento simples, se adquire uma versão. Caso haja
necessidade do emprego de um protocolo mais complexo como o BGP (
), uma nova versão do software deve ser adquirida.
Para aliar a gerência da rede com a gerência dos equipamentos responsáveis pelo
estrutura de rede, o Cisco IOS permite que a funcionalidade SNMP
olo Simples de Gerenciamento de Rede)
seja habilitada. Por meio desta, podem ser coletadas diversas informações do roteador, desde
o tempo em que ele está ligado até informações de roteamento através de comandos remotos.
executado em equipamentos Cisco, a utilização do IOS incorre na
se estes equipamentos, que possuem alto custo. Além disso, por
fica limitada ao objetivo de aplicação. Se
se apenas realizar o roteamento simples, se adquire uma versão. Caso haja
necessidade do emprego de um protocolo mais complexo como o BGP (Border Gateway
45
4.2 QUAGGA
Quagga é um software livre para roteamento baseado no protocolo TCP/IP10, semelhante
ao software Cisco IOS. Semelhanças de configuração como os modos de operação
apresentados na FIG 4.1, a possibilidade de abreviar comandos e poder utilizar o ponto de
interrogação para visualizar comandos disponíveis. Mais comparações estão citadas após
simulação apresentada na seção 5.5.2.
Ele suporta os protocolos BGP-4, BGP-4+, OSPFv2, OSPFv3, RIPv1, RIPv2 e RIPng.
Executado em Linux, BSD ou Solaris e distribuído pela GNU General Public License, o
Quagga é considerado um software de fácil configuração, uma vez que os comandos que o
software de roteamento fornece ao usuário são semelhantes aos dos roteadores Cisco,
proporcionando facilidade a administradores de rede que estão familiarizados com
equipamentos que possuem o Cisco IOS.
O Quagga é derivado do software livre Zebra. Parte dos desenvolvedores do Zebra
iniciaram um novo projeto a partir do Zebra. O novo projeto recebeu o nome de Quagga. Os
outros envolvidos no projeto Zebra deixaram de realizar atualizações.
Uma máquina com o Quagga instalado funciona como um roteador dedicado, passando a
trocar informações com outros roteadores segundo os diversos protocolos. O Quagga utiliza
essas informações para atualizar a tabela de roteamento do núcleo, garantindo que um dado
chegue ao seu correto destino.
Pode-se alterar a configuração e visualizar essa informação na tabela de roteamento
através do VTY11, ou terminal, que pode ser acessado através do protocolo TELNET. Este
consiste em um protocolo de terminal em modo texto que permite que um usuário efetue o
acesso a uma máquina através de uma rede em uma conexão TCP. A FIG 4.2 ilustra o
funcionamento de forma simples um acesso via TELNET (COMER, 2006).
Quando o usuário executa o TELNET, um programa na máquina do usuário se torna
cliente e estabelece uma conexão TCP com o servidor, meio pelo qual eles se comunicarão.
Com a conexão estabelecida, o cliente aceita toques do teclado do usuário e os envia para o
servidor e, concomitantemente, aceita caracteres que o servidor envia de volta e os exibe na
tela do usuário.
10 TCP/IP – Conjunto de protocolos responsáveis por fornecer serviços a máquinas interconectadas. 11 VTY – Virtual TeletYpe, interface de linha de comando que um usuário pode conectar-se através do protocolo TELNET.
FIG. 4.2
Diferente de softwares de roteamento tradicionais, como o Cisco IOS, o Quagga não
utiliza um processo para se encarregar de todas as funções de roteamento, ele atribui cada
serviço para um conjunto de
construir a tabela de roteamento. Todos esses
que é o encarregado de modificar as informações da tabela de roteamento do núcleo do Linux
e de promover a troca de informações entre vários protocolos de roteamento. A FIG 4.3
mostra a arquitetura do Quagga
e o núcleo do SO. Uma vantagem nessa estrutura consiste na possibilidade de incluir um novo
daemon relacionado a um novo protocolo sem afetar qualquer
FIG.
12
Daemon – Acrônimo de Disk And Execution MONitor
executado em background, utilizado para tarefas que se comunicam diretament
46
2 Funcionamento do protocolo TELNET
de roteamento tradicionais, como o Cisco IOS, o Quagga não
utiliza um processo para se encarregar de todas as funções de roteamento, ele atribui cada
serviço para um conjunto de daemons12, um para cada protocolo, que se encarregam de
roteamento. Todos esses daemons se comunicam com o
que é o encarregado de modificar as informações da tabela de roteamento do núcleo do Linux
e de promover a troca de informações entre vários protocolos de roteamento. A FIG 4.3
tetura do Quagga (Quagga, 2010), expondo o relacionamento entre os
e o núcleo do SO. Uma vantagem nessa estrutura consiste na possibilidade de incluir um novo
relacionado a um novo protocolo sem afetar qualquer software.
FIG. 4.3 Arquitetura do Quagga
Disk And Execution MONitor (Monitor de execução e de disco). Programa que é executado em background, utilizado para tarefas que se comunicam diretamente com o SO ou com os hardwares.
de roteamento tradicionais, como o Cisco IOS, o Quagga não
utiliza um processo para se encarregar de todas as funções de roteamento, ele atribui cada
, um para cada protocolo, que se encarregam de
se comunicam com o daemon zebra,
que é o encarregado de modificar as informações da tabela de roteamento do núcleo do Linux
e de promover a troca de informações entre vários protocolos de roteamento. A FIG 4.3
, expondo o relacionamento entre os daemons
e o núcleo do SO. Uma vantagem nessa estrutura consiste na possibilidade de incluir um novo
(Monitor de execução e de disco). Programa que é e com o SO ou com os hardwares.
47
Cada daemon possui o seu próprio arquivo de configuração e uma interface de
comunicação com o usuário, sendo cada um configurado separadamente. É utilizada uma
interface de linha de comando para que essa comunicação seja realizada, permitindo que a
configuração dos daemons seja realizada separadamente. O acesso a cada arquivo de
configuração relacionado a um daemon é feito por uma porta específica através do protocolo
TELNET. Para esse acesso, durante a instalação do Quagga, o SO adicionou ao arquivo
/etc/services as linhas contidas em TAB 4.1. Este arquivo associa um serviço a uma porta da
máquina.
TAB. 4.1 Linhas adicionadas no arquivo /etc/services
Serviço (daemon) Porta / Protocolo de acesso ao serviço Comentário
zebrasrv 2600/tcp #zebra service
Zebra 2601/tcp #zebra vty
Ripd 2602/tcp #ripd vty (zebra)
Ripngd 2603/tcp #ripngd vty (zebra)
Ospfd 2604/tcp #ospfd vty (zebra)
Bgpd 2605/tcp #bgpd vty (zebra)
ospf6d 2606/tcp #ospf6d vty (zebra)
ospfapi 2607/tcp #ospfapi
Isisd 2608/tcp #ISISd vty (zebra)
Para acessar o roteador, é necessário verificar se o arquivo de configuração do Quagga
está permitindo esse acesso. Este acesso é dado através da edição do arquivo
/etc/quagga/daemon. Este arquivo informa ao Quagga quais daemons devem ser inicializados.
Para iniciar, por exemplo, um simples gerenciador de roteamento, basta indicarmos no
arquivo que o daemon referente ao zebra deve ser inicializado.
Desta maneira, o roteador pode ser acessado via TELNET. As senhas referentes a esse
acesso também constam no arquivo /etc/quagga/daemon. Para utilizarmos protocolos de
roteamento, basta setarmos os respectivos daemons, juntamente com o daemon zebra.
Estando o arquivo da maneira adequada, acessa-se o roteador via TELNET de acordo
com o interesse do usuário. Assim as configurações do roteador podem ser alteradas.
48
5 ESTUDO DE CASO
5.1 OBJETIVO
Para esta fase de estudo de caso, realizaram-se testes com a rede possuindo diferentes
configurações. Inicialmente, a rede possuía características bem simples com apenas rotas
estáticas. Em seguida, aplicamos o protocolo RIP, em que as tabelas de rotas passaram a ser
dinâmicas. Posteriormente, os testes foram feitos com os roteadores com protocolo OSPF.
Após a realização de testes com rotas estáticas e com protocolos RIP e OSPF, foi
realizada uma comparação com um laboratório físico para enaltecer o valor da simulação de
um roteador em máquina virtual. Além das semelhanças, serão destacadas as funcionalidades
que o software de roteamento Quagga não apresenta em relação ao Cisco IOS.
Essa comparação foi realizada com a estrutura do Laboratório de Redes do Instituto
Militar de Engenharia, que possui a topologia apresentada na FIG 5.5. Tal procedimento é
válido, posto que os resultados obtidos destacam se as decisões no roteamento são
semelhantes às ocorridas no laboratório.
Uma análise dos pacotes enviados pelos roteadores será realizada para verificar se estes
pacotes estão de acordo, sintática e semanticamente, com a especificação do protocolo. Esta
análise será possível através de um analisador de tráfego.
5.2 AMBIENTE
O estudo de caso foi realizado em uma máquina com o SO baseado em Linux, Ubuntu
8.04. Para a simulação dos roteadores, foi utilizado o MMV VMware Server 2.0.1. Alguns
pacotes foram instalados para a realização dos trabalhos, sendo os principais o Openssh-
server, para a possibilidade de acesso remoto, e um analisador de tráfego.
49
5.3 TESTES
5.3.1 Configuração da rede
Configurou-se a rede de maneira a verificar se os resultados estão de acordo com uma
rede real. Primeiramente, como ilustrado na FIG. 5.1, estabeleceu-se a configuração com rotas
estáticas e seis máquinas virtuais, três atuando com o Quagga instalado e outras três
funcionando como uma máquina pertencente a cada rede.
Em seguida, aplicou-se o protocolo RIP nas máquinas com o Quagga. Com o RIP, foram
realizados dois testes aplicando diferentes topologias para visualização dos comportamentos
em cada caso. Um teste com a topologia da FIG. 5.3 e outro referente à FIG. 5.4. O mesmo
procedimento foi realizado com OSPF. E para complementar este trabalho, foi realizado o
teste para verificar a possibilidade da união entre roteador virtual e físico em uma mesma
topologia.
A verificação pode ser feita através de outros testes, como:
• Teste de comunicação entre as máquinas, através da confirmação de
recebimento de pacotes;
• Verificação do caminho percorrido pelos pacotes nos testes de
comunicação com a rede em seu estado normal e em situação de estresse,
como a falha em alguma interface;
• No caso dos protocolos, a captura das informações contidas nos pacotes
que são trocados.
A aplicação do protocolo BGP fica restrita pela falta de recursos computacionais, pois
seriam necessários, no mínimo três sistemas autônomos para a realização de testes
satisfatórios, cada um com suas máquinas-roteadores. Isso necessita de uma alta capacidade
de processamento e uma alta disponibilidade de memória.
5.3.1.1 Rotas estáticas
No primeiro caso, de rotas estáticas, deve-se acessar a porta relativa ao daemon zebra,
2601. Estabelecendo a rede como mostra a FIG 5.1.
FIG. 5.1 Topologia da rede para testes com rotas estáticas
No terminal, podemos configurar a máquina
testes, foram simuladas três redes, para
de estação e outra como roteador, totalizando seis máquinas
que o roteador denominado de Roteador1 possui uma interface de ligação com o Roteador2,
que por sua vez liga-se com o Roteador3. Cada roteador possui uma rede conectada a uma
interface. Diferentemente de máquinas físicas, não existe um meio físico conectando cada
máquina. Por isso, é necessário que o MMV e os roteadores sejam configurados para que haja
comunicação entre todas as máquinas.
As redes conectadas as interfaces “eth2” dos roteadores da FIG
representar uma LAN13 apresentada na FIG
switch que possuiria diversas máquinas conectadas a ele.
Para essa comunicação, utilizam
switches virtuais. Como há três redes ligadas às máquinas
introdução de três adaptadores em c
13
LAN – Local Area Network, rede local de com
50
Topologia da rede para testes com rotas estáticas
terminal, podemos configurar a máquina-roteador para os primeiros testes. Para esses
testes, foram simuladas três redes, para cada rede foi criada uma máquina virtual para servir
de estação e outra como roteador, totalizando seis máquinas. Como mostra a
que o roteador denominado de Roteador1 possui uma interface de ligação com o Roteador2,
com o Roteador3. Cada roteador possui uma rede conectada a uma
interface. Diferentemente de máquinas físicas, não existe um meio físico conectando cada
máquina. Por isso, é necessário que o MMV e os roteadores sejam configurados para que haja
ntre todas as máquinas.
As redes conectadas as interfaces “eth2” dos roteadores da FIG 5.1 tiveram um papel de
apresentada na FIG 5.2. Ou seja, essas interfaces se conectariam a um
que possuiria diversas máquinas conectadas a ele.
Para essa comunicação, utilizam-se adaptadores de rede, ou, como visto anteriormente
Como há três redes ligadas às máquinas-roteadores, é necessária a
introdução de três adaptadores em cada um destes.
, rede local de computadores.
Topologia da rede para testes com rotas estáticas
roteador para os primeiros testes. Para esses
cada rede foi criada uma máquina virtual para servir
. Como mostra a FIG 5.1, vemos
que o roteador denominado de Roteador1 possui uma interface de ligação com o Roteador2,
com o Roteador3. Cada roteador possui uma rede conectada a uma
interface. Diferentemente de máquinas físicas, não existe um meio físico conectando cada
máquina. Por isso, é necessário que o MMV e os roteadores sejam configurados para que haja
tiveram um papel de
. Ou seja, essas interfaces se conectariam a um
se adaptadores de rede, ou, como visto anteriormente
roteadores, é necessária a
FIG. 5.2 Representação de uma rede conectada a interface “eth2” dos roteadores da
Assim, é necessário para cada máquina
das redes conectadas àqueles saberem com quem se conecta. Estes adaptadores são do tipo
host-only e o endereço da interface relativa a este adaptador deve estar coerente com a
configuração do VMware. Deste modo, torna
máquina hospedeira.
Os adaptadores de rede das máquinas
roteador também são do tipo
interfaces podem ser diferentes daquele configurado previamente.
utilizar apenas um adaptador de rede para as comunicações entre máquinas
permitir que cada conexão possua o endereço desejado permitido. É necessário que seja
configurado na descrição da máquina virtual que o adap
à vmnet desejada.
Então se pode generalizar que, para estabelecer que máquinas virtuais simples estejam
ligadas a um roteador específico, deve
e especificar nas máquinas de cada rede um adaptador específico para que as conexões fiquem
como desejadas.
Para que haja comunicação entre todas as máquinas na topologia da
necessário que a opção de ip forwarding
suas interfaces de rede.
51
Representação de uma rede conectada a interface “eth2” dos roteadores da
FIG 5.1
para cada máquina-roteador um adaptador de rede para as máquinas
adas àqueles saberem com quem se conecta. Estes adaptadores são do tipo
e o endereço da interface relativa a este adaptador deve estar coerente com a
configuração do VMware. Deste modo, torna-se possível acessar a máquina virtual a partir da
Os adaptadores de rede das máquinas-roteadores que são conectados com outra máquina
roteador também são do tipo host-only, entretanto o endereço atribuído as suas respectivas
interfaces podem ser diferentes daquele configurado previamente. Isto ocorre com o intuito de
utilizar apenas um adaptador de rede para as comunicações entre máquinas
permitir que cada conexão possua o endereço desejado permitido. É necessário que seja
configurado na descrição da máquina virtual que o adaptador de rede desta máquina se refere
Então se pode generalizar que, para estabelecer que máquinas virtuais simples estejam
ligadas a um roteador específico, deve-se criar um adaptador de rede no gerenciador do MMV
máquinas de cada rede um adaptador específico para que as conexões fiquem
Para que haja comunicação entre todas as máquinas na topologia da
ip forwarding seja habilitada no roteador, que permite tráfego entre
Representação de uma rede conectada a interface “eth2” dos roteadores da
roteador um adaptador de rede para as máquinas
adas àqueles saberem com quem se conecta. Estes adaptadores são do tipo
e o endereço da interface relativa a este adaptador deve estar coerente com a
se possível acessar a máquina virtual a partir da
com outra máquina-
, entretanto o endereço atribuído as suas respectivas
Isto ocorre com o intuito de
utilizar apenas um adaptador de rede para as comunicações entre máquinas-roteadores e
permitir que cada conexão possua o endereço desejado permitido. É necessário que seja
tador de rede desta máquina se refere
Então se pode generalizar que, para estabelecer que máquinas virtuais simples estejam
se criar um adaptador de rede no gerenciador do MMV
máquinas de cada rede um adaptador específico para que as conexões fiquem
Para que haja comunicação entre todas as máquinas na topologia da FIG. 5.1, é
seja habilitada no roteador, que permite tráfego entre
52
Para constatar a perfeita comunicação, foram realizados testes com o comando PING14
para outras máquinas e através da ferramenta traceroute que detalha o percurso desses
pacotes.
5.3.1.2 RIP
Para a realização dos testes com o protocolo RIP, as configurações específicas do
protocolo são realizadas via TELNET através da porta 2602, qualquer alteração modificará o
arquivo de configuração referente ao daemon do RIP, o /etc/quagga/ripd.conf. Ou seja,
mesmo que os roteadores estejam configurados para implementar algum protocolo, as
configurações de interface, como endereço e largura de banda continuam sendo configurados
pela porta 2601, acessando o arquivo de configuração /etc/quagga/zebra.conf.
Foram realizados dois testes envolvendo diferentes topologias com esse protocolo nos
roteadores para verificar como a tabela de roteamento se comporta em cada máquina-roteador.
(FIG. 5.3 e FIG. 5.4). No primeiro teste, desejou-se simplesmente verificar a comunicação e o
percurso adotado por essas informações. A partir desse teste, pode-se constatar se as
informações estão seguindo a seqüência de saltos corretamente, ou se o percurso encaminhado
não é o esperado.
Por exemplo, pode-se concluir que alguma configuração na FIG. 5.3 encontra-se
incorreta se o percurso informado após a execução de um traceroute entre Roteador1 e a rede
192.168.7.0 for dado, ou como diretamente conectado ou não passando pela rede 192.168.1.0,
(ver APÊNDICE 1)
O segundo justifica-se para constatar alterações das informações da tabela de roteamento
em meio a uma mudança de estado da rede, como a falha de uma interface. Pode-se verificar
também a modificação na informação relacionada à distância, quantidade de saltos, para as
redes conhecidas. Assim, pode-se verificar se o protocolo RIP está atuando de acordo com o
esperado nos roteadores, atualizando as rotas e as distâncias.
14 PING – Denominação dada ao comando invocado para enviar requisições de eco ICMP, protocolo permite que roteadores emitam mensagens de erro ou de controle para outros roteadores. Utilizado para teste de alcançabilidade.
FIG. 5.3 Topologia para primeira etapa d
FIG. 5.4 Topologia para segunda etapa de teste com RIP
53
Topologia para primeira etapa de testes com RIP
Topologia para segunda etapa de teste com RIP
e testes com RIP
Topologia para segunda etapa de teste com RIP
54
5.3.1.3 OSPF
Analogamente aos testes com o RIP, para configurações relacionadas ao protocolo OSPF
é necessário realizar acesso via TELNET pela porta 2604.
Para os testes com o OSPF nos roteadores, a topologia representada pela FIG. 5.4
também foi utilizada. Além de testes de comunicação através de PING, alterou-se a
configuração da rede em termos de custo nas conexões para verificar como a rede se
comporta, visualizando o resultado das alterações na tabela de roteamento do núcleo,
atualizada pelo software de roteamento utilizado por este projeto.
Essas alterações podem ser realizadas das seguintes formas:
• Como o realizado no caso do protocolo RIP, através do desligamento de uma
interface de rede, para comprovar a alcançabilidade de alguma rede ou se ocorreu alguma
alteração na rota;
• Através da alteração dos custos nas ligações. Por meio deste protocolo, a tabela
de rotas de uma máquina-roteador será atualizada se houver duas condições forem
satisfeitas, a primeira seria ter duas ou mais rotas possíveis para alcançar uma rede, e a
segunda seria que o custo após a alteração da rota supere o custo de outra rota a essa rede;
• Como no teste do protocolo RIP, observar o conteúdo dos pacotes trafegados
através de um analisador de tráfego.
Essa verificação pode ser executada de maneira que diferentes mensagens, apresentadas
na TAB 3.2, sejam trafegadas entre as máquinas-roteadores. Se as máquinas virtuais destes
estiverem ligadas, mensagens HELLO serão emitidas de acordo com o período estabelecido
na configuração do roteador (ver ANEXO 2).
Ao alterar o custo, pode-se verificar o envio de mensagens LINK STATE UPDATE,
juntamente com a confirmação em mensagens LINK STATE ACK. Além dessas, visualiza-se
o tráfego do tipo DATABASE DESCRIPTION quando ocorre alguma alteração no banco de
dados que mantêm as rotas no roteador, isso pode ser consequência, por exemplo, a ativação
de uma interface desligada (ver ANEXO 2).
Com resultados positivos nos testes e nas análises, pode-se afirmar que a rede com o
protocolo especificado está em funcionamento pleno desejado.
55
5.4 SIMULAÇÃO
5.4.1 Interfaces de rede
Nos roteadores do laboratório existem três tipos de interface de rede, FastEthernet,
Ethernet e serial. As duas primeiras são variações da tecnologia Ethernet com diferentes
capacidades de tráfego por interface. A primeira com capacidade 100 Mbits/s e a segunda
com 10 Mbits/s. E a terceira consiste em mais um meio de comunicação entre roteadores.
O VMware permite que se adicione adaptador de rede na máquina virtual, que pode ser
caracterizado dos modos descritos na seção 2.4.1.1. O software de roteamento Quagga
reconhece as interfaces de rede como um único tipo. Porém, a capacidade de tráfego da
interface pode ser alterada na configuração do roteador. Ela pode ser configurada de 1 bit/s a
10Gbits/s. (ver ANEXO 3)
Para o caso da interface serial, o VMware disponibiliza uma porta serial como possível
hardware a ser adicionado na máquina virtual. Entretanto, a comunicação entre duas
máquinas virtuais utilizando portas seriais no VMware é realizada através de socket15, não
sendo útil para esta simulação. Portanto, neste caso as interfaces seriais serão tratadas como as
outras interfaces, com o detalhe da diferenciação por meio da capacidade da interface.
5.4.2 Análises de mensagens
Além dos testes de roteamento, a análise das mensagens trocadas pelos roteadores se
apresenta como um meio para verificação da atuação do protocolo. Essa análise pode ser
efetuada por meio de um analisador de tráfego, o TShark [tshark, 2010], versão para
servidores do Wireshark [Wireshark, 2010], analisador de tráfego com interface gráfica.
A análise do tráfego permite averiguar se as mensagens referentes ao protocolo
implementado na rede estão sintática e semanticamente corretos, ou seja, se as mensagens
possuem os campos conforme o especificado (ver ANEXO 1) e se o conteúdo das
informações está coerente com o estado atual do roteador (ver ANEXO 2).
A captura de mensagens ocorreu através da execução de comandos na máquina
hospedeira (ver APÊNDICE 2). Por meio de um analisador de tráfego, é possível que sejam
capturados pacotes através de uma interface. A máquina hospedeira possui, além das suas
15 Socket – Interface de comunicação bidirecional entre processos através de uma rede.
FIG. 5.5 Topologia do Laboratório de Redes do Instituto Militar de Engenharia
interfaces reais, as interfaces virtuais adicionadas através do VMware
em uma dessas interfaces virtuais. No APÊNDICE
por interfaces do tipo host-only
5.4.2.1 Desligamento de interface
Uma análise mais detalhada pode ser realizada ao interromper o funcionamento de uma
interface. Isso acarreta o envio de mensagens de atualização, ou
apresentado através do APÊNDICE 2
inativa. No caso, a interface referida é a “s1” do roteador CYPRUS da
56
Topologia do Laboratório de Redes do Instituto Militar de Engenharia
interfaces reais, as interfaces virtuais adicionadas através do VMware. A análise é realizada
em uma dessas interfaces virtuais. No APÊNDICE 2 pode ser constatada a captura de pacotes
only em um regime regular dos roteadores.
de interface
Uma análise mais detalhada pode ser realizada ao interromper o funcionamento de uma
interface. Isso acarreta o envio de mensagens de atualização, ou Link State Update
presentado através do APÊNDICE 2 o que ocorreu ao deixar uma interface do roteador
inativa. No caso, a interface referida é a “s1” do roteador CYPRUS da FIG
Topologia do Laboratório de Redes do Instituto Militar de Engenharia
A análise é realizada
constatada a captura de pacotes
Uma análise mais detalhada pode ser realizada ao interromper o funcionamento de uma
Link State Update. É
deixar uma interface do roteador
FIG. 5.5.
57
Pode ser constatada a coerência sintática do conteúdo destes pacotes capturados
comparando com o formato apresentado no ANEXO 1.
Percebe-se também que a semântica dos pacotes capturados se encontra coerentes com
o ocorrido e com a configuração do roteador CYPRUS. Conclui-se através do ANEXO 2 que:
• Pelo campo Source16, situado antes das informações referentes ao OSPF no
pacote, trata-se de um pacote enviado pela interface “s0” (10.0.0.9) com destino (campo
Destination) 224.0.0.517, ou seja, todas as interfaces de roteadores com OSPF;
• Pelo campo Message Type, trata-se de uma mensagem de atualização de estado
de enlace;
• Pelo campo Source OSPF Router, constata-se que realmente o roteador
anunciante é o CYPRUS. (ver ANEXO 2);
• Na parte referente à descrição do estado de enlace, a partir de LS Update
Packet no pacote capturado, percebe-se que a interface desligada não se encontra entre as
descritas.
No ANEXO 2, tem-se o resultado após a reativação desta interface. Verifica-se o retorno
na descrição do estado de enlace, uma que a interface está na rede 10.0.0.12/30.
Há de se destacar também que esta mensagem de estado de enlace também é repassada
por outros roteadores, como visto no APÊNDICE 2. Este pacote foi enviado por 10.0.0.21, ou
seja, o roteador SANTORINI está propagando a mensagem enviada pelo roteador CYPRUS.
5.4.2.2 Atribuição de endereço a uma nova interface
Para se verificar um envio de mensagem de descrição de banco de dados OSPF, atribuiu-
se um endereço para uma interface inativa do roteador NAXOS. Ao reiniciar a máquina,
foram capturados pacotes com mensagens de descrição OSPF, como pode ser visto no
APÊNDICE D. Percebe-se nas mensagens que as interfaces do roteador NAXOS enviam para
os roteadores adjacentes esse pacote.
A atribuição de um endereço a uma interface e a sua ativação também acarretou, como
esperado, em uma série de mensagens de atualização por parte de todos os roteadores
informando a introdução de um novo endereço em uma interface de um dos roteadores.
16
Source – Campo do datagrama internet que fornece a origem do pacote. Datagrama internet é a unidade de
transferência básica em redes. Todos os pacotes discutidos possuem a sintaxe do datagrama internet. (ver
ANEXO I) 17
224.0.0.5 - Endereço permanente do grupo de roteadores que implementem OSPF.
5.5 ROTEADOR FÍSICO E
Foi realizado o teste envolvendo duas máquinas virtua
estação real conectada ao Laboratório de Redes do IME. Uma máquina virtual como roteador
e uma representando a LAN como na FIG. 5.2. O objetivo deste teste consistiu em verificar a
comunicação do roteador virtual com os ro
aprendidas pelo roteador virtual
Como ilustrado na FIG. 5.6
adaptador de rede do tipo bridged
5.5). A máquina virtual se conecta a máquina
only. Este teste envolve verificar se a rede referente a este adaptador ser
aprendida pelos roteadores do Labora
que ela permitisse a comunicação entre o roteador virtual com o Laboratório.
FIG. 5.6 Representação do teste envolvendo roteador físico e virtual
Entretanto, testes de alcançabilidade para alguma interface de um roteador do Laboratório
a partir da máquina virtual representante da LAN não obtiveram êxito. Mesmo resultado
obtido a partir de algum roteador do Laboratório para essa máquina virtual.
resultado da execução do comando
TAB. 5.1 Resultado
Teste de alcançabilidade a partir ...
... do roteador do Laboratório.
... da máquina virtual representante da LAN na
FIG. 5.2.
58
ROTEADOR FÍSICO E VIRTUAL EM UMA MESMA REDE
Foi realizado o teste envolvendo duas máquinas virtuais utilizadas na simulação em uma
estação real conectada ao Laboratório de Redes do IME. Uma máquina virtual como roteador
e uma representando a LAN como na FIG. 5.2. O objetivo deste teste consistiu em verificar a
comunicação do roteador virtual com os roteadores do Laboratório e se as redes deste seriam
aprendidas pelo roteador virtual de acordo com o protocolo OSPF.
Como ilustrado na FIG. 5.6, a máquina virtual se conecta a estação física por meio de um
bridged (seção 2.4.1.1), estando numa rede do Laboratório (FIG.
na virtual se conecta a máquina-roteador por meio do adaptador do tipo
. Este teste envolve verificar se a rede referente a este adaptador ser
aprendida pelos roteadores do Laboratório, e vice-versa. Para isso, habilitou
que ela permitisse a comunicação entre o roteador virtual com o Laboratório.
Representação do teste envolvendo roteador físico e virtual
Entretanto, testes de alcançabilidade para alguma interface de um roteador do Laboratório
a partir da máquina virtual representante da LAN não obtiveram êxito. Mesmo resultado
obtido a partir de algum roteador do Laboratório para essa máquina virtual.
a execução do comando traceroute são apresentados na TAB. 5.1.
Resultado do teste entre um roteador físico e um virtual
Teste de alcançabilidade a partir ... Resultado: atingiu ...
... do roteador do Laboratório. ... a interface na máquina
diretamente conectada com a estação.
... da máquina virtual representante da LAN na ... a interface da estação.
is utilizadas na simulação em uma
estação real conectada ao Laboratório de Redes do IME. Uma máquina virtual como roteador
e uma representando a LAN como na FIG. 5.2. O objetivo deste teste consistiu em verificar a
teadores do Laboratório e se as redes deste seriam
, a máquina virtual se conecta a estação física por meio de um
estando numa rede do Laboratório (FIG.
roteador por meio do adaptador do tipo host-
. Este teste envolve verificar se a rede referente a este adaptador será reconhecida e
Para isso, habilitou-se a estação para
que ela permitisse a comunicação entre o roteador virtual com o Laboratório.
Representação do teste envolvendo roteador físico e virtual
Entretanto, testes de alcançabilidade para alguma interface de um roteador do Laboratório
a partir da máquina virtual representante da LAN não obtiveram êxito. Mesmo resultado
obtido a partir de algum roteador do Laboratório para essa máquina virtual. Testes com o
5.1.
entre um roteador físico e um virtual
Resultado: atingiu ...
... a interface na máquina-roteador
diretamente conectada com a estação.
a interface da estação.
59
5.6 CONSIDERAÇÕES
5.6.1 Conseqüências da cópia de máquina virtual
Alguns detalhes devem ser observados na criação das máquinas virtuais. A primeira
máquina virtual pode ser criada da forma convencional, instalando o sistema operacional. Esta
instalação é um processo custoso que, se for realizado para cada máquina virtual adicionada,
despenderá uma quantidade razoável de tempo.
Essa situação pode ser evitada a partir da segunda máquina virtual. Ao invés de realizar o
processo de instalação para cada uma, pode-se simplesmente copiar os arquivos da máquina
virtual e renomeá-lo para o novo nome. Renomear significa substituir todas as ocorrências do
antigo nome pelo novo.
Deve-se atentar para dois detalhes: arquivos lock (.lck) e a nomenclatura das interfaces de
rede.
Após a cópia dos arquivos da máquina virtual, pode não ser possível inicializar a máquina
com uma mensagem referente a arquivos bloqueados. Para evitar essa situação, arquivos de
extensão .lck devem ser apagados da pasta da máquina virtual.
Ao inicializar a nova máquina, o MMV identifica a semelhanças e questiona o usuário se
a máquina foi copiada ou movida. No caso de ser copiada, o MMV regera todos os seus
identificadores considerados únicos. Isso ocorre para evitar um conflito de endereços físicos,
por esta razão, interfaces de rede em máquina que normalmente são denominadas ethi, i
inicializando em zero, terão uma nomenclatura distinta da usual. A cada cópia, i será
incrementado do número de interfaces de rede que a máquina base de cópia possui.
Duas ações podem ser realizadas para deixar as interfaces com denominações coerentes:
• Remover o arquivo /etc/udev/rules.d/70-persistent-net.rules e reinicar a
máquina;
• Editar o arquivo /etc/udev/rules.d/70-persistent-net.rules de forma que as
interfaces de rede estejam consistentes com os novos endereços físicos resultantes da
cópia realizada.
60
5.5.1.1 Traceroute
Durante a execução dos testes na simulação, observou-se um atraso na obtenção do
resultado em uma primeira execução de um comando traceroute. Percebe-se que a execução
do comando atinge o destino, entretanto, não é exibido o trajeto até o destino, como
apresentado na TAB.5.2. Contudo, obtém-se o resultado completo após a repetição da
execução em instantes depois, como mostra a TAB. 5.3.
TAB. 5.2 Exemplo de uma traceroute executado a partir de uma máquina-roteador
traceroute to 10.0.0.33 (10.0.0.33), 30 hops max, 60 byte packets 1 * * * 2 * * * 3 10.0.0.33 34.737 ms 34.754 ms 34.745 ms
TAB. 5.3 Exemplo de uma traceroute executado a partir de uma máquina-roteador logo
após o exemplo de TAB. 5.2
traceroute to 10.0.0.33 (10.0.0.33), 30 hops max, 60 byte packets 1 10.0.0.13 0.430 ms 0.229 ms 0.230 ms 2 10.0.0.21 0.577 ms 0.436 ms 0.433 ms 3 10.0.0.33 0.933 ms 0.716 ms 0.707 ms
5.5.1.2 PING
No decorrer dos testes e da simulação, verificou-se que o teste de alcançabilidade não
retorna resultados se o destino for alcançável por mais de uma rota com métrica igual. A
alcançabilidade é verdadeira, pois é retornado um resultado se for especificado por qual
interface o teste deve ocorrer.
5.6.2 Quagga VS. Cisco IOS
Em uma simulação como esta, detectam-se as limitações do software de roteamento
Quagga, algumas configurações não podem ser estabelecidas, como comandos de
gerenciamento e performance da rede. Através destes comandos pode-se, por exemplo,
configurar o roteador para possuir funcionalidades que o SNMP fornece.
61
Durante a simulação, percebeu-se que o Quagga não possui uma série de comandos em
relação ao Cisco IOS. Alguns comandos presentes nas configurações de roteadores do
Laboratório são apresentados na TAB. 5.4
TAB. 5.4 Exemplos de comandos que não disponíveis no Quagga
Comando Função
service timestamps debug uptime Indica que uma marca de tempo deve ser
aplicada a mensagens de depuração
service timestamps log uptime Indica que uma marca de tempo deve ser
aplicada a mensagens de log18
ip default-gateway Define o default gateway do roteador
fair-queue Habilita o serviço de enfileiramento para
uma interface
Outra diferença entre estes softwares consiste que o Cisco IOS utiliza um processo para
carregar as funções de roteamento e o Quagga atribui um para cada serviço, como citado na
seção 4.2. Isto acarreta em ter que realizar diferentes acessos dependendo do objetivo do
administrador da rede. O acesso pode ser realizado via TELNET pela porta referente ao
daemon zebra, 2601, ou pelas portas referentes a protocolos, como 2602 para o RIP e 2604
para o OSPF.
Quando o acesso TELNET é realizado pela porta 2601, é possível visualizar e modificar
configurações, que não são relacionadas a protocolos, de interface e podem-se configurar
rotas estáticas. Como apresentado na seção 4.2, o daemon zebra é responsável por atualizar a
tabela de roteamento do núcleo. O acesso TELNET por outras portas, referentes a protocolos,
permite ao usuário visualizar e alterar configurações de roteamento.
18
Log – Arquivos de log guardam informações de um determinado programa.
62
6 INTERFACE WEB
Com intuito de simplificar o gerenciamento das máquinas virtuais, foi desenvolvido uma
interface web que oferece a um administrador opções configuração dos equipamentos.
Através dela, pode-se verificar como está a configuração dos roteadores de cada máquina-
roteador e permite também a possibilidade de alterar a configuração de algum roteador, como
métrica e endereço, por exemplo.
Esta seria uma forma simples para o administrador visualizar e alterar configuração dos
roteadores, uma vez que a maneira usual de se realizar esta tarefa seria por meio de um
terminal. Uma vez logado, o usuário pode realizar qualquer comando disponível pela
interface, além de possuir um campo com a opção de escrever um comando diferente dos
disponíveis.
Possibilidades disponíveis pela interface:
• Realizar PING e traceroute a partir de um roteador para um destino escolhido;
• Visualizar e editar a configuração de um roteador da rede;
• Escolher qual protocolo a ser utilizado na rede, ou OSPF ou RIP;
• Visualizar a tabela de rotas atualizada pelo Quagga.
6.1 FRAMEWORK DJANGO
Para o desenvolvimento desta interface web foi utilizado a ferramenta Django,
framework19 escrito na linguagem de programação Python. Sua utilização se justifica pelo
fato da linguagem Python possuir uma série de vantagens.
A biblioteca padrão de Python possui diversos módulos que auxiliam a programação,
como por exemplo, podem ser citados módulos para protocolos de rede, como HTTP e FTP, e
para acesso a serviços do SO. Além da biblioteca padrão, há uma gama de extensões
disponíveis para diversos tipos de aplicações. (Django, 2010)
Nesse raciocínio, o Django foca na automatização da programação. Ele utiliza o padrão
de projeto MVC (Model-View-Conrtoller), no qual se caracteriza por dividir uma aplicação
em três partes: uma que é apresentada na tela do usuário, uma que define como a interface se
comportará as entradas do usuário e uma para gerenciar a informação. (Gamma, 2000)
19
Framework – Estrutura que auxilia o desenvolvimento de projetos de software.
63
6.2 FUNCIONAMENTO
Uma das diferenças entre o software de roteamento Quagga e o Cisco IOS reside que o
utilizado por este projeto não permite ao usuário, uma vez estando no roteador, realizar
comando PING e traceroute. Entretanto, nesta interface web é possível a execução desses
comandos, pois são executados na máquina-roteador, ou seja, na máquina virtual que possui o
software de roteamento instalado.
Assim, o administrador da rede poderá controlar através de duas páginas em um
navegador, esta interface web e a página fornecida pelo VMware. Com essas duas páginas,
além de haver a possibilidade executar comandos e visualizar como os roteadores estão
configurados, o VMware disponibiliza uma interface gráfica de administração das máquinas
virtuais.
Todos os comandos realizados na interface web são chamadas a funções de uma
biblioteca criada especificamente para esta função. (ver ANEXO 4) Como o servidor da
interface web se encontra na máquina hospedeira, a execução de PING e traceroute de um
roteador para um destino escolhido se faz através da execução destes comandos remotamente,
uma vez que as máquinas virtuais são acessíveis a partir da máquina hospedeira. Este acesso é
possível se cada máquina-roteador possuir um adaptador de rede do tipo host-only utilizada
como default gateway de máquinas virtuais comuns.
Para não precisar de autenticação a cada execução, um par de chaves, pública e privada,
foi gerado na máquina hospedeira de modo a deixar a chave privada nesta máquina e a chave
pública nas máquinas que se deseja realizar comandos remotamente. Portanto, cada máquina
virtual terá essa chave pública. (ver APÊNDICE 2)
O SO gera uma chave de autenticação quando uma máquina acessa outra pela primeira
vez, porém essa autenticação necessita de senha. A execução dos comandos remotos funciona
de modo semelhante, mas o par de chaves, pública e privada, permite um acesso direto para
que os comandos sejam executados na máquina sem a necessidade senha por execução.
6.3 PÁGINAS WEB
A interface web é composta por algumas páginas web e cada um possui sua própria
funcionalidade. Cada página possui um campo de escolha informando as opções de máquinas
virtuais que estão funcionando como roteadores. Páginas que possuam algum campo para ser
preenchido com a numeração da porta referente a algum daemon do Quagga, possuem um
64
campo de escolha informando o número referente a cada um. Os campos de escolha apenas
informam quais são as opções para o usuário.
Estas opções são colhidas e tratadas a partir de um arquivo na máquina hospedeira
contendo as seguintes informações: nome da máquina virtual, nome do roteador e endereço
para acesso a máquina virtual.
As páginas web foram divididas em dois grupos:
• Primeiro grupo: páginas que executam comando na máquina-roteador;
• Segundo grupo: páginas que mostram e alteram a configuração do roteador via
TELNET.
6.3.1 Primeiro grupo de páginas
6.3.1.1 PING
Na página PING, o usuário pode realizar este comando a partir de uma máquina-roteador
a um destino da rede simulada com as máquinas virtuais. Para isso, o usuário deve preencher
os campos obrigatórios, podendo alterar as opções padrão deste comando. A página possui os
seguintes campos:
• Source: Campo obrigatório em formato de endereço IPv420. Deve ser
preenchido com uma das opções no campo de escolha, ou seja, endereço da máquina-
roteador a partir do qual se deseja realizar o PING;
• Target: Campo obrigatório em formato de endereço IPv4. Deve ser preenchido
com um destino da rede, para realização de teste de acessibilidade;
• Interval: Campo opcional com valor padrão 0.1 com unidade de medida em
segundos. Representa o intervalo entre cada execução do comando;
• Counter: Campo opcional com valor padrão 5. Representa o número de
execuções do comando.
• Packetsize: Campo opcional com valor padrão 56 bytes. Representa o tamanho
do pacote a ser enviado neste comando. O valor máximo que este campo pode ser
preenchido é 65507 bytes.
A página retorna o resultado da execução.
20 Formato de endereço IPv4 – A.B.C.D, sendo que A,B,C,D são números de 0 a 255.
65
6.3.1.2 Traceroute
Análogo a pagina PING, através da página traceroute pode se executado este comando a
partir de uma máquina-roteador a um destino da rede. Os campos Source e Target são
análogos ao da página PING. A página retorna o percurso de Source até Target
6.3.1.3 Route
A página Route retorna ao administrador da rede como está a tabela de rotas de uma
máquina-roteador, que é atualizada pelo software de roteamento. Possui o campo Source,
análogo ao do PING.
6.3.2 Segundo grupo de páginas
A visualização e configuração da rede são realizadas por comandos remotos. Cada
máquina virtual com o Quagga instalado possui três programas responsáveis por realizar o
acesso TELNET ao roteador e executar os comandos desejados. Através da interface web,
estes programas são executados remotamente exibindo o que foi feito no roteador, quer seja
alguma alteração quer seja apenas uma simples consulta a configuração.
A idéia básica destes programas é semelhante, eles realizam o acesso TELNET ao
roteador da máquina para executar comandos. Cada página do segundo grupo executa um dos
programas citados anteriormente. (ver ANEXO 4) Segue uma apresentação das páginas com
seu respectivo programas:
6.3.2.1 Enable Mode
A página Enable Mode permite que o usuário execute um comando no modo Router# da
FIG 4.1 em um roteador da rede. O programa que realiza esta operação é o enablemode.py,
ele recebe como parâmetro um comando para ser executado neste modo acessado pela porta
2601 e retorna todas as informações desde a acesso até execução do comando.
Dois campos devem ser preenchidos para o usuário obter o retorno desejado:
• Ip router: Campo obrigatório em formato de IPv4 referente ao endereço da
máquina roteador;
66
• Command: Campo obrigatório referente ao comando a ser executado.
6.3.2.2 Config Int
O usuário poderá obter e alterar informações de uma interface na página Config Int.
configint.py é o programa executado por essa página. Ele é responsável por exibir
configurações de interface e possibilita a alteração destas. Para isso, este programa recebe três
parâmetros, porta para o acesso via TELNET, interface na qual a configuração será explorada
e o comando a ser executado no modo Router(config-if)# da FIG. 4.1;
A página possui quatro campos obrigatórios:
• Ip router: Análogo ao da página Enable mode;
• Port: Refere-se à porta para a conexão TELNET;
• Interface: Interface em que se deseja alterar alguma configuração;
• Command: Análogo da página Enable mode.
A razão para se ter mais de uma porta como opção de acesso reside no fato de as
configurações de interface relacionada a protocolos serem realizadas por uma porta diferente,
uma vez que o Quagga restringe que configurações referentes a protocolos apenas podem ser
realizadas quando o roteador é acessado pela porta do daemon do protocolo.
6.3.2.3 Config Router
Esta página permite ao usuário a possibilidade de verificar e modificar o estado de
configuração do roteador no modo Router(config-router)# da FIG. 4.1 através da execução do
programa configrouter.py, que recebe como parâmetro a porta para se conectar ao roteador e o
comando relacionado a protocolo para ser executado neste modo.
A página é composta por três campos obrigatórios, Ip router, Port e command, todos
análogos ao da página, sendo que Port não será 2601, pois este modo pode ser acessado
apenas por portas de protocolos, como 2602 para o RIP ou 2604 para o OSPF.
67
7 CONCLUSÃO
No final deste projeto é necessário destacar o conhecimento agregado em todas as fases.
Este conhecimento é representado pelo conceito de máquinas virtuais, pela teoria dos
protocolos de roteamento, teoria sobre softwares de roteamento (Cisco IOS e Quagga) teoria
de desenvolvimento web em linguagem de programação Python.
Na simulação do Laboratório de Redes do IME com máquinas virtuais, procurou-se
analisar o comportamento do software de roteamento Quagga com o software presente nos
equipamentos Cisco, o Cisco IOS. As máquinas-roteadores demonstraram consistência na
atualização das respectivas tabelas de rotas e sucesso na alcançabilidade de máquinas na rede
simulada. Por meio de análise de tráfego, pôde-se notar a coerência sintática e semântica dos
pacotes com informações de roteamento trocados pelas máquinas-roteadores em algumas
situações corriqueiras em uma rede.
Durante o estudo de caso, notou-se que o software de roteamento Quagga possui uma
quantidade limitada de comandos em relação ao Cisco IOS. Esta limitação não impediu a
realização dos testes e da simulação. Entretanto, isto é um empecilho para a substituição de
roteadores por máquinas virtuais em ambientes de produção. Testes de alcançabilidade e o
percurso para atingir um destino da rede, pontos negativos do Quagga em relação ao Cisco
IOS, podem ser contornados pela interface web desenvolvida neste projeto, que disponibiliza
funcionalidades com estes objetivos, além de permitir que o administrador da rede visualize e
altere configurações do roteador.
Apesar das limitações, verificou-se através de testes e de simulação que um roteador pode
ser substituído por uma máquina virtual com o software de roteamento Quagga instalado e
configurado. A partir dos testes, conclui-se que os protocolos RIP e OSPF atuam de forma
estável em uma simulação de topologia com máquinas virtuais interligadas por máquinas-
roteadores (máquina virtual com software de roteamento).
Portanto, a simulação de roteadores com máquinas virtuais se mostra um interessante
meio para o estudo de roteamento em escolas e universidades, tendo em vista o elevado custo
dos equipamentos e a grande semelhança na sintaxe dos comandos no software de roteamento
Quagga com o Cisco IOS.
Por fim, uma sugestão para projeto futuro seria a simulação de roteador explorando todas
as características do protocolo BGP utilizando recursos computacionais de alta performance.
68
8 REFERÊNCIAS BIBLIOGRÁFICAS
About – QEMU [on-line] Disponível: http://www.qemu.org/about.html [capturado em 22 jan.
2010]
BONEY, J. Cisco IOS in a Nutshell. 2 ed. O´Reilly & Associates, Inc., 2005. 800p.
CARISSIMI, A. Virtualização: da teoria a soluções. Minicursos do Simpósio Brasileiro
de Redes de Computadores - SBRC´2008 [online], Porto Alegre, p. 173-207
Disponível: http://www.gta.ufrj.br/ensino/CPE758/artigos-basicos/cap4-v2.pdf
[capturado em 23 nov. 2009]
Cisco Systems. Cisco IOS Configuration Fundamentals. 1 ed. MacMillan Technical
Publishing, 1997. 1448p.
Citrix XenServer: Efficient Server Virtualization Sotware. [on-line] Disponível em Internet
via URL:: http://www.xensource.com [capturado em 28 jun. 2010]
COMER, D. Interligacao de redes com TCP/IP. 5 ed. Rio de Janeiro: Elsevier, 2006. 460p.
Django | The Web Framework for perfectionists with deadlines. [on-line] Disponível:
http://www.djangoproject.com/ [capturado em 9 jul. 2010]
GAMMA, E. et al. Padrões de Projeto: soluções reutilizáveis de software orientado a
objetos. 1 ed. Porto Alegre: Bookman, 2000. 364 p.
KVM. [on-line] Disponível: http://www.linux-kvm.org/page/Main_Page [capturado em 25
jan. 2010]
Linux Man Pages. [on-line] Disponível: http://linuxmanpages.com/ [capturado em 26 jun.
2010]
MENASCÉ, D. Virtualization: Concepts, Applications, and Performance Modeling. Int.
CMG Conference 2005: p. 407-414
Microsoft Hyper-V Server: Home Page [on-line] Disponível:
http://www.microsoft.com/hyper-v-server/en/us/default.aspx [capturado em 25 jan. 2010]
PETERSON, L., DAVIE, B. Redes de Computadores: uma abordagem de sistemas. 3 ed.
Rio de Janeiro: Elsevier, 2004. 588p.
POPEK, G., GOLDBERG, R. Communications of the ACM. Formal Requirements for
Virtualizable Third-Generation Architectures. [online], v. 17, n. 7, p. 412–421 Julho
1974. Disponível em:
69
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.141.4815&rep=rep1&type=pdf
[capturado em 24 nov. 2009]
Quagga Software Routing Suite. [on-line]. Disponível em: http://www.quagga.net/
[capturado em 25 jan. 2010]
ROSENBLUM, M., GARfiNKEL, T. IEEE Computer Society. Virtual MachineMonitors:
Current Technology and Future Trends. [online] v. 38, n. 5, p. 39-47 Maio 2005.
Disponível em:
http://www.stanford.edu/group/comparch/papers/Computer_RosenblumGarfinkel.pdf
[capturado em 24 nov. 2009]
SILBERSCHATZ, A., GALVIN, P., GAGNE, G. Sistemas Operacionais. 1 ed. Rio de
Janeiro: Campus, 2001.
SMITH, J., NAIR, R. The architecture of virtual machines. IEEE Computer Society Press,
v.38, n.5, p. 32-38, 2005.
SOMMERVILLE, I. Engenharia de Software. 7 ed. São Paulo: Pearson Education, 2007.
568 p.
TANENBAUM, A. Redes de computadores. 4 ed. Rio de Janeiro: Elsevier, 2003. 955p.
TANENBAUM, A. Sistemas Operacionais Modernos. 3 ed. São Paulo: Prentice Hall, 2009.
608p.
tshark - The Wireshark Network Analyzer 1.3.1. [on-line] Disponível:
http://www.wireshark.org/docs/man-pages/tshark.html [capturado em 22 jun. 2010]
VirtualBox [on-line] Disponível: http://www.virtualbox.org/ [capturado em 25 jan. 2010]
VMware Server User’s Guide. [on-line]. Disponível:
http://www.vmware.com/pdf/vmserver2.pdf [capturado em 18 set. 2009]
Why Choose VMware Virtualization for your Virtual Infrastructure [on-line] Disponível:
http://www.vmware.com/technical-resources/advantages/ [capturado em 25 jan. 2010]
Wireshark Network Analyzer 1.3.1. [on-line] Disponível:
http://www.wireshark.org/docs/man-pages/wireshark.html [capturado em 22 jun. 2010]
XAVIER, F. Roteadores Cisco - Guia Básico De Configuração e Operação. 1 ed. São
Paulo: Novatec, 2004. 256p.
Xen® hypervisor, the powerful open source industry standard for virtualiation. [on-line]
Disponível: http://www.xen.org/ [capturado em 28 jun. 2010]
Xen-BR. [on-line] Disponível: http://wiki.xen-br.org/ [capturado em 28 jun. 2010]
70
Zebra – Routing Software. [on-line]. Disponível: http://www.zebra.org/ [capturado em 25
jan. 2010]
71
9 APÊNDICES
9.1 APÊNDICE 1: DESCRIÇÃO DE TOPOLOGIAS
9.1.1 FIG. 5.3
Roteador1:
Interface eth1:
Endereço IP: 192.168.3.3
Máscara de sub-rede: 255.255.255.0
Interface eth2:
Endereço IP: 192.168.4.3
Máscara de sub-rede: 255.255.255.0
Roteador2:
Interface eth0:
Endereço IP: 192.168.1.3
Máscara de sub-rede: 255.255.255.0
Interface eth1:
Endereço IP: 192.168.3.4
Máscara de sub-rede: 255.255.255.0
Interface eth2:
Endereço IP: 192.168.5.3
Máscara de sub-rede: 255.255.255.0
Roteador3:
Interface eth0:
Endereço IP: 192.168.34.3
Máscara de sub-rede: 255.255.255.0
Interface eth1:
Endereço IP: 192.168.1.4
Máscara de sub-rede: 255.255.255.0
Interface eth2:
Endereço IP: 192.168.7.3
72
Máscara de sub-rede: 255.255.255.0
Roteador4:
Interface eth0:
Endereço IP: 192.168.34.4
Máscara de sub-rede: 255.255.255.0
Interface eth1:
Endereço IP: 192.168.8.3
Máscara de sub-rede: 255.255.255.0
9.1.2 FIG. 5.4
Roteador1:
Interface eth0:
Endereço IP: 192.168.7.3
Máscara de sub-rede: 255.255.255.0
Interface eth1:
Endereço IP: 192.168.3.3
Máscara de sub-rede: 255.255.255.0
Interface eth2:
Endereço IP: 192.168.4.3
Máscara de sub-rede: 255.255.255.0
Roteador2:
Interface eth0:
Endereço IP: 192.168.1.3
Máscara de sub-rede: 255.255.255.0
Interface eth1:
Endereço IP: 192.168.3.4
Máscara de sub-rede: 255.255.255.0
Interface eth2:
Endereço IP: 192.168.5.3
Máscara de sub-rede: 255.255.255.0
73
Roteador3:
Interface eth1:
Endereço IP: 192.168.1.4
Máscara de sub-rede: 255.255.255.0
Interface eth2:
Endereço IP: 192.168.34.3
Máscara de sub-rede: 255.255.255.0
Roteador4:
Interface eth0:
Endereço IP: 192.168.34.4
Máscara de sub-rede: 255.255.255.0
Interface eth1:
Endereço IP: 192.168.8.3
Máscara de sub-rede: 255.255.255.0
Interface eth0:
Endereço IP: 192.168.7.4
Máscara de sub-rede: 255.255.255.0
9.1.3 FIG. 5.5
CYPRUS:
Interface eth0:
Endereço IP: 10.0.0.9
Máscara de sub-rede: 255.255.255.252
Interface eth1:
Endereço IP: 10.0.0.14
Máscara de sub-rede: 255.255.255.252
Interface eth2:
Endereço IP: 10.0.0.6
Máscara de sub-rede: 255.255.255.252
Interface eth3:
Endereço IP: 192.168.0.254
Máscara de sub-rede: 255.255.255.0
74
THASSOS:
Interface eth0:
Endereço IP: 192.168.2.254
Máscara de sub-rede: 255.255.255.0
Interface eth1:
Endereço IP: 10.0.0.5
Máscara de sub-rede: 255.255.255.252
Interface eth2:
Endereço IP: 10.0.0.30
Máscara de sub-rede: 255.255.255.252
CRETA:
Interface eth0:
Endereço IP: 192.168.1.254
Máscara de sub-rede: 255.255.255.0
Interface eth1:
Endereço IP: 10.0.0.25
Máscara de sub-rede: 255.255.255.252
Interface eth2:
Endereço IP: 10.0.0.10
Máscara de sub-rede: 255.255.255.252
MYKONOS:
Interface eth0:
Endereço IP: 192.168.3.254
Máscara de sub-rede: 255.255.255.0
Interface eth1:
Endereço IP: 10.0.0.13
Máscara de sub-rede: 255.255.255.252
Interface eth2:
Endereço IP: 10.0.0.22
Máscara de sub-rede: 255.255.255.252
SANTORINI:
Interface eth0:
Endereço IP: 192.168.0.254
75
Máscara de sub-rede: 255.255.255.0
Interface eth1:
Endereço IP: 10.0.0.21
Máscara de sub-rede: 255.255.255.252
Interface eth2:
Endereço IP: 10.0.0.34
Máscara de sub-rede: 255.255.255.252
Interface eth3:
Endereço IP: 10.0.0.26
Máscara de sub-rede: 255.255.255.252
NAXOS:
Interface eth0:
Endereço IP: 10.0.0.33
Máscara de sub-rede: 255.255.255.252
Interface eth1:
Endereço IP: 10.0.0.29
Máscara de sub-rede: 255.255.255.252
Interface eth2:
Endereço IP: 10.0.0.38
Máscara de sub-rede: 255.255.255.252
9.2 APÊNDICE 2: COMANDOS
9.2.1 tshark
TAB. 9.1 Comandos para captura de pacotes através do tshark
Comando Função
tshark –D Lista as interfaces que o tráfego pode ser capturado
tshark –i 2 –V Captura tráfego através da interface 2 listada em “tshark -D” , mostrando o conteúdo
76
9.2.2 Autenticação remota sem senha
Na máquina hospedeira:
Gera chave pública e chave primária: # ssh-keygen -t rsa -f ~/.ssh/id_rsa
Transferir chave pública para máquina hóspede: # scp ~/.ssh/id_rsa.pub
username@endereco_hospede:~/
Na máquina-roteador:
mv id_rsa.pub authorized_keys
chmod 600 authorized_keys
chown root:root authorized_keys
77
10 ANEXOS
10.1 ANEXO 1:MENSAGENS OSPF
10.1.1 Cabeçalho OSPF
TAB. 10.1 Formato do cabeçalho OSPF
0 8 16 24 31 Versão (OSPF
Version) Tipo (Message
Type) Tamanho da mensagem (Packet Length)
Endereço IP do Roteador de Origem (Source OSPF Router) ID da Área (Area ID)
Soma de verificação (Packet Checksum) Tipo de Autenticação (Auth Type) Autenticação (octetos 0-3) (Auth Data) Autenticação (octetos 4-7) (Auth Data)
10.1.2 HELLO
TAB. 10.2 Formato da mensagem HELLO OSPF
0 8 16 24 31 Cabeçalho OSPF com tipo=1 (Message Type)
Máscara de rede (Network Mask) Intervalo de HELLO (Hello Interval) Opções (Options) Prio Gway (Router
Priority) Intervalo inativo do roteador (Router Dead Interval)
Roteador designado (Designated Router) Roteador designado de backup (Backup Designated Router)
Endereço IP vizinho1 (Active Neighbor) Endereço IP vizinho2
... Endereço IP vizinhon
78
10.1.3 DATABASE DESCRIPTION
TAB. 10.3 Formato da mensagem DATABASE DESCRIPTION OSPF
0 8 16 24 29 31 Cabeçalho OSPF com tipo=2
Mtu da interface Opções Todos 0s I M S
Roteador designado de backup Endereço IP vizinho1
Endereço IP vizinho2 ...
Endereço IP vizinhon
10.1.4 LINK STATE UPDATE
TAB. 10.4 Formato da mensagem LINK STATE UPDATE OSPF
0 16 31 Cabeçalho OSPF com tipo=4 (Message Type)
Número de anúncios de estado de enlace (Number of LSAs21)
Anúncio de estado de enlace1
... Anúncio de estado de enlacen
10.1.5 Formato do cabeçalho para anúncios de estados de enlace
TAB. 10.5 Formato do cabeçalho para anúncios de estados de enlace
0 16 31 Idade LS (LS Age) Tipo LS (LS Type)
ID LS (Link State ID) Roteador anunciante (Advertising Router)
Número de seqüência de enlace (LS Sequence Number) Soma de verificação de enlace (LS
Checksum) Tamanho LS (Length)
21
LSA – Anúncio de estado de enlace (Link State Advertisement)
79
10.2 ANEXO 2: ARQUIVOS
Partes do conteúdo obtido em capturas de pacotes na simulação. Estes arquivos estão contidos no DVD referente a este trabalho.
10.2.1 Desligamento de interface
Saída após realizar o desligamento da interface s1 no roteador CYPRUS da FIG. 5.5. Arquivo: teste_queda_10.0.0.14.txt
10.2.2 Reativação de interface
Saída após reativar a interface s1 no roteador CYPRUS. Arquivo: teste_retorno_10.0.0.14.txt
10.2.3 Pacotes HELLO
Saída da captura de pacotes através das interfaces do tipo host-only. Arquivo: envio_hello.txt
10.2.4 Outros anúncios
Pacote emitido por um roteador diferente do anunciante. Arquivo: propagacao_retorno_10.0.0.14.txt
10.2.5 Pacote de descrição de banco de dados
Captura de pacote de descrição de banco de dados OSPF. Arquivo: teste_insercao_ip_192.168.8.254.txt
10.3 ANEXO 3: MANUAL QUAGGA
Disponível no DVD referente a este trabalho.
10.4 ANEXO 4: CÓDIGO-FONTE DA INTERFACE WEB
Disponível no DVD referente a este trabalho.
80
10.5 ANEXO 5: PAGINA WEB
10.5.1 Página Ping
FIG. 10.1 Página Ping
81
10.5.2 Página Traceroute
FIG. 10.2 Página Traceroute
10.5.3 Página Route
FIG. 10.3 Página Route
82
10.5.4 Página Enable Mode
FIG. 10.4 Página Enable Mode
83
10.5.5 Página Config Int
FIG. 10.5 Página Config Int
10.5.6 Página Config Router
FIG. 10.6 Página Config Router