Redes Programáveis - Aula 9

Prévia do material em texto

Redes De�nidas por Software
Aula 8: Mininet – Estudos de casos
Apresentação
Para melhorarmos nosso entendimento sobre o funcionamento do SDN/OpenFlow é importante sabermos como reagem
o switch OpenFlow e o controlador no funcionamento de uma rede SDN.
Nesta aula, entraremos nos estudos de casos que envolvem SDN, como aplicação de learning switch e criação de um
Firewall. Além disso, abordaremos em mais detalhes a interação entre controlador e switch, apresentando os pacotes
trocados entre eles e exploraremos alguns campos importantes contidos neles.
Veremos, também, como usar um controlador externo ao Mininet e componentes do Python.
Objetivos
Listar exemplos de uso do Mininet;
Descrever os passos realizados de interação entre switch e controlador.
Troca de pacotes de controle e informações passadas entre switch
e controlador
Na aula anterior, vimos a captura de pacotes OpenFlow com o Wireshark. No exemplo a seguir, veremos mais detalhes sobre
essa troca de pacotes de controle e quais informações são passadas entre switch e controlador.
SOFTWARE(S) NECESSÁRIO(S) PARA A ATIVIDADE
- Mininet
- Wireshark
Análise de pacotes de um servidor HTTP
ATIVIDADE PRÁTICA
• Cenário/Problema Proposto
Analisar o pacote de um servidor HTTP em uma topologia de 4 hosts, 1 switch e 1 controlador.
• Desenvolvimento da atividade prática
O passo a passo está descrito abaixo.
• Re�exão
Ao �m da atividade será possível veri�car a troca de mensagens do servidor HTTP e as mensagens do controlador.
Atenção
Como já vimos, o ping não é o único comando que você pode executar em um host. Os hosts Mininet podem executar qualquer
comando ou aplicativo disponível para o sistema Linux (ou VM) subjacente ao seu sistema de arquivos.
Você também pode inserir qualquer comando shell, incluindo controle de tarefas (&, jobs, kill etc.). Assim, neste exemplo,
iniciaremos um servidor HTTP simples em h4, e faremos uma solicitação de h1.
Estando na VM, devemos executar o comando abaixo para criar a topologia da Figura 8.2:
$ sudo mn –topo=single,4
Ou seja, criaremos uma topologia com 4 hosts ligadas a um switch.
Outro comando interessante é o dump. Com ele, podemos ver outras informações dos componentes da topologia.
mininet> dump
 Figura 8.1 – Iniciando topologia e saída de dump.
Existem alguns scripts Python já criados que acrescentados ao caminho padrão de execução. Um exemplo é um servidor HTTP
simples.
 HTTP simples
 Clique no botão acima.
HTTP simples
Para isso execute:
Mininet> h4 python -m SimpleHTTPServer 80 &
O “-m” no comando está relacionado a executarmos um módulo Python já no caminho de execução padrão. Além
disso, lançamos um servidor na porta 80 que executará em background, daí o “&” no comando.
Agora, faremos um comando wget de algum host que fará um request HTTP ao servidor h4 (IP 10.0.0.4):
mininet> h1 wget 10.0.0.4
Veremos, assim, o download do arquivo “index.html”. Todo o processo pode ser monitorado pelo Wireshark, caso queira
ver a interação de pacotes.
Por meio do diagrama da Figura 8.2, acompanharemos o caminho percorrido no procedimento.
Nos concentrarmos nos pacotes HTTP e OpenFlow. Dessa forma, ignoremos a parte dos pacotes ARP.
Assim, h1 faz um HTTP GET para o h4. Como temos uma “conversa” utilizando TCP sempre iniciamos com uma
mensagem do tipo SYN.
Se estivéssemos utilizando um switch tradicional, este pacote seria
encaminhado para h4 baseado no conhecimento de qual porta deveria
encaminhar o pacote a partir do endereço MAC de destino.
Atenção
Entretanto, estamos utilizando um switch OpenFlow (S1). Logo, S1 checará sua tabela de �uxo local. Desde de que este seja o
primeiro pacote do �uxo, provavelmente não terá uma entrada na tabela “case” (match) com este pacote. Isso é chamado table
miss, que ocorre geralmente quando não temos match entre o algum �uxo e as entradas na tabela.
A ação padrão é repassar este pacote para o controlador em uma mensagem Packet-IN, que encapsula originalmente a
mensagem TCP SYN e pode incluir a mensagem inteira ou apenas o cabeçalho da mensagem e referenciá-la com um buffer
ID.
 buffer ID
 Clique no botão acima.
