16 REVISTA DE TECNOLOGIA DA INFORMAÇÃO E COMUNICAÇÃO, VOL. 6, NO.
2, OUTUBRO 2016
Simuladores e Emuladores de Rede para o Projeto e
Solução de Problemas em Ambientes de Produção
Marcelo Sousa, Joab Silva, Whasley Souza, Yngrid Cabral, Uênio Rocha, e Tatiana Olimpio
Instituto Federal da Paraı́ba – IFPB campus Campina Grande
Capı́tulo Técnico da ComSoc – Ramo Estudantil IEEE do IFPB campus Campina Grande
E-mails: {marcelo.portela, joab.a.silva, whasley.s.c, yngrid.k.cabral, uenio.v.rocha, tatiana.olimpio.br}@ieee.org
Resumo—Simuladores e emuladores tem um papel importante
para auxiliar no funcionamento de redes de computadores. Por
tentarem se aproximar ao modo de operação de um ambiente real
é possı́vel extrair vantagens no uso de ferramentas desse tipo.
Sob a identificação adequada dos requisitos daquele ambiente
(requisitos do cliente) um engenheiro de redes pode projetar de
maneira adequada as soluções para o respectivo cenário, com a
oportunidade de realizar testes exaustivos antes da aplicação em
equipamentos reais. Isso pode economizar recursos financeiros,
além de resultar em uma melhor documentação de projeto, o que
contribui também para uma melhor identificação e solução de
problemas (trobleshooting). Neste artigo, os autores apresentam
as principais caracterı́sticas de alguns simuladores e emuladores
de redes de computadores, assim como algumas diferenças em
seus modos de operação. A contextualização com ambientes reais
é realizada, citando vantagens e desvantagens dessas ferramentas
frente à interação com protocolos, dispositivos reais e confiabi-
lidade na tentativa de reproduzir o comportamento da rede em
ambientes de produção. Um detalhamento maior é exposto na
análise do simulador Cisco Packet Tracer e do emulador GNS3,
que também integram parte de um experimento em laboratório
real, com componentes de roteamento, comutação, Internet das
Coisas e sistemas operacionais variados.
Index Terms—Simuladores, emuladores, Cisco Packet Tracer,
GNS3, Projeto de Redes.
I. I NTRODUÇ ÃO
Softwares que reproduzem caracterı́sticas e funcionalidades
de dispositivos de rede tornaram-se amplamente disponı́veis. A
diferença teórica entre os softwares emuladores e os softwares
simuladores é que os primeiros reproduzem fielmente carac-
terı́sticas do objeto original, podendo substituı́-lo em diversas
funções. Essencialmente, um emulador é um software criado
para transcrever instruções de um determinado processador
ao processador no qual ele está sendo executado. Também
é capaz de reproduzir funções de circuitos integrados. Já os
programas simuladores imitam o objeto original em algumas
funções, porém, não em todas e nem sempre de maneira muito
realista.
Em se tratando de redes de computadores, ambos têm o
seu campo de atuação. Os simuladores reproduzem algumas
caracterı́sticas de dispositivos de redes reais, possibilitando a
execução de alguns experimentos. Nem tudo é permitido, en-
tretanto. Alguns protocolos não são compreendidos, algumas
funções não se encontram disponı́veis e, em alguns casos,
configurações realizadas produzem um efeito diferente do que
é observado em dispositivos reais [1].
Um simulador [2] é um programa de computador que tenta
reproduzir com a maior fidelidade possı́vel alguma experiência
ou comportamento real [3]. Exemplos de simuladores de redes
são: Cisco Packet Tracer [4]; NS2 [5]; NS3 [6]; Castalia [7];
OMNET++ [8]; OPNET [9].
Simulações são consideradas imitações do Modus Operandi
de procedimentos ou sistemas do mundo real, executado ao
longo do tempo. Em outras palavras, simuladores envolvem
a criação de uma história artificial do sistema, em que, por
meio de observações, é possı́vel retirar inferências sobre as
caracterı́sticas do sistema real. Esses modelos são elaborados
tomando como base um conjunto de suposições em relação
à operação do sistema. Tais suposições são representadas
utilizando expressões matemáticas, lógicas e um relaciona-
mento simbólico entre as entidades ou objetos de interesse
compreendidos no sistema. Uma vez desenvolvido e validado,
um modelo pode ser utilizado para investigar uma vasta
diversidade de questionamentos sobre o sistema no mundo
real [10].
Um emulador é uma ferramenta que reproduz uma pla-
taforma virtualizada que permite que uma dada arquitetura
de computador consiga executar sistemas que foram desen-
volvidos para outra arquitetura especı́fica. Desse modo, um
emulador permite que o usário faça com que o seu computador
pessoal aparente ser outra plataforma (como um switch ou
roteador) para rodar outro sistema operacional, como por
exemplo, o Internetwork Operating System (IOS) [11], ou o
RouterOS [12].
Os softwares emuladores, por sua vez, têm a capacidade
de transformar um computador comum em um dispositivo de
rede, como um roteador real, replicando praticamente todas
as suas funções. A limitação fica por conta do desempenho
do elemento emulado, notadamente inferior ao de um ele-
mento fı́sico. Por este motivo, é desaconselhável a aplicação
de elementos emulados em testes de desempenho [1]. Esse
comportamento se deve principalmente pelo fato de o que o
elemento fı́sico conta com recursos computacionais dedicados
ao fim especı́fico de interesse.
Este artigo tem como principal objetivo apresentar carac-
terı́sticas de alguns simuladores e emuladores de rede dis-
ponı́veis para uso de estudantes, professores, pesquisadores e,
principalmente, para profissionais que lidam com a operação
de redes de computadores, no que se refere tanto ao projeto,
quanto ao trobleshooting de redes. As análises consideram
aspectos relativos à confiabilidade dos softwares, possibilidade
 REVISTA DE TECNOLOGIA DA INFORMAÇÃO E COMUNICAÇÃO, VOL. 6, NO. 2, OUTUBRO 2016
