Aula 04 - Controladores OpenFlow POX, NOX, Onix, entre

Prévia do material em texto

Redes De�nidas por Software
Aula 04: Controladores OpenFlow – POX, NOX, Onix, entre
outros
Apresentação
O controlador é a peça fundamental da arquitetura de SDNs e pode ser visto como um sistema operacional da rede.
Basicamente o fato de o controlador estar desacoplado do plano de dados e plano de controle é que dá origem ao
paradigma de redes de�nidas por software. Logo, conhecer sua forma de funcionamento é essencial para compreensão
do funcionamento de uma rede SDN.
Assim, apresentaremos nesta unidade os principais tipos de controladores e como também mostraremos seu tipo de
programação e linguagem utilizada.
Objetivos
Listar as atribuições de um controlador SDN;
Apontar as principais implementações de controladores.
 Premissa
Conforme dito em unidades anteriores, dentro de SDN temos o controlador como ponto ou peça principal de sua
arquitetura; a�nal, é ele quem executa o Network Operating System (NOS), que pode ser visto como um sistema
operacional para rede.
 Fonte: Shutterstock
 Sistemas Operacionais e NOSs
Em SDNs, a lógica de controle foi movida para uma entidade externa – o controlador SDN ou NOS. O NOS pode ser
considerado uma plataforma de software que fornece recursos e abstrações essenciais, as quais facilitam a programação
de dispositivos de encaminhamento (switches). Ele se baseia em uma visão abstrata da rede, porém logicamente
centralizada. Sua �nalidade é, portanto, semelhante à de um Sistema Operacional (SO) tradicional.
O sistema operacional de uma máquina nos fornece abstrações para as aplicações acessarem o hardware. Eles oferecem,
por exemplo, Application Programming Interface (APIs) de programação de alto nível, justamente para facilitar seu uso.
Além disso, o SO gerencia o acesso ao equipamento. Isso inclui informações tanto de estatísticas de uso do disco rígido
quanto de adaptador de rede (placa de rede), CPU e memória. Assim sendo, o SO facilita o desenvolvimento e a
portabilidade de aplicações, pois as tarefas mais complicadas são realizadas por ele próprio.
Em contraste, as redes têm sido, até agora, gerenciadas e con�guradas usando-se um conjunto de instruções que são
especí�cas do dispositivo e de baixo nível. Na maioria, dos equipamentos, os sistemas que rodam são proprietários e
fechados (p. ex., Cisco IOS e Juniper JunOS, Sistemas Operacionais da Cisco e da Juniper, respectivamente). A ideia de
sistemas operacionais abstraindo características especí�cas de dispositivos e fornecendo, de maneira transparente,
funcionalidades comuns ainda está praticamente ausente nas redes.
Exemplo
Por exemplo, hoje os projetistas de protocolos de roteamento, ao resolverem problemas de rede, precisam lidar com
complicados algoritmos distribuídos. Pro�ssionais de rede, portanto, têm resolvido os mesmos problemas repetidas vezes
(GUDE et al., 2008).
A SDN justamente promete facilitar o gerenciamento da rede e aliviar o
ônus de resolver problemas de rede. Isso por meio de um controle
logicamente centralizado, oferecido por um NOS.
 Con�ra a seguir o valor de um NOS:
 Clique no botão acima.