buffer ID
Ao usar um buffer ID, o switch guarda todo pacote em memória e o controlador pode, mais tarde, instruir o switch
sobre o que fazer com o pacote guardado indicando seu buffer ID.
Quando o controlador recebe o pacote, algumas ações podem ser tomadas. O controlador pode enviar uma
mensagem de Packet-OUT e/ou uma mensagem de modi�cação de �uxo de volta para o switch.
O Packet-OUT é uma mensagem de instrução do controlador para o switch informando o que ele deve fazer com um
pacote especí�co. A mensagem de Packet-OUT pode conter o pacote completo ou a referência do buffer ID que o
switch está guardando.
Neste exemplo, o controlador simplesmente envia o pacote com referência para o buffer ID = 250 com a ação de
encaminhar para a porta 4 do switch, conforme Figura 8.2.
Outra opção é termos a modi�cação de �uxo (Flow-MOD), Figura 8.3. O controlador envia a mensagem de modi�cação de
�uxo que instrui o switch a instalar uma nova entrada de �uxo na tabela de �uxo.
As entradas de �uxo indicam ao switch o que fazer com futuros pacotes similares ao recebido quando chegarem ao switch, se
baseando nas ações de matching e mask com os campos.
Neste exemplo, o controlador envia uma modi�cação de �uxo dizendo efetivamente que qualquer request TCP da porta 80 do
IP e MAC de h1 para o IP e MAC de h4 deve ser encaminhado à porta 4 do switch.
Uma mensagem de modi�cação de �uxo pode conter diversas ações possíveis, como:
• Ações de incluir mudança de múltiplos cabeçalhos como IPs, MACs e portas TCP.
• Ações como inundar (�ooding) todas as portas com informação para deletar um pacote ou informar ao switch que um pacote
com determinado match deve ser enviado ao controlador.
 Figura 8.2 – Packet-IN e Packet-OUT trocados entre switch e controlador [Mahler 2013].
 Figura 8.3 – Exemplo de pacote de modificação de fluxo (Flow-MOD) [Mahler 2013].
 Timeout
 Clique no botão acima.
Timeout
Outro campo que temos é o de Timeout.
Na mensagem de Flow-MOD, podemos ver dois timeouts, que informam ao switch quanto tempo ele deve guardar a
entrada da tabela de �uxo.
Neste exemplo, temos o Idle Timeout = 20, indicando que, se ele não receber HTTP requests que casem com a entrada
dentro de 20 segundos, esta entrada de �uxo será removida.
O Hard timeout = 60 indica que, independentemente de receber ou não alguma requisição dentro de 60 segundos, ela
será removida.
Prioridade (Priority) é um campo muito importante, pois os �uxos de entrada são organizados por ordem de
prioridades. Logo, se dois campos do mesmo pacote casam com alguma entrada de �uxo, aquele com a maior
prioridade será usado, enquanto que o outro será ignorado.
Assim, esta mensagem de modi�cação resulta em uma nova entrada de �uxo no switch S1, (Flow Entry (H1->H4 Port
80)).
Este processo todo foi relacionado ao envio de h1 para h4. Como resposta, h4 responde com SYN/ACK. O SYN/ACK
chega ao switch e ele não tem casamento especí�co com nenhuma entrada na tabela de �uxo. Ele possui uma entrada
para pacote SYN de h1 para h4, mas não para o SYN/ACK.
Logo, novamente, temos um table miss, que instrui normalmente o switch a entrar em contato com o controlador.
O mesmo processo anterior de encapsulamento é realizado, conforme Figura 8.4, agora com um Buffer ID diferente. Temos
também o Packet-OUT (ação de encaminhar pela porta 1) e Flow-MOD (semelhante ao caso anterior, que resulta em uma
entrada na tabela referente a H4->H1 Reply, que trata o caso do SYN/ACK).
 Figura – 8.4 - Packet-IN e OUT do retorno de h4 para h1. [modificação de Mahler 2013].
