PONTIFÍCIA UNIVERSIDADE CATÓLICA DO PARANÁ ESCOLA POLITECNICA CURSO DE ENGENHARIA ELÉTRICA ÊNFASE EM TELECOMUNICAÇÕES CLECIO DA SILVA NASCIMENTO

Transcrição

1 PONTIFÍCIA UNIVERSIDADE CATÓLICA DO PARANÁ ESCOLA POLITECNICA CURSO DE ENGENHARIA ELÉTRICA ÊNFASE EM TELECOMUNICAÇÕES CLECIO DA SILVA NASCIMENTO REDES DEFINIDAS POR SOFTWARE: OPENFLOW CURITIBA 2013

2 CLECIO DA SILVA NASCIMENTO REDES DEFINIDAS POR SOFTWARE: OPENFLOW Trabalho de Conclusão de Curso Engenharia Elétrica ênfase em Telecomunicações da Pontifícia Universidade Católica do Paraná, como requisito parcial à obtenção do título de Engenheiro em Telecomunicações. Orientador: Prof. Dr. Edgard Jamhour CURITIBA 2013

3 CLECIO DA SILVA NASCIMENTO REDES DEFINIDAS POR SOFTWARE: OPENFLOW Trabalho de Conclusão de Curso Engenharia Elétrica ênfase em Telecomunicações da Pontifícia Universidade Católica do Paraná, como requisito parcial à obtenção do título de Engenheiro em Telecomunicações. COMISSÃO EXAMINADORA Prof. Dr. Edgard Jamhour PUCPR Prof. Dr. James Alexandre Baraniuk PUCPR Cidade, de de 2013.

4 RESUMO O alto custo de equipamentos fechados proprietários compõe a infraestrutura das redes de pacotes atual, onde as arquiteturas básicas são originadas a partir da combinação de circuitos dedicados a alto desempenho no processamento de pacotes, ou seja, circuitos integrados de aplicação específica. Um software de controle é responsável pela lista de protocolos que complementa a infraestrutura, logo qualquer alteração lógica de controle, tratamento dos pacotes e introduzir novas funcionalidades é ação restrita do fabricante do equipamento, que gera um processo moroso e custoso. A falta de controle do funcionamento interno dos equipamentos, além de barrar a evolução das arquiteturas, inovação de novos serviços e aplicações de rede gera um alto custo de infraestrutura. Iniciando o conceito de redes definidas por software a tecnologia OpenFlow torna possível o controle remoto dos equipamentos de rede voltado totalmente para a arquitetura de roteamento, RouteFlow, que é aplicável em equipamentos comerciais, utilizando software livre para controle das funções aplicadas. Palavras-chave: Software livre. Virtualização. Rede de pacotes.

5 ABSTRACT The high cost of equipment proprietary closed network infrastructure comprises the current packet, where the starting basic architectures are derived from a combination of dedicated circuits to high performance packet processing, or application specific integrated circuits. Control software is responsible for the protocol list that complements the infrastructure, so any change control logic, handling packages and introduce new features action is restricted equipment manufacturer, which generates a time-consuming and costly process. The lack of control of the internal operation of the equipment, and to stop the development of architectures, innovation of new services and applications network generates a high cost of infrastructure. Starting the concept of software defined networks OpenFlow technology makes possible the remote network equipment geared totally to the routing architecture, RouteFlow, which is applicable in commercial equipment, using free software for control of functions applied. Key-words: Free software. Virtualization. Packet network.