de integração com ambientes reais e capacidadde para lidar
com protocolos de redes avançados.
O restante do artigo está dividido da seguinte maneira: a
Seção II apresenta caracterı́sticas importantes de simuladores
de rede, assim como mostra que eles podem ter propósitos
distintos de aplicação; a Seção III detalha os principais
parâmetros de funcionamento do simulador Cisco Packet Tra-
cer e descreve um exemplo de cenário com Internet das Coisas;
a Seção IV aborda a operação de alguns softwares emuladores
presentes no mercado, com um foco maior na descrição de
funcionamento do GNS3 e suas potencialidades. Ainda nessa
seção, os resultados de uma implementação de Rede Definida
por Software, realizada no Mininet, são discutidos; a Seção V
apresenta um experimento realizado no Laboratório de Redes
do IFPB, campus Campina Grande, que envolve a integração
de um ambiente emulado com o GNS3 (hosts Linux, Win-
dows, roteadores Cisco e MikroTik) e de dispositivos fı́sicos,
como equipamentos Cisco para roteamento e comutação, hosts
Linux e Windows e um Arduino com shield Ethernet; as
considerações finais estão reunidas na Seção VI.
II. S IMULADORES DE R EDE
Em projetos de sistemas que se encontram em fases iniciais,
como concepção e projeto, é comum a utilização de simula-
dores para averiguar requisitos antes da sua materialização.
Modelos de simulação também podem ser utilizados como
ferramenta de análise para predizer efeitos das mudanças exis-
tentes no sistema, como também ferramenta de projeto para
predizer o desempenho de novos arcabouços sob variação de
um conjunto de circunstâncias [13]. Simulação tem se demons-
trado como uma solução viabilizadora em vários domı́nios,
pois a observação com base empı́rica, apenas no mundo real,
pode se tornar inviável devido ao alto custo e investimento de
tempo necessário para tal. Entretanto, em algumas situações,
simulações também podem se apresentar inviáveis quando o
sistema a ser modelado envolve certa complexidade em termos
de expressar algo matematicamente [10].
No campo da comunicação e redes de computadores, simu-
ladores englobam um conjunto de modelos que são capazes de
representar, com certo grau de aproximação, o comportamento
dos elementos contidos na rede se prevalendo de cálculos
matemáticos para descrever a interação entre as entidades e
seus respectivos eventos [13].
III. O C ISCO PACKET T RACER
O Packet Tracer é um simulador desenvolvido pela Cisco
Systems para ser utilizado como ferramenta no Networking
Academy (NetAcad), um programa mundial de treinamento de
novos profissionais na área de redes e comunicação de dados.
O NetAcad está difundido por vários paı́ses [3].
A interface do simulador é bastante intuitiva e possibilita
exibir a topologia fı́sica ou também a topologia lógica da
rede projetada, de modo que para configurar um determinado
dispositivo, basta clicar em sua posição para abrir um menu
especı́fico com várias opções.
Por meio desse simulador é possı́vel criar topologias com
variadas infraestruturas de redes (simples ou complexas).
17
Adicionalmente, é possı́vel criar animações didáticas demons-
trando o tráfego de pacotes e o funcionamento interno de
diversos protocolos comumente adotados em redes, assim
como visualizar os cabeçalhos dos pacotes e reproduzir com
excelente nı́vel de fidelidade o processo de configuração
de diversos dispositivos empregados em ambientes reais de
produção [3]. A seguir, algumas caracterı́sticas operacionais
do Packet Tracer são discutidas.
A. Modo de Tempo Real
Há dois modos de funcionamento: Tempo Real e Modo de
Simulação. No primeiro, a simulação é realizada com base
em uma representação de passagem do tempo muito próxima
a um cenário real. Um mostrador no formato HH:MM:SS é
apresentado no lado esquerdo inferior da plataforma, de ma-
neira que um incremento em segundos é disponibilizado para o
usuário. Ainda nesse modo é possı́vel utilizar uma função para
adiantar a representação do tempo, pelo botão (Fast Forward
Time). Apertar esse botão resulta em um adiantamento de 30
segundos em relação ao momento corrente.
Uma consequência importante no uso desse modo é ob-
servar que os tempos (timers) dos protocolos suportados são
respeitados de maneira muito próxima a cenários reais. Por
exemplo, os perı́odos necessários para a convergência de
diversos protocolos podem ser observados, de acordo com
o previsto nas documentações correspondentes. Protocolos
como STP, RSTP, OSPF RIP, EIGRP, HSRP, entre outros,
compatibilizam seus funcionamentos temporais de maneira
muito próxima a cenários reais, o que também pode auxiliar
no projeto e solução de problemas em ambientes de produção.
B. Modo de Simulação
Há um modo de operação bastante elucidativo, no que se
refere à análise de tráfego e do funcionamento de protocolos:
o Modo de Simulação. Nesse modo, é possı́vel programar
a evolução da simulação e obter uma análise discreta, com
relação ao fluxo de pacotes. Algumas opções aumentam o
potencial desse modo. Por exemplo, é possı́vel especificar se
todos, ou apenas alguns dos protocolos suportados participarão
da visualização de análise de tráfego. Outra funcionalidade
importante é poder habilitar a opção de auto-captura, ou de
captura manual (passo-a-passo). Na primeira, o tráfego flui
automaticamente dispositivo a dispostivo, de acordo com a
taxa de reprodução programada pelo usuário. Na segunda
opção, o tráfego flui até um dispositivo, mas para que siga para
um próximo, é necessário que o usuário realize essa captura
manual. A auto-captura é indicada para analisar um macro
comportamento do cenário. Já a captura manual é indicada
para a análise de um comportamento mais granular e discreto.
Há um Painel de Simualação que apresenta a ocorrência
temporal em segundos de cada PDU (Protocol Data Unit).
Aqui está um dos pontos fortes do Packet Tracer. Ao clicar
em um desses pacotes, um conjunto de informações referentes
àquela PDU é apresentada, de modo que o usuário pode
analisar o conteúdo de cada camada do modelo OSI (Open
Systems Interconnection). Esse recurso, aliado a uma descrição
 18 REVISTA DE TECNOLOGIA DA INFORMAÇÃO E COMUNICAÇÃO, VOL. 6, NO. 2, OUTUBRO 2016