Con�ra a seguir o valor de um NOS:
Como nos Sistemas Operacionais tradicionais, o valor crucial de um NOS é fornecer abstrações, serviços
essenciais e APIs comuns aos desenvolvedores. Funcionalidades genéricas – como informações de topologia de
rede, estado da rede, descoberta de dispositivos e distribuição de con�guração de rede – podem ser fornecidas
como serviços do NOS.
Com o NOS, um desenvolvedor não precisa se preocupar com detalhes de baixo nível de distribuição de dados
entre elementos de roteamento, por exemplo. Tais sistemas podem criar, sem dúvida, um novo ambiente capaz
de promover a inovação em um ritmo mais rápido, reduzindo assim a complexidade inerente à criação de novos
protocolos de rede e aplicativos de rede. Semelhante a um sistema operacional tradicional, a plataforma de
controle abstrai os detalhes de nível inferior de conexão e interação com dispositivos de encaminhamento.
Assim, o NOS provê uma API para gerenciar a rede; isso permite que operações de gerenciamento de rede sejam
executadas como programas centralizados. Dessa forma, programas se comunicam com o NOS, por exemplo,
para que decisões de roteamento possam ser calculadas com o conhecimento da topologia da rede.
Desse modo, programas podem ser escritos com abstrações de alto nível (p. ex., nome de usuário e de host, em
vez de IP e MAC), o que possibilita também que aplicações de gerenciamento sejam independentes da tecnologia
de rede – Ethernet, WiFi etc. (COUTO, 2017).
O controlador de rede, ou NOS, pode dessa forma concentrar a comunicação com todos os elementos
programáveis que compõem a rede, oferecendo uma visão uni�cada do estado da rede (CASADO et al., 2010).
Um NOS (ou um controlador) é um elemento crítico em uma arquitetura SDN, por ser a principal peça de suporte
do controle lógico do equipamento e gerar a con�guração de rede com base nas políticas de�nidas pelo operador
de rede.
Existe um conjunto muito diversi�cado de controladores e plataformas de controle, com diferentes opções de
arquiteturas e de design.
Assim, os controladores existentes podem ser categorizados com base em muitos aspectos. Do ponto de vista
da arquitetura, uma das questões mais relevantes é se eles são centralizados ou distribuídos. Essa é uma das
principais linhas de projetos das plataformas de controle SDN e, por essa razão, a primeira que discutiremos a
seguir.
 Fonte: Shutterstock
 Tipos de Controladores | Centralizados × Distribuídos
