ricardo anÍsio da silva
Post on 01-Jan-2022
1 Views
Preview:
TRANSCRIPT
RICARDO ANÍSIO DA SILVA
OTIMIZAÇÃO DE TRÁFEGO BROADCAST EM REDES OPENFLOW
Universidade Federal de Pernambuco
posgraduacao@cin.ufpe.br
www.cin.ufpe.br/~posgraduacao
Recife
2017
RICARDO ANÍSIO DA SILVA
OTIMIZAÇÃO DE TRÁFEGO BROADCAST EM REDES OPENFLOW
Dissertação apresentada ao Programa dePós-graduação em Ciências da Computa-ção, do Centro de Informática da Universi-dade Federal de Pernambuco, como partedos requisitos necessários à obtenção do tí-tulo de Mestre em Ciência da Computação.
Orientador: Djamel Fawzi Hadj Sadok
Recife
2017
Catalogação na fonte
Bibliotecária Monick Raquel Silvestre da S. Portes, CRB4-1217
S586o Silva, Ricardo Anísio da
Otimização de tráfego broadcast em redes Openflow / Ricardo Anísio da Silva. – 2017.
67 f.: il., fig., tab. Orientador: Djamel Fawzi Hadj Sadok. Dissertação (Mestrado) – Universidade Federal de Pernambuco. CIn,
Ciência da Computação, Recife, 2017. Inclui referências e apêndice.
1. Redes de computadores. 2. Redes definidas por software. I. Sadok, Djamel Fawzi Hadj (orientador). II. Título. 004.6 CDD (23. ed.) UFPE- MEI 2017-249
Ricardo Anísio da Silva
Otimização de Tráfego Broadcast em Redes Openflow
Dissertação apresentada ao Programa de Pós-Graduação em Ciência da Computação daUniversidade Federal de Pernambuco, comorequisito parcial para a obtenção do título deMestre Profissional em 14 de junho de 2017.
Aprovado em: 14/06/2017.
BANCA EXAMINADORA
__________________________________________Prof. Djamel Fawzi Hadj Sadok Centro de Informática / UFPE
(Orientador)
__________________________________________Prof. Rafael Roque Aschoff
Instituto Federal de Pernambuco
__________________________________________Profª. Patrícia Takako Endo
Universidade de Pernambuco
Dedico esse trabalho a minha mãe “Dinha”, com todo meu amor e gratidão, por
tudo que fez ao longo de minha vida. Desejo poder ter sido merecedor do esforço
dedicado por você em todos os aspectos, especialmente quanto à minha formação.
Dedico também a minha esposa Mônica, pelo amor, apoio, confiança e motivação
incondicional que sempre me impulsionou em direção às vitórias dos meus desafios.
AGRADECIMENTOS
Gostaria de agradecer primeiramente a Deus que permitiu que tudo isso acon-
tecesse, ao longo de minha vida, e não somente nestes anos como aluno de pós-
graduação, mas que em todos os momentos é o maior mestre que alguém pode
conhecer.
A toda minha família, em especial minha mãe Raimunda que foi a principal in-
centivadora dos meus estudos, minha esposa Mônica que me incentivou nos momentos
mais difíceis, dando total apoio moral.
Agradeço a todos os professores do Centro de Informática da Universidade
Federal de Pernambuco (CIN), por me proporcionarem o conhecimento, não apenas
racional, mas a manifestação do caráter e afetividade da educação no processo de
formação profissional.
Em especial ao meu orientador professor Doutor Djamel Sadok, pela oportu-
nidade dada, pelas trocas de ideias, pela cobrança, por me ensinar a ter uma visão
crítica dos resultados, e pelos caminhos que foram indicados.
Aos meus amigos da turma de mestrado profissional, por me darem todo apoio
e incentivo necessário aos estudos das disciplinas cursadas, e ainda por prestarem
todo apoio moral na semana de estudos em Recife.
Ao Instituto Federal Paraibano e seus diretores, por me apoiarem durante o
mestrado.
Finalmente, gostaria de agradecer a todos que contribuíram de alguma forma
direta ou indiretamente à realização de mais uma etapa na minha vida.
Obrigado a todos!
“O Aprendizado é o significado mais límpido
da vida, pois jamais se termina uma existência
sem que se aprenda algo.”
Maria Clara Fraga Lopes
RESUMO
O paradigma das Redes Definidas por Software (SDN) vem mudando a forma degerenciar e operar redes de computadores através da sua principal idéia, a separaçãodos planos de dados e de conotrole. O protocolo Openflow implementa este conceito e,devido às vantagens de menor custo de operação e maior facilidade de adaptação aprojetos de comutadores já existentes, é encontrado hoje em diversos equipamentosde rede comercializados por muitos fabricantes. Com o uso do paradigma SDN e doprotocolo Openflow, a inovação e evolução da rede são facilitadas. Dessa forma, muitosserviços típicos de rede podem ser repensados, de forma a torná-los mais flexíveis.Ao projetar uma rede SDN deve-se levar em consideração algumas particularidadesde desempenho, como por exemplo: tabela de fluxos e comunicação com controlador.Estas características tornam as métricas tradicionais de desempenho como vazão,latência, jitter e perda de pacotes insuficientes para avaliar o desempenho de uma redeSDN. O foco principal desta dissertação, esta no controle da tabela de fluxo provenientede requisições ARP. Desta forma, esta proposta visa a diminuição e o controle dotráfego broadcast através da Arquitetura SDN. A partir da criação de um novo módulo,desenvolvido para determinar o uso de múltiplos caminhos no encaminhamento detráfego referente a um fluxo, demonstrando neste trabalho que algumas métricas decontrole de requisições broadcast, podem ser atendidas. O módulo foi implementado eavaliado através de um simulador. Os resultados de avaliações referentes a diversosaspectos da solução proposta, são apresentados nesta dissertação, demonstrando queos ganhos na utilização do controle da tabela de fluxo e na quantidade de mensagensflow-mod do Openflow, geram uma dimunição na quantidade de dados transmitidasentre o controlador e o comutador.
Palavras-chave: Redes Definidas por Software (SDN). OpenFlow. Broadcast.
ABSTRACT
The paradigm of Software Defined Networking (SDN) has been changing theway in which to manage and operate computer networks through its main idea, theseparation of data plans and control. The Openflow protocol implements this conceptand, due to the advantages of lower cost of operation and greater ease of adaptationto designs of existing switches, is found today in several network equipment marketedby many manufacturers. With the use of the SDN paradigm and the Openflow protocol,network innovation and evolution are facilitated. In this way, many typical networkservices can be rethought in order to make them more flexible. When designing anSDN network one must take into account some particularities of performance, as forexample: table of flows and communication with controller. These characteristics maketraditional performance metrics such as flow, latency, jitter, and packet loss insufficientto evaluate the performance of an SDN network. The main focus of this dissertation isto control the flow table from ARP requests. In this way, this proposal aims at reducingand controlling broadcast traffic through the use and extension of the SDN Architecture.From the creation of a new module, developed to determine the use of multiple pathsin the traffic routing referring to a flow, demonstrating in this work that some controlmetrics of broadcast requests can be met. The module was implemented and evaluatedthrough a simulator. The results of evaluations regarding several aspects of the proposedsolution are presented in this dissertation, demonstrating that the gains in the use of theflow table control and in the number of flow-mod messages of Openflow, generate adecrease in the amount of data transmitted between the Controller and the switch.
Keywords: Software defined networks (SDN). OpenFlow. Broadcast.
LISTA DE FIGURAS
Figura 1 – Camadas de uma Rede SDN . . . . . . . . . . . . . . . . . . . . . . 22
Figura 2 – Arquitetura Openflow . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Figura 3 – Mininet Topologia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Figura 4 – Open vSwitch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Figura 5 – TCPdump . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Figura 6 – Wireshark . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Figura 7 – Requisições arp geram novos fluxos . . . . . . . . . . . . . . . . . . 34
Figura 8 – Respostas arp geram mais fluxos . . . . . . . . . . . . . . . . . . . . 35
Figura 9 – Modelo Openflow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Figura 10 – Controlador responde requisições ARP . . . . . . . . . . . . . . . . 39
Figura 11 – Topologia Linear . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
Figura 12 – Topologia Tree . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
Figura 13 – FITS autonomous island interconnection architecture . . . . . . . . . 43
Figura 14 – Gráfico Topologia Linear Padrão . . . . . . . . . . . . . . . . . . . . 45
Figura 15 – Gráfico Topologia Linear Proposta . . . . . . . . . . . . . . . . . . . 46
Figura 16 – Grafico comparativo Topologia Linear . . . . . . . . . . . . . . . . . 47
Figura 17 – Gráfico Topologia Tree Padrão . . . . . . . . . . . . . . . . . . . . . 48
Figura 18 – Gráfico Topologia Tree Proposta . . . . . . . . . . . . . . . . . . . . 49
Figura 19 – Grafico comparativo Topologia Tree . . . . . . . . . . . . . . . . . . 50
Figura 20 – Gráfico Topologia Linear Padrão (flow-mod) . . . . . . . . . . . . . . 51
Figura 21 – Gráfico Topologia Linear Proposta (flow-mod) . . . . . . . . . . . . . 52
Figura 22 – Gráfico Topologia Linear Comparativo (flow-mod) . . . . . . . . . . . 53
Figura 23 – Gráfico Topologia Tree Padrão (flow-mod) . . . . . . . . . . . . . . . 54
Figura 24 – Gráfico Topologia Tree Proposta (flow-mod) . . . . . . . . . . . . . . 55
Figura 25 – Gráfico Topologia Tree Comparativo (flow-mod) . . . . . . . . . . . . 56
LISTA DE TABELAS
Tabela 1 – Topologia Linear Padrão . . . . . . . . . . . . . . . . . . . . . . . . . 44
Tabela 2 – Topologia Linear Proposta . . . . . . . . . . . . . . . . . . . . . . . . 45
Tabela 3 – Topologia Linear Comparativo . . . . . . . . . . . . . . . . . . . . . 46
Tabela 4 – Topologia Tree Padrão . . . . . . . . . . . . . . . . . . . . . . . . . . 47
Tabela 5 – Topologia Tree Proposta . . . . . . . . . . . . . . . . . . . . . . . . . 48
Tabela 6 – opologia Tree Comparativo (flow-mod) . . . . . . . . . . . . . . . . . 49
Tabela 7 – Topologia Linear Padrão (flow-mod) . . . . . . . . . . . . . . . . . . 50
Tabela 8 – Topologia Linear Proposta (fow-mod) . . . . . . . . . . . . . . . . . 51
Tabela 9 – Topologia Linear Comparativo . . . . . . . . . . . . . . . . . . . . . 52
Tabela 10 – Topologia Tree Padrão (flow-mod) . . . . . . . . . . . . . . . . . . . 53
Tabela 11 – Topologia tree Proposta (flow-mod) . . . . . . . . . . . . . . . . . . . 54
Tabela 12 – Topologia tree Comparativo (flow-mod) . . . . . . . . . . . . . . . . 55
LISTA DE ABREVIATURAS E SIGLAS
API Application Programming Interface
ARP Address Resolution Protocol
CPU Central Processing Unit - Unidade Central de Processamento
DAS Documento de Arrecadação do Simples Nacional
DE Diagnóstico de Enfermagem
DOS Disk Operating System (Sistema Operacional em Disco)
FITS Future Internet Testbed with Security
GNU General Public License
GPL General Public License
HP Health Points
IBM International Business Machines
IP Internet Protocol
JSON JavaScript Object Notation
KVM Kernel-based Virtual Machine
MAC Media Access Control
NEC National Eletrical Code
ONF Open Network Foudation
OSI Open Systems Interconnection
PC Passivo Circulante
RFC Request for Comments
SDN Software Defined Networks
TI Tecnologia da Informação
UNESP Universidade Estadual Paulista
W3C World Wide Web Consortioum, entidade que regulamenta os padrões
de internet
SUMÁRIO
1 INTRODUÇÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
1.1 Motivação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
1.2 Objetivos da Pesquisa . . . . . . . . . . . . . . . . . . . . . . . . . 18
1.2.1 Objetivo Geral . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
1.2.2 Objetivos Específicos . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
1.3 Organização . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2 REVISÃO DA LITERATURA . . . . . . . . . . . . . . . . . . . . . . . 20
2.1 Redes Definidas Por Softwares . . . . . . . . . . . . . . . . . . . . 20
2.2 Protocolo Openflow . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.3 Controladores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.3.1 Controlador Nox . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.3.2 Controlador Pox . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.3.3 Controlador Ryu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.4 Mensagens Openflow . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.5 Soluções Open Source . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.5.1 Mininet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.5.2 Open Vswitch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.5.3 OpenWrt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.5.4 NetFPGA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
2.6 Soluções Proprietárias . . . . . . . . . . . . . . . . . . . . . . . . . 30
2.7 Ferramentas de Analise de Tráfego . . . . . . . . . . . . . . . . . . 31
3 SOLUÇÃO PROPOSTA . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.1 Broadcast . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.2 Modelo Openflow . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.3 Otimização do Broadcast . . . . . . . . . . . . . . . . . . . . . . . . 37
4 AVALIAÇÃO DA PROPOSTA . . . . . . . . . . . . . . . . . . . . . . 40
4.1 Ambiente de Testes . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.2 Coleta de Dados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
5 ANÁLISE DOS RESULTADOS . . . . . . . . . . . . . . . . . . . . . 44
6 CONCLUSÃO E TRABALHOS FUTUROS . . . . . . . . . . . . . . . 57
REFERÊNCIAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
APÊNDICES 63
APÊNDICE A – CÓDIGO DE OBTENÇÃO DAS ESTATÍSTICAS DOS
FLUXOS OPENFLOW . . . . . . . . . . . . . . . . 64
15
1 INTRODUÇÃO
As redes de telecomunicações tornaram-se uma das principais fontes de infor-
mação a nível mundial. Em consequência do sucesso e popularização, surgiram vários
problemas para manter a qualidade nos diferentes tipos de tráfego, o que encarece a
entrega dos serviços das redes corporativas, tais como: a transmissão de tráfego de
voz, dados e streaming de vídeos.
De acordo com o grupo pioneiro em tecnologias inovadoras Furukawa, as re-
des de telecomunicações estão sendo aperfeiçoadas para suportar a transmissão
de informações com a introdução de novas tecnologias, tanto do lado dos equipa-
mentos da rede (elementos de rede), quanto dos meios de transmissão (redes de
transporte) e dos sistemas de operações para o gerenciamento (Gerência de Redes de
Telecomunicações). (SAKATO; O’DONNELL; HINGORANI, 2012).
Um grupo de pesquisadores de rede da Universidade de Stanford e da Califórnia
em Berkeley desenvolveu uma solução programável, nomeada de Rede Definida por
Software (SDN). A SDN é um novo paradigma, criada com o intuito de ser utilizada em
redes de computadores em produção, permite que administradores e pesquisadores
possam testar novos protocolos e tecnologias independentes das aplicações proprietá-
rias, provendo a interoperabilidade entre diferentes fabricantes que antes não existia.
(FALSARELLA, 2012).
Baseado no contexto de crescimento, os administradores de redes corporativas
se veem com a responsabilidade de manter a qualidade e a segurança da informação
que trafega na rede da empresa. Considerando que aplicações e funcionalidades são
adicionadas diariamente, é necessário criar um ponto concentrador de gerenciamento
para facilitar a administração dessas tecnologias. Nesse ambiente, surgem as redes
programáveis, junto ao protocolo OpenFlow, que possui padrão aberto, com uma pro-
posta tecnológica que se baseia em um modelo de controle de rede centralizado, sendo
assim, entrega um modo para que o administrador consiga melhorar o gerenciamento
Capítulo 1. Introdução 16
dos diferentes tipos de tráfego na sua rede.
Diante dessa gama de cenários voltados para a Internet do futuro, há uma
série de possibilidades a serem exploradas. Uma delas é o desmembramento das
funções atribuídas á rede tradicional, normalmente prejudicada pela maior demanda
de dados que pode ocasionar uma lentidão em seu funcionamento. Com o advento da
SDN, o serviço prestado pela rede será melhor gerenciado, potencializando o tráfego e
adequando-a ás novas tecnologias. Uma vez que a internet, normalmente não garante
essa qualidade essencial em aplicações sensíveis, como por exemplo, a tecnologia de
Voz sobre IP (VoIP).
1.1 Motivação
Nos últimos anos a velocidade e a quantidade das informações que trafegam
pela Rede têm experimentado um crescimento que não tende mais a regredir. O mesmo
ocorre, em escala menor, na rede de uma organização, se não corretamente gerenciado
pode ocasionar lentidão ou até mesmo a indisponibilidade de um ou mais serviços.
O controle de tráfego do broadcast, tem a intenção de segmentar uma rede lógica
afim de aumentar o controle de tráfego da rede, diminuir o alcance de disseminação de
pacotes de difusão (broadcast) e de pragas virtuais, melhorado assim o desempenho e
a segurança de uma determinada rede.
Atualmente é cada vez mais comum o uso de soluções virtuais, disponíveis
a um clique, para substituir ações que, eram efetuadas fisicamente, demandando
deslocamentos e disponibilidade de tempo, como por exemplo, em livrarias online onde
podem se adquirir livros, físicos ou virtuais, em pouco tempo sem a necessidade de
sair de sua residência. Em uma organização esta tendência segue o mesmo caminho
afim de agilizar processos, diminuir custos e aumentar lucros.
Este aumento de aplicações e, consequentemente, de informações trafegando
pela rede trouxe uma nova preocupação para a equipe de TI (Tecnologia da Informação)
que é o congestionamento dos links. O crescimento desenfreado do tráfego de rede
Capítulo 1. Introdução 17
cria gargalos em determinados pontos da estrutura, podendo gerar lentidão ou até
tornar alguns serviços indisponíveis temporariamente. Esta situação pode ser agravada
pela propagação de pacotes de difusão (broadcast) que em muitos casos consomem
fatia considerável da banda de um enlace de dados.
Outra questão importante a se considerar é a segurança. Com o aumento
de informações confidenciais circulando pela rede cresce também o interesse de
pessoas mal intencionadas buscando capturar dados para fins diversos por meio da
disseminação de pragas virtuais (vírus, worms, malwares, etc) ou através de sniffers,
capturando pacotes e extraindo dados que lhe pareçam interessantes para uso futuro.
ça da (MARCO AURÉLIO MAIA, 2013)
Uma rede possui vários dispositivos: computadores, impressoras e outros, co-
nectados, que disseminam uma grande quantidade de pacotes de difusão, seja por
falhas na conexão, mau funcionamento de placas de redes, ou até mesmo por protoco-
los e aplicações que geram este tipo de tráfego, podendo causar atraso no tempo de
resposta e lentidão na rede
. (RIBEIRO et al., 2011) No modelo a ser proposto, existe um controle lógico
de difusão por onde os pacotes de broadcast são contidos e não se propagam a
outras redes. A proposta se faz através do endereço físico das interfaces de rede dos
dispositivos (endereço MAC). Neste método, o administrador de redes associa um
endereço MAC de um dispositivo a uma tabela no controlador. (MUSSI et al., 2011)
Um dos maiores inconvenientes desta modalidade de agrupamento é o fato
de que, antes de se colocar em operação, devem se cadastrar todos os endereços
MAC dos dispositivos que serão conectados na rede, o que, dependendo do tamanho
da rede, pode dispender bastante tempo de trabalho. Outra limitação desta solução
refere-se a impossibilidade de associar mais de uma rede para cada endereço MAC.
Capítulo 1. Introdução 18
1.2 Objetivos da Pesquisa
Nesta seção serão descritos os objetivos gerais e específicos que se buscam
alcançar por meio deste trabalho.
1.2.1 Objetivo Geral
O objetivo principal deste trabalho é melhorar o desempenho de sistemas e
serviços em redes Openflow. Um modulo para auxiliar o controlador neste tipo de ambi-
ente precisa ser desenvolvido levando em consideração todas as suas especificidades
para, assim, adequar-se ao máximo a infraestrutura existente nas organizações.
1.2.2 Objetivos Específicos
Para atender ao objetivo geral deste trabalho, foram definidos os seguintes
objetivos específicos:
• Alterar o controlador, para que possa diminuir o número de mensagens broadcast
em uma rede;
• Diminuir o processamento no controlador, reduzindo a carga de trabalho;
• Criar um modulo auxiliar para manter o mapeamento da tabela ARP no controla-
dor;
• Reduzir o número de mensagens flow-mod em uma rede.
1.3 Organização
A sequência desta dissertação está organizada como indicado a seguir.
No Capítulo 2 é feita uma revisão da literatura, descrevendo as redes definidas
por software e suas tecnologias, além de ferramentas e soluções para uso nessas
redes.
No Capítulo 3 é apresentado o problema de dominio de colisão em redes
openflow e a solução proposta para reduzir este probrema.
Capítulo 1. Introdução 19
No Capítulo 4 é feito a avaliação da proposta, onde é realizado os testes em
ambiente emulado, onde é feito a avaliação da proposta em topologias de redes
distintas, também é coletado os dados que serão analisados no capítulo 5 desta
dissertação.
Já no Capítulo 5 é apresentado o detalhamento e a validação das simulações
empreendidas neste estudo. Neste mesmo capítulo, são detalhados os parâmetros
das simulações e apresentados os resultados dos experimentos, juntamente com a
avaliação de desempenho da proposta, comparando o desempenho por cenários e
comparando seus desempenhos entre si.
E por fim, as conclusões desta dissertação são apresentadas no Capítulo 6.
20
2 REVISÃO DA LITERATURA
A globalização inclui um processo de integração econômica, cultural, social e
política e com isso abriu diversas portas ao mundo empresarial, quebrando barreiras
como distância e limites de fronteiras, trazendo ao mundo as grandes multinacionais.
Essas empresas, com ajuda da tecnologia, movimentam o mercado financeiro, cada
vez mais expandindo, não se importando com a distância física entre matriz e filiais.
Para manter esse cenário conectado em um ambiente de redes convergentes com
diversos tipos de aplicações, os administradores de redes se veem cada vez mais
condicionados a automatizar processos, facilitar a sua vida e abstrair a complexidade
dos processos internos para o usuário, e é nesse cenário que surge o conceito das
redes definidas por software, permitindo ao administrador gerir seus equipamentos
de rede remotamente, programar roteadores, switches através de software e integrar
aplicações, serviços e funcionalidades aos usuários de maneira transparente.
David Cearley, vice-presidente do Instituto Gartner, líder mundial em pesquisa e
aconselhamento sobre tecnologia, destacou uma das vantagens das redes SDN:
O ambiente de rede nos próximos cinco anos não será mais controlado por
roteadores e switches ou por outros tipos de hardware, mas sim por software. A grande
vantagem dessa mudança é uma melhoria do monitoramento e também aumento de
desempenho da infraestrutura de TI, que passará a ser controlada de forma centralizada.
As configurações serão feitas em um único ponto da rede e não mais por devices
individuais. (CEARLEY, 2014).
2.1 Redes Definidas Por Softwares
O SDN oferece um controle centralizado da rede, com base em seu principal
conceito de abstração dos planos de dados e o plano de controle, isto é, abstraindo as
complexidades da rede. Sendo assim, assumindo tarefas que antes eram realizadas
pelo hardware, de forma que permita o gerenciamento da rede através de uma Interface
Capítulo 2. Revisão da Literatura 21
de Programação de Aplicações ou API, (do inglês, Application Programming Interface).
As tecnologias atuais de rede não estão dando conta de todas as exigências dos
usuários devido a complexidade e a quantidade de protocolos usados. Geralmente
são desenvolvidas e definidas de forma isolada e, para dificultar ainda mais, alguns
fabricantes desenvolvem protocolos proprietários. Esses problemas vêm causando
transtorno aos usuários, já que a grande parte utiliza a Internet para alguma forma de
comunicação. (RODRÍGUEZ, 2014).
Atualmente, existe a necessidade das corporações se alinharem ao crescimento
do mercado tecnológico e se atualizarem diante das novas tecnologias e tendências.
O avanço trazido pelo SDN extrapola o modelo tradicional de um conjunto de “caixas
pretas” deixando de tratar o hardware das redes de forma independente e passando a
mesclar suas funções cada vez mais com os softwares, trazendo inúmeras possibilida-
des de flexibilidade para usuário e administrador.
A comunicação entre a camada de controle e a camada de infraestrutura é
feita através de um protocolo padronizado. Deste modo, tanto o controlador como os
dispositivos de rede precisam interpretar este protocolo, modelo esse que pode ser
visualizado na Figura 2.1, onde existe a separação das camadas em detalhes de uma
rede definida por software. Em equipamentos ativos de rede como switch e roteadores,
o plano de controle e o plano de dado são gerenciados pelo mesmo equipamento, no
caso de uma rede definida por software o plano de controle fica externo ao dispositivo
de rede, no qual pode ser alocada externamente em uma máquina física ou virtual.
Capítulo 2. Revisão da Literatura 22
Figura 1 – Camadas de uma Rede SDN
Duque, 2012.
A arquitetura SDN é inerente aos saltos na evolução das redes, dado que o
legado tradicional se encontra em seu limite, pois novos protocolos e tecnologias já cita-
das não são suportados mediante a arquitetura atual. SDN é um novo paradigma criado
com o intuito de ser utilizada em redes de computadores em produção, permitindo que
administradores e pesquisadores possam testar novos protocolos e tecnologias inde-
pendentes das aplicações proprietárias, provendo a interoperabilidade entre diferentes
fabricantes que antes não existiam. (FALSARELLA, 2012).
O parque tecnológico de empresas com diversas filiais e backbones de opera-
doras de telecomunicações possui geralmente certa quantidade de equipamentos com
fabricantes distintos, o que exige a contratação de vários profissionais especializados
em cada fabricante, gerando um custo relativamente maior. No ambiente controlado por
software, um único gestor pode se especializar na tecnologia SDN e formular o tráfego
centralizado, controlando a interoperabilidade da rede, a partir de uma única interface.
Alterando configurações e regras de qualquer ativo da rede quando necessário, fazendo
Capítulo 2. Revisão da Literatura 23
com que o administrador gerencie as cargas de tráfego distintas de uma forma flexível
e mais eficiente.
2.2 Protocolo Openflow
O paradigma SDN é considerado a nova evolução das redes modernas. Mas
para que o funcionamento da nova tendência tecnológica (SDN) se torne possível, será
preciso habilitar um protocolo aberto de comunicação entre os diferentes comutadores
de rede e o controlador. O protocolo a ser utilizado é o OpenFlow, já que tem como
principal característica proporcionar uma interface aberta para que a comunicação
entre os equipamentos da rede e o controlador em uma rede definida por software seja
possível. (COSTA, 2013).
O OpenFlow é um protocolo que permite modificar o comportamento dos disposi-
tivos de rede através de um conjunto de instruções definidos por um controlador remoto.
Vários fabricantes estão incluindo o protocolo OpenFlow em seus equipamentos como
roteadores, switches e access points. (ARAÚJO, 2013).
Desde então, o OpenFlow foi desenvolvido a partir da versão (OpenFlow 1.0
Standards) desde março de 2008, quando foi proposto pelo grupo constituído de
pesquisadores da Universidade de Stanford. No entanto o principal objetivo desses
pesquisadores era criar uma rede programável com o propósito de torná-la uma rede
de computadores com tecnologia SDN baseada em OpenFlow. (MCKEOWN, 2008).
De acordo com Lopes (MCKEOWN, 2008), “A plataforma OpenFlow é o principal
exemplo de aplicação do conceito SDN. Atendendo a demanda de validação de novas
propostas de arquiteturas e protocolos de rede sobre equipamentos com sistema
proprietários comerciais diferentes”.
Conforme ilustrado na Figura 2.2, o Controlador OpenFlow se comunica com
o plano de controle do switch através da rede utilizando o protocolo de comunicação
OpenFlow, possibilitando assim que todos os pacatos trafeguem na rede de forma
gerenciada.
Capítulo 2. Revisão da Literatura 24
Figura 2 – Arquitetura Openflow
Sheffer, 2014.
2.3 Controladores
O controlador OpenFlow atua como um sistema operacional de rede para
centralizar a comunicação com os elementos programáveis, agindo como um plano de
controle em uma rede definida por software. Desta forma permite adicionar e remover
as entradas de dados em uma tabela de fluxo, uma vez que o controlador pode trabalhar
de forma distribuída.
Segundo Rodríguez (RODRÍGUEZ, 2014). “O controlador consiste em um modo
de controle centralizado, seja fisicamente ou logicamente, que executa aplicações
sobre a rede OpenFlow, configurando e gerenciando as tabelas de fluxo dos elementos
encaminhadores.” Existem vários controladores desenvolvidos em linguagens de pro-
gramação variadas como NOX, baseado em C++; FLOODLIGHT, OPENDAYLIGHT, em
Java, POX e Ryu em Python.
Capítulo 2. Revisão da Literatura 25
2.3.1 Controlador Nox
O NOX é um controlador de referência que acompanha o OpenFlow, ele surgiu
da Interface de Programação de Aplicações (APIs) desenvolvida em C ++. O NOX atua
como uma camada de abstração, que desenvolve as aplicações e os serviços que
controla as entradas de fluxo nos comutadores OpenFlow. (RODRÍGUEZ, 2014).
Conforme abordado por Costa (COSTA, 2013), o NOX é uma plataforma de
controle de rede OpenFlow, com o propósito de prover uma interface de programação
de alto nível em que as aplicações de gerenciamento da rede possam ser construídas.
2.3.2 Controlador Pox
O POX é uma versão baseada no modelo do NOX, é o principal controlador
OpenFlow de código aberto escrito em Python. O controlador surgiu das APIs de Python
do controlador NOX, é um dos controladores mais utilizados atualmente. Segundo
Junior (AMILTON JUNIOR, 2010), “O controlador POX é bastante recomendado para
experimentos e fins educacionais. Comparado com o NOX, que é desenvolvido em
programação C++, ele possui um desempenho inferior, já que o desenvolvimento de
aplicações nele é mais rápido e fácil de ser utilizado.” (CHARPINEL JUNIOR, 2012).
2.3.3 Controlador Ryu
Conforme explanado por Rodríguez (RODRÍGUEZ, 2014), “o controlador Ryu
é um componente criado para o contexto das redes definidas por software. Todo seu
código está disponível gratuitamente com a licença de Apache 2.0 e está completa-
mente escrito na linguagem de programação Python, facilitando assim a criação de
novas aplicações de controle.”.
O Ryu fornece componentes de software com APIs muito bem definidas, que
facilitam aos desenvolvedores a criação de novas formas de gerenciamento de redes
e aplicações de controle, ou seja, o controlador dá suporte a vários protocolos para
o gerenciamento dos equipamentos de rede como Net Conf, OF-com, OpenFlow.
(RODRÍGUEZ, 2014).
Capítulo 2. Revisão da Literatura 26
2.4 Mensagens Openflow
O protocolo Openflow possui uma série de mensagens. As mais comuns são:
• Flow-mod - Sentido Controlador –> Switch. São as mensagens utilizadas na
gerencia da tabela de fluxos do switch. São usadas para adicionar, alterar ou
remover uma entrada da tabela.
• packetIn - Sentido Switch –> Controlador. O switch enviar mensagens Packet-
In, para o controlador definir o que deverá ser feito com aquele tipo de pacote.
São usadas em requisições ao controlador.
• Flow-out - Sentido Controlador –> Switch. O controlador é capaz de enviar
pacotes para a rede através do switch. O controlador encapsula o pacote a ser
enviado em uma mensagem flow-out. Na mensagem flow-out é especificada a
porta do switch pela o pacote será enviado para a rede.
• Flow-stats - São mensagens usadas na coleta de estatísticas do switch. Po-
dem ser request, do controlador para o switch. Ou response, do switch para o
controlador.
2.5 Soluções Open Source
A tradução do termo em inglês “open source” é código aberto. Um software com
o código aberto pode ser executado, copiado, distribuído, modificado e aperfeiçoado
por todos seus usuários, segundo conceitos encontrados no site do Projeto Software
Livre Brasil.projeto softwareeto software.projeto open source. (COSTA et al., 2013).
O software open source é também conhecido como “free software”. Neste caso,
a palavra “free” não indica gratuidade, mas sim, liberdade. A liberdade é um dos valores
defendidos pelo movimento open source, além da colaboração e o compartilhamento
Capítulo 2. Revisão da Literatura 27
do conhecimento. Devido à ambigüidade do significado do termo “free software”, foi
cria da a expressão “open source”.
Estes softwares são desenvolvidos por pessoas espalhadas em todo o mundo,
em função do acesso ao código fonte.
Em torno de um software, os colaboradores formam uma comunidade. Atual-
mente, existem comunidades open source no mundo todo, em torno de diversos tipos
de software. (CESTAROLLI, 2015)
2.5.1 Mininet
O Mininet é uma ferramenta de emulação de rede que possibilita criar uma rede
virtualizada, com switch, roteadores, controladores e hosts, baseado na arquitetura
SDN. O Emulador é executado em um único núcleo (kernel) real e tem como base o
protocolo OpenFlow, possibilitando aos pesquisadores criar protótipos de rede através
de uma forma simples e barata, antes de programá-lo na rede atual. O emulador foi
utilizado para realização de testes para afirmar a viabilidade na implementação do novo
paradigma em nosso trabalho. Por se tratar de um ambiente virtualizado, utilizando um
único (kernel) do Linux, possui suas limitações. As redes virtualizadas podem exceder
os limites de CPU do hardware e a largura de banda disponível no servidor. (KAUR;
SINGH; GHUMMAN, 2014).
O Mininet possui algumas topologias pré-definidas, como: single, linear, tree, etc
figura 2.3. Além dessas topologias pré-definidas, o Mininet possui suporte a topologias
customizadas. (SISWANTO; KARIMAH, 2014)
Capítulo 2. Revisão da Literatura 28
Figura 3 – Mininet Topologia
SISWANTO; KARIMAH, 2014
2.5.2 Open Vswitch
O modelo OpenFlow é um comutador em software executado em uma máquina
Linux, com o princípio de separação do plano de dados e plano de controle. Esse
modelo vem sendo utilizado por pesquisadores em vários estudos técnicos, contudo o
modelo carece em desempenho. Perante essa lacuna, foi desenvolvido um comutador
virtual adequado à arquitetura OpenFlow nomeado de Open vSwitch (OVS). (OPEN
VSWITCH, 2014).
O OVS é um switch virtual de multicamada, em conformidade com uma licença
de código aberto Apache 2.0, executado em um (kernel) Linux compatível com as mais
variadas distribuições, tais como: Debian, Fedora, Ubuntu e CentOS. Vale ressaltar que
a quantidade de portas é relacionada com o limite de portas disponíveis no Desktop e
Notebook, incluindo portas sem fio. Figura 2.4. (RODRÍGUEZ; CAMPELO, 2014).
Capítulo 2. Revisão da Literatura 29
Figura 4 – Open vSwitch
RODRÍGUES; SOUSA CAMPELO, 2014
Em princípio, seu desenvolvimento foi para uso como um comutador virtual em
ambientes virtualizados, mas apesar da sua capacidade de comutação de pacotes
L2/L3, o OVS dá suporte a vários servidores físicos, e sua arquitetura suporta várias
tecnologias de virtualização, como Xen, KVM e outras. (OPENWRT, 2015).
2.5.3 OpenWrt
OpenWrt é descrito como uma distribuição baseada no kernel do Linux, utilizado
em dispositivos embarcados. É um projeto gratuito de código aberto licenciado sob
uma licença GPL. A distribuição é de fácil acesso, hospedado por meio do seu site
oficial, possui uma interface gráfica conhecida como Luci, de simples administração,
porém é possível administrar por meio de linha de comando conhecida como (ash).
Vale ressaltar que o projeto não está limitado apenas a dispositivos embuti-
dos, de outro modo, dispositivos como roteadores, computadores portáteis, MikroTik
e computadores pessoais baseados em arquitetura x86, também possui suporte ao
Capítulo 2. Revisão da Literatura 30
projeto. Como não é destinado apenas a um único dispositivo, o sistema possui suporte
integrado às necessidades dos usuários, ou seja, o sistema operacional fornece funcio-
nalidades mais completas de acordo com a experiência do usuário final. (PEREIRA,
2011).
2.5.4 NetFPGA
A plataforma NetFPGA’s é um hardware programável de código aberto, com
módulo OpenFlow habilitado, projetada para pesquisadores e estudantes construírem
protótipos de redes em alta velocidade, além de desenvolver protótipos de comutadores
para a Internet do futuro utilizando o protocolo OpenFlow. O projeto consiste em placas
PCI-e, com portas gigabit, conectadas a um PC baseado em Linux, possibilitando o
desenvolvimento de novas funcionalidades. (LOPES, 2015).
2.6 Soluções Proprietárias
O SDN está deixando de ser solução de laboratório e tornando-se realidade
em escala corporativa. Esta revolução na indústria de redes é em consequência à
expansão de ambientes altamente virtualizados. Alinhando a este campo tecnológico, é
fundamental a utilização de protocolo aberto, como por exemplo, o protocolo OpenFlow,
permitindo assim a criação de aplicações voltadas a problemas específicos de rede,
assim como controle de acesso, entre outros.
Grandes empresas como IBM, HP, NEC, já desenvolvem aplicações que se
utilizam dessa tecnologia, que cada vez mais vem ganhando destaque dentro deste
cenário de Redes Definidas por Software. Apesar de ser uma tecnologia de rede ainda
muito recente, algumas pesquisas revelam que em alguns anos será um negócio de
bilhões de dólares. O SDN é uma das coisas mais relevantes da última década em se
tratando de infraestrutura de redes, e vem chamando a atenção por sua simplicidade e
facilidade de gerenciar e programar as redes. (DUQUE, 2012).
A gigante do mercado de soluções em tecnologia da informação, HP, possui
a maior base de infraestrutura instalada com suporte ao OpenFlow. Membro e um
Capítulo 2. Revisão da Literatura 31
dos fundadores do grupo ONF, investe pesado em soluções SDN desde 2008. A HP
desenvolveu uma solução corporativa de controlador de rede chamado VAN (Virtual
Applications Network ), o controlador, além de prover um ponto unificado e centralizado
para gerenciamento da rede, provê soluções de automação da rede de ponta a ponta,
ou seja, do datacenter ao campus. (HP COMPANY, 2015).
A companhia multinacional do mercado de redes de computadores a Cisco, en-
trou estrategicamente no conceito SDN, desenvolvendo um conceito chave denominado
de ONE (Open network Enviroment), uma serie de APIs e SDKs para desenvolvedores.
A solução fornece uma visão ampla do conceito, dividindo em camadas, dentre elas,
a camada de infraestrutura consiste em fazer com que dispositivos físicos e virtuais
trabalhem em conjunto em uma rede com capacidade de programação. (CISCO, 2015).
À medida que o SDN amadurece no mercado de soluções estratégicas, novos
olhares se abrem no meio corporativo, onde grande parte dos fabricantes está se
movendo e oferecendo produtos e soluções no mercado. Suas aplicações criam um
ambiente propício para a competitividade, que antes dessa evolução estava restrito
para um único fabricante, sendo assim a visão é oferecer a melhor solução para cada
caso de negócio.
2.7 Ferramentas de Analise de Tráfego
• Tcpdump: Desenvolvido em 1987 é um analisador de pacotes de código aberto
usado em linha de comando desenvolvido para auxiliar os gestores de rede. A
ferramenta exibe as informações contidas no pacote capturado em uma ou mais
interfaces de rede. (QUINTERO, 2014). Figura 2.5. (ROSANTE; BREGA, 2011)
Capítulo 2. Revisão da Literatura 32
Figura 5 – TCPdump
ROSANTE; BREGA, 2011
• Wireshark: É uma das ferramentas mais conhecidas no mundo, serve para aná-
lise de pacotes que trafegam na rede. Foi desenvolvida em 1998 e é compatível
com qualquer sistema operacional, possuindo uma interface gráfica, Figura 2.6.
(NDATINYA et al., 2015)
Figura 6 – Wireshark
NDATINYA et al., 2015
33
3 SOLUÇÃO PROPOSTA
Com a evolução das redes e a necessidade de topologias mais flexíveis e escalá-
veis, foram desenvolvidos equipamentos como bridges e switches. Estes equipamentos
comutadores eliminam o domínio único de colisão isolando suas portas, formando
assim, um domínio de colisão para cada interface. Para isso, o quadro recebido será
processado pelo equipamento e encaminhado à porta na qual o host de destino se
encontra, conforme sua tabela de comutação que é formada de forma automática e
dinâmica. Então, se um endereço de destino não consta na tabela de comutação, o
Switch repassa o quadro em todas as suas interfaces, dessa forma, para cada quadro
recebido será armazenado na tabela de comutação a porta em que o endereço físico
do remetente se encontra. (SCHWARZ et al., 2014)
Comutadores se tornaram muito importantes para desempenho da rede, sendo
eles a conexão central da rede local. Notamos então, que em redes de médio a grande
porte se faz necessário a utilização de muitos switches. Nestes casos é possível orga-
nizar estes equipamentos em diferentes topologias, afim de ter caminhos redundantes
para evitar falhas, expandir a rede, ter alta disponibilidade, realizar isolamentos na rede
e fazendo tudo isso sempre com auto desempenho. Porém, ao formar caminhos re-
dundantes irá formar loops entre switches, que são indesejados pois geram problemas
como alocação de todos os enlaces e o travamento da rede.
Estes problemas ocorrem pelo próprio funcionamento padrão dos equipamentos
e dos protocolos de rede, que mandam mensagens em broadcast gerando encaminha-
mentos das cópias do frame, passando de um switch para outro em um loop. Dessa
forma, os quadros percorrerão os switches de forma cíclica, multiplicando-se de forma
exponencial.
Capítulo 3. Solução Proposta 34
3.1 Broadcast
O broadcast causa processamento extra em uma rede. Em uma rede definida
por software o broadcast causa mais danos, um deles é gerar processamento no
controlador. Quando um pacote é enviado em broadcast, o controlador precisa criar
fluxos no switch para encaminhar esses pacotes. O ideal é minimizar a criação de
fluxos, para reduzir a carga de processamento no controlador. A Figura 3.1 e Figura
3.2 demonstram o funcionamento de uma conexão ARP em uma rede definida por
software. Cada requisição ARP gera o mesmo processo mostrado acima.
Figura 7 – Requisições arp geram novos fluxos
Próprio Autor
Capítulo 3. Solução Proposta 35
Figura 8 – Respostas arp geram mais fluxos
Próprio Autor
3.2 Modelo Openflow
Um modelo para SDN é o Openflow, que foi proposto na Universidade de
Stanford nos Estados Unidos (MCKEOWN, 2008). Ele foi a primeira proposta de
interface de comunicação entre as camadas de controle e de hardware.
Openflow usa informações contidas em cabeçalhos de protocolos de pacotes
recebidos para identificar fluxos de pacotes, e assim aplicar regras de encaminhamento
definidas estaticamente ou dinamicamente por um controlador. Figura 3.3.
Capítulo 3. Solução Proposta 36
Figura 9 – Modelo Openflow
O controlador pode residir em um outro equipamento, possibilitando o controle
centralizado da rede. Com isso o administrador de rede pode definir como os determi-
nados fluxos de pacotes devem ser encaminhados pelos equipamentos de rede. Esse
modelo possibilita realizar balanceamento de tráfego e tratar o problema com enlaces
redundantes de uma só vez. (ALVES JUNIOR; ALBINI; INFORMÁTICA, 2012).
Para isso, precisam-se identificar os determinados fluxos de pacotes e assumir
diferentes caminhos pelos switches, de forma a utilizar todos os recursos disponíveis e
evitar encaminhamentos cíclicos.
Atualmente, com o crescimento das redes, necessita-se de um controle da rede
muito mais eficaz e seguro. Portanto, nos cenários de médio a grande porte, a realização
de controle de tráfego é imprescindível. Dessa forma, tirando os gargalos da rede e
aproveitando os recursos físicos, com certeza resulta em um impacto muito positivo
para o desempenho da rede e consequentemente na produtividade da instituição.
De fato, o que nos impulsiona a tratar estas questões é ter acesso a um protocolo
que nos possibilita programar o funcionamento dos Switches. Sendo que, sem essa
possibilidade estamos limitados aos mecanismos disponibilizados pelos fabricantes
Capítulo 3. Solução Proposta 37
dos equipamentos, não havendo muito poder de controle e customização. Sendo assim,
Openflow/SDN possibilita desenvolver uma implementação de controle de rede para
fazer o devido controle de tráfego e otimização de recursos físicos. (COSTA, 2013).
Algumas topologias de nível de enlace são formadas com intenções de tornar
a rede tolerante a falhas, realizar balanceamento de carga, e evitar gargalos. No
entanto, ao configurar essas topologias com switches geralmente se formarão caminhos
fechados (loops), necessitando a utilização de mecanismos que evitam os problemas
de broadcast resultantes dos loops entre switches e bridges.
Em uma rede local, esse protocolo ARP tem por finalidade identificar o endereço
MAC da interface de rede de um equipamento que possui um determinado endereço IP.
Ele é necessário para que um host em uma rede local descubra o endereço MAC de
outro host com que precisa se comunicar e cujo endereço IP é conhecido. Assim, o
host de origem transmite uma mensagem ARP em broadcast, perguntando qual é o
endereço MAC do host que possui o endereço IP em questão. (OLIVEIRA; SHINODA;
SCHWEITZER, 2015)
3.3 Otimização do Broadcast
A proposta é modificar o controlador para manter uma tabela ARP com o mape-
amento do emderço IP com o MAC dos hosts. Populamos a tabela com informações
extraídas dos pacotes da camada de rede que passam pelo controlador. Os pacotes
da camada de rede contêm endereços IP de origem/destino, usados para formar a
tabela. A tabela é criada utilizando a estrutura de dados conhecida como dicionário, da
linguagem Python.
O funcionamento do módulo proposto é bem simples. Ao chegar um pacote
ARP request, o módulo verifica se o endereço IP de destino se encontra em sua tabela.
Caso o endereço IP se encontre na tabela, significa que o MAC corresponde ao IP que
Capítulo 3. Solução Proposta 38
também está na tabela, então uma função responsável por gerar uma mensagem ARP
response é chamada.
O controlador é responsável por tomar decisões e adicionar e/ou remover as
entradas na tabela de fluxos, de acordo com o objetivo desejado. Exerce a função
de uma camada de abstração da infraestrutura física, permitindo de forma mais fácil
a criação de aplicações e serviços que gerenciem as entradas de fluxos na rede. A
programação do controlador permite a evolução das tecnologias nos planos de dados
e as inovações na lógica das aplicações de controle.
O controlador possui métodos para criação de pacotes ARP. O pacote ARP
response criado possui o MAC de destino extraído da tabela. O índice do dicionário é o
endereço IP e, o valor é o endereço MAC.
Quando a requisição é para um endereço inexistente na tabela, ocorre broadcast
na rede. Uma entrada do tipo flood é criada na tabela do switch, para permitir que o
ARP request seja enviado para todos na rede, com exceção do host de origem.
Sem a proposta, uma requisição ARP sempre gera no mínimo duas mensagens
flowmod. Uma mensagem adiciona um fluxo para o ARP request, e outra adiciona um
fluxo para o ARP response.
Com a solução proposta serão geradas mensagens flow-mod apenas quando
o MAC de destino não estiver na tabela ARP mantida pelo controlador. Quando a
tabela ARP do controlador contiver o MAC requisitado, não será necessário adicionar
entradas na tabela do switch. O controlador receberá a requisição ARP e, responderá
usando uma mensagem flowout, sem precisar manipular a tabela do switch. Reduzindo
o número de mensagens flow-mod.
A Figura 3.4 mostra o funcionamento da proposta.
Capítulo 3. Solução Proposta 39
Figura 10 – Controlador responde requisições ARP
Próprio Autor
40
4 AVALIAÇÃO DA PROPOSTA
4.1 Ambiente de Testes
Para o ambiente emulado da solução proposta utilizou-se o Mininet (MORLING;
CAIN, 1975). Para realizar a avaliação do funcionamento da aplicação, emulou-se
utilizando duas topologias, uma Linear e outra em árvore, ambas conforme descritas
em detalhes adiante.
• Topologia Linear com 2 Switches: Como avaliação inicial, utiliza-se a topologia
mais simples disponível no emulador com dois switches. Os switches são co-
nectados diretamente e dois hosts são conectados cada um a um dos switches
Figura 4.1.
Figura 11 – Topologia Linear
Próprio Autor
• Topologia tree com três Níveis e Sete Switches: A topologia tree é um tipo de
topologia voltada para data centers. Realizou-se a avaliação de funcionamento
em uma topologia de três níveis com sete switches e oito hosts conectados de
acordo com a Figura 4.2.
Capítulo 4. Avaliação da Proposta 41
Figura 12 – Topologia Tree
Próprio Autor
Foi utilizado o controlador POX, por ser um sistema simples e normalmente
usado na academia. Podendo ser obtido em seu repositório oficial (POXREPO, 2013)
no github.
Neste trabalho foi usada a versão 2.0.0 em uma máquina virtual com 4GB de
memória RAM e suporte a virtualização por hardware.
Depois de estudar a estrutura interna do controlador, pode-se iniciar a realização
de modificações. Inicialmente apenas mudanças pequenas foram realizadas, mudanças
como alterar o conteúdo de mensagens exibidas na tela.
Um software bastante útil é o Wireshark (OREBAUGH; RAMIREZ; BEALE,
2006), com ele pode-se visualizar as mensagens do protocolo Openflow em tempo de
execução.
Capítulo 4. Avaliação da Proposta 42
4.2 Coleta de Dados
Switches Openflow possuem um campo em sua tabela para armazenar estatísti-
cas sobre fluxos. O controlador é capaz de enviar requisições para o switch, solicitando
estatísticas dos fluxos.
Durante os experimentos foi utilizado um módulo POX responsável pela captura
de estatísticas. Algumas modificações no módulo de estatísticas foram necessárias,
para adequá-lo aos experimentos. Há ferramentas como o dpctl, que permitem visualizar
a tabela do switch.
Com o dpctl daria para capturar os fluxos apenas no final dos experimentos. A
Tabela é atualizada constantemente, o que motivou o uso do flow-stats, por possibilitar
intervalos entre execuções, permitindo executar o flow-stats seguidas vezes durante
o experimento. Quanto as mensagens flow-mod, o software usado foi o Wireshark
(OREBAUGH; RAMIREZ; BEALE, 2006). O TCPdump (FUENTES; KAR, 2005) foi
utilizado para capturar os pacotes, e o Wireshark para analisa-los.
Durante a execução desta pesquisa, a falta de hardware com Openflow habilitado
representou um grande desafio. Para contornar a falta de switch Openflow, foram
levantadas algumas alternativas. A melhor opção seria realizar os experimentos no
Future Internet Testbed with Security (FITS)(NUNES; PONTES; GUEDES, ). No FITS
seria possível realizar os testes com máquinas geograficamente distantes, como ilustra
a Figura 4.3. (BIAłEK, 2011). Devido as circunstâncias, não foi possível realizar esta
verificação.
Capítulo 4. Avaliação da Proposta 43
Figura 13 – FITS autonomous island interconnection architecture
FITS Project
44
5 ANÁLISE DOS RESULTADOS
As primeiras amostras de um experimento geralmente configuram a fase de
estabilização, enquanto as últimas são a fase de desestabilização. Foram descartados
as 5 primeiras e últimas medições de cada experimento, foi usado esse valor após a
observação de que os primeiros resultados eram bastante dispersos. Foi calculada a
média aritmética de cada experimento, a fim de encontrar a tendência central de cada
experimento, para compara-los. O desvio padrão foi calculado para estipular o quanto
as medidas se distanciaram da média. A margem de erro e intervalo de confiança foram
calculados para identificar quais valores poderiam ser considerados corretos. Um nível
de confiança de 95% foi estipulado.
Primeiramente foi realizado o levantamento dos dados utilizando a topologia
Linear do Mininet, utilizando 2 switches e 4 hosts Figura 4.1, sem uso do modulo
proposto, onde foi calculado a média de entradas de fluxos na tabela.
Tabela 1 – Topologia Linear Padrão
Topologia Linear Padrão (quantidade)
Média 16,388
Desvio-Padrão 1,603
Margem-de-erro 0,388
Intervalo-de-confiança 16.000 e 16.776
Capítulo 5. Análise dos Resultados 45
Figura 14 – Gráfico Topologia Linear Padrão
Realizamos o mesmo levantamento dos dados utilizando a topologia Linear do
Mininet com o uso do modulo proposto, onde foi calculado a média de entradas de
fluxos na tabela.
Tabela 2 – Topologia Linear Proposta
Topologia Linear Proposta(Quantidade)
Média 14,388
Desvio-Padrão 1,603
Margem-de-erro 0,388
Intervalo-de-Confiança 14.000 e 14.776
Capítulo 5. Análise dos Resultados 46
Figura 15 – Gráfico Topologia Linear Proposta
Por fim, comparamos os gráficos da topologia Linear padrão com a Topologia
Linear utilizando o modulo proposto. No gráfico da Figura 5.3, podemos observar
que fazendo uso da proposta deste trabalho, podemos diminuir consideralvelmente a
quantidade de entradas na tabela de fluxo.
Tabela 3 – Topologia Linear Comparativo
Topologia Linear Padrão (quantidade Proposta (quantidade)
Média 16,388 14,388
Desvio-Padrão 1,603 1,603
Margem-de-erro 0,388 0,388
Intervalo-de-confiança 16.000 e 16.776 14.000 e 14.776
Capítulo 5. Análise dos Resultados 47
Figura 16 – Grafico comparativo Topologia Linear
Os mesmos experimentos foram realizados utilizando a topologia em Árvore,
utilizando 7 switches e 8 hosts Figura 4.2. Os testes foram realizados nessa topologia
sem uso do modulo proposto, onde foi calculado a média de entradas de fluxos na
tabela.
Tabela 4 – Topologia Tree Padrão
Topologia Tree Padrão (quantidade)
Média 25,187
Desvio-Padrão 1,703
Margem-de-erro 0,439
Intervalo-de-confiança 24.748 e 25.626
Capítulo 5. Análise dos Resultados 48
Figura 17 – Gráfico Topologia Tree Padrão
Quando utilizamos o modulo proposto, principalmente nesta topologia, notamos
uma grande redução no número de entradas de fluxo na tabela em compração ao uso
da topologia padrão sem os recurso do modulo proposto.
Tabela 5 – Topologia Tree Proposta
Topologia Tree Proposta (quantidade)
Média 17,125
Desvio-Padrão 1,111
Margem-de-erro 0,286
Intervalo-de-confiança 16.839 e 17,411
Capítulo 5. Análise dos Resultados 49
Figura 18 – Gráfico Topologia Tree Proposta
Comparando os gráficos da topologia Tree padrão com a Topologia Tree utili-
zando o modulo proposto, podemos verificar uma grande diferença na quantidade de
fluxo de entrada na tabela entre as duas propostas.
Tabela 6 – opologia Tree Comparativo (flow-mod)
Topologia Tree Padrão (quantidade) Proposta (quantidade)
Média 25,187 17,125
Desvio-Padrão 1,703 1,111
Margem-de-erro 0,439 0,286
Intervalo-de-confiança 24.748 e 25.626 16.839 e 17,411
Capítulo 5. Análise dos Resultados 50
Figura 19 – Grafico comparativo Topologia Tree
Na execução dos experimentos foi usada uma opção do emulador especifica
para realização de testes. Com o parâmetro –test o Mininet cria uma rede, executa o
experimento, e “para” a rede.
O parâmetro –test pode receber como valor iperf, pingall, etc. O valor do pa-
râmetro –test define qual teste será realizado na rede. Testes usando pingall foram
usados na construção das tabelas dos switches e para gerar mensagens flow-mod.
Mensagens do tipo flow-mod são utilizadas para gerenciar a tabela do switch. Com uma
mensagem flow-mod o controlador pode adicionar, alterar ou remover uma entrada na
tabela. Com o pingall as máquinas pingarão umas às outras.
Tabela 7 – Topologia Linear Padrão (flow-mod)
Topologia Linear Padrão (quantidade)
Média 96
Capítulo 5. Análise dos Resultados 51
Figura 20 – Gráfico Topologia Linear Padrão (flow-mod)
Tabela 8 – Topologia Linear Proposta (fow-mod)
Topologia Linear Proposta (quantidade)
Média 75
Capítulo 5. Análise dos Resultados 52
Figura 21 – Gráfico Topologia Linear Proposta (flow-mod)
As metas são a redução do número de entradas na tabela do switch e o número
de mensagens flow-mod geradas. Com a redução de entradas na tabela do switch, um
número maior de entradas poderão ser criadas, sem haver necessidade de adicionar
mais memória.
Tabela 9 – Topologia Linear Comparativo
Topologia Linear Padrão(quantidade)
Proposta(quantidade)
Média 96 75
Capítulo 5. Análise dos Resultados 53
Figura 22 – Gráfico Topologia Linear Comparativo (flow-mod)
Reduzindo o número de mensagens flow-mod, há uma redução da carga de
trabalho do controlador. Reduzindo a carga de trabalho do controlador, abre-se espaço
para adição de mais máquinas a rede.
Tabela 10 – Topologia Tree Padrão (flow-mod)
Topologia Tree Padrão (quantidade)
Média 122
Capítulo 5. Análise dos Resultados 54
Figura 23 – Gráfico Topologia Tree Padrão (flow-mod)
Tabela 11 – Topologia tree Proposta (flow-mod)
Topologia Tree Proposta (quantidade
Média 86
Capítulo 5. Análise dos Resultados 55
Figura 24 – Gráfico Topologia Tree Proposta (flow-mod)
Na construção da tabela do switch os dois módulos apresentam variação nos
valores obtidos. O módulo padrão gera uma quantidade superior. Mesmo considerando
o valor mais alto do módulo proposto com o mais baixo do módulo padrão, o proposto
obtêm valores menores.
Tabela 12 – Topologia tree Comparativo (flow-mod)
Topologia Tree Padrão (quantidade) Proposta (quantidade)
Média 122 86
Capítulo 5. Análise dos Resultados 56
Figura 25 – Gráfico Topologia Tree Comparativo (flow-mod)
Não há variação quanto a quantidade de mensagens flow-mod, em ambos os
módulos.
Não há desvio padrão, margem de erro e intervalo de confiança.
57
6 CONCLUSÃO E TRABALHOS FUTUROS
A consolidação do paradigma de Redes Definidas por Software vem mudando a
forma de gerenciar e projetar as redes de computadores, permitindo que elas possam
evoluir e melhorar mais rapidamente em relação ao que ocorre atualmente. Dessa
forma, com SDN foi possível criar um ambiente de teste para estudar temas com
importante papel nas redes de computadores.
Em SDN o controlador pode se tornar o gargalo da rede. Com o barateamento e
aumento do poder computacional dos switches, o hardware normalmente não repre-
senta um grande problema. Nas redes tradicionais o broadcast é um problema, e se
estende a SDN.
O OpenFlow tem a capacidade de fornecer aos pesquisadores um ambiente
de testes em uma rede como a rede local de nossas Universidades. Assim ele abre
as portas para que os pesquisadores possam testar suas inovações e garantir que
seus experimentos sejam testados em um ambiente suficientemente semelhante ao de
uma rede real qualquer, conseguindo assim, ganhar a confiança para uma implantação
generalizada.
Através deste trabalho buscou-se apresentar inicialmente um breve contexto
das redes de computadores, ficando evidenciado que a atual arquitetura das Redes é
pouco flexível, pois mesmo que tenha sofrido algumas modificações nos últimos anos,
estas não foram suficientes para atender as demandas de novas aplicações que cada
vez mais vem sendo inseridas no contexto tecnológico.
Ainda, o presente trabalho buscou apresentar os principais conceitos sobre
Redes Definidas por Software, como por exemplo, os vários aspectos que envolvem o
protocolo OpenFlow, o controlador da rede, sendo utilizado o POX, o qual foi especial-
mente desenvolvido para o ensino e pesquisa das SDNs.
Por fim, através do simulador SDN MiniNet juntamente com a utilização dos
Capítulo 6. Conclusão e Trabalhos Futuros 58
recursos oferecidos pelo controlador POX, foi realizada a implementação e a simulação
dos cenários.
Com a redução do broadcast gerado por mensagens ARP request, foram alcan-
çadas redução nas mensagens geradas pelo controlador e redução da quantidade de
entradas na tabela do switch. Com a utilização do módulo proposto houve uma redução
de mensagens flow-mod e das entradas na tabela de fluxos. A redução do broadcast
ARP em rede SDN auxilia na redução da carga de mensagens geradas no plano de
controle.
Em suma, apesar do paradigma ser recente, considerando o presente sucesso
das SDNs, acredita-se que esta nova tecnologia realmente irá trazer muitos avanços
para o desenvolvimento de novos serviços, aplicações e soluções para a área de redes
de computadores como um todo.
Muitos são os desafios de pesquisa. Como sugestão para trabalhos futuros
sugerimos:
• Adicionar um modulo automatizado para entrada de fluxo gerada nas tabelas,
não sendo necessário a inclusão manual dod dados na tabela ARP;
• Adicionar um timeout a cada entrada da tabela ARP: Adicionar um tempo de
permanência de cada entrada na tabela. Após o esgotamento desse tempo, a
entrada deve ser removida da tabela.
• Testar a solução em ambiente real de produção, para verificar as métricas
alcançadas;
• Procurar explorar melhor a visão global da rede, oferecida pelo controlador.
Conhecer a rede como um todo, provavelmente ajudará na manutenção da
tabela. Implementar características que tornem a solução inteligente.
Como sugestão de trabalhos futuros, pode-se citar o desenvolvimento e a imple-
mentação de mais cenários, a integração com Ambientes Virtuais de Aprendizagem,
Capítulo 6. Conclusão e Trabalhos Futuros 59
a realização de testes em equipamentos físicos em uma rede real sem afetar o trá-
fego em produção, a utilização e o estudo dessa nova tecnologia em cursos de redes
de computadores, expandindo o paradigma SDN, dessa maneira agregando novos
conhecimentos, contribuindo tanto na formação técnica quanto na científica de seus
entusiastas.
Em suma, apesar do paradigma ser recente, considerando o presente sucesso
das SDNs, acredita-se que esta nova tecnologia realmente irá trazer muitos avanços
para o desenvolvimento de novos serviços, aplicações e soluções para a área de redes
de computadores como um todo.
60
REFERÊNCIAS
ALVES JUNIOR, J.; ALBINI, L. C. P.; INFORMÁTICA, U. F. do Paraná. Setor de CienciasExatas. Programa de Pós-Graduaçao em. Um protocolo de roteamento resistente aataques Blackhole sem detecção de nós maliciosos. 2012. Dissertação (Mestrado).Disponível em: <http://dspace.c3sl.ufpr.br:8080/dspace/handle/1884/27759>.
AMILTON JUNIOR. Sniffer – Entenda como funciona. 2010. Disponível em:<http://dicasemgeral.xpg.uol.com.br/dicas-em-geral/12471/sniffer-entenda-como-funciona/>. Acesso em: 14/08/2016.
ARAÚJO, M. Uma Abordagem para Aprovisionamento de QoS em Redes Definidas porSoftware baseadas em OpenFlow. 2013. Disponível em: <https://onedrive.live.com/view.aspx?cid=5AE8B415C3832C39&resid=5ae8b415c3832c39!354&app=WordPdf>.Acesso em: 06/07/2016.
BIAłEK, M. Conservative treatment of idiopathic scoliosis according to FITSconcept: presentation of the method and preliminary, short term radiologicaland clinical results based on SOSORT and SRS criteria. Scoliosis, BioMedCentral, v. 6, p. 25 – None, 2011. ISSN 1748-7161. Disponível em: <https://www.ncbi.nlm.nih.gov/pmc/articles/PMC3286410/>.
CEARLEY, D. SDN é uma das 4 tendências que transformarão a TI em 5 Anos, AfirmaGartner. 2014. Disponível em: <http://www.dbserver.com.br/DbOnline_Details.aspx/3240/sdn--uma-das-4-tendncias-que-transformaro-a-ti-em-5-anos-afirma-gartner>.Acesso em: 04/07/2016.
CESTAROLLI, M. Soluções de ERP open source para 2015. 2015. Disponível em:<http://erp1.com.br/2015/03/solucoes-de-erp-open-source-para-2015/>.
CHARPINEL JUNIOR, S. R. Alocação Dinâmica de Circuitos Virtuais usando DRAGON:Uma Proposta de Interoperabilidade com Comutadores OpenFlow. 2012. 59 p.Monografia (Ciência da Computação) — UNIVERSIDADE FEDERAL DO ESPÍRITOSANTO.
CISCO. Evolved Programmable Network. 2015. Disponível em: <http://www.cisco.com/web/BR/solucoes/sp/network_infrastructure/index.html>. Acesso em: 18/08/2016.
COSTA, D. A. da et al. Avaliação da contribuição de desenvolvedores para projetos desoftware usando mineração de repositórios de software e mineração de processos.2013. Dissertação (Mestrado) — Universidade Federal do Rio Grande do Norte.Disponível em: <http://repositorio.ufrn.br:8080/jspui/handle/123456789/18082>.
COSTA, L. R. OpenFlow e o paradigma de redes definidas por software. 2013. 143 p.Monografia ((Licenciatura em Ciência da Computação)) — Universidade de Brasília.
DUQUE, D. H. Redes Definidas por Software. 2012. Disponível em: <http://br.monografias.com/trabalhos3/redes-definidas-software/redes-definidas-software2.shtml>. Acesso em: 26/08/2016.
Referências 61
FALSARELLA, D. SDN (Software Defined Networking) e o futuro das redes. 2012.Disponível em: <http://imasters.com.br/tecnologia/redes-e-servidores/sdn-software-defined-networking-e-o-futuro-das-redes/>. Acesso em: 22/08/2016.
HP COMPANY. OpenFlow : tecnologia de capacitação para redes definidas por software.2015. Disponível em: <http://h17007.www1.hp.com/br/pt/solutions/technology/openflow/index.aspx>. Acesso em: 17/08/2016.
KAUR, K.; SINGH, J.; GHUMMAN, N. S. Mininet as Software Defined NetworkingTesting Platform. International Conference on Communication, Computin g & Systems(ICCCS–2014), n. 4, 2014.
LOPES, Y. Tecnologia SDN promove o fim da escuridão na Rede de Comunicação.2015. Disponível em: <http://www3.selinc.com.br/news/?p=1259>. Acesso em:17/08/2016.
MARCO AURÉLIO MAIA. O que é Segurança da informação. 2013. Disponível em:<http://segurancadainformacao.modulo.com.br/seguranca-da-informacao>.
MCKEOWN, N. OpenFlow: Enabling Innovation in Campus Networks. Março 2008.
MUSSI, S. S. et al. Diferenciação de fluxos sem manutenção de estados em roteadores.2011. Dissertação (Mestrado) — Universidade Federal do Espírito Santo. Disponível em:<http://www.bdtd.ufes.br/tedesimplificado/tde_busca/arquivo.php?codArquivo=1603>.
NDATINYA, V. et al. Network forensics analysis using Wireshark. IJSN, v. 10, n. 2, p. 91– 106, 2015. Disponível em: <http://dx.doi.org/10.1504/IJSN.2015.070421>.
OLIVEIRA, R. L. S. de U.; SHINODA, A. A. U.; SCHWEITZER, C. M. U. L3-arpsec -módulo seguro para controle e proteção do protocolo de resolução de endereços emredes definidas por software. 2015. Dissertação (Mestrado) — Universidade EstadualPaulista (UNESP). Disponível em: <http://hdl.handle.net/11449/128103>.
OPEN VSWITCH. Production Quality, Multilayer Open Virtual Switch. 2014. Disponívelem: <http://www.openvswitch.org/>. Acesso em: 17/08/2016.
OPENWRT. OpenWrt Wireless Freedom. 2015. Disponível em: <https://openwrt.org>.Acesso em: 17/08/2016.
PEREIRA, P. Como usar o TCPDump. 2011. Disponível em: <http://www.pedropereira.net/como-usar-o-tcpdump/>. Acesso em: 17/08/2016.
QUINTERO, D. SDN (Software Defined Networking) e o futuro das redes. 2014.Disponível em: <https://www.ibm.com/developerworks/community/blogs/fd26864d-cb41-49cf-b719-d89c6b072893/entry/sdn_software_defined_networkingeofuturo_das_redes?lang=en>. Acesso em: 18/08/2016.
RIBEIRO, V. P. de A. et al. Classificação de tráfego online baseada em sub-fluxos. 2011.Dissertação (Mestrado) — Universidade de Fortaleza. Disponível em: <https://uolp.unifor.br/oul/ObraBdtdSiteTrazer.do?method=trazer&ns=true&obraCodigo=88170>.
RODRÍGUEZ, F. L. Arquitetura e Protótipo uma Rede SDN-Openflow para Provedorde Serviço. 2014. Disponível em: <http://repositorio.unb.br/bitstream/10482/16030/1/2014_FernandoLopezRodrigues.pdf>. Acesso em: 06/07/2016.
Referências 62
RODRÍGUEZ, F. L.; CAMPELO, D. R. de S. Arquitetura e protótipo de uma redeSDN-OpenFlow para provedor de serviço. 2014. Dissertação (Mestrado). Disponívelem: <http://repositorio.unb.br/handle/10482/16030>.
ROSANTE, J. C. U.; BREGA, J. R. F. U. Proposta de uma ferramenta de visualização erealidade virtual para o monitoramento de tráfego de redes de computadores. 2011.Dissertação (Mestrado) — Universidade Estadual Paulista (UNESP). Disponível em:<http://hdl.handle.net/11449/98695>.
SAKATO, M.; O’DONNELL, M.; HINGORANI, M. M. A Central Swivel Point in theRFC Clamp Loader Controls PCNA Opening and Loading on DNA. Journal ofMolecular Biology, v. 416, n. 2, p. 163 – 175, 2 2012. ISSN 0022-2836. Disponível em:<https://www.ncbi.nlm.nih.gov/pmc/articles/PMC3269524/>.
SCHWARZ, M. F. et al. Mecanismo para integração de comutadores openflow nainfraestrutura do testbed emulab. 2014. Dissertação (Mestrado) — Universidade deSão Paulo. Disponível em: <http://www.teses.usp.br/teses/disponiveis/3/3141/tde-19032015-164205/>.
SISWANTO, D. F.; KARIMAH, S. A. Experiment with custom Mininet Topology tosimulate network topology. 1st SDNRG ITB Meetup, Novembro 2014. Acesso em:26/08/2016.
63
APÊNDICES
64
APÊNDICE A – CÓDIGO DE OBTENÇÃO DAS ESTATÍSTICAS
DOS FLUXOS OPENFLOW
#
#
#!/usr/bin/python
# Copyright 2012 William Yu
# [email protected]
#
# This file is part of POX.
#
# POX is free software: you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation, either version 3 of the License, or
# (at your option) any later version.
#
# POX is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with POX. If not, see <http://www.gnu.org/licenses/>.
#
APÊNDICE A. Código de Obtenção das Estatísticas dos Fluxos Openflow 65
“”“
This is a demonstration file created to show how to obtain flow
and port statistics from OpenFlow 1.0-enabled switches. The flow
statistics handler contains a summary of web-only traffic.
“”“
# standard includes
from pox.core import core
from pox.lib.util import dpidToStr
import pox.openflow.libopenflow_01 as of
#
# include as part of the betta branch
from pox.openflow.of_json import *
log = core.getLogger()
#
# handler for timer function that sends the requests to all the
# switches connected to the controller.
def _timer_func ():
for connection in core.openflow._connections.values():
connection.send(of.ofp_stats_request(body=of.ofp_flow_stats_request()))
connection.send(of.ofp_stats_request(body=of.ofp_port_stats_request()))
log.debug(“Sent %i flow/port stats request(s)”, len(core.openflow._connections))
#
# handler to display flow statistics received in JSON format
# structure of event.stats is defined by ofp_flow_stats()
APÊNDICE A. Código de Obtenção das Estatísticas dos Fluxos Openflow 66
def _handle_flowstats_received (event):
stats = flow_stats_to_list(event.stats)
log.debug(“FlowStatsReceived from %s: %s”,
dpidToStr(event.connection.dpid), stats)
#
# Get number of bytes/packets in flows for web traffic only
tbytes = 0
tflows = 0
tpacket = 0
for f in event.stats:
tbytes += f.byte_count
tpacket += f.packet_count
tflows += 1
print(“Bytes %s – Pacotes %s – Fluxos %s” %(tbytes, tpacket, tflows))
#
# handler to display port statistics received in JSON format
def _handle_portstats_received (event):
stats = flow_stats_to_list(event.stats)
log.debug(“PortStatsReceived from %s: %s”,
dpidToStr(event.connection.dpid), stats)
#
# main functiont to launch the module
def launch ():
from pox.lib.recoco import Timer
APÊNDICE A. Código de Obtenção das Estatísticas dos Fluxos Openflow 67
#
# attach handsers to listners
core.openflow.addListenerByName(“FlowStatsReceived”,
_handle_flowstats_received)
core.openflow.addListenerByName(“PortStatsReceived”,
_handle_portstats_received)
#
# timer set to execute every one seconds
Timer(1, _timer_func, recurring=True)
top related