sobre o que está acontecendo na camada correspondente, é
muito poderoso para a identificação e solução de problemas.
Ainda com relação à análise de informações de cada PDU
é possı́vel verificar os detalhes de entrada e os detalhes de
saı́da, com relação ao dispositivo. Portanto, as informações de
cabeçalho, payload e trailler ficam disponı́veis ao usuário, de
maneira detalhada, indicando, inclusive a quantidade de bits
de cada campo.
C. Dispositivos Finais
O conjunto de Dispositivos Finais disponı́veis é composto
de: PC Desktop; Laptop; Servidor; Impressora; Telefones;
Televisão; Tablet; Smartphone; e Sniffer. Com exceção do Te-
lefone Analógico e do Sniffer, os outros dispositivos permitem
a atribuição de endereçamento IP.
Um PC, por exemplo, apresenta algumas abas importantes:
• Physical – apresenta uma visão frontal do gabinete
do PC, com uma indicação de ligado/desligado do LED
de Power do dispositivo. Além disso, diversas opções de
interface de rede são disponibilizadas para serem acres-
centadas ao PC, entre elas uma placa para comunicação
sem fio (WMP300N).
• Config – possibilita a alteração do nome do disposi-
tivo, assim como alterar parâmetros atrelados à interface
correspondente. Por exemplo, é possı́vel alterar o modo
Duplex (Half, Full, ou Auto) e alterar a largura de banda
(100 Mbps, 10 Mbps, ou Auto). Adicionalmente, nessa
aba também é possı́vel realizar a alteração manual do
endereço MAC da respectiva interface.
• Desktop – disponibiliza diversas funções de
configuração. Entre as mais importantes e utilizadas
estão: IP Configuration, em que é possı́vel alterar
parâmetros de endereçamento IPv4 e IPv6, com
atribuição estática ou por DHCP; Terminal, que atua
como um simulador de Terminal, como programas do
tipo Putty e TeraTerm; Command Prompt, que funciona
de maneira semelhante ao prompt de comandos de um
sistema operacional Windows, inclusive preservando
a sintaxe dos comandos; Web Browser, que habilita a
navegação Web, semelhante a um navegador do tipo
Google Chrome ou Mozilla Firefox.
Em um dispositivo Servidor, por exemplo, é possı́vel
indicar quais serviços o usuário deseja habilitar. Opções
como HTTP, HTTPS, DHCP, DNS, FTP, entre outros,
estão disponı́veis para o usuário.
D. Dispositivos Intermediários
Os principais dispositivos intermediários são compostos por:
Roteadores; Switches; Hubs; Dispositivos Sem Fio; Firewalls;
e Modems DSL. No geral, os dispositivos apresentam uma
visão relativa às interfaces de rede, assim como disponibilizam
a opção para inserir módulos adicionais. Existe a opção de
acessar a CLI (Command Line Interface) do dispositivo, de
maneira direta, por meio de uma aba interna ao roteador ou
switch. Adicionalmente, como em ambientes de produção, o
usuário pode acessar a CLI do dispositivo por duas opções:
• Fora da Banda (Out of Band) – em que recursos da rede
não são alocados. Normalmente este é um acesso por
linha console (cabo rollover) ou por linha auxiliar (via
modem) e caracteriza-se por ser um acesso mais seguro
e estável;
• Dentro da Banda (Inband) – em que recursos da rede
precisam ser utilizados. Geralmente protocolos como
Telnet ou SSH são executados para esse tipo de acesso,
em que cliente e servidor necessitam possuir endereços
IP e garantirem conectividade.
E. Meios Fı́sicos
Há diversas opções de meio fı́sico para conectar os dispositi-
vos finais e intermediários: cabo console; cabo direto (cobre);
cabo cruzado (cobre); fibra óptica; cabo para telefone; cabo
coaxial; cabos de conexão serial – DCE (Data Communication
Equipment) e DTE (Data Terminal Equipment); cabo octal;
cabo customizável para IoE (Internet of Everything) [14]; e
cabo de USB.
Algumas conexões realizadas entre dispositivos precisam
respeitar os requisitos de projeto, principalmente se o recurso
Auto MDIX (Medium Dependent Interface Crossover) não
estiver habilitado. Por exemplo, a conexão entre um PC e um
roteador, por meio de cabo de cobre, deve ser usada no modo
cruzado (cross-over).
Para fins de aprendizado, há um modo de escolha automática
sobre o tipo de cabo utilizado, em que o próprio Packet Tracer
indica a melhor opção de cabo a ser implantado entre os
dispositivos.
F. Internet das Coisas
A partir da versão 7, o Packet Tracer conta com recursos de
simulação de cenários de Internet das Coisas. Há componentes
especı́ficos, como placas com microcontrolador, sensores e
atuadores. A Figura 1 ilustra um dos cenários de amostra
trazidos na versão 7 do Packet Tracer, referente a um sistema
monitor de temperatura. O cenário contém um PC, um Sevidor
de Registros, um Monitor de Temperatura, um Termostato
e um switch que conecta esses dispositivos. Dois atuadores
para aumentar ou dimininuir a temperatura estão conectados
ao Termostato. Essa amostra de simulação instrui o usuário
a acessar o Servidor de Registros, por meio do endereço
1.1.1.1 e monitorar a temperatura. É possı́vel alterar os
parâmetros de temperatura por meio da manipulação direta no
Termostato, ou no servidor.
Em ambientes de produção, uma plataforma microcontro-
ladora que tem sido bastante utilizada para implantar funci-
onalidades de Internet das Coisas é o Arduino. Por meio do
acoplamento a shields Ethernet, Wi-Fi, ou ZigBee, o Arduino
possibilita o monitoramento e controle de fenômenos em áreas
de interesse, visto que adquire conectividade em rede [15].
G. Activity Wizard
O Activity Wizard é um recurso interessante do Packet
Tracer. Ele habilita a programação de roteiros de atividades, de
modo que haja uma contabilização do percentual de acertos em
 REVISTA DE TECNOLOGIA DA INFORMAÇÃO E COMUNICAÇÃO, VOL. 6, NO. 2, OUTUBRO 2016