Uma das principais diferenças de arquiteturas de controladores está no fato de eles serem centralizados ou distribuídos. A
seguir, apresentaremos as características de cada tipo, assim como suas vantagens e desvantagens.
Atenção! Aqui existe uma videoaula, acesso pelo conteúdo online
Clique nos botões para ver as informações.
Quando temos um controlador centralizado, uma entidade única é quem gerencia sozinha todos os dispositivos de
encaminhamento da rede. Naturalmente, esse tipo de abordagem pode representar um único ponto de falha, pois
como só ele gerencia tudo, caso pare de funcionar, compromete toda a rede, podendo ainda haver limitações de
escala.
Um único controlador pode não ser su�ciente para gerenciar uma rede com grande número de elementos no plano
de dados. Ou seja, pode não ser adequado nem sugerido para ambientes com redes muito grandes.
O objetivo principal, na sua concepção, é que sejam simples. Assim, controladores centralizados foram projetados
como sistemas altamente concorrentes, para justamente atingirem as taxas de dados exigidas por redes de classe
corporativa e data centers. Logo, grande parte desses controladores são baseados em projetos de multithread para
explorar o paralelismo de arquiteturas de equipamentos com mais de um core (núcleo).
Outros controladores centralizados têm como alvo ambientes especí�cos, como infraestruturas em nuvem e redes
de operadoras. Além disso, alguns oferecem funcionalidades e garantias especí�cas, como segurança e isolamento
para os aplicativos. Para isso, eles utilizam uma arquitetura baseada em contêiner chamado micro-NOS. Assim, é
possível isolar os aplicativos e evitar a propagação de falhas por toda a pilha SDN.
Couto (2017) lista as seguintes características para controladores centralizados:
Vantagem:
Arquitetura simples;
Desvantagens:
Ponto único de falha;
Limitações de escalabilidade. (COUTO, 2017.)
Como exemplo de controladores centralizados, podemos citar: NOX, NOX-MT, Maestro, Beacon e Floodlight.
Controladores centralizados 
Ao contrário do que ocorre em um projeto centralizado, um NOS distribuído pode ser ampliado para atender aos
requisitos de qualquer ambiente (desde pequenas a grandes redes). Um controlador distribuído pode ser do tipo
cluster centralizado ou um conjunto �sicamente distribuído de elementos. Ou seja, podemos ter um conjunto de
equipamentos �sicamente no mesmo local funcionando como um cluster. Dessa forma,temos diversos
controladores em um mesmo local. Ou podemos ter controladores distribuídos pela rede.
Enquanto a alternativa de cluster é capaz de oferecer alto rendimento para data centers muito densos, a forma
distribuída pode ser mais e�ciente ou tolerante a diferentes tipos de falhas lógicas e físicas.
Além disso, temos uma opção híbrida que mistura os dois tipos. Por exemplo, um provedor de nuvem que abrange
vários data centers interconectados por uma rede, com um cluster de controladores dentro de cada data center e
elementos controladores distribuídos nos diferentes sites (GUDE, 2008).
Outro aspecto que temos em controladores distribuídos é que a maioria deles oferece semântica de consistência
fraca. Isso signi�ca que atualizações de dados, em equipamentos distintos, serão eventualmente feitas em todos os
dispositivos regidos pelo controlador. Isso implica que há um período durante o qual dispositivos distintos podem ler
valores diferentes (valor antigo ou novo) para o mesmo atributo.
A consistência forte, por outro lado, garante que todos os dispositivos do controlador lerão o valor do atributo mais
atualizado após uma operação de gravação. Apesar de seu impacto no desempenho do sistema, a consistência forte
oferece uma interface mais simples para os desenvolvedores de aplicativos. Todavia, apenas o Onix, ONOS e
SMaRtLight fornecem esse modelo de persistência de dados.
Outra propriedade comum de controladores distribuídos é a tolerância a falhas. Quando um dispositivo deixa de
funcionar, outro vizinho deve assumir os deveres do equipamento que falhou. Até agora, apesar de alguns
controladores tolerarem falhas de travamento, eles não toleram falhas arbitrárias, o que signi�ca que qualquer
equipamento com um comportamento anormal não será substituído por um nó potencialmente “bem-comportado”.
Um único controlador pode ser su�ciente para gerenciar uma pequena rede, no entanto, representa um único ponto
de falha. Da mesma forma, os controladores independentes podem ser distribuídos pela rede, cada um deles
gerenciando um segmento de rede, reduzindo o impacto de uma única falha do controlador. No entanto, se a
disponibilidade do plano de controle for crítica, um cluster de controladores pode ser usado para atingir um maior
grau de disponibilidade e/ou para suportar mais dispositivos. Por �m, um controlador distribuído pode melhorar a
resiliência e a escalabilidade do plano de controle, bem como reduzir o impacto de problemas causados pela partição
de rede, por exemplo.
Couto (2017) lista as seguintes características para controladores distribuídos:
Diversos controladores podem gerenciar a rede:
Tipos de controladores distribuídos
Cluster de nós: diversos controladores em um mesmo local (ex.: oferece alta vazão em rede de centro de
dados);
Nós �sicamente distribuídos: controladores distribuídos por uma rede de longo alcance (ex.: oferece
tolerância a falhas);
Híbrido: clusters de nós �sicamente distribuídos (ex.: provedor de nuvem que gerencia múltiplos centros
de dados).
Quanto ao tipo de consistência
Controladores distribuídos 
Fraca
Informações (p. ex., novos �uxos) da rede são trocadas eventualmente entre controladores;
Pode existir um período de tempo no qual os controladores possuem visões diferentes da rede;
Encontrado na maioria dos controladores.
Forte
Alterações na rede são informadas a todos os controladores;
Gera sobrecarga na rede, mas torna as aplicações mais simples;
Implementada pelo Onix, ONOS e SmaRtLight.
Vantagens:
Mais tolerantes a falhas;
Maior escalabilidade.
Desvantagem:
Complexidade da infraestrutura.
Exemplos:
Onix;
Hyper�ow;
HP VAN SDN;
ONOS;
SmaRtLight. (COUTO, 2017.)
 Fonte: Shutterstock
 Eastbound e Westbound APIs
Se nos lembrarmos bem da arquitetura de SDNs e nos orientarmos a deixar o controlador como seu centro, teremos que a
comunicação do controlador para os equipamentos se faz a partir da southbound API; já do controlador para as
aplicações teremos a northbound API. Como era de se esperar, temos também as APIs relacionadas às orientações leste e
oeste do controlador.
As APIs Eastbound e Westbound (leste e oeste, respectivamente) são um caso especial de interfaces requeridas por
controladores distribuídos conforme ilustrado na �gura 1.
Atenção! Aqui existe uma videoaula, acesso pelo conteúdo online
 Figura 1 – Eastbound e Westbound APIs. Fonte: Couto (2017).
Atenção
Atualmente, cada controlador implementa sua própria API leste/oeste. As funções dessas interfaces incluem dados de
importação/exportação entre controladores, algoritmos para modelos de consistência de dados e recursos de
monitoramento/noti�cação. Nesse caso, por exemplo, pode-se veri�car se um controlador está ativo ou noti�car
determinada substituição em um conjunto de dispositivos de encaminhamento.
 Controlador NOX