6 LISTA DE ILUSTRAÇÕES Figura 1 Arquitetura de Roteadores: modelo atual mainframe e modelo programável OpenFlow Figura 2 Exemplo de uma rede com OpenFlow habilitado Figura 3 Cabeçalhos disponíveis no OpenFlow para a especificação de fluxo Figura 4 Elementos de uma rede OpenFlow Figura 5 Modelo de operação híbrido com VLANs isolando tráfego legado e OpenFlow Figura 6 Diagrama do tratamento de um pacote no pipeline de um switch OpenFlow Figura 7 Rede com switch, TDM, WDM e roteadores IP controlados por openflow Figura 8 Cenário OpenFlow Tutorial a ser trabalhado Figura 9 Cenário OpenFlow Tutorial a ser trabalhado Figura 10 Wireshark capturando mensagens Echo Reply/ Echo Request Fonte:Wireshark dissecador, Figura 11 Wireshark capturando mensagens Hello Fonte:Wireshark dissecador, Figura 12 Wireshark capturando mensagens Feature Request Fonte:Wireshark dissecador, Figura 13 Wireshark capturando mensagens Set Config Fonte:Wireshark dissecador, Figura 14 Wireshark capturando mensagens Feature Reply Fonte:Wireshark dissecador, Figura 15 Wireshark capturando mensagens Packet In Fonte:Wireshark dissecador, Figura 16 Wireshark capturando mensagens Packet out Fonte:Wireshark dissecador, Figura 17 Wireshark capturando mensagens Port Status Figura 18 Wireshark capturando mensagens ARP, ICMP e OFP

7 LISTA DE TABELAS Tabela 1 Mensagens Openflow Tabela 2 Mensagens Openflow para ping... 30

8 LISTA DE ABREVIATURAS E SIGLAS APIs PUCPR SNMP CLI GENI NetFPGA SSL TCP SSL VLAN ASICs FPGAs Dpctl Application Programming Interface Pontifícia Universidade Católica do Paraná Simple Network Management Protocol command-line interface Global Environment for Network Innovations Net Field-Programmable Gate Array Secure Socket Layer Transmission Control Protocol Secure Socket Layer Virtual Local Area Network Application-specific integrated circuit Field-programmable gate array administer OpenFlow datapaths

9 SUMÁRIO 1 INTRODUÇÃO OPENFLOW TABELA DE FLUXOS CANAL SEGURO PROTOCOLO OPENFLOW CONTROLADOR FUNCIONAMENTO OPENFLOW Mercado PROBLEMATIZAÇÃO OBJETIVOS OBJETIVO GERAL OBJETIVOS ESPECÍFICOS FERRAMENTAS DE DESENVOLVIMENTO CENÁRIO REDE OPENFLOW MININET WIRESHARK UTILITARIO DPTL CONTROLADOR COM O IPERF ANÁLISE DOS RESULTADOS CONSIDERAÇÕES FINAIS REFERÊNCIAS... 38

10 9 1 INTRODUÇÃO A arquitetura em camadas e os protocolos do modelo TCP/IP tornaram a evolução da internet possível com uma grande penetração e aplicações diversas, logo a internet se tornou comercial onde os equipamentos de rede são as famosas caixas pretas, com implementações integradas verticalmente com software fechado sobre harware proprietário. Em redes definidas por software se caracteriza por um plano de controle distribuído o qual os avanços na padronização de APIs sejam totalmente independentes de qualquer fabricante. Permitindo remover a maior parte da lógica aplicada na tomada de decisão aos dispositivos de rede para controladores externos, similar a servidores comerciais PCs, por ser mais barato, escalável e recurso de fácil acesso. Arquitetura de roteamento atual é composta basicamente de duas camadas distintas, conforme modelo atual (Figura 1), software de controle, o qual é encarregado de tomar decisões de roteamento que transfere essas decisões para um plano de encaminhamento através de uma API proprietária e hardware dedicado ao encaminhamento de pacotes. As funcionalidades programadas pelo fabricante limita o uso dos dispositivos por intermédio de uma única interação da gerencia que ocorre através de interfaces WEB, SNMP e CLI. Figura 1 Arquitetura de Roteadores: modelo atual mainframe e modelo programável OpenFlow. Fonte: Cad. CPqD Tecnologia, 2011.

11 10 Sabendo que as duas camadas de roteamento não precisa esta fechada no mesmo equipamento, alinhando uma forma de se programar o dispositivo de rede remotamente, a camada de controle pode ser movida para um servidor dedicado central com alta capacidade de processamento. Logo a flexibilidade de se inserir, remover e dedicar uma aplicação de software por meio de um protocolo aberto para programar um equipamento e proporcionar um alto desempenho no encaminhamento de pacotes em hardware, é a definição mais concisa do software OpenFlow. 2 OPENFLOW Protocolo proposto pela Universidade de Stanford para validação de novas arquiteturas e protocolos de rede em equipamentos comerciais define um protocolo padrão para determinar as ações de encaminhamento de pacotes em dispositivos de redes, ou seja, toda a ação e regras instaladas no hardware de rede são repassadas para um elemento externo, o controlador, que pode ser implementado em um servidor comum, conforme a figura 2. Figura 2 Exemplo de uma rede com OpenFlow habilitado. Fonte: Cad. CPqD Tecnologia, 2011