O restante da troca de mensagens entre h1 e h4 ocorre apenas via switch, sem necessitar da intervenção do controlador,
conforme Figura 8.5.
 Figura 8.5 – Demais pacotes do mesmo fluxo não recorrem mais ao controlador [Mahler 2013].
Neste diagrama de exemplo, vimos o OpenFlowsendo reativo ao switch, ou seja, agindo em resposta a pacotes que chegaram
a ele.
Aplicações OpenFlow, por outro lado, podem ser proativas, instalando nos switches entradas especí�cas. Dessa forma, não
necessita este contato do switch com o controlador para �uxos pré-estabelecidos no switch.
Veja alguns pacotes dessa interação no Wireshark:
 Figura 8.6 – Wireshark conteúdo de Packet-IN de h1 para h4.
 Wireshark
 Clique no botão acima.
Wireshark
No Wireshark, devemos selecionar o pacote que queremos analisar. Depois, na janela abaixo, devemos navegar pelas
setas até chegarmos em OpenFlow (LOXI) e, mais abaixo, em Ethernet packet.
Podemos ver que é um pacote de h1 para h4 (pelos endereços MAC de Src e Dst).
Caso queira con�rmar os endereços digite:
mininet> h1 ifcon�g -a
Mininet> h4 ifcon�g -a
Com isso, teremos os MACs das interfaces dos hosts e podemos procurá-las no Wireshark.
Além disso, podemos ver que gerou uma mensagem com buffer ID: 258, pela razão de NO_MATCH, ou seja, não tinha
nenhum casamento com as entradas até então.
Na Figura 8.7, temos um exemplo de Flow-MOD (of_�ow_add). Neste caso, temos uma modi�cação especí�ca, pois temos o
endereço de fonte de MAC, IP e porta TCP de origem e destino 80.
Mais abaixo, veremos outras informações como os timeouts e ação de encaminhar para a porta 4 (ambas não mostradas na
Figura 8.7). O mesmo caminho de volta (H4->h1) pode ser visto nos demais pacotes.
 Figura 8.7 – Exemplo de Flow-MOD
Atenção! Aqui existe uma videoaula, acesso pelo conteúdo online
Usando um controlador externo e exemplo de Learning Switch
ATIVIDADE PRÁTICA
• Cenário/Problema Proposto
Como utilizar um controlador externo e veri�car o funcionamento de um learning switch. Topologia de 3 hosts, 1 switch e 1
controlador externo.
• Desenvolvimento da atividade prática
O passo a passo está descrito abaixo.
• Re�exão
Ao �m da atividade, será possível veri�car como utilizar um controlador externo no mininet e o comportamento de um switch
após aplicar as regras de controle.
Primeiro, acessaremos a VM por meio de dois terminais remotos do mobaxterm. Para isso, basta estarmos em uma aba já
conectada à VM, e irmos com o mouse no botão direito em: “Duplicate tab”. Em uma das tabs, rodaremos o Mininet enquanto
na outra rodaremos um controlador remoto.
Uma opção para este exemplo é usarmos o controlador POX. O POX é um controlador SDN baseado em Python voltado para
pesquisa e educação. A VM que usamos já vem com uma versão do POX pré-instalada.
 POX
 Clique no botão acima.