É o controlador original do OpenFlow; logo, foi o primeiro produzido. Hoje em dia, sua principal função é apoiar o
desenvolvimento de novos controladores. Ele opera de maneira centralizada sobre o conceito de �uxos de dados (Figura
2) e possui código aberto (licença GPLv3). Sua interface utiliza a linguagem de programação C++ e suporta comandos do
OpenFlow versão 1.0.
 Figura 2 - Exemplo de componentes de uma rede baseada em NOX. Fonte: Couto (2017).
A Figura 2 mostra os principais componentes de uma rede baseada em NOX. Temos um conjunto de switches
(comutadores) e um controlador NOX (PC servidor) conectado à rede. O software NOX (e os aplicativos de gerenciamento
executados no NOX) são executados nesse servidor.
O software NOX gerencia um conjunto de regras (instaladas nos dipositivos de rede), reagindo a eventos da rede. Ele
mantém a visão da rede em um banco de dados em execução no controlador.
Con�ra mais informações sobre o software:
 O software NOX
 Clique no botão acima.
O software NOX
A visão de rede contém os resultados das observações da rede pelo NOX, e os aplicativos usam essas
informações/estado para tomar decisões de gerenciamento.
Guedes et al. (2012) listam uma série de eventos de�nida pelo NOX:
packet in (switch; port; packet) entra em ação quando o comutador (switch) envia um pacote (packet)
recebido por uma porta (port) física para o controlador;
stats in (switch; xid; pattern; packets; bytes) acionado quando o comutador (switch) retorna os contadores
de pacotes (packets) e bytes em resposta a um pedido de estatísticas associadas às regras contidas em
algum padrão (pattern) determinado. O xid representa o identi�cador do pedido.
�ow removed (switch; pattern; packets; bytes) acionado quando uma regra com padrão (pattern) ultrapassa
o seu tempo-limite e é removido da tabela de �uxo do comutador (switch). Packets e bytes são parâmetros
que contêm os valores dos contadores para a regra.
switch join (switch) acionado quando o comutador (switch) entra na rede.
switch exit (switch) acionado quando o comutador (switch) sai da rede.
port change (switch; port; up) acionado quando o enlace de um switch ligado a uma porta (port) física é
ligado ou desligado. O parâmetro up representa o novo status do enlace. (GUEDES et al., 2012.)
O NOX, a �m de controlar o tráfego de rede, tem de ser capaz de alterar o comportamento dos switches da rede.
Para isso, os switches exempli�cados na Figura 4.2 suportam a abstração do OpenFlow, que descrevemos mais
adiante. Guedes et al. (2012) listam as seguintes funcionalidades providas pelo NOX para enviar mensagens aos
switches:
install (switch; pattern; priority; timeout; actions) – Insere uma regra com o dado, padrão, prioridade,
tempo-limite e ações na tabela de �uxos do switch.
uninstall (switch; pattern) – Remove a regra contida em padrão da tabela de �uxos do switch.
send (switch; packet; action) – Envia o dado pacote para o switch e aplica a ação lá.
query stats (switch; pattern) – Gera um pedido para estatı́sticas de uma regra contida no padrão no switch e
retorna um identi�cador de requisição xid, que pode ser usadopara mapear uma resposta assı́ncrona do
switch. (GUEDES et al., 2012.)
Um exemplo de ação do controlador será apresentado nas Figuras 3 a 10. Nelas temos os principais passos realizados
entre o controlador SDN e os switches OpenFlow.
Quando um pacote chega ao equipamente e possui uma entrada corresponde na tabela de �uxo do comutador, este
atualiza os contadores apropriados e aplica as ações correspondentes. Se o pacote não corresponder a uma entrada de
�uxo, será encaminhado a um processo no controlador. Esses pacotes não correspondentes são frequentemente o
primeiro pacote de um �uxo (p. Ex., de início de �uxo). No entanto, os processos do controlador podem optar por receber
todos os pacotes de certos protocolos (p. ex., DNS); assim, nunca inserirão uma entrada de �uxo para eles.
Os aplicativos NOX usam esses inícios de �uxo para:
construir a visão de rede (observação); e
determinar se deve encaminhar o tráfego – e, em caso a�rmativo, ao longo de qual rota fazê-lo (controle).
Para ilustrar seu funcionamento, considere um programa controlador em Python, o qual implementa um repetidor simples.
Para este exemplo, temos um switch ligado a um controlador, ao conjunto de hosts ligados à porta 1, enquanto, na porta 2,
temos uma rede ampla (Figura 11).
 Figura 11 – Topologia simples. Fonte: Guedes et al. (2012).