12 11 O conceito de fluxo especifica o OpenFlow melhor, onde é constituído pela combinação de campos do cabeçalho do pacote a ser processado pelo dispositivo, as camadas de enlace, de rede ou de transporte, seguindo o modelo TCP/IP. A exposição dos recursos do hardware permite a concatenação de várias tabelas, por exemplo, IP/Ethernet/MPLS, OpenFlow é a generalização do plano de dados, assim qualquer modelo de encaminhamento de dados baseado em combinação de valores para tomada de decisão nos campos de cabeçalho dos pacotes pode ser suportado (Figura 3). O OpenFlow reutiliza as funcionalidades do hardware existente através da definição de conjunto de regras e de ações associadas de encaminhar, descartar, enviar para o controlador e reescrever campos do cabeçalho. Figura 3 Cabeçalhos disponíveis no OpenFlow para a especificação de fluxo. Fonte: Cad. CPqD Tecnologia, Uma rede programável como OpenFlow, os equipamentos de rede são ativados para que o estado das tabelas de fluxo seja implementado por um meio seguro de acordo com a decisão do controlador em software. Regras, ações e contadores forma cada entrada de uma tabela de fluxo, as regras tem como base na definição do valor de um ou mais campos no cabeçalho, que por sua vez associa-se a um conjunto de ações que determina como os dados devem ser processados e seu encaminhamento. Para remover fluxos desativados e manter estatísticas de uso, são utilizados os contadores, logo podem ser interpretadas como decisões em cache do plano de controle as entradas da tabela de fluxo, que por sua vez é a mínima unidade de informação no plano de controle. Uma rede programável consiste em equipamentos de rede habilitados para que o estado das tabelas de fluxos possa ser instalado através de um canal seguro, conforme as decisões de um controlador em software.

13 TABELA DE FLUXOS Cada entrada na tabela de fluxos do hardware de rede consiste em regra, ações e contadores. A regra é formada com base na definição do valor de um ou mais campos do cabeçalho do pacote, que se associa a um conjunto de ações que definem o modo como os pacotes devem ser processados e para onde devem ser encaminhados, logo os contadores são utilizados para manter estatísticas de utilização e para remover fluxos inativos. As entradas da tabela de fluxos podem ser interpretadas como decisões em cache (hardware) do plano de controle (software), sendo a mínima unidade de informação no plano de dados da rede. 2.2 CANAL SEGURO Para que a rede não sofra ataques, o canal seguro serve para garantir a confiabilidade na troca de informações entre o switch e o controlador. A interface de acesso recomendada é o protocolo SSL (Secure Socket Layer). Interfaces alternativas (passivas ou ativas) incluem TCP e pcap (packet capture), e são especialmente úteis em ambientes virtuais e experimentais pela simplicidade de utilização, pois não necessitam de chaves criptográficas. 2.3 PROTOCOLO OPENFLOW Protocolo aberto para comunicação que usa uma interface externa, definida pelo OpenFlow para a troca de mensagens entre os equipamentos de rede e os controladores. Essas mensagens podem ser simétricas, assíncronas ou, ainda, iniciadas pelo controlador. 2.4 CONTROLADOR É o software responsável por tomar decisões e adicionar e remover as entradas na tabela de fluxos, de acordo com o objetivo desejado. O controlador exerce a função de uma camada de abstração da infraestrutura física, facilitando a criação de aplicações e serviços que gerenciem as entradas de fluxos na rede e funcionalidade reutilizável. Dessa forma, o controlador OpenFlow atua como um sistema operacional (SO) para gerenciamento e controle das redes, e