Figura 1. Simulação de monitoramento de temperatura, por meio de uma
atividade de amostra do Cisco Packet Tracer.
configurações e montagens, por parte do usuário. Esse recurso
é bastante útil para ambientes de capacitação, por exemplo,
em que o instrutor pode programar roteiros de atividades
para os alunos, que por sua vez, têm a opção de saber quais
itens conseguiram acertar. Arquivos desse tipo possuem uma
extensão .pka.
IV. E MULADORES DE R EDE
A principal vantagem do uso de emuladores ao invés de
simuladores de rede é a possibilidade de lidar com tráfego
em tempo real e disponibilizar cenários mais próximos a
ambientes de produção. Adicionalmente, um dos maiores
benefı́cios proporcionados é a possibilidade de interconectar
o ambiente virtual (emulado) a um ambiente real.
Outro ponto importante a ser considerado quanto ao uso
de emuladores é a interface entre o elemento emulado e
o usuário, que pode interagir com o elemento virtual em
tempo real, e de forma muito semelhante ao que faria se
estivesse lidando com um dispositivo fı́sico. A configuração
dos elementos virtuais, por exemplo, pode ser realizada de
forma análoga à de elementos reais, e não por meio de uma
linguagem de programação criada especificamente para este
propósito. Comandos digitados em um dado elemento afetam
a rede experimental em tempo real [1].
A. O GNS3
Apesar de os simuladores de rede serem ferramentas im-
portantes, quando o usuário configura algum dispositivo, na
realidade ele interaje com o software que reproduz aquela
experiência, e não com o equipamento real. Por causa disso,
várias funcionalidades mais complexas dos equipamentos não
são suportadas por um programa simulador [3]. Por exemplo, o
Packet Tracer não suporta de maneira extensa protocolos como
o BGP e o MPLS. Mesmo em alguns comandos presentes é
possı́vel observar uma limitação na quantidade de argumentos
disponı́veis para uso.
O GNS3 é um aplicativo gratuito sob licença da GNU que
provê a interface gráfica que permite ao usuário construir a
topologia de rede que pretende configurar. Ele reúne diversos
emuladores de sistemas operacionais. O mais conhecido é
o Dynamips, que permite emular roteadores Cisco e provê
19
uma coleção de dispositivos genéricos e interfaces. Também
é possı́vel emular o funcionamento de switches, por meio de
uma modalidade conhecida como EtherSwitch, em que um
roteador possui um módulo de switch e consegue implementar
funções como VLANs, STP, Port-Security, entre outras. Há
outros emuladores suportados pelo GNS3 [16]:
• Qemu – Emula dispositivos Cisco ASA, roteadores Ju-
niper, roteadores Vyatta e hosts Linux;
• Pemu – Essa é uma variação de Qemu, utilizada para
Firewalls PIX, da Cisco;
• Virtualbox – Emula roteadores Juniper, roteadores
Vyatta, hosts Linux e hosts Windows;
• VMware – Permite a emulação de sistemas operacionais
para hosts e para roteadores Juniper, o Junos OS, por
exemplo;
• Docker – Habilita a utilização de conteiners para otimizar
a alocação de recursos de sistemas virtualizados.
Toda instância de um roteador (ou qualquer outro disposi-
tivo emulado) lida com a cópia do próprio sistema operacional,
que compete com recursos de RAM e CPU do host. Além
disso, dispositivos como roteadores e firewalls necessitam de
aplicativos terminais para prover acesso ao administrador de
rede. Há um outro conjunto de funcionalidades que estende a
operação do GNS3, relacionado a aplicativos terminais. De-
pendendo do sistema operacional, o aplicativo terminal pode
ser o Gnome Terminal, iTerm2, Konsole, PuTTY, SecureCRT,
SuperPutty, TeraTerm, Windows Telnet Client, Xterm, entre
outros. Independentemente de qual aplicação terminal seja
utilizada, ela consome mais recursos para que as sessões sejam
estabelecidas, embora não seja algo tão significativo.
Há duas ferramentas importantes que aumentam os be-
nefı́cios de uso do GNS3:
• Wireshark – Aplicativo popular de captura de pacotes;
• VPCS (Virtual PC Simulator) – Permite simular um
máximo de nove PCs, para uso em operações simples
como ping, traceroute, atribuição de endereços etc.
Essas ferramentas também consomem recursos de memória
e CPU do host. Desse modo, ajustar alguns parâmetros no
GNS3 é importante para garantir um correto funcionamento e
otimizar o gerenciamento de recursos da máquina fı́sica. Por
exemplo, o ajuste do valor de Idle-PC evita uma sobrecarga
próxima de 100% da CPU do host [16]. O processo envolvido
com o ajuste do valor de Idle-PC estima o perı́odo em que
a imagem do Sistema Operacional está ociosa (sem desem-
penhar tarefas) e coloca o roteador em um estado idle (sleep
mode).
Do ponto de vista operacional, há algumas diferenças no uso
do Packet Tracer e do GNS3. Por exemplo, no Packet Tracer,
uma interface fı́sica ao ser ligada, há um LED indicando
atividade dessa interface, que fica na cor verde. Por outro lado,
no GNS3, os LEDs das interfaces indicam apenas que aquele
dispositivo (Roteador, Switch, Firewal, PC etc) está ligado
(verde) ou desligado (vermelho).
Outra diferença importante é que o GNS3 não é dotado de
um Modo de Simulação, como no Packet Tracer. Entretanto,
o GNS3 permite a integração com o Wireshark para a análise
 20 REVISTA DE TECNOLOGIA DA INFORMAÇÃO E COMUNICAÇÃO, VOL. 6, NO. 2, OUTUBRO 2016