POX
Agora, veri�caremos se os hosts podem efetuar ping uns aos outros, e se todos os hosts veem o mesmo tráfego (como o
comportamento de um hub). Para isso, abriremos um xterm para cada host e veremos o tráfego em cada um deles.
No console do Mininet, inicie três xterms:
mininet> xterm h1 h2 h3
Depois disso, teremos três xterms abertos cada um relacionado ao h1, h2 e h3.
Organize cada xterm para que todos estejam na tela de uma só vez.
Nos xterms de h2 e h3, execute o tcpdump, um utilitário para imprimir os pacotes vistos pelo host h2:
# tcpdump -XX -n -i h2-eth0
E para o h3:
# tcpdump -XX -n -i h3-eth0
No xterm do h1 faça o ping:
# ping -c1 10.0.0.2
Atenção
Os pacotes de ping estão indo agora para o controlador, que inunda todas as interfaces, exceto a de envio.
Você deverá ver pacotes ARP e ICMP idênticos correspondentes ao ping em ambos os xterms executando o tcpdump. É assim
que um hub funciona. Ele envia todos os pacotes para todas as portas da rede.~
Agora, veja o que acontece quando um host inexistente não responde. De h1 xterm execute:
# ping -c1 10.0.0.5
Você deve ver três solicitações ARP não atendidas no tcpdump dos xterms. Você pode fechar os xterms por hora.
Agora, primeiramente, veri�que a acessibilidade dos hosts. O Mininet deve estar em execução, junto com o POX em uma
segunda janela. No console do Mininet, execute:
mininet> pingall
Veremos que todos os pacotes serão recebidos (6/6 received) e nenhum perdido (0% dropped). Isto é apenas um teste de
conectividade e “sanidade”.
Agora, no terminal com o POX em execução, pararemos o controlador usando ctrl+c.
Atenção
Agora, executaremos o POX com outro componente. O código contido no arquivo “of_tutorial.py” dentro de misc que executamos
chama o act_like_hub () do manipulador para mensagens packet_in para implementar o comportamento do switch. Ou seja, na
verdade, o tratamento adequado que desejamos (funcionar como switch) não está sendo implementado, este código faz o switch
se comportar como um hub.
Usaremos outro componete que realmente implementa o switch OpenFlow, que aprenderá as regras desejadas.
Para isso, primeiramente, no Mininet, faremos:
mininet> quit
$ sudo mn -c
Para parar sua execução e limpar tudo de con�guração.
No terminal que estávamos executando o POX, faremos:
$ pox/pox.py log.level --DEBUG forwarding.l2_learning
E depois retornado ao terminal do Mininet novamente:
$ sudo mn --topo single,3 --mac --controller remote --switch ovsk
Ali mesmo abriremos novamente os xterms:
mininet> xterm h1 h2 h3
Novamente ajustaremos os xterms para vermos todos ao mesmo tempo e repetiremos os comandos anteriores:
No xterm de h2:
# tcpdump -XX -n -i h2-eth0
No xterm de h3:
# tcpdump -XX -n -i h3-eth0
E, no xterm do h1, faça o ping:
# ping -c1 10.0.0.2
Agora, podemos ver que apenas em h2 o pacote é recebido. Se �zermos em h1:
# ping -c1 10.0.0.3
Veremos apenas h3 recebendo o pacote. Se formos no terminal em que o POX está rodando, veremos as entradas sendo
“aprendidas” pelo switch.
 Exemplo de Firewall aplicado ao endereço MAC
 Clique no botão acima.
