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
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
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)
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.
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.”
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.
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.
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
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
TCP Transport Control Protocol UDP User Datagram Protocol VLAN Virtual Local Area Network
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.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
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).
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.
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.
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).
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).
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).
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.
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.
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.
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.
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
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.
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).
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.
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).
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).
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.
• 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.
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.
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.
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
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
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
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>
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:
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ó.
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:
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.
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.
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.
(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.
-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.
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.
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 à
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:
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.
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.
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.
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.
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
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:
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.
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.
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.
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.