e captura de tráfego, de maneira real, o que o torna uma
ferramenta poderosa mais próxima a ambientes reais.
1) O Uso de Máquinas Virtuais e do Docker: O GNS3
permite o uso de máquinas virtuais, por meio de progra-
mas, como o Virtualbox e VMware Player. Na prática, cada
máquina virtual precisa ser criada separadamente e de modo
independente ao GNS3, no programa virtualizador correspon-
dente. Em seguida, essas máquinas podem ser importadas
para o GNS3 e alguns parâmetros ainda podem ser alterados.
Em ambos os casos, o adequado é ajustar os modos de
configuração de parâmetros de hardware, em especial no que
se refere às configurações de rede. Por exemplo, ao utilizar
uma RouterBoard Mikrotik, virtualizada com o Virtualbox, é
possı́vel ativar as quatro interfaces disponibilizadas, de modo
a aumentar a densidade de portas do roteador e escalar seu uso
dentro do GNS3. Os endereços MAC das interfaces também
podem ser especificados no próprio Virtualbox.
Aleḿ de roteadores e switches de fabricantes variados é
possı́vel utilizar máquinas virtuais para carregar hosts Li-
nux e Windows, por exemplo. Para esses casos, os sistemas
operacionais são carregados por completo e disponibilizados
para uso no GNS3. Essa caracterı́stica é muito importante e
é um diferencial, quando se compara potencialidades frente
a programas simuladores. Emular os sistemas operacionais
permite explorar as vulnerabilidades de cada um, assim como
projetar soluções casadas com versões especı́ficas de software
e de atualizações.
Um sistema completo virtualizado requer um conjunto
próprio de recursos alocados e apresenta um compartilhamento
mı́nimo. Há maior isolamento, mas são sistemas que exigem
mais recursos para funcionar.
O Docker [17] é uma plataforma Open Source escrito em
Go, que é uma linguagem de programação de alto desem-
penho desenvolvida pela Google, que facilita a criação e
administração de ambientes isolados. O Docker possibilita o
empacotamento de uma aplicação ou ambiente inteiro dentro
de um container, de modo que o ambiente inteiro torna-se
portável para qualquer outro host que contenha o Docker
instalado. Isso reduz bastante o tempo de implantação de
alguma infraestrutura ou até mesmo aplicação, pois não há ne-
cessidade de ajustes de ambiente para o correto funcionamento
do serviço. Outra facilidade do Docker é poder criar imagens
(containers prontos para implantação) a partir de arquivos de
definição denominados Dockerfiles [18].
No GNS3, o Docker é suportado a partir da versão 1.5. Pode
ser utilizado apenas como uma versão enxuta de computador,
substituindo as custosas (em consumo de recursos) máquinas
virtuais ou o VPCS, se apenas ferramentas como telnet,
nmap etc são necessárias. Também podem ser utilizadas para
emular infraestruturas de containers de ambientes de produção.
Os containers utilizam o kernel do host, consumindo menos
mémoria RAM e CPU, além de rodarem com programas
simples, em vez de o sistema operacional completo.
2) Integração com Dispositivos Reais: Uma das funciona-
lidades mais importantes disponibilizadas pelo GNS3, para
a interação com ambientes de produção é a integração com
dispositivos reais. Ele possui um tipo de dispositivo especial
projetado para essa função: um dispositivo nuvem. Ao adici-
onar a interface fı́sica do host à nuvem, é possı́vel conectar
dispositivos emulados (internamente ao GNS3) a dispositivos
de rede externos, como PCs e até mesmo roteadores.
Entretanto, quando um roteador envia quadros, eles passam
diretamente para a fila de saı́da da interface de rede. Ou seja,
o computador host pode enviar quadros ao roteador virtual,
mas o roteador virtual não pode enviar quadros ao computador
host. Dispositivos conectados externamente (na rede local, por
exemplo) não experimentam esse empecilho, de modo que
não há problema na comunicação entre eles e os dispositivos
virtualizados internos.
Há maneiras de viabilizar a comunicação entre o computa-
dor host e os dispositivos virtuais. Mas cada sistema operaci-
onal possui uma abordagem diferente, incluindo a adição de
uma bridge virtual interna [16].
3) O Dynamips: O Dynamips é um emulador gratuito sob
licença da GNU que permite executar imagens reais do Cisco
IOS, desde que o usuário tenha o arquivo (.bin ou .image)
de alguma imagem do sistema que seja compatı́vel com
os equipamentos suportados pelo emulador. Os arquivos de
configuração gerados nesse emulador podem ser exportardos
para equipamentos reais e vice-versa, o que pode ser útil para
os administradores realizarem testes-piloto antes de lançarem
uma nova configuração em ambientes reais [3]. Ele permite
a reprodução fiel das caracterı́sticas de diversos modelos de
roteadores do fabricante Cisco Systems, tornando possı́vel a
criação de cenários de estudo que, se fossem fisicamente estru-
turados, apresentariam um custo muito elevado. O Dynamips
permite a adição virtual de alguns módulos disponı́veis para
cada plataforma de roteador, que incrementam funcionalidades
e recursos a cada um deles.
Um software desenvolvido posteriormente, denominado Dy-
nagen, opera em conjunto com o Dynamips, fornecendo uma
interface front-end para a definição dos elementos virtu-
ais, além de prover um meio centralizado de controle das
instâncias virtuais [1].
B. O CORE
O CORE (Common Open Research Emulator) é uma ferra-
menta para emular redes de computadores, desenvolvido pela
divisão de pesquisa e tecnologia da Boeing. Por meio dele é
possı́vel projetar, implementar e avaliar topologias contendo
máquinas UNIX e equipamentos de redes como roteadores e
switches. Ele roda nativamente no Linux ou no FreeBSD [19].
Entre os variados recursos, o CORE habilita:
• Executar programas instalados na máquina real;
• Interagir com a rede real existente no ambiente;
• Ter cada máquina ou ativo de rede simulado sendo
controlado via comandos em shell;
• Simular redes sem fio.
C. O Mininet
O Mininet é um emulador de rede, que pode reunir dis-
positivos finais, switches, roteadores e enlaces em um kernel
único de Linux. Ele utiliza um processo de virtualização para
representar uma rede completa. Um host Mininet se comporta
como uma máquina real, sendo possı́vel utilizar protocolos
 REVISTA DE TECNOLOGIA DA INFORMAÇÃO E COMUNICAÇÃO, VOL. 6, NO. 2, OUTUBRO 2016
