Os livros infantis brasileiros que aqui circulam, não circulam como lá
INSTITUTO FEDERAL DE EDUCAÇÃO, CIÊNCIA E...
64
INSTITUTO FEDERAL DE EDUCAÇÃO, CIÊNCIA E TECNOLOGIA FLUMINENSE JOÃO PAULO SEIXAS ALVES E SILVA PATRICK RIBEIRO FARIA REDES DEFINIDAS POR SOFTWARE: Uma Abordagem Inicial ao Conceito e Prática CAMPOS DOS GOYTACAZES 2017
Transcript of INSTITUTO FEDERAL DE EDUCAÇÃO, CIÊNCIA E...
INSTITUTO FEDERAL DE EDUCAÇÃO, CIÊNCIA E TECNOLOGIA FLUMINENSE
JOÃO PAULO SEIXAS ALVES E SILVA
PATRICK RIBEIRO FARIA
REDES DEFINIDAS POR SOFTWARE:
Uma Abordagem Inicial ao Conceito e Prática
CAMPOS DOS GOYTACAZES
2017
João Paulo Seixas Alves e Silva
Patrick Ribeiro Faria
Redes Definidas por Software:
Uma Abordagem Inicial ao Conceito e Prática
Monografia apresentada ao Instituto Federal
de Educação, Ciência e Tecnologia
Fluminense, Campus Campos-Centro, como
requisito parcial para conclusão do Curso
Bacharel em Sistemas de Informação.
Orientador: Prof. Fábio Duncan de Souza
Campos dos Goytacazes
2017
João Paulo Seixas Alves e Silva
Patrick Ribeiro Faria
Redes Definidas por Software:
Uma Abordagem Inicial ao Conceito e Prática
Monografia apresentada ao Instituto Federal
de Educação, Ciência e Tecnologia
Fluminense, Campus Campos-Centro, como
requisito parcial para conclusão do Curso
Bacharel em Sistemas de Informação.
Campos dos Goytacazes, ____ de
______________ de ____.
BANCA EXAMINADORA
___________________________________________
Prof. M.Sc. Fábio Duncan de Souza (Orientador)
IFF Campos
___________________________________________
Prof. M.Sc. Fernando Carvalho (Examinador)
IFF Campos
___________________________________________
Prof. M.Sc. Vinícius Barcelos da Silva (Examinador)
IFF Campos
AGRADECIMENTOS
A realização deste trabalho só foi possível graças a todos os
compartilhadores de conhecimento de forma livre e espontânea, aos professores
que mesmo com tantas dificuldades ensinam por amor ao que fazem, aos amigos
que colaboraram com este projeto diretamente e indiretamente, ao nosso orientador
professor Fábio Duncan que nos acolheu e ao Campus Campos-Centro, que
apresenta como foco o melhor desempenho e sucesso dos alunos dentro e fora da
instituição.
“Governos do mundo industrial!
Eu sou do ciberespaço, o novo lar da mente.
Em nome do futuro, peço que vocês do passado nos deixe em paz.
Vocês não são bem-vindos.
Não têm o direito de reinar aqui.
Não conhecem a nós, nem ao nosso mundo.
O ciberespaço não pertence a vocês.
Seus conceitos legais de propriedade, expressão, identidade, movimento e contexto, não se
aplicam a nós.
Eles se baseiam na matéria, e aqui, ela não existe.”
(John Perry Barlow)
Resumo
A infraestrutura de rede que foi criada para a internet na década de 90,
possui limitações em diferentes tecnologias para atender as demandas atuais. Uma
possível solução para flexibilizar e potencializar esta infraestrutura pode estar nas
redes definidas por softwares. Estas apresentam um novo paradigma, a
possibilidade de programar redes de computadores. Este trabalho investigou a
viabilidade deste tipo de tecnologia e apresentou os seus conceitos e aplicação
básica. Testes foram realizados a fim de comprovar o funcionamento da tecnologia e
de criar uma documentação acessível na língua portuguesa.
Palavras chaves: Redes Definidas por Software, Openflow, Mininet
Abstract
The network infrastructure that was created for the internet in the 90s, has
shown tremendous growth in a short time. A possible solution to the current network
problems generated due to its exponential growth, may be in the Software Defined
Networking (SDN). A paradigm that has been studied and experienced by a number
of universities and researchers. This work intends to investigate the feasibility of use
of such technology and present their concepts and basic application.
Keywords: Software Defined Networking, Openflow, Mininet
LISTA DE TABELAS
Tabela 1: Exemplo de regras na tabela de fluxo openflow. Fonte: RKUO, 2015.......21
LISTA DE FIGURAS
Figura 1: As duas camadas da arquitetura de rede. Fonte: (BRITO, 2013)..............15
Figura 2: Comparativo entre infraestrutura tradicional e SDN. Fonte: Adaptado de
(Hewlett-Packard, 2012)..............................................................................................17
Figura 3: Arquitetura Básica Openflow. Fonte: Adaptado de (MCKEOWN et al,
2008)............................................................................................................................18
Figura 4: Entrada de fluxo em uma tabela. Fonte: (DUQUE et al., 2012).................21
Figura 5: Componentes de uma rede baseada no NOX. Fonte: (COUTO, 2010).....24
Figura 6: Modelo de operação híbrido com VLANs entre tráfego tradicional e Open-
flow. Fonte: Adaptado de (ROTHENBERG et al, 2010).............................................26
Figura 7: Algoritmo da topologia simples personalizada da Mininet..........................37
Figura 8: Janela gráfica do miniedit.py......................................................................39
Figura 9: Tela do consoles.py....................................................................................40
Figura 10: Iniciando a topologia básica padrão na Mininet.......................................46
Figura 11: Tráfego capturado pelo Wireshark com Openvswitch..............................47
Figura 12: Resposta da rede dentro da Mininet.........................................................48
Figura 13: Desconectando de todos os controladores da Mininet.............................48
Figura 14: Sem resposta na rede da Mininet.............................................................49
Figura 15: Iniciando o componente do controlador POX na rede Mininet.................50
Figura 16: Tráfego capturado pelo Wireshark com controlador POX........................50
Figura 17: Topologia complexa de rede na Mininet...................................................53
Figura 18: Resultados da inserção da nova topologia no controlador da Mininet.....54
Figura 19: Tráfego capturado pelo Wireshark com controlador POX numa topologia
grande..........................................................................................................................57
LISTA DE ABREVIATURAS E SIGLAS
ACL Access Control List
API Application Programming Interface
ARP Address Resolution Protocol
BGP Border Gateway Protocol
CLI Command-line Interface
CPU Central Process Unit
DHCP Dynamic host Configuration Protocol
DNS Domain Name System
FIB Forwarding Information Base
GPL General Public License
HTTP Hypertext Transfer Protocol
ICMP Internet Control Message Protocol
IP Internet Protocol version 4
IPv6 Internet Protocol version 6
JSON JavaScript Object Notation
JVM Java Virtual Machine
LACP Link Aggregation Control Protocol
LAN Local Area Network
MAC Media Access Control
NAT Network Address Translation
OF OpenFlow
ONF Open Networking Foundation
SPF Open Shortest Path First
RAM Random Access Memory
RIB Routing Information Base
RSPAN Remote switched Port Analyzer
SDN Software Defined Networking
SPAN switched Port Analyzer
SSH Secure Shell
SSL Secure Socket Layer
STP Spanning Tree Protocol
TCP Transport Control Protocol
UDP User Datagram Protocol
VLAN Virtual Local Area Network
VM Virtual Machine
SUMÁRIO
1 - Introdução..............................................................................................................12
1.1 - Justificativa......................................................................................................13
1.2 - Objetivo...........................................................................................................13
1.2.1 - Objetivos específicos...............................................................................13
2 - Revisão da Literatura.............................................................................................14
2.1 - Infraestruturas de Redes................................................................................14
2.1.1 - Rede Tradicional......................................................................................14
2.1.2 - Redes Definidas por Software.................................................................16
2.2 - Arquitetura Openflow......................................................................................18
2.2.1 - Tabela de Fluxo.......................................................................................20
2.2.2 - O Canal Seguro.......................................................................................22
2.2.3 - O Protocolo Openflow.............................................................................22
2.2.4 - O Controlador..........................................................................................23
2.2.5 - O funcionamento da Arquitetura Openflow.............................................24
2.2.6 - Aceitação da tecnologia..........................................................................26
2.3 - Máquina Virtual Mininet..................................................................................28
2.4 - Softwares controladores.................................................................................29
2.4.1 - Controlador NOX.....................................................................................30
2.4.2 - Controlador POX.....................................................................................30
2.4.3 - Controlador Beacon.................................................................................31
2.4.4 - Controlador FloodLight............................................................................31
3 - Metodologia............................................................................................................33
3.1 - Tecnologias Utilizadas....................................................................................33
3.2 - Criação de uma Infraestrutura de Rede Virtualizada com a Mininet..............34
3.2.1 - Requisitos Básicos..................................................................................34
3.2.2 - Inicialização da Mininet...........................................................................34
3.2.3 - Acesso à Mininet via SSH.......................................................................35
3.2.4 - Principais comandos da Mininet..............................................................35
3.2.5 - Topologias de rede na Mininet................................................................37
3.3 - Implementação da Infraestrutura SDN...........................................................41
3.3.1 - Instalação do POX...................................................................................41
3.3.2 - Execução do POX...................................................................................41
3.3.3 - Componentes do POX.............................................................................42
3.3.4 - Pacotes do POX......................................................................................44
3.4 - Análise do tráfego SDN..................................................................................44
4 - Resultados dos experimentos................................................................................46
4.1 - Experimento com rede padrão Mininet...........................................................46
4.2 - Experimento com switch camada 2................................................................48
4.3 - Experimento com módulo spanning_tree no switch camada 2......................52
CONCLUSÃO..............................................................................................................59
REFERÊNCIAS...........................................................................................................60
12
1 - Introdução
A rede mundial de computadores ou Internet, foi uma das grandes
responsáveis pelo avanço tecnológico no mundo. A quantidade de serviços,
produtos, conteúdos gerados devido ao aumento do uso desta arquitetura de rede,
fez com que se tornasse um assunto de ampla discussão nos últimos anos. É
através da internet que a globalização se faz cada vez mais presente nos dias
atuais. A expansão da infraestrutura da internet foi possível graças a evolução das
tecnologias de redes de computadores como, switches, gateways, roteadores dentre
outros. Contudo, esses equipamentos tornaram-se por vezes limitadores em casos
mais específicos de gerenciamento de redes.
Os atuais componentes que interligam as redes e tratam diferentes tráfegos,
são limitados a trabalhar da forma predeterminada pelo fabricante, impossibilitando
assim uma possível flexibilidade para tratar de problemas ou otimizações nos
segmentos de redes. As Redes Definidas por Software (SDN do inglês Software
Defined Networking) tem como proposta básica separar os planos de dados e de
controle (ROTHENBERG et al, 2010).
Esta solução pretende tratar problemas como a diversidade de dados que
circulam na rede, estruturas complexas devido aos diferentes dispositivos e
necessidade de maior e mais organizado controle sobre a rede (ROJAS, 2013). É
um possível avanço que está sendo estudado e experimentado em universidades
reconhecidas mundialmente, além de grandes empresas, como exemplo, o
Facebook©, que apresentou o uso desta nova tecnologia de redes definidas por
software em algumas de suas redes internas de Data Center (VANIAN, 2014).
13
1.1 - Justificativa
As redes de telecomunicações têm um grande impacto social, estimulando a
comunidade científica a desenvolver estudos e soluções para melhorar a experiência
da inclusão digital. Um dos problemas das infraestruturas de redes atuais é a
limitação do hardware nos switches e roteadores dos fabricantes. Tal limitação é
atribuída ao fato dos equipamentos terem softwares proprietários, ou seja, código
fechado e protegidos por leis de copyright, limitando assim sua visualização e
alteração.
1.2 - Objetivo
Este trabalho tem por objetivo demonstrar uma possível solução para tornar
mais flexíveis e gerenciáveis as redes, apresentando os conceitos e práticas básicas
das redes definidas por software.
1.2.1 - Objetivos específicos
• Conceituar os componentes principais da estrutura SDN.
• Demonstrar a preparação do ambiente virtualizado para uso da SDN.
• Apresentar ferramentas em softwares livres que viabilizem o estudo na
prática.
• Visualizar os resultados do fluxo de dados da SDN utilizando softwares
livres no ambiente virtualizado.
• Disponibilizar uma literatura em língua portuguesa que viabilize ao leitor a
reprodução dos passos para a construção de exemplos simples de arquiteturas de
redes SDN.
14
2 - Revisão da Literatura
2.1 - Infraestruturas de Redes
A internet é um grande conjunto de redes, muitas vezes conhecida como a
rede das redes, pois sua disponibilidade depende da conexão direta ou indireta entre
os vários segmentos de rede existentes (FRIEDERICKA, 2005).
A estrutura de redes de telecomunicações conceitualmente, se divide em 2
planos; o plano de controle (gerência) e o plano de dados (encaminhamento)
(FEAMSTER et al., 2014).
2.1.1 - Rede Tradicional
Na estrutura tradicional, ainda utilizada na maior parte das redes, os planos
de encaminhamento e controle são unidos em apenas um dispositivo. Não está
disponível um controle flexível destes planos, estando acessível ao profissional de
rede apenas as configurações liberadas pelo fabricante do dispositivo em questão.
As configurações mais avançadas, necessitam de algum equipamento específico
que disponibilize tal recurso.
Para administradores de redes e provedores de internet, as soluções para
problemas específicos das redes ficam restritas a soluções implementadas pelos
fabricantes, tornando-as dependentes e inflexíveis.
15
A arquitetura atualmente utilizada pelos principais dispositivos de rede,
roteadores e switches, são comumente divididas em um plano de dados e o plano
de controle. As ações são determinadas pelo plano de controle, o qual é responsável
pela gerência ou implementação lógica. Já o encaminhamento dos pacotes entre os
dispositivos dá-se através do plano de dados (BRITO, 2013). A única forma de
interação entre estes dois planos dá-se através do software embarcado e de suas
interfaces, limitando assim o uso dos dispositivos às suas funcionalidades pré-
programadas pelo fabricante.
Então faz sentido pensar que nesta arquitetura como observa-se na Figura
1, os planos, não necessariamente precisariam estar unidos num mesmo dispositivo.
Caso um padrão estivesse disponível para se gerenciar o comportamento da
rede de forma remota, isto permitiria por exemplo que o plano de controle fosse
instalado em um servidor dedicado com capacidade de processamento suficiente
para se adequar ao volume de dados a serem processados (GORANSSON; BLACK,
2014, p. 59). Deste pensamento surgiu um consórcio, chamado de Openflow, que
visa manter aliado o alto desempenho do encaminhamento dos pacotes (via
hardware) aliado à flexibilidade de inserir, remover ou especializar aplicações em
softwares (ROTHENBERG et al, 2010).
Figura 1: As duas camadas da arquitetura de rede. Fonte: (BRITO, 2013).
16
2.1.2 - Redes Definidas por Software
O conceito de redes definidas por software teve sua iniciativa bem-sucedida
com a definição da interface e do protocolo Openflow (MCKEOWN et al, 2008). Este
é considerado um dos primeiros padrões de rede definida por software. Definiu
originalmente o protocolo de comunicação em ambientes SDN que permite que haja
interação com o plano de encaminhamento de dispositivos de rede, como switches e
roteadores, tanto físicos como virtuais (SDXCentral, 2014). Com Openflow, os
elementos de encaminhamento oferecem uma interface de programação simples
que lhes permite, por exemplo, estender o acesso e controle da tabela de consulta
utilizada pelo hardware para determinar o próximo passo de cada pacote recebido
(COHESIVEFT, 2012). Dessa forma, o encaminhamento continua sendo eficiente,
pois a consulta a tabela de encaminhamento continua sendo tarefa do hardware,
mas a decisão sobre como cada pacote deve ser processado, pode ser transferida
para um nível superior, onde diferentes funcionalidades podem ser implementadas
(BRITO, 2013). Essa estrutura permite que a rede seja controlada de forma
extensível através de aplicações expressas em software. Com este novo conceito
proposto pelo paradigma SDN, diversos problemas de rede podem ser resolvidos,
tais como políticas de QoS (Quality of Service), tunneling, VLANs dentre outros, visto
que o administrador da rede poderá programá-la conforme necessário. O próprio
profissional poderá tratar os problemas de rede direto no controlador e com isso, não
precisará esperar uma solução do fabricante, nem adquirir um novo equipamento
(ROJAS, 2013).
Atualmente algumas empresas fabricam equipamentos híbridos, que
funcionam tanto pré-programados, quanto com sua camada lógica acessível
separadamente do plano de dados (Hewlett-Packard, 2013; CISCO, 2014).
As SDN são mantidas pela Open Networking Foundation (ONF), uma
entidade sem fins lucrativos criada em 2011 pela Deusche Telekom©, Facebook©,
Google©, Microsoft©, Verizon© e Yahoo© (RTI, 2014; SALISBURY, 2013).
A ideia é que as SDN sejam um padrão otimizável, de plataforma acessível
como as atuais tecnologias de código aberto, promovendo uma interoperabilidade
entre aplicações, switches e outros equipamentos de diversos fabricantes, que
provavelmente resultará em mudanças culturais no mercado (PICHINI, 2013).
17
As Redes Definidas por Software vem com o propósito de otimizar o
funcionamento das redes, tornando-as mais eficientes e simplificadas. Com isso,
reduzirá a quantidade de dispositivos gerenciadores, centralizando-os no plano de
controle (GORANSSON; BLACK, 2014, p. 60). Como pode se observar na
comparação feita na Figura 2, onde por exemplo, vários planos de controles são
reduzidos a um apenas, ou seja, cada roteador deixa de ter seu próprio plano de
controle e terceirizam estes recursos a um componente externo de forma
centralizada. Isso também diminui a complexidade da comunicação da rede
(Hewlett-Packard, 2012).
Figura 2: Comparativo entre infraestrutura tradicional e SDN. Fonte: Adaptado de (Hewlett-Packard, 2012).
18
2.2 - Arquitetura Openflow
A arquitetura Openflow é o conjunto de ferramentas e tecnologias que põe
em prática a ideia de redes programáveis, definindo um novo protocolo para
gerenciar as ações do plano de encaminhamento de pacotes dos dispositivos de
rede, sejam roteadores, switches ou pontos de acesso wireless. As regras e ações
anteriormente instaladas em um hardware fechado, agora serão administradas por
um elemento externo, chamado controlador.
Uma Arquitetura Openflow é composta basicamente por:
• Controlador que pode ser instalado em um servidor local e acessado
remotamente;
• Tabela de fluxo responsável por guardar as informações de cada fluxo da
rede, sendo composta por ações, regras e contadores;
• Um canal seguro por onde ocorre a comunicação do controlador e o hardware
responsável pelo encaminhamento de pacotes;
• E o Protocolo openflow que é a interface para a troca de mensagens.
Figura 3: Arquitetura Básica Openflow. Fonte: Adaptado de (MCKEOWN et al, 2008).
19
A Figura 3 apresenta um exemplo de Arquitetura Openflow, os itens
identificados pelo item 1 são Switches Openflow resposáveis pela comunicação da
rede, compostos pelo Canal Seguro, Tabela de Fluxo, Plano de Dados (Hardware) e
o Plano de Controle (Software). O Item 2 é o Controlador, responsável por gerenciar
todo o Plano de Controle da rede. A comunicação entre os switches e o Controlador
acontece através do Canal Seguro (um tráfego sempre criptografado) pelo Protocolo
Openflow. Neste exemplo a criptografia utilizada é SSL. Os itens 3 e 4 são os
usuários finais da rede, apenas exemplos de um uso comum das redes de
computadores, como servidores de jogos ou uma rede wireless.
Em comparação com a tradicional Arquitetura TCP/IP que divide a rede em 4
camadas distintas, Acesso ao Meio, Rede, Transporte e Aplicação, a Arquitetura
Openflow possui três camadas. A primeira, e no topo, camada de Aplicação, que
possui aplicativos oferecendo serviços à rede como firewalls, virtualização e
balanceamento de fluxo. Logo abaixo, no meio, a camada de Controle, onde está o
controlador, o elemento mais pertinente da rede. Por último, a camada Física ou de
Infraestrutura, por onde trafega os fluxos da rede (Teletex, 2014).
O padrão Openflow propõe um caminho para os pesquisadores
programarem os dispositivos de rede de forma remota através da separação do
plano de controle e de encaminhamento, podendo assim experimentar novos
protocolos. O Openflow é baseado em um switch Ethernet, uma tabela de fluxo
interna e uma interface padronizada para adicionar e remover entradas nesta tabela
de fluxo. O objetivo é que os fabricantes de dispositivos de rede adicionem o
OpenFlow aos seus produtos e implantações.
O Openflow permite aos pesquisadores realizar experimentos em
comutadores de rede distintos de forma uniforme. Desta maneira, os fabricantes não
precisam expor o funcionamento interno de seus equipamentos além de permitir que
os pesquisadores avaliem suas idéias numa rede de tráfego real (SHENKER et al,
2008).
Naturalmente, o padrão Openflow poderá reutilizar as principais
funcionalidades do hardware já existente, como NAT, firewall ou VLANs. Uma rede
programável Openflow nada mais é do que comutadores de rede habilitados para
trabalhar com um controlador para gerenciar a tabela de fluxo de forma remota
através de um canal seguro.
20
A proposta do padrão Openflow pretende manter uma especificação de
switch. Este padrão foi desenvolvido pela Open Networking Foundation (ONF) que é
um consórcio formado por um grupo de pesquisadores, administradores de rede e
universidades que acreditam que suas pesquisas serão aprimoradas com a
expansão do Openflow (OPEN NETWORK FOUNDATION, 2017).
O padrão openflow acarreta mudanças significativas na infraestrutura de
rede atual podendo gerar incompatibilidades e impactos negativos que precisam ser
avaliados e controlados durante sua adoção (MCKEOWN et al, 2008). Prevendo
este possível impacto, alguns dos grandes fornecedores destes equipamentos,
estão produzindo switches híbridos, que são ponto chave na transição entre as
infraestruturas.
Ao reconhecer o problema, comunidades de redes estão trabalhando
desenvolvendo redes programáveis. Um exemplo é o GENI, um mecanismo
proposto para experimentar novas arquiteturas de redes e distribuir sistemas (GENI,
2017). Estas redes programáveis requerem switches programáveis e roteadores
que, usando virtualização, podem processar pacotes para múltiplos testes
experimentais isolados simultaneamente. As redes programáveis virtualizadas
podem diminuir a barreira para a entrada de novas ideias, aumentando a taxa de
inovação na infraestrutura de rede.
A característica mais importante da arquitetura Openflow, é a emancipação
do plano de dados do hardware proprietário. Vale lembrar que qualquer modelo de
encaminhamento de dados, que tenha por base, a tomada de decisão baseada em
algum valor ou na combinação de valores dos campos dos cabeçalhos de cada
pacote, será suportado pelo controlador (ROTHENBERG et al, 2010).
2.2.1 - Tabela de Fluxo
A tabela de fluxo encontra-se no hardware da rede (switch) e é composta por
entradas que estão em fluxo neste equipamento, estas entradas são divididas em
contadores, ações e regras conforme a Figura 4.
21
As regras são formadas tendo como base a definição de um valor de um ou
mais campos no cabeçalho do pacote, junto a esta existe um conjunto de ações que
definem o modo como os pacotes devem ser encaminhados e processados, já os
contadores são de uso somente para obter e manter estatisticamente a utilização do
fluxo e para sua possível remoção caso estejam inativos (GORANSSON; BLACK,
2014, p. 65). Cada entrada na tabela de fluxo é passível de interpretação pelo plano
de controle, sendo portanto umA tabela de fluxo encontra-se no hardware da rede
(switch) e é composta por entradas que estão em fluxo neste equipamento, estas
entradas são divididas em contadores, ações e regras conforme a unidade pequena
de informação exemplificada na Tabela 1 (RKUO, 2015).
Figura 4: Entrada de fluxo em uma tabela. Fonte: (DUQUE et al.,2012).
.
Fonte: RKUO, 2015.
Tabela 1 - Exemplo de regras na tabela de fluxo openflow.
22
2.2.2 - O Canal Seguro
O Canal seguro tem como função garantir a confidencialidade na troca de
informações entre o controlador e o switch Openflow para que a rede não venha
sofrer ataques de pessoas mal-intencionadas (GORANSSON; BLACK, 2014, p. 86).
O canal seguro irá conectar o switch Openflow ao controlador, permitindo
assim uma conexão segura por onde passará os comandos e informações referente
ao fluxo da rede (ROTHENBERG et al, 2010).
2.2.3 - O Protocolo Openflow
O protocolo Openflow é definido pela arquitetura Openflow para trocar
mensagens entre os comutadores de redes (switches, hosts e controladores) através
de uma interface externa (controlador). Tais mensagens têm três naturezas:
síncronas (dependem de um retorno), assíncronas (não necessitam de retorno) e do
controlador (iniciadas somente por este). Os controladores da rede podem
programar as tabelas de fluxo dos switches através do protocolo openflow
(McKeown et al, 2010).
O protocolo Openflow está em camadas acima dos Protocolos de
Transporte, como TCP (Transmission Control Protocol) ou UDP (User Datagram
Protocol), e utiliza o TLS (Transport Layer Security) para criptografar as mensagens
trocadas (GORANSSON; BLACK, 2014, p. 85).
23
2.2.4 - O Controlador
O Controlador funciona como o Sistema Operacional da rede, gerenciando e
controlando a tabela de fluxo, oferecendo assim, um sistema base para reutilização
de componentes programáveis e definindo os níveis de abstração do sistema
(ROTHENBERG et al, 2010). Aplicações e serviços da rede são gerenciados pelo
controlador que facilita a ação destes através de uma abstração da estrutura física.
Novas aplicações para a rede, podem ser desenvolvidas de forma livre por
profissionais com conhecimentos avançados em programação e redes de
computadores.
Já foram desenvolvidos alguns controladores em diferentes linguagens. Um
exemplo é o controlador NOX (COUTO, 2010) que foi desenvolvido para funcionar
com programas escritos em C++ e Python, este terá uma seção específica adiante.
A Figura 5 tem por objetivo demonstrar uma abstração de uma rede
Openflow gerenciada por um controlador NOX. O controlador executará algumas
aplicações. A forma como é vista a rede pelo controlador pode ser armazenada, por
exemplo, em um simples banco de dados local ou em um servidor remoto.
24
2.2.5 - O funcionamento da Arquitetura Openflow
O funcionamento da arquitetura é sobre os fluxos da rede. Por definição,
fluxo é uma sequência de pacotes em um único sentido onde cada pacote
compartilha um conjunto de valores de cabeçalho em comum. Exemplos:
Fluxo 1: pacotes com destino 192.168.0.0/24
Fluxo 2: pacotes com interface de entrada 2 e VLAN ID 10
Fluxo 3: pacotes com MAC de origem X, MAC de destino Y, e porta TCP de
destino 80.
Ao chegar um pacote de um fluxo em um controlador Openflow, os
cabeçalhos são lidos e comparados às regras da tabela de fluxo, as ações definidas
pelas regras serão tomadas e seus contadores atualizados. Quando o controlador
Openflow recebe um pacote, os cabeçalhos deste são comparados às regras das
entradas das tabelas de fluxo, tais ações definidas por estas regras são tomadas e
os contadores são atualizados. Caso não haja correspondência entre alguma
entrada e o pacote, este último é encaminhado ao controlador. Caso contrário,
apenas o cabeçalho é enviado ao controlador mantendo assim o pacote
armazenado em buffer do equipamento (ROTHENBERG et al, 2010).
Figura 5: Componentes de uma rede baseada no NOX. Fonte:(COUTO, 2010).
25
Por exemplo, têm-se um fluxo onde todos os pacotes de uma faixa de
endereço específica de IP (Internet Protocol), em uma conexão TCP passando por
uma porta específica, ou seja, uma VLAN, poderão ter algumas ações tomadas,
como: enviar o fluxo para uma porta (ou portas) específica; modificar campos do
cabeçalho; transmitir o pacote ao controlador; descartar os dados ou enviar o pacote
para o processamento normal. É comum que pacotes que chegam ao controlador
sejam correspondentes de um novo fluxo, necessitando então instalar novas regras
no switch para que todos os pacotes deste determinado fluxo sofram ações
específicas.
26
Quando enviados para processamento normal o tráfego experimental da
rede (Openflow) não interfere no tráfego de produção padrão. Conforme ilustrado na
Figura 6, uma outra forma de garantir essa segmentação e não interferência entre
ambos é a criação de um conjunto de VLANs para o tráfego experimental e tráfego
padrão. Essa separação também favorece a utilização de equipamentos híbridos
que processam protocolos e funcionalidades embarcadas e ao mesmo tempo
tráfego baseado no padrão Openflow (ROTHENBERG et al, 2010).
2.2.6 - Aceitação da tecnologia
O Padrão Openflow distingue o plano de controle (ou gerência) do plano de
dados (ou encaminhamento), permitindo e inserindo o controlador em servidores
com sistemas operacionais que podem ser acessados remotamente. É de
responsabilidade do software controlador definir como será o fluxo de determinado
pacote e de que forma será processado na rede.
Figura 6: Modelo de operação híbrido com VLANs entre tráfego tradicional e Openflow. Fonte:Adaptado de (ROTHENBERG et al, 2010).
27
Esta separação facilita a implementação e criação de código em linguagens
de programação comuns da área de tecnologia. Tal flexibilidade favorece
pesquisadores, desenvolvedores, administradores de rede, plataforma de serviços,
sistemas de gerenciamento de dados, serviços em nuvem e até servidores de
conteúdo independente a desenvolverem suas próprias aplicações. Sendo assim, o
controle da rede deixa de estar em softwares embarcados nos equipamentos dos
fabricantes e fica nas próprias aplicações desenvolvidas.
A forma como o Openflow é controlado atualmente nas redes via software
oferece um serviço de encaminhamento orientado a fluxos que reconhece mais de
20 cabeçalhos comuns nas redes tradicionais, proporcionando uma grande
compatibilidade. Uma rede Openflow garante isolamento entre os diferentes
controladores que estão operando na rede através da definição de fatias de rede,
conhecido como slices ou flow-spaces. Isso permite que o tráfego padrão ou dos
protocolos tradicionais, e o tráfego experimental openflow operem juntos
(ROTHENBERG et al, 2010).
As tecnologias para equipamentos programáveis para o padrão Openflow
vem se consolidando em conjunto com tecnologias similares. O padrão Openflow é
compatível com a Internet atual. O tráfego das redes tradicionais podem ser
operadas com facilidade em conjunto com o tráfego Openflow através do seu
modelo de fatias de rede. Este novo paradigma agrega inovação tecnológica,
gerência integrada e redes virtualizadas a fim de promover desenvolvimento em
protocolos e serviços de redes (ROTHENBERG et al, 2010).
Com o plano de controle movido para um servidor dedicado de alta
capacidade de processamento, a velocidade no encaminhamento de pacotes tende
a ser mais alta, pelo fato da performance de direcionamento do fluxo estar
diretamente ligada a capacidade de processamento do hardware da rede. Vale
ressaltar que apesar do controle estar fisicamente centralizado, este continua
distribuído logicamente. Sendo assim, não é necessária alteração dos protocolos de
roteamento já existentes (ROTHENBERG et al, 2010).
28
2.3 - Máquina Virtual Mininet
Para a experimentação de uma rede definida por software, a princípio, é
necessário utilizar uma infraestrutura física de rede para a interligação dos
equipamentos compatíveis com a tecnologia. Porém, é comum que o pesquisador
não disponha de uma infraestrutura desta para realizar seus experimentos. Uma
alternativa é o uso de um ambiente virtualizado para emular uma rede. Um exemplo
de emulador que vem sendo utilizado na literatura é a máquina virtual Mininet.
A Mininet é um emulador de rede, ou mais precisamente um sistema de
orquestração de emulação de redes. Funciona como uma coleção de hosts,
switches, roteadores e links em um único kernel Linux. Mininet usa virtualização leve
para fazer um único sistema parecer uma rede completa, executando no mesmo
kernel, o sistema e códigos do usuário. Os hosts da Mininet se comportam como
uma máquina real podendo ser acessados via SSH, executando programas, e
incluindo qualquer software que esteja instalado no sistema Linux hospedeiro. Os
programas executados podem enviar pacotes através do que parece ser uma
verdadeira interface Ethernet, com uma certa velocidade de conexão e de atraso. Os
pacotes são processados pelo switches Ethernet, roteadores ou qualquer outro
comutador de rede virtualizado. Neste ambiente, hosts, switches, links, e
controladores implementados em software possuem a maior parte do seu
comportamento semelhante aos implementados em hardware (Mininet, 2016).
As principais características da Mininet são:
• Fornecer uma maneira simples e barata para a realização de testes em redes
para desenvolvimento de aplicações Openflow.
• Permitir que múltiplos pesquisadores possam trabalhar de forma
independente na mesma topologia de rede.
• Incluir ferramentas livres para depurar e executar testes em toda a rede.
• Agilizar a inicialização de uma rede simples para apenas alguns segundos.
• Criar topologias personalizadas com um único switch, ou topologias maiores
que se assemelham um centro de dados.
• Executar pacotes Linux desde servidores web a ferramentas de
monitoramento de rede.
29
• Ser disponibilizado para notebooks, servidores, máquinas virtuais, sistemas
operacionais GNU Linux e sistemas de gerenciamento em nuvem como por exemplo
a Amazon EC2 (Mininet, 2016).
Mininet é um projeto Open Source, o que incentiva seus usuários a examinar
seu código-fonte, modificá-lo, corrigir bugs, resolver problemas de arquivos,
solicitações de recursos, entre outros (LANTZ, 2017).
Contudo, a Mininet também tem seus pontos negativos que devem ser
levados em consideração para uma boa experimentação do processo. A execução
em um único sistema é conveniente, mas impõe certos limites de recursos. Por
exemplo, se um servidor tem 3 GHz de capacidade de processamento e um switch
cerca de 10 Gbps de transferência de dados, esses recursos precisam ser
compartilhados e equilibrados entre os hosts e switches virtuais. Isso ocorre devido
aos recursos serem multiplexados em tempo real pelo kernel da máquina
simuladora, uma vez que a largura de banda total é limitada por restrições de CPU e
RAM. A Mininet usa um único kernel do Linux para todos os hosts virtuais, isso
significa que não se pode executar software que depende de plataformas BSD,
Windows, ou outros kernels de sistema operacionais distintos.
Estas informações e a própria Mininet podem ser encontradas e adquiridas
livremente no site oficial (Mininet, 2016).
2.4 - Softwares controladores
O principal componente das redes definidas por software é o controlador.
Este serve como uma camada de abstração para a criação serviços e aplicações
que gerenciarão as entradas dos fluxos nos switches Openflow. O controlador é o
componente responsável por concentrar a comunicação de todos os dispositivos
programáveis da rede, oferecendo assim uma visão unificada da mesma. Os
controladores também são conhecidos como sistemas operacionais de rede, em
uma analogia com os sistemas operacionais usados em computadores. A ideia do
controlador é a mesma dos Sistemas Operacionais, ou seja, oferecer uma interface
de alto nível para aplicações utilizarem os recursos de hardware e ao mesmo tempo
gerenciar as interações entre essas aplicações.
30
2.4.1 - Controlador NOX
O NOX é uma proposta de controlador para redes definidas por software
aplicações desenvolvidas em Python e C++. As suas interfaces de alto nível
simplificam a programação isentando o profisional de connhecimentos específicos
do funcionamento de baixo nivel e viabilizando a portabilidade das aplicações para
diferentes arquiteturas. Em uma rede Openflow, é comum existir um ou mais
servidores executando NOX, cada um é responsável por ser um controlador
Openflow. Todos os controladores compartilham uma visão única da rede, que é
mantida através de uma base de dados em um dos seus servidores. A visão da rede
é construída através desta base de informações e usada na tomada de decisões
pelas aplicações de gerenciamento. Tais informações são, topologia da rede,
localização de elementos, serviços oferecidos entre outros. As aplicações criadas a
partir destas informações gerenciarão o tráfego através de comutadores Openflow
de forma remota. Essa gerência é realizada à nível de fluxo, ou seja, quando
determinada ação é realizada no primeiro pacote do fluxo todos os outros pacotes
deste mesmo fluxo seguirão a mesma ação (COUTO, 2010).
O NOX é um controlador simples para redes definidas por software, que
promove gerenciamento dos fluxos da rede através de eventos, bem como a
comunicação entre os switches da forma mais básica à avançada.
2.4.2 - Controlador POX
POX é um controlador para redes definidas por software escrito em Python.
No início foi construído para ser um controlador Openflow porém mais adiante pôde
funcionar como um switch Openflow sendo útil para escrever softwares em Python.
O POX necessita de Python 2.7 instalado previamente, sendo executado em
plataformas Linux, Mac OS e Windows.
31
Atualmente o POX funciona com protocolo Openflow 1.0. O POX é uma
plataforma simples para desenvolvimento, testes e prototipação de aplicações de
redes utilizando Python. Este controlador veio para substituir o NOX em casos onde
o desempenho seja um requisito necessário. O POX é mais eficiente e oferece um
melhor desempenho que o NOX quando executado em Python, porém, o contrário
acontece quando a linguagem utilizada é o C++, neste o NOX leva vantagem
(McCauley, 2014).
2.4.3 - Controlador Beacon
O controlador Beacon foi desenvolvido em JAVA com o intuito de receber
operações de controle em função de eventos e threads. O Beacon vem sendo
desenvolvido pela Universidade de Stanford desde 2011 e suas principais
características são de ser um software livre com licença GPL (General Public
License), ser multithreaded e manter redes experimentais por meses mesmo com
inatividade (BEACON, 2011).
Uma característica peculiar neste controlador é que pode ser utilizado na
plataforma Android e pode ser atualizado em tempo de execução sem interrupção
do seu funcionamento.
2.4.4 - Controlador FloodLight
O Floodlight, baseado no Beacon, não é somente um controlador Openflow
mas também uma coleção de aplicações construídas em cima do controlador
Floodlight. Este controlador contém núcleo e módulos escritos principalmente em
Java, porém também é possível programar em Jython, que é uma implementação da
linguagem Python que gera bytecode para máquinas JVM (Java Virtual Machine),
sendo assim possível fazer aplicações híbridas unindo Java e Python.
A comunicação entre os módulos deste controlador é feita através de
serviços tendo em vista que sua arquitetura é formada por módulos que exportam
serviços.
32
O Floodlight tem por características principais o descobrimento e
identificação do status da topologia da rede, possibilidade de integração com redes
que não são Openflow e também a compatibilidade com a máquina virtual de redes
Mininet (FLOODLIGHT, 2016).
33
3 - Metodologia
Neste capítulo serão abordados os procedimentos práticos necessários para
a preparação de uma infraestrutura básica de a virtualização de uma rede definida
por software. Em conjunto serão explanados aspectos fundamentais para a
instalação das principais ferramentas utilizadas e a execução de comandos para
testes no controlador.
3.1 - Tecnologias Utilizadas
Mininet: Possibilitará a criação de um protótipo de rede virtual realista,
executada em um kernel real pois não serão utilizados switches físicos para testes.
Criará switches, hosts e possibilitará a execução de códigos de aplicações. Uma
máquina virtual capaz de gerar uma grande rede para experimentos Openflow.
Wireshark: Um sniffer de rede para a captura e visualização de pacotes
gerados em uma rede. A distribuição de referência Openflow inclui um Wireshark
Dissector nativo na máquina virtual Mininet. Este consegue analisar as mensagens
enviadas pela porta padrão do Openflow: 6634 ou de qualquer outra natureza
desejada
Terminal SSH: É utilizado para se conectar à máquina virtual através de uma
interface de rede virtual. Sendo possível copiar e colar por este terminal, compilar
módulos do controlador e inicializar o Wireshark nativo.
Terminal xterm: Utilizado para se conectar a um host da rede virtual, através
da Command-line Interface (CLI) da Mininet. Este se conectará a um componente da
rede virtual criada.
Switch Openflow: A Mininet contém três opções de switches para a rede
virtual; switches que utilizam o kernel-space, switches que usam o user-space, e
switches que simulam o Openvswitch. Este último será utilizado nas
experimentações por ser o padrão.
34
3.2 - Criação de uma Infraestrutura de Rede Virtua-
lizada com a Mininet
3.2.1 - Requisitos Básicos
Para executar a Mininet, algumas configurações se fazem necessárias:
• Deve-se alocar pelo menos 512 MB de RAM para a máquina virtual.
• Necessita-se de duas placas de rede na máquina virtual, sendo uma para sua
própria rede interna (NAT) e outra para conexão entre a máquina virtual e máquina
física através do SSH, utiliza-se a configuração host-only network.
3.2.2 - Inicialização da Mininet
Ao iniciar a máquina virtual com a imagem da Mininet montada, são
utilizados os seguintes parâmetros para o login quando solicitado:
• Username: mininet
• Password: mininet
O usuário root não está ativo para login por padrão, sendo possível utilizar o
comando sudo para executar comandos como super usuário.
Primeiramente deverão ser encontrados os endereços IPs da máquina
virtual, no terminal, para isso executa-se o comando ifconfig.
Será possível observar algumas interfaces, exemplo eth0, eth1 e lo, desde
que tenham sido configuradas na máquina virtual. As duas primeiras interfaces são
placas de rede virtuais configuradas e criadas antes de executar a máquina virtual
no software de virtualização. Isto que possibilitará a conexão da internet com seu
computador hospedeiro. Caso não seja possível ver as interfaces, executa-se os
comandos a seguir ou em caso de não sucesso, devem ser revisadas as
configurações da máquina virtual:
sudo dhclient eth0
sudo dhclient eth1
35
Executa-se novamente o comando ’ifconfig’ para verificar se as interfaces
estão visíveis. Normalmente encontra-se ethX, onde X é o número correspondente a
interface da placa. Com as interfaces ativas, é necessário anotar o endereço IP da
segunda interface (host-only network) que seguirá o padrão de IP da máquina
hospedeira. Logo em seguida não se faz necessário utilizar o terminal da VM
Mininet, pois com este IP, pode-se conectar à Mininet via o terminal SSH, tornando
trabalho mais flexível.
3.2.3 - Acesso à Mininet via SSH
Com os requisitos anteriormente configurados na VM Mininet, deve-se abrir
um terminal de comandos e em seguida digitar:
ssh -X mininet@[Endereço IP guardado]
Após isso será pedido o password, digita-se “mininet” (sem aspas). A opção
-X é para habilitar o servidor X Window na máquina virtual caso exista.
3.2.4 - Principais comandos da Mininet
Nesta seção serão apresentados os principais comandos utilizados dentro
da Mininet. Para iniciar a Command Line Interface (CLI) da Mininet no terminal basta
executar o comando:
$ sudo mn
Uma topologia mínima é criada por padrão. Esta topologia inclui dois hosts
comuns e um controlador interligado a um switch Openflow (Openvswitch) através
de um enlace ethernet. A confirmação de que o usuário se encontra na CLI da
Mininet será a identificação no prompt de cada linha de comando:
mininet>
A seguir serão apresentados alguns comandos básicos da Mininet.
36
Ajuda e apresentação dos comandos:
mininet> help
Exibição dos nós de uma topologia:
mininet> nodes
Exibição dos links:
mininet> net
Apresentar informações sobre todos os nós de uma rede - mininet> dump
Caso a primeira palavra digitada na CLI da Mininet seja o nome de um dos
nós ou componentes da rede, seja um switch, host ou controlador, o comando à
frente será executado por este componente. Exemplo:
mininet> h2 ifconfig
Em resposta a este comando, serão informadas as configurações de IP do
host h2 logo em seguida. Outra opção para executar estes comandos por nós
distintos, é abrir uma janela de terminal adjacente para o nó desejado, para isso,
utiliza-se o emulador de terminal X ou terminal xterm. Exemplo:
mininet> xterm h2 h3 s1
O comando anterior abrirá três janelas, cada uma com o nome do seu respectivo nó.
Um comando para teste de alcance entre todos os nós da rede é o:
mininet> pingall
O comando pingall faz com que todos os componentes da rede enviem pings entre
si. Para encerrar a CLI da Mininet:
mininet> exit
37
3.2.5 - Topologias de rede na Mininet
A Mininet traz uma topologia padrão, com um único switch ligado a dois
hosts. No entanto pode-se criar topologias diferentes, como por exemplo:
sudo mn --topo single, X
sudo mn --topo linear, X
sudo mn --topo tree, X,Y
Na primeira linha, cria-se uma topologia com um único switch ligado a X
hosts, onde X é a quantidade de hosts. Já na segunda linha, cria uma topologia
linear com X switches conectados entre si, ligados cada um a X hosts, sendo ainda
X o número de referente a quantidades. A terceira linha cria uma topologia em
formato de árvore, onde a altura é X e com o número Y de números de filhos por nó.
Figura 7: Algoritmo da topologia simples personalizada da Mininet.
38
O algoritmo mostrado na Figura 7 cria uma classe com o nome "MyTopo"
para a topologia personalizada de exemplo. A classe iniciará uma função para criar
uma topologia adicionando dois hosts e dois switches interconectando-os. Os hosts
receberão o nome de "h1" e "h2" e os switches de "s3" e "s4". Para conectar os
hosts aos switches serão criados 3 links. Estes links conectarão os elementos da
rede de forma que fique o host h1 à esquerda do switch s3, o switch s3 conectado à
esquerda do switch s4 e do lado direito do switch s4 o host h3.
É possível criar topologias bem diferentes e personalizadas utilizando
módulos em python. O código custom/topo-2sw-2host.py que acompanha a Mininet
cria dois switches (Openvswitch), interligados entre si, conectados a um host cada.
Para executar a Mininet com uma topologia personalizada executa-se:
sudo mn --custom ~/Mininet/custom/minha_topologia.py --topo mytopo
A Mininet fornece API para a criação de novas configurações para uma
Rede Definida por Software. Alguns exemplos de uso podem ser encontrados no
diretório Mininet/examples, suas descrições encontram-se em
Mininet/examples/README. Destacam-se na Mininet duas ferramentas gráficas, que
produzem uma experiência menos abstrata:
O miniedit.py, pode ser executado através do comando:
sudo ./Mininet/examples/miniedit.py
39
Este abrirá uma janela gráfica onde será possível desenhar uma topologia
de maneira fácil e simples conforme a Figura 8.
A topologia desenhada no exemplo anterior possui 3 switches conectados a
um controlador central e 4 hosts, estes conectados a 2 switches.
Com o consoles.py poderá ver uma janela gráfica através do comando:
sudo ./mininet/examples/consoles.py
O comando anterior abrirá uma janela gráfica com uma grade de janelas de
console conforme a Figura 9, uma para cada componente da rede, e permite a
interação e o acompanhamento de cada nó, incluindo monitoramento através de
gráficos e comandos ping.
Figura 8: Janela gráfica do miniedit.py.
40
A Figura 9 mostra o console de 16 hosts e a taxa de transferência de cada
um. Alguns comandos podem ser utilizados através dos botões, como por exemplo
Ping e Clear. É possível também criar API própria para a Mininet. Uma API básica
utiliza das bibliotecas mininet.node, mininet.cli e mininet.net. A primeira contém os
módulos para se criar todos os nós virtuais de uma rede, a segunda por sua vez
serve para que se possa executar a CLI da Mininet e a terceira contém os módulos
necessários para se montar a rede virtual propriamente dita.
Figura 9: Tela do consoles.py.
41
3.3 - Implementação da Infraestrutura SDN
Para fim de estudo foi escolhido o controlador POX por usar componentes
feitos em python, facilitando o entendimento das aplicações nos testes deste
trabalho. O controlador POX possui vários módulos pré configurados dentro do
diretório forwarding, para serem usados como controladores dos switches Openflow,
como exemplo tem-se os módulos forwarding.l2_learning.py;
forwarding.l3_learning.py; forwarding.hub.py, onde o primeiro configura o controlador
para operar como switch de camada 2, o segundo como switch de camada 3 e o
último como um HUB.
3.3.1 - Instalação do POX
Para executar o POX, é necessário ter o Python 2.7 ou superior instalado no
sistema operacional. Um Sistema Operacional indicado é dispensável pois por ser
uma aplicação interpretada, indicar um sistema operacional é irrelevante. O POX
está disponível como software livre no repositório Github (POX Controller, 2017),
desta forma, basta fazer o download do pacote e extraí-lo.
3.3.2 - Execução do POX
A inicialização do POX se faz através do comando “./pox.py” do módulo
pox.py no terminal. Na mesma linha de comando pode-se usar algumas opções de
inicialização conforme a seguir:
--verbose: Útil para depuração de problemas relacionados a inicialização, exibe
informações extras
--no-cli: Não deixa inicializar nenhuma interface interativa.
--no-openflow: Impede a inicialização automática do módulo openflow.
42
O POX como é um controlador utilizado em sua maioria para pesquisa
(podendo ser utilizado em produção), não faz sentido executá-lo sem nenhum
módulo ou componente. Caso os pesquisadores queiram colocar em produção as
suas aplicações, deverão especificá-las na linha de comando após as opções
mencionadas anteriormente. Assim, após a chamada do módulo pox.py, a linha de
comando deve ficar conforme exemplo a seguir:
./pox.py --no-cli [nome da aplicação]
Pode-se executar vários módulos especificamente na linha de comando,
porém é esperado que alguns componentes não funcionem de forma adequada em
conjunto com outros, pois se os mesmos tendem a funcionalidades diferentes ou
pouco semelhantes, pode ser que venham interferir diretamente no funcionamento
um do outro. Há ainda componentes que dependem de outro para funcionar, isso
depende do tipo de trabalho desempenhado pelo pesquisador. Em seguida um
exemplo de mais de um componente executado ao mesmo tempo:
./pox.py --no-cli [módulo 1] --[opção] [módulo2] --[opção]
3.3.3 - Componentes do POX
O controlador POX vem com alguns componentes nativos, sendo alguns
convenientes para testes. Contudo, a intenção é que o pesquisador se inspire a criar
suas próprias aplicações.
Conforme dito em capítulos anteriores, o conceito de componentes nada
mais são do que programas que serão executados pelo controlador que fornecerão
funcionalidade e gerenciarão a rede a partir deste.
A seguir é apresentada uma lista com os principais componentes do POX,
juntamente a uma breve descrição de cada.
-py: Utilizado para depuração interativa ao se inicializar o interpretador Python.
Funciona somente se a opção --no-cli estiver desabilitada.
-forwarding.l2_learning: Atribui aos switches Openflow a funcionalidade de switches
de aprendizagem de camada dois. Porém, instala também fluxos extras para cada
conexão com origem e destino idênticos, fazendo com que fluxos com origens
diferentes e destinos iguais tenham fluxos distintos.
43
-forwarding.l2_pairs: Faz o mesmo que “forwarding.l2_learning”, porém gerencia
regras com base em endereços MAC desconsiderando origem e destino.
-forwarding.l3_learning: Este é um componente que não é um roteador nem um
switch mas entende endereçamento MAC para IP, um tipo de switch L3.
-forwarding.l2_multi: Funciona como um switch de aprendizagem L2 mas está em
ambientes com vários switches. Quando um switch aprende um MAC todos os
outros também aprendem. Precisa do componente openflow.discovery.
-openflow.spanning_tree: Também necessita de um módulo de aprendizagem, este
componente descobre a topologia da rede e a transforma em árvore com o objetivo
de evitar inundação nas portas dos switches, evita o que são conhecidos como loops
lógicos da rede, semelhante ao Spanning Tree Protocol (STP).
-web.webcore: Inicializa um servidor web dentro do POX, desta forma outros
componentes da rede podem requisitar e fornecer conteúdos estáticos e dinâmicos.
-messenger: Este componente fornece uma interface a fim de realizar conexão e
troca de mensagens bidirecionais por meio de JavaScript Object Notation (JSON)1
(JSON, 2016).
-openflow.of_01: Componente inicializado por padrão quando não há referência por
nenhum outro ou quando não existe a opção --no-openflow. Faz comunicação com
switches Openflow.
-openflow.discovery: Serve para descoberta de topologia através de mensagens de
controle entre os switches Openflow.
-openflow.debug: Captura mensagens trocadas entre controlador e switches
Openflow na rede, semelhante ao Wireshark e tcpdump mas de forma resumida.
-openflow.keepalive: Faz avaliações do estado dos componentes da rede em
relação a sua conectividade com a rede através de mensagens de eco periódicas.
-misc.pong: Envia respostas pong para todas a requisições pings na rede.
-misc.arp_responder: O mesmo que o misc.pong com a diferença de responder a
requisições ARP.
-misc.dns_spy: Monitora e guardas as respostas DNS.
-misc.mac_blocker: Usado em conjunto com outros componentes de
encaminhamento permitindo bloquear endereços MAC específicos. Mostra interface
gráfica com informações sobre eventos de bloqueio.
1 JSON é um formato leve para intercâmbio de dados computacionais que pode ou não utilizar
JavaScript.
44
-Log: Caso exista necessidade de Log, este componente é responsável opr criação
de logs com data e hora.
-Tk: Usado na construção de interfaces gráficas baseadas no POX.
3.3.4 - Pacotes do POX
Como o POX é um controlador para redes definidas por softwares, é natural
que venha interagir com diferentes tipos de pacotes e não somente com fluxos
Openflow. O controlador possui uma biblioteca exclusiva para a análise e construção
destes pacotes, a pox.lib.packet. Tal biblioteca possui suporte para diferentes tipos
de cabeçalhos e carga útil (payload). Normalmente o POX lida com pacotes Ethernet
que por sua vez trabalha com pacotes IP e contém ao mesmo tempo, pacotes TCP.
Alguns exemplos de pacotes suportados por esta biblioteca são: IP, TCP, DHCP,
LLDP, ARP, ICMP, UDP, DNS e VLAN.
3.4 - Análise do tráfego SDN
A Mininet vem com o Openflow Wireshark Dissector nativo. O Wireshark é
um software para captura de tráfego numa rede em produção, servindo para análise
de tráfego tanto Openflow quanto para depuração de outros pacotes. O comando
“sudo wireshark &” no terminal SSH inicializa-o.
Acessando no menu Capture e em seguida Interfaces, será aberta uma nova
janela e clica-se no botão Start. A partir deste momento, será apresentado a captura
de diversos pacotes em tráfego. Para filtrar somente tráfego Openflow faz-se
necessário a criação de um filtro. Na caixa de Filter coloca-se of, de Openflow, e
pressiona-se Apply para começar a capturar somente o tráfego escolhido.
Após inicializar o controlador o tráfego Openflow aparecem alguns tipos de
mensagens, estes são apresentadas abaixo:
Hello: Controlador envia o número da sua versão ao switch através do TCP
handshake.
Hello: Em retorno o switch envia o número das versões suportadas.
45
Features Request: Controlador requisita ao switch quais portas estão
disponíveis.
Set Config: Controlador requisita ao switch quais fluxos estão expirando.
Features Reply: Resposta do switch ao controlado com as suas portas e
características.
Port Status: switch avisa o controlador das mudanças em relação a
velocidade de cada porta ou de alguma conexão.
Várias mensagens, por vezes repetidas, aparecerão durante a captura do
tráfego, isso pode deixar a análise confusa devido a uma grande quantidade de
componentes estarem se comunicando na rede. É notável também a aparição das
mensagens Echo Request/Echo Reply com frequência, pois as mesmas são
responsáveis por manter ativas as conexões entre switches e controladores.
Abaixo algumas mensagens Openflow ao se realizar um ping na rede:
Packet-In: Pacote enviado pelo switch ao controlador devido à inexistência
de uma entrada na tabela de fluxo.
Packet-Out: Controlador envia pacote de volta ao switch.
Flow-Mod ou Flow_Add: Controlador adiciona na tabela de fluxo do switch
uma nova entrada.
Flow-Expired: switch avisa ao controlador que expirou um fluxo devido à
inatividade.
46
4 - Resultados dos experimentos
O experimento realizado foi feito em ambiente virtualizado utilizando a
Mininet, onde foram simulados topologias de rede com hosts e switches para testes.
Através do Wireshark pôde-se analisar os resultados obtidos, de acordo com as
mensagens trocadas pelos componentes virtuais.
O experimento foi executado sobre o hardware descrito a seguir.
● Processador Intel® Core™ i5-6500 CPU @ 3.20GHz × 4
● Gráfico Intel® Skylake DT GT2
● Sistema Operacional Ubuntu 15.10 64 bit
● Placa-Mãe Asus H170 Pro Gaming
● 8 GB RAM Corsair DDR 4
● SSD Samsung 850-EVO
4.1 - Experimento com rede padrão Mininet
Para realização da primeira parte do experimento foi criado a topologia de
rede virtual composta por 2 hosts, 1 switch, 1 controlador e 2 links conforme Figura
10:
Figura 10: Iniciando a topologia básica padrão na Mininet.
47
Ao receber esta resposta da Mininet, observada na Figura 10, aplica-se o
comando pingall, e o Wireshark deverá capturar os seguintes tráfegos vistos na
Figura 11:
Após o Controlador e o switch trocarem requisições Hello, Features_Request,
Features_Reply, Set_Config e Port_status começam as mensagens de Packet-In
vindo de um endereço MAC para Broadcast. Em seguida uma mensagem Packet-
Out é enviada do controlador ao switch referente ao um pacote que não tinha
nenhuma entrada na tabela de fluxo. Próximo passo é a mensagem Flow_Add,
também vista em outras versões como Flow_Mod, ambas adicionam na tabela de
fluxo uma nova entrada para este novo fluxo.
Figura 11: Tráfego capturado pelo Wireshark com Openvswitch.
48
Até próximos pings não existe participação do controlador na rede e a troca
de mensagens deve cessar até que a validade deste fluxo acabe e em seguida
aparecer a mensagem Flow_Expired, referente a expiração de fluxo.
4.2 - Experimento com switch camada 2
Neste experimento, continua-se com a mesma topologia básica da Mininet,
porém é carregado o componente forwarding.l2_learning no controlador, fazendo
com que esta rede trabalhe conforme um switch de autoaprendizado na segunda
camada. switches, por definição, operam na camada 2 (Enlace), onde protocolos de
camadas superiores não são suportados. switches L2 não entendem endereços IP,
roteamento IP, ou qualquer outra operação que envolva o protocolo IP. A seguir,
será apresentada uma demonstração dos comandos para o carregamento do
componente:
A Figura 12 mostra a resposta da Mininet com o controlador em
funcionamento onde os 2 hosts se comunicam.
Desconecte-se do controlador conforme a Figura 13.
Figura 12: Resposta da rede dentro da Mininet.
Figura 13: Desconectando de todos os controladores da Mininet.
49
Com a interrupção do controlador, pode-se notar que não há comunicação
entre os hosts como mostra o retorno na Figura 14, pois não há um responsável
para encaminhar os dados.
Para resolver este problema e retornar o funcionamento da rede, torna-se
necessário um controlador ativo com suas regras funcionais, será feita a mudança
do openvswitch que é o padrão da Mininet, para o controlador POX, com o
componente forwarding.l2_learning do controlador de acordo com a Figura 15.
Figura 14: Sem resposta na rede da Mininet.
50
Com o novo componente carregado no controlador, pode-se observar o
seguinte tráfego capturado na Figura 16:
Figura 15: Iniciando o componente do controlador POX na rede Mininet.
Figura 16: Tráfego capturado pelo Wireshark com controlador POX.
51
Com o switch da rede se comportando neste momento com um switch
camada 2 de autoaprendizado observa-se o protocolo ARP aparecer no tráfego.
Este protocolo resolve endereços da camada de Internet em endereços da camada
de enlace, uma função crítica em redes de múltiplos acessos.
Na captura do tráfego feita pelo Wireshark são encontradas várias linhas que
caracterizam fluxos entres os componentes da rede. Para o experimento é
necessário atentar-se para algumas destas linhas. Após as ações nas linhas 5270,
5272, 5274, 5276, 5277, 5278, 5279, 5280, correspondente da coluna ‘No.’, o switch
adicionou os hosts da rede na tabela de fluxo. Nas linhas 5320 e 5323 mostram uma
requisição do protocolo ARP, na coluna ‘Protocol’. Esta requisição serve para
identificar os endereços físicos descritos na coluna ‘Source’. A identificação destes
endereços físicos é feita através do switch aos endereços IP conectados a ele.
Continuando nas mesmas linhas, a coluna Info mostra as mensagens enviadas pelo
switch aos hosts para o descobrimento dos seus MAC através do protocolo ARP.
Identificados os respectivos endereços físicos, o switch relaciona-os ao seu
respectivo endereço IP na tabela de fluxo. Esta é a mudança ocorrida do primeiro
experimento para este. No primeiro experimento pôde-se notar o funcionamento de
uma rede baseada no controlador padrão da Mininet, o Openvswitch. O
Openvswitch trabalha como um switch de multicamadas, porém este possui o
adicional de protocolos da arquitetura Openflow. Alguns destes protocolos são o
NetFlow, sFlow, SPAN, RSPAN, CLI, LACP e 802.1ag.
52
4.3 - Experimento com módulo spanning_tree no
switch camada 2
Prosseguindo com a prática SDN, foram realizados vários testes de alguns
componentes que vem por padrão no controlador POX. Os componentes podem se
combinar para fazer o controlador da rede trabalhar de forma mais robusta e/ou
dedicado a algum serviço específico. O Wireshark utilizado para interceptar os
pacotes da rede e identificar mudanças no comportamento, não obteve o resultado
esperado, porém, trouxe análises satisfatórias para as conclusões. A justificativa
encontrada foi que a maioria destes componentes são para agregar algum serviço
que a rede possa oferecer e não mudar drasticamente sua estrutura, como, por
exemplo, o funcionamento de um hub para um switch. Entende-se componente e
modulo como a mesma coisa. Este último experimento foi realizado em cima de uma
topologia de 64 hosts, 9 switches, Um controlador e 72 links distribuída conforme a
Figura 17. Para criar a topologia digita-se o comando abaixo no terminal conectado a
Mininet via SSH:
$ sudo mn --switch ovs --controller ref --topo tree,depth=2,fanout=8
53
Para adicionar os componentes openflow.spanning_tree e
samples.spanning_tree ao controlador, faz-se necessário que a linha de comando
seja executada:
./pox.py forwarding.l2_learning openflow.spanning_tree samples.spanning_tree
Estes componentes necessitam de um módulo de descoberta, por exemplo o
forwading.l2_learning usado no teste.
Este componente, openflow.spannning_tree tem duas opções que alteram o
comportamento de inicialização:
--no-floods desativa inundações em todas as portas assim que um switch se conecta
em uma destas portas em loop.
Figura 17: Topologia complexa de rede na Mininet.
54
--hold-down impede alteração de controle de inundações até que um ciclo de
descoberta completa fosse concluída (e, portanto, todas as ligações tenham tido a
oportunidade de ser descobertas).
Assim, a mais segura (e provavelmente o mais sensível) invocação é
“openflow.spanning_tree --no-flood –hold-down”.
A Figura 18 mostra o resultado da inserção destes componentes no
controlador. Por padrão o componente openflow.of_01 e openflow.discovery são
carregados automaticamente.
Figura 18: Resultados da inserção da nova topologia no controlador da Mininet.
55
O openflow.of_01 comunica com switches openflow 1.0 e pode-se iniciá-lo
manualmente para permitir que troque suas opções, por exemplo, para definir qual
interface ou porta ele está escutando.
Já o openflow.discovery envia mensagens LLDP especialmente construídas
para fora dos switches openflow, permitindo que este avalie a topologia da rede.
Este gera eventos (os quais pode-se capturar) quando os links levantam ou caem.
Na Figura 19 nota-se o componente openflow.of_01 conectando os switches
ao controlador e em seguida o módulo openflow.discovery detectando os links entre
os switches. Ao detectar as ligações entre os switches, o componente
openflow.spanning_tree reconhece alguns loops lógicos e muda algumas portas
para que não haja inundações e a topologia entre em loop. Este é o componente
principal desta análise. Parecido com o STP, este módulo evita loops lógicos na rede
que poderiam causar mal funcionamento e possivelmente a perda de conexão
daquela parte da rede em loop.
Para finalizar e demonstrar como mesmo em ambiente virtualizado a rede
possui plena eficiência, o host identificado como h1, foi escolhido para acessar a
Internet através do navegador Mozilla Firefox. Para acessar a Internet de dentro da
Mininet é necessário que o switch principal da rede s1 libere a interface de rede do
switch intermediário s2, e posteriormente que este switch 2 faça o mesmo com o
host 1. O host 2 é necessário para rodar o servidor web para que possam ser feitas
requisições HTTP em outro host.
Após toda topologia estar em funcionamento, através do terminal da Mininet,
deve-se iniciar os terminais X dos hosts h1 e h2, e dos switches s1 e s2 conforme
linha de comando a seguir:
mininet> xterm s1 s2 h1 h2
Digita-se no terminal s1:
ovs-vsctl add-port s1 s2-eth1
Para liberar a interface de rede eth1 do switch 2.
Digita-se no terminal s2:
56
dhclient s1-eth1
Para ativar a interface eth1 do switch 2.
Digita-se no terminal h2:
python -m simpleHTTPServer 80 &
Para inicializar o servidor web para receber requisições http.
Digita-se no terminal do h1:
dhclient h1-eth0
apt-get update
apt-get install firefox
firefox &
Digita-se os comandos anteriores para ativar a interface de saída eth0,
atualizar a base de pacotes do sistema operacional, instalar o pacote firefox e iniciar
uma instância do firefox no X Window.
57
Com o navegador aberto e sendo utilizado, a Figura 20 mostra uma parte do
tráfego interceptados pelo Wireshark:
A Figura 19 é uma parte do tráfego relacionada ao host 1, de IP 10.0.0.1,
com a página da Internet “http://www.google.com” , IP 216.58.222.3. É possível ver a
troca de pacotes entre o host e a página do Google na linha 2767 da coluna No.,
onde a máquina 10.0.0.1 envia um pacote of_packet_in para o endereço 216.58.22.3
utilizando protocolo Openflow 1.0 (OF 1.0, coluna Protocol). Também é possível ver
outras trocas de pacotes e mensagens nas linhas 2780 e 2805.
Figura 19: Tráfego capturado pelo Wireshark com controlador POX numa topologia grande.
58
A Figura 20 é uma parte do tráfego relacionada ao host 1 de IP 10.0.0.1,
com a página da Internet “http://www.stanford.org”, IP 52.32.123.204. É possível ver
a troca de pacotes entre o host e a página da Universidade de Stanford na linha
2580 da coluna No., onde a máquina 10.0.0.1 envia um pacote of_packet_in para o
endereço 52.32.123.204 (stanford.org) utilizando protocolo Openflow 1.0 (OF 1.0,
coluna Protocol). Também é possível ver outras trocas de pacotes e mensagens nas
linhas e 2583, 2603, 2607 e 2614.
Com estes últimos testes de análise de tráfego através da ferramenta
Wireshark, pode-se concluir que houve tráfego efetivo de um host da rede
virtualizada pela Mininet e a internet, representada pelas páginas
“htttp://www.google.com” e “http://www.stanford.org”.
59
CONCLUSÃO
As Redes Definidas por Software estão avançando através de pesquisa e
trabalho, entre empresas e universidades. A Arquitetura e o Protocolo Openflow
trazem essa ideia inovadora para a prática, estabelecendo mecanismos e
ferramentas para uma implementação sólida e com real potencial.
Este trabalho apresentou as Redes Definidas por Software e os seus
avanços em relação a rede tradicional. Através da Mininet pôde-se implementar uma
topologia de rede virtualizada com tráfego real e em seguida o carregamento do
componente forwarding.l2_learning no controlador da rede. Foi também em conjunto
com a ferramenta Wireshark que pôde-se constatar um tráfego em produção e a
mudança do comportamento da rede com o carregamento deste novo componente.
A ideia de retirar a parte programática das redes trouxe avanço da
infraestrutura da Internet e uma independência para o gerenciamento da rede.
Ferramentas como NOX, POX, Virtual Machine (VM) Mininet, VirtualBox e
outros facilitam as pesquisas daqueles que não tem a disponibilidade de um switch
Openflow físico.
As Redes Definidas por Software são uma grande oportunidade para
aprimorar o funcionamento da internet em aspectos como qualidade de serviço,
segurança da informação, escalabilidade e resiliência.
Conclui-se assim que para tratar os novos desafios que a Internet passará, a
inovação da sua infraestrutura deverá ser repensada, uma grande mudança já
começou, foram as Redes Definidas por Software.
60
REFERÊNCIAS
ALENCAR, Felipe. Mininet: Uma rede virtual instantânea no seu PC, 2013. Disponível em: <http://www.felipealencar.net/2013/05/mininet-uma-rede-virtual-instantanea-no.html>. Acesso em: 15 Jul. 2015.
BEACON, 2011. Disponível em: <https://openflow.stanford.edu/display/Beacon/Home>. Acesso em: 29 Set. 2014.
BRITO, Samuel Henrique Bucke. Paradigma SDN de Redes Programáveis. LabCisco, 2013. Disponível em: <http://labcisco.blogspot.com.br/2013/07/paradigma-sdn-de-redes-programaveis.html>. Acesso em: 20 Mar. 2015.
CISCO. Open Network Environment: Bring the Network Closer to Applications, 2014. Disponível em: <http://www.cisco.com/c/en/us/products/collateral/switches/nexus-1000v-switch-vmware-vsphere/white_paper_c11-728045.html>. Acesso em: 07 Out. 2015.
COHESIVEFT. White Paper: Openflow is Software Defined Networking: Software Defined Networking is Not Only Openflow. 24 Set. 2012.
COUTO, Rodrigo de Souza. Openflow. UFRJ, 2010. Dinsponível em: <http://www.gta.ufrj.br/ensino/eel879/trabalhos_vf_2010_2/rodrigo/nox.html>. Acesso em: 22 Set. 2015.
DUQUE, Diego Henrique; COUTO, Edimilson Joaquim; PINTO, Marcelo Henrique et al. "Redes Definidas por Software", 2012. Disponível em <http://br.monografias.com/trabalhos3/redes-definidas-software/redes-definidas-software2.shtml>. Acesso em: 20 Dez. 2016.
FEAMSTER et al. Nick Feamster, Jennifer Rexford e Ellen Zegura. The road to sdn: An intellectual history of programmable networks, 2014.
FLOODLIGHT, Project. Floodlight is an Open SDN Controller, 2016. Disponível em: <http://www.projectfloodlight.org/floodlight/>. Acesso em: 12 Fev. 2016.
FRIEDERICKA, Anna. “Departamento de Ciência da Computação Universidade Federal da Bahia;” Curso de Inclusão Digital, 2005. Disponível em: <http://homes.dcc.ufba.br/~frieda/inclusaodigital/internet.htm>. Acesso em: 03 Mar. 2015.
GREENE, Kate. TR10: Software Defined Networking. MIT Technology Review, 2009. Disponível em: <http://www2.technologyreview.com/article/412194/tr10-software-defined-networking/> Acesso em: 02Dez. 2014.
HELLER, Brandon. Openflow Switch Specification. Version 1.0.0, Open Networking Foundation, 31 Dez. 2009.
Hewlett-Packard. SDN: Programmable network aligned to business applications delivers agility, 2013. Disponível em: <http://h17007.www1.hpe.com/docs/networking/solutions/sdn/4AA4-8807ENW.pdf>. Acesso em: 07 Out. 2015
Hewlett-Packard. Realizing the power of SDN with HT Virtual Application Networks, 2012. Disponível em: <h17007.www1.hpe.com/docs/interopny/4AA4-3871ENW.pdf>. Acesso em: 03 Jul. 2016.
IZARD, Ryan. Floodlight Documentation, 2016. Disponível em: <https://floodlight.atlassian.net/wiki/display/floodlightcontroller/>. Acesso em: 01 Abr. 2016.
JAIN, Raj; PAUL, Subharthi. “Network Virtualization and Software Defined Networking for Cloud Computing:” A Survey, 2013.
61
JSON, 2016. Disponível em: <http://www.json.org/>. Acesso em: 22 Mai. 2016.
KLEIS, Elton Gastardelli. Redes Definidas por SW I: Aplicação para Diferenciação de Caminhos, 2015. Disponível em: <http://www.teleco.com.br/tutoriais/tutorialsw1/default.asp>. Acesso em: 16 Out.2015.
LeClerc, Marc. The basics of SDN and the Openflow Network Architecture. Noviflow, 2013. Disponívelem: <http://noviflow.com/the-basics-of-sdn-and-the-openflow-network-architecture/>. Acesso em: 20 Ago. 2015.
LINKLETTER, Brian. Using the POX SDN controller, 2015. Disponível em: <http://www.brianlinkletter.com/using-the-pox-sdn-controller/>. Acesso em: 06 Jun. 2016.
McCauley, Murphy. POX Wiki, 2014. Disponível em: <https://openflow.stanford.edu/display/ONL/POX+Wiki>. Acesso em: 13 Mar. 2016.
MCKEOWN, Nick; ANDERSON, Tom; BALAKRISHNAN, Hari; et al. Openflow: Enabling Innovation in Campus Networks. ACM SIGCOMM Computer Communication Review, Volume 38, Issue 2, p. 69-74,2008.
Mininet Team. An Instant Virtual Network on your Laptop (or other PC), 2016. Disponível em: <http://mininet.org/>. Acesso em: 25 Mar. 2016.
LANTZ, Bob. "Mininet Core Team". Emulator for rapid prototyping of Software Defined Networks, 2016. Disponível em: <https://github.com/mininet/mininet>. Acesso em: 10 Jan. 2017.
NetFPGA, 2011. Disponível em: <http://archive.openflow.org/wk/index.php/NetFPGA/>. Acesso em: 21 Set. 2015.
NOX. Disponível em: <https://sdn-wiki.fokus.fraunhofer.de/doku.php?id=nox>. Acesso em: 28 Set. 2014.
NUNES, Bruno A.; MENDONÇA, Marc; NGUYEN, Xuan-Nam et al. A survey of software-defined networking: Past, present and future of programmable networks, 2014.
OPEN NETWORK FOUNDATION: Our Mission. 2017. Disponível em: <https://www.opennetworking.org/mission/>. Acesso em: 02 Jul. 2017.
PICHINI, Paulo. SDN revoluciona mundo das redes. Baguete, 2013. Disponível em: <http://www.baguete.com.br/artigos/1237/paulo-pichini/22/05/2013/sdn-software-defined-network-revoluciona-mundo-das-redes>. Acesso em: 01 Jul. 2015.
POX. Disponível em: <https://openflow.stanford.edu/display/ONL/POX+Wiki>. Acesso em: 22 Set. 2014.
POX Controller. Disponível em: <https://github.com/noxrepo/pox>. Acesso em: 20 Set. 2017.
RKUO. ONS Tutorial - SDN Essential, 2015. Disponível em: <https://github.com/rkuo/NetworkOS/blob/master/ONS%20Tutorial-SDN%20Essential.md>. Acesso em: 24 Fev. 2017.
ROJAS, Marco Antonio Torrez. “LARC”, Campus Party BR 6, 2013.
ROTHENBERG, Christian Esteve; NASCIMENTO, Marcelo Ribeiro; SALVADOR, Marcos Rogério et al. Openflow e redes definidas por software. CpqD, 2010. Disponível em: <http://www.cpqd.com.br/cadernosdetecnologia/Vol7_N1_jul2010_jun2011/pdf/artigo6.pdf>. Acesso em: 22 Nov. 2014.
RTI: Redes, Telecomunicações e Instalações; Edição 173, Aranda Editora, p. 104-107, São Paulo, 2014.
62
SALISBURY, Brent. Inside Google's Software-Defined Network, 2013. Disponível em: <http://www.networkcomputing.com/networking/inside-googles-software-defined-network/a/d-id/1234201?>. Acesso em: 02 Jul. 2015.
SDXCentral. What is a Floodlight Controller?. 2015. Dinsponível em: <https://www.sdxcentral.com/sdn/definitions/sdn-controllers/open-source-sdn-controllers/what-is-floodlight-controller/>. Acesso em: 10 Fev. 2016.
SDXCentral. What is OpenFlow? Definition and how it relates to SDN. 2014. Disponível em: <https://www.sdxcentral.com/sdn/definitions/what-is-openflow/>. Acesso em Mar. 2017.
Teletex. Redes Definidas por Software: A tecnologia que chegou para ficar, 2014. Disponível em: <http://blog.teletex.com.br/post/97578909487/redes-definidas-por-software-a-tecnologia-que/> Acessoem: 21 Jun 2016.
VANIAN, Jonathan. Facebook shows the promise of SDN with new networking tech. Gigaom, 2014. Disponível em: <https://gigaom.com/2014/11/14/facebook-shows-the-promise-of-sdn-with-new-networking-tech/>. Acesso em: 02 Mar. 2015.
WIRESHARK, 2014. Disponível em: <https://www.wireshark.org/>. Acesso em: 02 Fev. 2015.