Observe, na Figura 12, o exemplo de código para termos a função de repetidor no switch:
 Figura 12 – Código de repetidor simples. Fonte: Guedes et al. (2012).
O manipulador switch join chama o repetidor quando o switch se associa à rede. A função repetidor instala regras no
switch que o instruem a enviar pacotes da porta 1 para a 2, e vice-versa. As chamadas install usam a prioridade DEFAULT e
None como tempo-limite, o que indica que as regras instaladas são permanentes.
A seguir, teremos alguns exemplos de aplicativos que rodam no NOX. Não existe a necessidade de entendermos todos os
comandos em Python exempli�cados; eles servem apenas como ilustração de como as regras são escritas e tratadas.
Na Figura 13, temos um aplicativo NOX que con�gura regras de marcação de VLAN baseada na autenticação do usuário,
com base em um mapeamento prede�nido de usuário para VLAN.
 Figura 13 – Exemplo de aplicação NOX para atribuição de VLAN a usuários. Fonte: Gude et al. (2008).
O NOX é responsável por detectar todas as iniciações de �uxo, atribuindo
o �uxo ao ponto de acesso de usuário, host e ingresso correto, bem como
despachando o evento para o aplicativo. Ele também poderia, com
pequenas modi�cações no módulo de roteamento, suportar o isolamento
de tráfego.
Na Figura 14, temos um aplicativo que tenta detectar hosts com a varredura e contagem do número de destinos L2 e L3
exclusivos que um host tenta contactar, mas que não foram autenticados. Como o NOX tem acesso ao tráfego na rede e
pode aproveitar a exibição dela, é capaz de rastreiar todos os hosts autenticados.
 Figura 14 – Aplicação NOX detecção de hosts. Fonte: Gude et al. (2008).
Atenção
Em casos em que não se tem um controlador, ou entidade com essa facilidade de conhecimento da rede, a detecção de
varredura requer um ponto de estrangulamento de tráfego e heurísticas para adivinhar se um endereço IP está ativo.
Saiba mais
Controlador POX
Baseado no NOX, o controlador POX também opera de forma centralizada e possui código aberto. Tem interface Pyhton,
que é mais simples, porém apresenta pior desempenho. Normalmente é utilizado quando a demanda por desempenho
não é o requisito principal da aplicação, sendo sua facilidade de implementação mais interessante. Esse controlador é
muito utilizado no aprendizado de SDN em conjunto o Mininet (um arcabouço de simulação). Mais sobre esse controlador
será abordado em outra unidade do curso, quando tratamos de Mininet.
Atenção! Aqui existe uma videoaula, acesso pelo conteúdo online
 Outros Controladores
 Clique no botão acima.
Outros Controladores
A Tabela 1 apresenta os cinco controladores open source mais importantes, que podem ser usados pelo Mininet
remotamente: POX, Ryu, Trema, FloodLight e OpenDaylight. Sobre o POX falamos anteriormente; a seguir,
veremos o quatro restantes. Há, contudo, vários outros controladores SDN – o Jaxon (Java), o Beacon (Java), o
Maestro (Java) –, os quais não serão comentados por serem considerados obsoletos.
 Fonte: Kaur et al. (2014).
Ryu – É um controlador SDN baseado em componentes. Ele possui uma coleção de componentes SDN embutidos
(built-in) que podem ser chamados. Esses componentes podem ser alterados, estendidos e compostos para criar novos
aplicativos de controle personalizados. Ele permite que qualquer linguagem de programação seja usada no
desenvolvimento de um novo componente.
Trema – É um framework para Ruby e C que cria uma plataforma de software para desenvolvedores OpenFlow. É
considerado fácil de usar, com a vantagem de ter código livre. Os controladores Trema são scripts, escritos em Ruby, com
o qual é possível escrever seu próprio controlador adicionando manipuladores de mensagem para sua classe controller
(GUEDES et al. 2012).
Floodlight – É um controlador OpenFlow de classe corporativa, baseado em Java, tendo seu projeto se originado do
controlador Beacon. O controlador FloodLight contém vários módulos, cada qual fornecendo um serviço para outros
módulos e para o aplicativo de lógica de controle. Sua comunicação se dá a partir de uma API Java simples ou de uma API
REST.
OpenDayLight – É um projeto de código aberto cujo objetivo é criar um código robusto, que cubra os principais
componentes da arquitetura SDN (isso para ganhar a aceitação entre os vendedores e usuários, e ter uma comunidade
crescente, que contribua para que seu código se torne componente de produtos comerciais).
 Atividade