como SSH para acesso remoto, ou ferramentas como o iperf
para avaliar o desempenho da rede, assim como rodar progra-
mas arbitrários, incluindo qualquer um que esteja instalado
no sistema Linux de base. Devido à caracterı́stica de poder
facilmente interagir com uma rede, por meio da CLI Mininet,
customizá-la ou a implementar em hardware real, o Mininet é
útil para desenvolvimento, capacitação e pesquisas. Entretanto,
ele não possui interface gráfica amigável, de maneira que
programas alternativos podem ser utilizados na apresentação
e animação das topologias.
Esse emulador também é uma boa alternativa para desen-
volver e compartilhar experimentos com o OpenFlow [20] e
sistemas de Redes Definidas por Software (SDN – Software-
Defined Networks) [21]. Redes desse tipo têm sido uma impor-
tante fonte de pesquisa e desenvolvimento, com o objetivo de
desvincular o plano de controle do plano de encaminhamento
de dados.
O controlador é de fundamental importância em uma SDN.
Por meio dele é possı́vel implementar protocolos já estabele-
cidos no mercado, ou simplesmente criar regras de encami-
nhamento de pacotes de acordo com a necessidade. Existem
diversas soluções de controladores e a escolha do melhor
controlador depende do propósito de utilização. O software HP
VAN SDN Controller [22] fornece uma interface com diversas
possibilidades de implementações e controle, habilitando uma
análise de engenharia de tráfego mais detalhada. Esse contro-
lador, em conjunto com o Mininet, foi utilizado neste artigo
para simular o comportamente do tráfego de pacotes em redes
passı́veis de controle por uma entidade externa, separando o
plano de controle do plano de encaminhamento de dados.
A Figura 2 apresenta um cenário de rede gerada a partir
do Mininet contendo seis switches OpenFlow. Neste cenário,
o algoritmo de encaminhamento habilitado para definir as
rotas é o SPF (Shortest Path First) [23]. De acordo com
o SPF a rota escolhida é a que apresenta o menor custo
entre origem e destino. Uma requisição foi gerada a partir
do host 10.10.2.1 com destino ao host 10.10.2.254.
A rota definida é destacada seguindo pelos switches 3, 1 e 6,
respectivamente.
A Figura 3 apresenta o mesmo cenário anterior, porém com
o algoritmo SPF desabilitado. Neste caso, a definição da rota
foi realizada pelo administrador da rede no controlador. Por
alguma razão, em um cenário de produção a rota de menor
custo poderia não ser a rota de melhor desempenho para o
tráfego de pacotes, em determinado intervalo de tempo. Ou
seja, essa é uma situação em que o administrador da rede
ganha benefı́cio nos recursos de SDN, em poder influenciar
o comportamento do roteamento. Após a interação e análise
do ambiente de produção, o administrador da rede poderia
julgar que a rota de melhor desempenho para a rede é a aquela
apresentada na Figura 3. Essa rota foi definida por meio de
um script em Python e, para ser aplicada, foi necessário alterar
parâmetros de configuração.
Por padrão, uma rota gerada a partir do SPF tem um
parâmetro denominado prioridade, com valor igual a 29.999.
Logo, um valor de prioridade maior é necessário para substituir
a rota SPF. A rota gerada no controlador foi definida com
prioridade 30.000, conforme está apresentado na Figura 4.
21
V. E XPERIMENTO DE I NTEGRAÇ ÃO ENTRE UM A MBIENTE
V IRTUAL E UM A MBIENTE R EAL
Esta seção apresenta as caracterı́sticas de um experimento
de integração entre um ambiente virtual (emulado no GNS3)
e um ambiente real (implementado em diversos equipamentos
fı́sicos). O experimento foi realizado no Laboratório de Redes,
do IFPB Campina Grande, onde também funciona a Academia
Cisco, do campus.
Considere a Figura 5. O cenário mostra diversos dispositivos
emulados no GNS3. A relação entre os sistemas operacionais
e os programas correspondentes de virtualização é descrita a
seguir:
• Virtualbox – 1 host Windows 7; 1 host Linux Fedora 22;
1 roteador MikroTik (R3-Mikrotik);
• Dynamips – 2 roteadores Cisco 3725 (R1-Cisco e R2-
Cisco).
A rede virtualizada conta com o protocolo de roteamento
dinâmico OSPF, rodando entre os roteadores. As interfaces
f0/0 (R2-Cisco), f0/0 (R1-Cisco) e e0 (R3-Cisco) foram
configuradas no modo passivo para mensagens de atualização
do protocolo. Desse modo, a rede se torna menos vulnerável a
ataques de segurança, pois a troca de mensagens de roteamento
fica confinada onde realmente é necessário.
A integração do GNS3 com os dispositivos reais foi reali-
zada por meio de um dispositivo nuvem (extremo à direita).
Uma bridge virtual (br0) foi criada entre as interfaces eth0
(do PC utilizado para hospedar o GNS3) e uma outra interface
virtual, também criada (tap0). O processo completo para
habilitar a integração dessas interfaces pode ser encontrado
em [16].
O PC hospedeiro do GNS3 foi conectado a um switch real
Cisco, de modelo 2960, e a ele, diversos dispositivos reais
foram conectados. A Figura 6 ilustra a topologia da rede de
dispositivos reais conectados. Nessa figura, a representação da
conexão com o GNS3 (extremo à esquerda) serve para indicar
a integração partindo do ambiente real para o ambiente emu-
lado. Segue uma breve descrição das principais caracterı́sticas
desses dispositivos e do funcionamento da rede real:
• PC GNS3 – Possui um sistema operacional Linux Mint
17.3, processador Intel Core i7 e 16 GB de memória
RAM. É nele em que o GNS3, com as suas máquinas
virtuais foram processadas. Seus endereços IPv4 cor-
responderam a: 192.168.255.200/24, na interface
fı́sica eth0; e 192.168.255.254/24 na interface
virtual br0. O endereço do gateway padrão é igual a
192.168.255.250, que corresponde à interface g0/0
do roteador Cisco R1. A interface eth0 desse PC está
conectada fisicamente (cabo direto de cobre) ao switch
Cisco 2960.
• Laptop – Possui um sistema operacional Linux
Mint 17.2, processador Intel Core i7 e 6 GB de
memória RAM. Seus endereços IPv4 corresponderam a:
192.168.255.100/24, na interface fı́sica eth0; e
192.168.255.250, para o gateway padrão. Uma rota
estática foi adicionada para alcançar a rede emulada,
10.0.0.0/28 (vide Figura 5), o que ocasionou resul-
tado positivo de conectividade.
 22 REVISTA DE TECNOLOGIA DA INFORMAÇÃO E COMUNICAÇÃO, VOL. 6, NO. 2, OUTUBRO 2016

Figura 2. Uso do HP VAN SDN Controller, em conjunto com o Mininet, para analisar o tráfego de pacotes em uma rede de comunicação de dados. De
acordo com o algoritmo selecionado para o roteamento, o SPF, a rota escolhida é aquela de menor custo, que está destacada em vermelho.

Figura 3. Alteração da saı́da de roteamento, por meio do uso de recursos de SDN, indicada em vermelho.