14 13 oferece uma plataforma com base na reutilização de componentes e na definição como comandos da API. Novas aplicações de rede podem ser desenvolvidas rapidamente através de um controlador que permite a evolução em paralelo das tecnologias nos planos de dados e as inovações na lógica das aplicações de controle. A Figura 4 mostra uma rede com OpenFlow e o controlador NOX executando inúmeras aplicações que necessitam de uma visão do estado da rede. Essa visão pode ser armazenada, por exemplo, em um simples banco de dados executado localmente ou em um servidor remoto. Figura 4 Elementos de uma rede OpenFlow. Fonte: Cad. CPqD Tecnologia, FUNCIONAMENTO OPENFLOW Um pacote chega a um equipamento com OpenFlow habilitado, os cabeçalhos do pacote são comparados às regras das entradas das tabelas de fluxos, os contadores são atualizados e as ações correspondentes são realizadas. Se não houver correspondência entre o pacote e alguma entrada da tabela de fluxos, o pacote é encaminhado, por completo, ao controlador. Apenas o cabeçalho é encaminhado ao controlador mantendo o pacote armazenado no buffer do hardware. Os pacotes que chegam ao controlador correspondem ao primeiro pacote de um novo fluxo, o controlador pode optar por instalar uma regra no switch para que todos os pacotes de determinado fluxo sejam enviados para o controlador. O fluxo de todos os pacotes numa faixa de IP, uma conexão TCP em uma porta especifica ou todos os pacotes de uma mesma VLAN são exemplos de fluxo. Onde as ações associadas aos fluxos esta o encaminhamento de pacotes para uma

15 14 determinada porta, mudança nos campos do cabeçalho, encapsular e transmitir o pacote para o controlador, descartar os dados, por segurança, com a implementação de firewalls e encaminhar pacotes para o processamento normal do equipamento nas camadas dois ou três garantindo que o tráfego experimental não interfira no processamento do tráfego de procução, conforme figura 5. Figura 5 Modelo de operação híbrido com VLANs isolando tráfego legado e OpenFlow. Fonte: Cad. CPqD Tecnologia, O protocolo dar suporte a múltiplas tabelas de fluxos, onde podemos detalhar o tratamento do pacote de acordo com a Figura 6, mediante um novo conjunto de instruções, bem como novas ações e campos de cabeçalho para uma definição ainda mais completa dos fluxos e do conjunto de ações associadas. Figura 6 Diagrama do tratamento de um pacote no pipeline de um switch OpenFlow. Fonte: Cad. CPqD Tecnologia, As principais razões que contribuem para a aceitação da tecnologia OpenFlow são as seguintes:

16 15 a) O OpenFlow pode ser incorporado em equipamentos de rede: Roteadores, switches, pontos de acesso Wi-Fi comerciais em operação, sem modificação do hardware apenas mediante uma atualização do firmware e com a mesma garantia no desempenho de tecnologias já consolidadas no encaminhamento de pacotes IP/Ethernet. b) O protocolo OpenFlow separa o plano de controle do plano de dados: Permite a utilização de controladores remotos baseados em servidores com sistemas operacionais e linguagens de programação comuns na indústria de TI. O software do controlador é responsável por definir o modo como os fluxos de pacotes são encaminhados e processados na rede. Assim permite que o controle sobre o plano de dados seja de certa forma terceirizada a pesquisadores, sistemas de gerência, desenvolvedores, operadores de rede, plataformas de serviços e, até mesmo, às próprias aplicações finais, como, por exemplo, servidores de conteúdo ou serviços em nuvem. O controle da rede deixa de estar embarcado nos equipamentos e limitado por implementações e padrões já consolidados. c) O OpenFlow independente da forma que o software controla a rede: Por oferecer um simples serviço de encaminhamento multicamada (L1-L4) orientado a fluxos definidos por qualquer combinação de mais de 20 cabeçalhos-padrão. Uma rede OpenFlow permite a definição de fatias de rede (slices ou flow-spaces), e ainda com garantia de isolamento entre os diferentes controladores que operam sobre a rede, permitindo que o tráfego operacional e o tráfego experimental operem em paralelo. d) o OpenFlow é compatível com a Internet atual: O tráfego pode continuar em operação em uma ou mais fatias da rede OpenFlow. O protocolo OpenFlow é uma tecnologia inovadora que abre uma série de oportunidades de desenvolvimento tecnológico na área das redes de pacotes. Com a consolidação das tecnologias de equipamentos programáveis em software no padrão OpenFlow, ou tecnologias similares, o conceito de redes definidas por