Exemplo de Firewall aplicado ao endereço MAC
Atenção! Aqui existe uma videoaula, acesso pelo conteúdo online
Conclusão
Nesta aula, veri�camos em mais detalhes a troca de mensagens que ocorre entre um controlador e switch OpenFlow quando
não temos uma regra de casamento com a entrada da tabela de �uxos.
Além disso, veri�camos como é possível executar um controlador remoto e como implementar em Python um Firewall que, a
partir do endereço MAC, bloqueia a troca de mensagens.
Atenção! Aqui existe uma videoaula, acesso pelo conteúdo online
 Atividade
1. Quais pacotes podem ser gerados pelo controlador, quando o switch OpenFlow interage devido a um table miss?
a) Packet-IN e SYN
b) Apenas pacotes Packet-IN
c) Packet-OUT e Flow-MOD
d) Apenas pacotes Flow-MOD
e) ACK e Flow-MOD
2. Quanto à forma de funcionamento do switch OpenFlow e controlador, podemos dizer que:
a) Ocorre somente de forma reativa, onde o switch, ao receber algo que não sabe lidar, entra em contato com o controlador.
b) Ocorre somente de forma proativa, onde o controlador informa ao switch tudo que ele conhece de regra de antemão e, o switch, ao
receber algo diferente, apenas descarta.
c) Pode ser reativo ou proativo, em que as aplicações OpenFlow já informam ao switch o que fazer quando proativo e o switch consulta o
controlador quando reativo.
d) Pode ser reativo ou proativo, onde o switch consulta de forma própria o controlador no proativo.
e) Nenhuma das anteriores.
3. Pela saída do comando dump do Mininet podemos ver:
a) Os endereços MAC dos nodes
b) Apenas os endereços IP dos nodes
c) O nome dos hosts, endereços MAC, IP e PID
d) O nome dos hosts, endereço IP e PID
e) Endereços de MAC e IP e PID
4. Sobre os campos encontrados em Packet-IN, OUT e Flow-MOD, podemos dizer:
a) O campo priority indica o desempate na ordem de envio que o pacote deve ter, caso mais que um pacote chegue ao switch.
b) Podemos ter o campo buffer ID que representa onde a informação está alocada em memória.
c) O campo buffer ID representa uma referência que o switch faz ao pacote ao repassar ao controlador ao invés de todo conteúdo do
pacote.
d) O campo timeout indica quanto tempo o pacote terá de “vida”.
e) O campo action indica qual ação o controlador executará.
5. Caso tenhamos mais do que um campo de case com alguma regra, a ação será:
a) Descartaro pacote pois não se sabe o que fazer com ele.
b) Tentar realizar um merge das possíveis ações.
c) Pedir uma ação de desempate ao controlador.
d) Olhar o campo de prioridade de cada campo para selecionar qual será levado em conta.
e) Repassar ao controlador apenas as ações que podem ser tomadas.
6. Sobre timeouts da tabela de �uxo, podemos dizer:
a) Temos dois timeouts: um idle timeout e um hard timeout.
b) Temos dois timeouts: um soft timeout e outro hard timeout.
c) Temos apenas um timeout: o idle timeout.
d) Temos apenas um timeout: o hard timeout.
e) Temos apenas um timeout: o soft timeout.
Notas
mobaxterm 1
A instalação do mobaxterm é simples, por isso não será apresentada aqui. Basta ir a um site de buscas e pesquisar por
mobaxterm, depois baixá-lo e instá-lo.
Referências
CHHABRA, Anshuman. Implementing a Layer-2 Firewall using POX and Mininet. Disponível em:
//www.anshumanc.ml/networks/2017/09/19/�rewall/. Acesso em: 16 set. 2019.
GITHUB. Tutorial OpenFlow. Disponível em: https://github.com/mininet/open�ow-tutorial/wiki/Create-a-Learning-Switch.
Acesso em: 16 set. 2019.
Próxima aula
javascript:void(0);
javascript:void(0);
As funcionalidades do NFV.
Explore mais
Assista ao vídeo Con�gure POX controller as Learning Switch with Mininet: SDN Laboratory. 
javascript:void(0);