Figura 4. Indicação do novo valor de prioridade (30.000) utilizado para sobrepor a prioridade padrão do SPF (29.999), o que resulta na implementação das
regras de roteamento programadas pelo administrador da rede (Follow Flow).

• Arduino Mega – Possui um shield Ethernet, o qual foi
utilizado para testes de conectividade com diversos dispo-
sitivos. Um SD card de 8 GB foi utilizado para armazenar
os códigos de programação do Arduino. Seus endereços
IPv4 corresponderam a: 192.168.255.125/24, na
interface fı́sica eth0; e 192.168.255.250, para o
gateway padrão. Testar a conectividade e compatibilidade
nesses tipos de operações de rede, envolvendo sistemas
embarcados é importante, visto que eles ocupam um
papel importante em cenários reais de Internet das Coisas.
• Switch – Foi utilizado com configurações padrão, sem
endereçamento IP ativo nas VLANs de gerenciamento.
Ele conecta fisicamente todos os dispositivos reais pre-
sentes na rede 192.168.255.0/24.
• R1 – Atua como o gateway padrão da rede
192.168.255.0/24. Seus endereços IPv4
corresponderam a: 192.168.255.250/24, na
interface g0/0; e 10.10.10.1/30 na interface serial
s0/1/0. Juntamente com outros treze roteadores,
R1 utiliza um protocolo de roteamento OSPF, com
g0/0 sendo configurada como interface passiva. Uma
rota estática com destino à rede 10.0.0.0/28
 REVISTA DE TECNOLOGIA DA INFORMAÇÃO E COMUNICAÇÃO, VOL. 6, NO. 2, OUTUBRO 2016 23

Figura 5. Captura da tela do GNS3, apresentando o cenário e os dispositivos emulados. Esses dispositivos se conectam ao mundo real por meio do elemento
nuvem.

Figura 6. Captura de tela do Cisco Packet Tracer, apresentando uma simulação da rede real, que foi implementada no laboratório.
 24 REVISTA DE TECNOLOGIA DA INFORMAÇÃO E COMUNICAÇÃO, VOL. 6, NO. 2, OUTUBRO 2016

foi configurada em R1, em que a indicação de

endereço de próximo salto foi feita para R1-Cisco,
com distância administrativa unitária padrão. Outra
rota estática (flutuante) com o mesmo destino de rede
foi configurada, embora utilizando outra indicação de
endereço de próximo salto, ou seja, apontando para
R3-Mikrotik e com distância administrativa igual a
cinco. Na prática, apenas a primeira rota estática é
instalada na Tabela de Roteamento (RIB – Routing
Information Base) do roteador, pois apresenta menor
valor de distância administrativa (é mais confiável). A
segunda rota estática serve como um backup. Caso a
rota principal falhe, a secundária assume, o que aumenta
a disponibilidade da rede e melhora a qualidade de
serviço. Todos os roteadores reais são do modelo Cisco
1941 e apenas uma área foi utilizada na configuração do
OSPF (Área 0). Um processo de redistribuição de rota
foi realizado, de modo que a rota estática configurada
anteriormente foi injetada no processo OSPF.
• De R2 a R14 – os pares de roteadores utilizam re-
des ponto-a-ponto (/30), o que além de enconomizar
endereços, aumenta a segurança, visto que apenas dois
hosts (um em cada extremidade do enlace) são permiti-
dos. Todos eles rodam o OSPF, mas a interface g0/0
de R14 foi configurada como passiva. R14 consegue
alcançar a rede 10.0.0.0/28 pois R1 realizou uma Figura 7. Rack contendo os roteadores Cisco 1941 utilizados no experimento.
Um total de 14 roteadores foram conectados, garantindo conectividade por
redistribuição de rota estática. Por fim, uma operação de meio do protocolo OSPF, na Camada de Rede, do protocolo PPP, na Camada
NAT overload foi configurada em R14, de modo que de Enlace e de cabos seriais com padrão V.35, na Camada Fı́sica.
todos os endereços provenientes das redes internas sejam
traduzidos para um único endereço de acesso a redes
externas (e após alguns saltos, à Internet).
Cumpre ressaltar que apesar de a Figura 6 apresentar
uma topologia lógica contendo a representação de diversos
dispositivos, essa rede foi implementada em dispositivos reais,
que também tiveram a sua operação integrada com o funcio-
namento de dispositivos emulados, internamente ao GNS3. A
Figura 7 ilustra uma foto do rack que contém os roteadores
reais utilizados no experimento.
Adicionalmente, vale salientar que anteriormente à
implementação das configurações e setup dos dispositivos
reais, o projeto da rede foi auxiliado pelo Packet Tracer.
Como resultado, os dispositivos da rede emulada conseguiram
integrar de maneira bem sucedida com os dispositivos reais,
inclusive garantiram o acesso à Internet. A Figura 8 mostra
o resultado de uma operação de traceroute a partir
de R3-Mikrotik com destino a um endereço de servidor
tradicional de DNS, o 8.8.8.8. O acesso foi realizado
diretamente à uma ferramenta denominada Winbox, que é
utilizada para acessar dispositivos MikroTik. Por meio de
uma interface gráfica amigável, foi possı́vel observar os
saltos de roteamento realizados no caminho de upload (visto
que é a única direção com a qual o traceroute tem
compromisso).

VI. C ONCLUS ÃO
O projeto de redes e troubleshooting pode ser auxiliado
pelo uso de simuladores e emuladores. Enquanto simuladores
Figura 8. Saı́das a um teste de traçado de caminho de upload. É possı́vel
observar os saltos percorrendo as diversas redes /30 entre os roteadores reais
do laboratório, passando por endereços públicos na Internet, até chegar ao
destino solicitado.
 REVISTA DE TECNOLOGIA DA INFORMAÇÃO E COMUNICAÇÃO, VOL. 6, NO. 2, OUTUBRO 2016 25