17 16 software envolve novos paradigmas de gerência integrada, inovação em protocolos e serviços baseados em recursos de redes virtualizados. (CHOWDHURY; BOUTABA, 2009) Mercado Os fatores disruptivo do protocolo openflow tem atraído com bastante força a indústria, onde empresas como HP, ERICSSON, NEC, Extreme, Arista, Ciena, Juniper e Cisco trabalham no desenvolvimento dos protótipos com suporte ao openflow. Os fornecedores Broadcom e Marven dão suporte nos processadores. Novas empresas com o foco em Openflow como a Nicira é uma empresa de SDN e a Big Switch Networks oferece uma estrutura de switch openflow. Operadoras também tem interesse Deutsche Telekom e Docomo, além de provedores de serviços em nuvem, como Google, Facebook e Amazon. Os cenários de rede em que a tecnologia OpenFlow traz desenvolvimento são os seguintes: a) Redes corporativas: Gerando novos mecanismos de controle de acesso e segurança, gerência integrada de rede cabeada e sem fio, configuração de VLANs; b) Backbone: convergência de redes de pacotes e circuitos, (Figura 7), como, por exemplo, agregação e gerência dinâmica e flexível do tráfego, novos mecanismos de roteamento e engenharia de tráfego e recuperação de falhas; balanceamento do tráfego Web; mobilidade de máquinas virtuais; Figura 7 Rede com switch, TDM, WDM e roteadores IP controlados por openflow. Fonte: GUDLA et al., 2010.

18 17 c) Redes celulares: uso transparente de diversas redes de acesso (Wi- Fi/3G/WiMAX); d) Data center: técnicas de conservação de energia, engenharia de tráfego, roteamento plano e multicaminho, suporte à virtualização de hosts e software switches; e) Redes domésticas: terceirização (outsourcing) da gerência de rede, compartilhamento da rede com vários provedores de serviços e usuários, como, por exemplo, Open Wi-Fi, e gerência de energia com medidores inteligentes, como smart grid; Toda abordagem baseada em controladores centralizados é um desafio nos aspectos de escalabilidade, resiliência a falhas e segurança. Pois é muito importante deixar claro que a centralização do modelo openflow é somente lógica, ou seja, não é restrita a uma implementação distribuída dos elementos controladores para garantir a escala, desempenho e confiabilidade. Logo com a consolidação da materialização dos serviços de roteamento e o isolamento das maquinas virtuais haverá um melhor aproveitamento dos recursos da infraestrutura, obtendo topologias lógicas independentes sobre uma mesma rede, executando protocolos diferentes. 3 PROBLEMATIZAÇÃO As redes tornaram-se parte da infraestrutura crítica das nossas empresas, casas e escolas. Quase não existe nenhuma maneira prática para realizar experimentos com novos protocolos de redes em ambientes de escala real transportando tráfego. O resultado é que a maioria das novas idéias a partir da rede comunidade de pesquisa não é testada. Com é conhecido o problema, a comunidade de rede está trabalhando para o desenvolvimento de redes programáveis, como uma proposta de centro de pesquisa para a experimentação de novas arquiteturas de rede e distribuídos sistemas. A essas redes programáveis pede switches programáveis e roteadores que por intermédio de virtualização pode processar pacotes para múltiplos experimentos isolados de redes simultaneamente. GENI (Global Environment for Network Innovations) prevê que um pesquisador será alocado para uma fatia de recursos em toda a rede, constituído por

