MINISTÉRIO DA DEFESA EXÉRCITO BRASILEIRO DEPARTAMENTO DE …€¦ · 3.5 BORDER GATEWAY PROTOCOL...

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



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


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



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


ização modifica o código-fonte do SO hóspede de maneira que, em




que o SO possa utilizar, conhecida como API (Application Programming Interface).

Na virtualização total, quando ocorre uma instrução sensível, o hardware



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


fonte do SO hóspede de maneira que, em




Application Programming Interface).

hardware cria uma



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


. 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


Um MMV controlando uma virtualização total e uma paravirtualização


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


trata de interpretar as instruções sensíveis geradas

minado micronúcleo, que


Um MMV controlando uma virtualização total e uma paravirtualização


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


roteamento por vetor distância. O primeiro ocorre uma vez que o algoritmo não detecta ciclos


confiáveis ou tomar precauções para evitar esses ciclos.

Em segundo, este tipo de roteamento usado pelo RIP pode criar



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



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



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


corre uma vez que o algoritmo não detecta ciclos


Em segundo, este tipo de roteamento usado pelo RIP pode criar um problema de



ente, ajuda a limitar a

sse problema é mostrado na FIG 3.1.



re, por exemplo, quando uma conexão falha a um destino específico



, 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.


um grafo orientado no qual se define um custo para cada arco. Com base nos

o OSPF calcula o menor caminho.


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.



nho mais curto até cada roteador, obtido por meio do algoritmo referente.


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


um grafo orientado no qual se define um custo para cada arco. Com base nos pesos dos arcos,


. Todas as áreas estão conectadas a ela,

. A utilização de áreas numeradas

backbone. Como ocorre nas



nho mais curto até cada roteador, obtido por meio do algoritmo referente.


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)



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



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


estrutura de rede, o Cisco IOS permite que a funcionalidade

Simple Network Management Protocol, ou Protocolo Simples de Gerenciamento de Rede)



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.


estrutura de rede, o Cisco IOS permite que a funcionalidade SNMP

olo Simples de Gerenciamento de Rede)



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


serviço para um conjunto de daemons12, um para cada protocolo, que se encarregam de

roteamento. Todos esses daemons se comunicam com o



tetura do Quagga (Quagga, 2010), expondo o relacionamento entre os


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


, um para cada protocolo, que se encarregam de

se comunicam com o daemon zebra,



, expondo o relacionamento entre os daemons


(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


com o Roteador3. Cada roteador possui uma rede conectada a uma



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


com o Roteador3. Cada roteador possui uma rede conectada a uma



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


configurado na descrição da máquina virtual que o adaptador de rede desta máquina se refere


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


tador de rede desta máquina se refere


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


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


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



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


Representação do teste envolvendo roteador físico e virtual



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



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


Representação do teste envolvendo roteador físico e virtual



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


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


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:



Roteador2:

Interface eth0:



Interface eth1:



Interface eth2:



Roteador3:

Interface eth0:



Interface eth1:



Interface eth2:


72


Roteador4:

Interface eth0:



Interface eth1:



9.1.2 FIG. 5.4

Roteador1:

Interface eth0:



Interface eth1:



Interface eth2:



Roteador2:

Interface eth0:



Interface eth1:



Interface eth2:



73

Roteador3:

Interface eth1:



Interface eth2:



Roteador4:

Interface eth0:



Interface eth1:



Interface eth0:



9.1.3 FIG. 5.5

CYPRUS:

Interface eth0:



Interface eth1:



Interface eth2:



Interface eth3:

Endereço IP: 192.168.0.254


74

THASSOS:

Interface eth0:

Endereço IP: 192.168.2.254


Interface eth1:



Interface eth2:



CRETA:

Interface eth0:

Endereço IP: 192.168.1.254


Interface eth1:



Interface eth2:



MYKONOS:

Interface eth0:

Endereço IP: 192.168.3.254


Interface eth1:



Interface eth2:



SANTORINI:

Interface eth0:

Endereço IP: 192.168.0.254

75


Interface eth1:



Interface eth2:



Interface eth3:



NAXOS:

Interface eth0:



Interface eth1:



Interface eth2:



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

MINISTÉRIO DA DEFESA EXÉRCITO BRASILEIRO DEPARTAMENTO DE …€¦ · 3.5 BORDER GATEWAY PROTOCOL...

Documents

Transcript of MINISTÉRIO DA DEFESA EXÉRCITO BRASILEIRO DEPARTAMENTO DE …€¦ · 3.5 BORDER GATEWAY PROTOCOL...