utilizam um software próprio para rodar uma aproximação
dos sistemas simulados, os emuladores virtualizam esses
sistemas, o que os aproxima mais da operação real de
equipamentos em ambientes de produção. Este artigo apre-
sentou uma caracterização de simuladores e emuladores de
rede disponı́veis no mercado e compartilhou os parâmetros
de preparação de um experimento envolvendo o projeto e
integração de um ambiente virtual a um ambiente real. O
correto funcionamento do cenário implantado possibilitou que
dispositivos emulados, internos ao GNS3, conseguissem co-
nectividade a dispositivos na Internet. O protocolo OSPF foi
utilizado de maneira bem sucedida, tanto no ambiente emu-
lado, quanto nos equipamentos reais. O Cisco Packet Tracer foi
utilizado para projetar a rede fı́sica e as configurações foram
posteriormente copiadas para os dispositivos correspondentes.
Como proposta para a continuação do trabalho, os autores
pretendem investigar aspectos que envolvem a segurança da
informação em cenários que integram o ambiente virtual ao
real.
AGRADECIMENTOS
Os autores agradecem ao Capı́tulo Técnico da ComSoc, do
Ramo Estudantil IEEE, campus Campina Grande e ao IFPB
pelo apoio ao desenvolvimento deste trabalho.
[13] B. Jerry. Discrete-Event System Simulation. Pearson Education, 2009.
[14] J. Marek, B. Hoefflinger and U.-M. Gomez. “MEMS – Micro-
Electromechanical Sensors for the Internet of Everything”. In CHIPS
2020, volume 2, pp. 221–229. Springer, 2016.
[15] K. A. Hribernik, Z. Ghrairi, C. Hans and K.-D. Thoben. “Co-creating
the Internet of Things – First Experiences in the Participatory Design
of Intelligent Products with Arduino”. In 17th International Conference
on Concurrent Enterprising (ICE), pp. 1–9. IEEE, 2011.
[16] C. Welsh. GNS3 Network Simulation Guide. Packt Publishing, 2013.
[17] K. Matthias and S. P. Kane. Primeiros Passos com Docker – Uso de
Contêineres em Produção. Novatec, 2015.
[18] O que é Docker? Mundo Docker. Disponı́vel em.
“http://www.mundodocker.com.br/o-que-e-docker/”, Acessado em
Setembro de 2016.
[19] A. M. Moreiras, R. R. dos Santos, A. Y. Harano, E. S. Cordeiro, T. J.
Nakamura, E. B. Morales, H. de Souza Ganzeli, R. M. Carnier and
G. B. Lugoboni. Laboratório de IPv6 – Aprenda na Prática Usando
um Emulador de Redes. Novatec, 2015.
[20] M. Cello, M. Marchese and M. Mongelli. “On the QoS Estimation in
an OpenFlow Network: The Packet Loss Case”. IEEE Communications
Letters, vol. 20, no. 3, pp. 554–557, March 2016.
[21] F. A. Lopes, M. Santos, R. Fidalgo and S. Fernandes. “A Software Engi-
neering Perspective on SDN Programmability”. IEEE Communications
Surveys and Tutorials, 2016.
[22] J. Tourrilhes, P. Sharma, S. Banerjee and J. Pettit. “The Evolution of
SDN and OpenFlow: A Standards Perspective”. IEEE Computer Society,
vol. 47, no. 11, pp. 22–29, 2014.
[23] J. McQuillan, I. Richer and E. Rosen. “The New Routing Algorithm
for the ARPANET”. IEEE Transactions on Communications, vol. 28,
no. 5, pp. 711–719, 1980.

R EFER ÊNCIAS
[1] M. A. Filippetti. “Uma Arquitetura para a Construção de Labo-
ratórios Hı́bridos de Redes de Computadores Remotamente Acessı́veis”.
Dissertação de Mestrado, Instituto de Pesquisas Tecnológicas do Estado
de São Paulo – IPT, 2008.
[2] I. Minakov, R. Passerone, A. Rizzardi and S. Sicari. “A Comparative
Study of Recent Wireless Sensor Network Simulators”. ACM Transac-
tions on Sensor Networks, vol. 12, no. 3, pp. 20:1–20:39, July 2016.
[3] S. H. B. Brito. Laboratórios de Tecnologias Cisco em Infraestrutura de
Redes. Novatec, second edition, 2014.
[4] N. H. Prasad, B. K. Reddy, B. Amarnath and M. Puthanial. “Intervlan
Routing and Various Configurations on Vlan in a Network using Cisco
Packet Tracer”. International Journal for Innovative Research in Science
and Technology, vol. 2, no. 11, pp. 749–758, 2016.
[5] P. Panse, T. Shrimali and M. Dave. “Performance Evaluation of Vehi-
cular Ad Hoc Network Using SUMO and NS2”. In Proceedings of the
International Congress on Information and Communication Technology,
pp. 127–135. Springer, 2016.
[6] N. Ravindranath, I. Singh, A. Prasad and V. Rao. “Performance
Evaluation of IEEE 802.11ac and 802.11n using NS3”. Indian Journal
of Science and Technology, vol. 9, no. 26, 2016.
[7] M. B. Taj and M. A. Kbir. “The Impact of MAC Protocols in Energy
Consumption of Transferring Multimedia Contents Using Castalia Si-
mulator”. In International Conference on Electrical and Information
Technologies (ICEIT), pp. 521–525, May 2016.
[8] M. Pasha, M. U. Farooq et al.. “A Proof-of-Concept Model for Vehicular
Cloud Computing Using OMNeT++ and SUMO”. In Innovations in
Computer Science and Engineering, pp. 193–198. Springer, 2016.
[9] X. Li, M. Peng, J. Cai, C. Yi and H. Zhang. “OPNET-Based Modeling
and Simulation of Mobile Zigbee Sensor Networks”. Peer-to-Peer
Networking and Applications, vol. 9, no. 2, pp. 414–423, 2016.
[10] G. N. Martins. “Avaliação da Confiabilidade de Simulador em Redes
de Sensores Sem Fio com Base em Plataforma Real de Sensoriamento”.
Dissertação de Mestrado, Coordenação de Pós-Graduação em Ciência
da Computação, Campina Grande, PB, Agosto 2016.
[11] M. Tahmassebpour. “Immediate Detection of DDoS Attacks with using
NetFlow on Cisco Devices IOS”. Indian Journal of Science and
Technology, vol. 9, no. 26, 2016.
[12] A. M. Saliu, M. I. Kolo, M. K. Muhammad and L. A. Nafiu. “Internet
Authentication and Billing (Hotspot) System Using MikroTik Router
Operating System”. International Journal of Wireless Communications
and Mobile Computing, vol. 1, no. 1, pp. 51–57, 2013.