19 18 uma porção de links de rede, elementos de processamento de pacotes que nem roteadores e finalmente com a união dos pesquisadores, cada pesquisador programa suas fatia. Mas como os pesquisadores irão controlar uma parte de sua rede local de uma maneira que não perturbe outros que dependem isso? O objetivo com esse protocolo é propor um novo recurso chave que podem ajudar a ampliar a programação na rede. Um desafio é convencer os fornecedores de equipamentos comerciais para fornecer equipamento programável aberto, plataforma virtualizada em seus switches e roteadores para que os pesquisadores possam implantar novos protocolos, enquanto os administradores de rede possa ter um equipamento bem suportado. Switch e roteadores comerciais não fornecem normalmente uma plataforma de software aberto, muito menos fornecer um meio de virtualizar ou seu hardware ou software. Na prática a rede comercial é que padronizada as interfaces externas e toda a flexibilidade interna do switch está escondida. A parte interna se difere de fabricante para fabricante, numa plataforma sem padrão para experimentar novas idéias. Além disso, fornecedores de equipamentos de rede são resistentes sobre a abertura de interfaces dentro de suas caixas, pois passaram anos na implantação e ajustes distribuídos de protocolos e algoritmos, e com razão temem que novos experimentos tragam as redes a desabar. E com plataformas abertas, maior é à entrada de novos concorrentes. Já existem algumas plataformas de software livre, mas não tem o desempenho que precisamos. O mais simples exemplo é um PC com várias interfaces de rede, todos os sistemas operacionais conhecidos apoiam o roteamento de pacotes entre as interfaces e implementações de código aberto. Existem protocolos de roteamento em distribuição Linux e, na maior parte dos casos é possível modificar o sistema operacional para pacotes de processo em diversas formas. O problema é o desempenho, onde um PC não pode suportar o número de portas necessárias, nem o processamento de pacotes. O desempenho do switch muda o processamento sobre 100Gbits/s de dados, enquanto que um PC típico esforça para exceder de 1 Gbit/s e a diferença entre os dois é cada vez maior.

20 19 No outro extremo é NetFPGA, uma plataforma flexível e aberta para investigação e experimentação de taxas de linha orientada para o uso no ensino e laboratórios de pesquisa. NetFPGA é uma placa PCI de baixo custo com uma FPGA programável pelo usuário para o processamento de pacotes, e com quatro portas de Gigabit Ethernet. NetFPGA é limitada apenas quatro interfaces de rede, sendo assim insuficiente. As soluções comerciais são muito fechadas, e as soluções de pesquisa por ter um desempenho insuficiente e ou caras. Parece improvável que as soluções de pesquisa, com a sua generalidade completa, possa superar o seu desempenho ou limitações de custo. A abordagem mais promissora é a de comprometer a generalidade e buscar um grau de flexibilidade no switch que é: Passível de implementações de alto desempenho e baixo custo. Capaz de suportar uma ampla gama de pesquisa. Assegurar e isolar o tráfego experimental da produção. De acordo com a necessidade dos fornecedores de plataformas fechadas. 4 OBJETIVOS 4.1 OBJETIVO GERAL Trabalhar com rede definida por software com o protocolo OpenFlow, e assim testar em um cenário virtualizado de rede um switch virtual para OpenFlow. 4.2 OBJETIVOS ESPECÍFICOS Os objetivos específicos do trabalho são: a) Simular um cenário entre um switch e um controlador openflow, virtualizando um serviço através de máquinas virtuais; b) Ver as tabelas de fluxos com dpctl. c) Dissecar as mensagens OpenFlow com o Wireshark d) Simular uma rede multi-switch, multi-host com a Mininet

21 FERRAMENTAS DE DESENVOLVIMENTO Ferramentas de Desenvolvimento O ambiente de desenvolvimento, no processo as ferramentas mais úteis para transformar o hub em um switch de aprendizagem e ferramentas de depuração específicas OpenFlow em geral. Segue algumas terminologias, começando com tipos de terminais: VMware / VirtualBox terminal console: conecta a OpenFlowTutorial, criada quando subimos a maquina virtual. SSH terminal: conecta a OpenFlowTutorial, usando putty no Windows. Terminal Xterm: se conecta a um host na rede virtual. O VM OpenFlowTutorial inclui uma série de utilitários de rede OpenFlow - gerais e específicos pré-instalados: OpenFlow Controlador: fica acima da interface OpenFlow, responsável pela distribuição de referência OpenFlow que funciona como um switch Ethernet, em combinação com um switch OpenFlow. OpenFlow Switch: fica abaixo da interface OpenFlow, a distribuição de referência OpenFlow inclui um espaço de usuário e uma base-kernel software de switch. dpctl: utilitário de linha de comando que envia mensagens rápidas OpenFlow, útil para a visualização da porta do switch e as estatísticas de fluxo, além de inserir manualmente as entradas de fluxo. Wireshark: de utilidade geral para os pacotes de visualização gráfica. OpenFlow inclui uma Wireshark dissecador, que analisa mensagens OpenFlow enviados para a porta padrão OpenFlow (6633) de uma forma convenientemente legível. iperf: utilitário de linha de comando para testar a velocidade de uma única conexão TCP. Mininet: utilitário de linha de comando para emular uma rede OpenFlow em uma única máquina. Mininet permite que os hosts virtuais com seus próprios endereços IP para se comunicar através de links Ethernet virtuais com switches OpenFlow de software, utilizando a rede de virtualização construída em versões recentes do Linux. cbench: utilitário para testar a taxa de controladores OpenFlow configuração de fluxo.