1. Como exemplo(s) de vantagens dos controladores centralizados, podemos citar:
a) Poderem usar um NOS fechado e proprietário.
b) Utilizarem a Eastbound e Westbound.
c) Serem simples e conseguirem lidar com alta taxa de dados.
d) Utilizarem um servidor especializado para a tarefa.
e) Estarem fisicamente mais bem-distribuídos entre os equipamentos.
2. Que tipo de API temos: I - do controlador para os equipamentos; II - do controlador para as aplicações; e III – entre
controladores?
a) I – Northbound; II – Southbound; e III – Westbound.
b) I – Northbound; II – Southbound; e III – Eastbound.
c) I – Northbound; II – Eastbound; e III – Westbound.
d) I – Southbound; II – Northbound; e III – Westbound e Eastbound.
e) I – Southbound, II – Eastbound; e III – Westbound.
3. São exemplos de controladores:
a) Ryu, POX e NOX.
b) Floodlight, OpenFlow, NOX, Trema e Onix.
c) OpenDayLight, TCP, NOX, POX e Beacon.
d) Beacon, NOX, POX, DNS e Ryu.
e) Ryu, Floodlight, OpenDayLight e GENI.
4. O que um switch OpenFlow faz ao receber um pacote (�uxo de mensagem) que não possui entrada na sua tabela de
�uxos?
a) Descarta o fluxo, pois trata de uma ameaça, visto que não possui informação.
b) Calcula a partir de sua visão da rede o próximo salto que o pacote deve seguir.
c) Envia-o ao controlador para ele decidir o que deve ser feito.
d) Encaminha-o diretamente ao seu gateway.
e) Modifica o pacote e informa ao controlador sobre sua alteração.
5. Quanto ao tipo de consistência, como os controladores podem ser classi�cados?
a) Apenas como consistência forte.
b) Apenas como consistência fraca.
c) Como consistência média, pois depende do tipo de mensagem a se tratar.
d) Esse tipo de classificação não se aplica aos controladores.
e) Consistência fraca ou forte.
6. Por qual outro nome também são referenciados os controladores?
a) OpenFlow
b) SDN-based
c) POX
d) NOS
e) SDN-API
Notas
Referências
CASADO, M.; KOPONEN, T.; RAMANATHAN, R.; SHENKER, S. (2010b). Virtualizing the network forwarding plane. In: Proceedings
of the Workshop on Programmable Routers for Extensible Services of Tomorrow. PRESTO ’10. pages 8:1–8:6, New York, NY.
COUTO, R. S. Tópicos Especiais em Redesde Telecomunicações. Notas de aula. Disponível em:
//www.lee.uerj.br/~rodrigo/sdnpel. Acesso em: abril 2019.
GUDE, N.; KOPONEN, T.; PETTIT, J.; PFAFF, B.; CASADO, M.; MCKEOWN, N.; SHENKER, S. NOX: Towards an operating system for
networks. ACM SIGCOMM Computer Communication Review, 2008.
GUEDES, D. et al. Redes De�nidas por Software: uma abordagem sistêmica para o desenvolvimento das pesquisas em Redes
de Computadores. Minicurso 4 do XXX Simpósio Brasileiro de Redes de Computadores e Sistemas Distribuídos. Maio, 2012.
[Online]. Disponível em: //homepages.dcc.ufmg.br/~mmvieira/cc/papers/minicurso-sdn.pdf. Acesso em: abr. 2019.
KAUR, S.; SINGH, J.; GHUMMAN, N. S. Network programmability using POX controller. In: Procedings ICCCS, 2014.
Próxima aula
OpenFlow;
OpenvSwitch.
Explore mais
Assista ao video:
javascript:void(0);
javascript:void(0);
Demonstration of POX controller with Mininet- POX as forwarding Hub: SDN Laboratory
<https://www.youtube.com/watch?v=qfq5euEm_Es> .
https://www.youtube.com/watch?v=qfq5euEm_Es