22 21 5 CENÁRIO REDE OPENFLOW Inicialmente preparamos a maquina virtual MININET, utilitário que auxilia com linhas de comandos a emular uma rede OpenFlow criando os hosts virtuais com IP independentes e conectados por links virtuais. Foi utilizado uma topologia com três hosts, um switches definição do endereço IP e Mac para cada host. Criado um único switch software OpenFlow no kernel do sistema Linux com três portas e inicializado um controlador de referencia OpenFlow. Através do comando: sudo mn --topo single,3 --mac --switch ovsk --controller remote no ambiente do utilitário MININET. Segue na figura 8 o ambiente simulado; Figura 8 Cenário OpenFlow Tutorial a ser trabalhado. Fonte: Antes de iniciar o trabalho de analise sobre essa rede OpenFlow é necessário explanar mais sobre os utilitários do protocolo.

23 MININET Mininet cria uma rede virtual real, rodando um kernel real, switch e código do aplicativo, em uma única máquina virtual, em segundos, com um único comando podemos criar um ambiente de rede definido por software, como controladores, switch e hosts com referencia ao protocolo OpenFlow. Facilitando a interação com a rede usando o Mininet CLI, compartilhá-lo com os outros, ou implantá-lo em hardware real. Mininet também é uma maneira de desenvolver, compartilhar e experimentar com OpenFlow e sistemas de rede definida por software, figura 9. Figura 9 Cenário OpenFlow Tutorial a ser trabalhado. Fonte: Trabalhando em Mininet utilizaremos alguns comandos específicos: Para ver a lista de nós disponíveis, no console Mininet, execute: nodes Para ver uma lista de comandos disponíveis no console Mininet, execute: help Para verificar o IP de um host virtual, no console Mininet, execute: h2 ifconfig Para executar comandos interativos e observando a saída de depuração é a de gerar um xterm para um ou mais hosts virtuais. No console Mininet, execute: xterm h2 h3 Para limpar qualquer estado ou processos usando residual: sudo mn-c Para verificar a conectividade do host através do switch OpenFlow:

24 23 h2 ping -c3 h3 Mininet tem uma infinidade de outros comandos e opções de inicialização para ajudar com a depuração. O prompt Mininet> é para Mininet console, $ é para terminal SSH (usuário normal) e # é para terminal SSH (root). 5.2 WIRESHARK A imagem de maquina virtual inclui o OpenFlow Wireshark dissecador préinstalado. Wireshark é extremamente útil para visualizar as mensagens do protocolo OpenFlow e a depuração geral. Através do aplicativo putty, executar seguinte comando: putty.exe -X mininet@[ip] Inicialize o Wireshark, execute: sudo wireshark & Logo em seguida iniciamos a captura dos pacotes na interface loopback do computador, filtrando apenas por of,openflow. Assim podemos observar Echo Request e mensagens de resposta de eco, onde essas mensagens permitem ao controlador verificar se o switch esta ativo, figura 10. Figura 10 Wireshark capturando mensagens Echo Reply/ Echo Request. Fonte:Wireshark dissecador, 2013

25 24 Para ver as mensagens de inicialização do OpenFlow é preciso reiniciar a rede. Onde matamos a rede MININET com o seguinte comando: sudo mn c Com o Wireshark dissecador, vamos iniciar a rede novamente. Olhar para as mensagens de controle OpenFlow entre o switch e o controlador. Limpar as mensagens anteriores, indo para capturar-> Restart. Além disso, não estamos tão interessados em ver apenas mensagens Echo Request (tipo 2) e Echo Reply (tipo 3). As mensagens exibidas, inicia-se a partir das taxas de Hello. Na 'protocolo OpenFlow na seção central os campos de mensagem. No campo Recursos opção para exibir as capacidades do caminho de dados. Estas mensagens segue a seguir no tabela 1: Tabela 1 Mensagens Openflow Mensagem Tipo Descrição Hello Controller->Switch Encaminhamento do handshake TCP, onde o controlador envia o seu numero de versão para o switch. Hello Switch->Controller O Switch responde com seu número de versão. Features Request Controller->Switch O controlador pede para ver quais portas estão Set Config disponíveis. Controller->Switch O controlador solicita ao switch para enviar fluxo de expiração. Features Reply Switch->Controller As respostas do switch com uma lista de portas, velocidades de portas, tabelas e ações. Port Status Switch->Controller Permite ao switch informar para o controlador mudanças de velocidade de porta ou conectividade. Fonte: própria, Assim todas as mensagens são enviadas através localhost pelo uso Mininet, para uma determinando remetente de uma mensagem pode ficar confusa quando há muitos switches emulados. Logo, isso não será um problema, já que temos apenas um switch nesse cenário. O controlador está no porto OpenFlow padrão (6633), enquanto o switch estiver na outra porta ao nível do utilizador, figura 11.

26 25 Figura 11 Wireshark capturando mensagens Hello. Fonte:Wireshark dissecador, 2013 Para a mensagem Feature Request, onde o controlador solicita ver quais portas estão disponíveis, segue na figura 12. Figura 12 Wireshark capturando mensagens Feature Request.

27 26 Fonte:Wireshark dissecador, 2013 Para a mensagem Set Config, segue a figura 13. Figura 13 Wireshark capturando mensagens Set Config.

28 27 Fonte:Wireshark dissecador, 2013 Para a mensagem Feature Reply, onde já aparece às características do switch com definições de portas, ações e capacidade. Segue a figura 14. Figura 14 Wireshark capturando mensagens Feature Reply.

29 28 Fonte:Wireshark dissecador, 2013 Capturado mensagens Packet In, figura 15 Figura 15 Wireshark capturando mensagens Packet In. Fonte:Wireshark dissecador, 2013 Capturado mensagens Packet out, figura 16

30 29 Figura 16 Wireshark capturando mensagens Packet out. Fonte:Wireshark dissecador, 2013 Capturado mensagens Port Status, figura 17 Figura 17 Wireshark capturando mensagens Port Status. Fonte:Wireshark dissecador, 2013 Uma solicitação ARP perde a tabela de fluxo, o que gera uma mensagem Packet-Out broadcast. Logo em seguida, a resposta ARP volta, com os dois

31 30 endereços MAC agora conhecido para o controlador, ele pode empurrar para baixo o fluxo para o switch com uma mensagem Flow-Mod. O switch é quem empurra os fluxos para os pacotes ICMP, as próximas solicitações de ping subsequentes irão direto através da central de dados, com os fluxos de conexão h2 e h3 já empurrados para o switch, não haverá envolvimento do controlador, figura 18. Figura 18 Wireshark capturando mensagens ARP, ICMP e OFP. Fonte:Wireshark dissecador, 2013 Logo para visualizar as mensagens OpenFlow geradas em respostas de pacotes, no console mininet executamos um teste de ping, h2 ping-c1 h3, e assim novas mensagens no Wireshark deve aparecer conforme a tabela 2. Tabela 2 Mensagens Openflow para ping Mensagem Tipo Descrição Packet-In Switch->Controller Um pacote foi recebido e não corresponder a uma entrada na tabela de fluxo do switch, fazendo com que o pacote a seja enviado para o controlador. Packet-Out Controller->Switch O controlador de enviar um pacote de saída a uma ou mais portas de switch. Flow-Mod Controller->Switch Instrui um switch a adicionar um fluxo especial para sua tabela de fluxo. Flow-Expired Switch->Controller Um fluxo expirou após um período de inatividade. Fonte: própria, Logo uma solicitação ARP a tabela de fluxo, que gera uma mensagem Packet -Out broadcast. Em seguida, a resposta ARP volta, com os dois endereços MAC agora conhecido para o controlador, ele pode empurrar para baixo o fluxo para o switch com uma mensagem Flow- Mod. O switch que em seguida empurra os fluxos para os pacotes ICMP. As próximas solicitações de ping irão direto através da