SDN
Introdução
Baseado em:
• SDN: Software Defined Networks
by Thomas D. Nadeau and Ken Gray
• Material de treinamento do Prof. Cesar Marcondes (UFSCAR)
Nível Aplicação
1
Motivação - 1
Conceitos motivacionais:
• Estamos entrando na era da computação elástica: A
flexibilidade na operação da computação, armazenamento e
recursos de rede .
• Com a virtualização de SOs, é possível mover ou expandir
servidores para data centers em qualquer localização com
uma simples operação.
• As empresas programam o crescimento e adquirem recursos
previamente para atender as demandas, todavia, parte do
recurso fica em desuso se não houver flexibilização.
Nível Aplicação
2
Motivação - 2
• Máquinas Virtuais devem ter endereços IPs dedicados aos
respectivos SOs, válidos e roteáveis e a flexibilização implica em
gerir estes endereços.
• A utilização de protocolos específicos com a flexibilização
também requer que os mesmos protocolos estejam disponíveis
em todos os ambientes.
• Gerência de flexibilização enquanto no interno de apenas um
data-center não é crítico, mas quando cresce...
• Ao mesmo tempo que cresce a computação elástica, o custo da
potência computacional estava diminuindo ao ponto de ter
milhares de processadores à disposição.
• Então: Temos hoje mais potência e queremos mais flexibilidade.
Nível Aplicação
3
Motivação - 3
Do ponto de vista da rede:
• Um dispositivo de rede é constituído por um plano de dados
que liga as várias portas de rede e um plano de controle que
é o cérebro de um dispositivo (implementa um protocolo).
• Como foram concebidos os equipamentos de rede, exigem
que determinada função seja implementada de forma
distribuída: o controle está em cada um dos equipamentos.
Roteadores e switches são muito caros principalmente
devido aos componentes de controle;
Nível Aplicação
4
Control and Data planes: not a new concept
Qualquer roteador ou
switch moderno multislot
tem seu plano de
controle rodando em
processador dedicado e o
plano de dados
executando
independente em uma
ou mais linhas, cada uma
com um processador
dedicado. O processador
do roteador e as linhas
estão conectados sobre
uma rede pequena
interna de alta
velocidade.
Nível Aplicação
5
Motivação - 4
Ideia: A potência de processamento pode ser aproveitada para
executar um plano de controle logicamente centralizado e
usar hardware de comutação barato:
SDN – Software Defined Networks ou
Redes Definidas por Software
• Os propositores de SDN perceberam que os fornecedores de
equipamentos de rede não atendiam suas necessidades,
particularmente quanto a inovação e desenvolvimento.
• Se alguém quisesse experimentar um novo protocolo , como o
firmware não suportava, fazia-se uma requisição ao fabricante
e esperava-se todas as etapas do desenvolvimento (meses,
anos…).
Nível Aplicação
6
Motivação - 5
ONF – Open Network Foundation – suporta comercialmente os
esforços de SDN e é a autoridade de padronização (Criada em 2011).
Previsões de crescimento de SDN ao redor do mundo:
1) Instituto IHS:
Em quem
acreditar?
2)
http://www.researchandmarkets.com/research/vk7xrn/software_defined:
The total Software Defined Data Center (SDDC) market is expected
to grow from $21.78 billion in 2015 to $77.18 billion by 2020, at an
estimated Compound Annual Growth Rate (CAGR) of 28.8% from
2015 to 2020.
Nível Aplicação
7
Motivação - 6
• Alguns engenheiros de Stanford criaram um protocolo –
Openflow – que implementou esta ideia.
• Baseado nesta arquitetura básica, imagina-se o quão rápido e
fácil seria projetar um novo protocolo apenas implementando no
data center usando hardware em preço de commodities.
• Ainda melhor, é possível implementar isto em um ambiente de
computação elástica em uma máquina virtual.
• A motivação para SDN e OpenFlow foi a flexibilidade de como
programar o dispositivo de rede e não onde está a programação.
Nível Aplicação
8
Projeto OpenFlow
OpenFlow foi arquitetado para ter diversos dispositivos contendo
apenas planos de dados que respondem a comandos enviados
para eles de um controlador centralizado que hospeda um
único plano de controle para aquela rede;
A função de data-path ainda
reside no switch, enquanto que
as decisões de roteamento de
alto nível são movidas para um
Controlador, normalmente
localizado em um servidor. Os
Switches e o Controlador se
comunicam através do protocolo
OF. Um Controlador adiciona e
ou remove entradas da tabela de
fluxos em nome da aplicação.
Nível Aplicação
9
Como evoluir?
• Joga fora o que foi feito até hoje ?
É mais provável uma abordagem híbrida:
– pelo qual uma parte das redes sejam operadas por um
controlador logicamente centralizado;
– outras partes seria executadas pelo plano de controle
distribuído mais tradicional.
Isso implica que esses dois mundos devem interagir uns com
os outros.
Nível Aplicação
10
IETF no circuito
• IETF acompanha a discussão e os primeiros rascunhos do
IETF estão surgindo.
• Há envolvimento de empresas (Juniper, Cisco, Level3…)
direcionado para desenvolver programação de rede
chamada Interface to the Routing System (I2RS).
• Ideia básica do I2RS: criar um protocolo e componentes
para programar a base de informação de roteamento do
dispositivo (routing information base - RIB) usando um
protocolo rápido para permitir interação em tempo-real da
RIB com o gerente que a controla.
• Enquanto OF centraliza as decisões de encaminhamento, a
estratégia do IETF divide a tomada de decisão entre
aplicações do usuário, gerência central e protocolos de
roteamento tradicionais executados
no hw de rede.
Nível Aplicação
11
Definição SDN
• Software-defined networks (SDN)
Uma abordagem arquitetônica que otimiza e simplifica as
operações de redes ligando intimamente aplicações e
serviços de rede reais ou virtuais. Para este objetivo
emprega um ponto de controle central – o controlador SDN
– que media e facilita a comunicação entre aplicações que
pretendem interagir com os elementos de rede e os
elementos de rede que querem transmitir informações a
estas aplicações. O controlador expõe e abstrai funções de
rede e operações via uma interface programável,
bidirecional, moderna e application-friendly.
(Derivada da ONF)
Nível Aplicação
12
Plano de Controle
No alto nível, o plano de controle estabelece os dados locais a
serem utilizados para criar as tabelas de encaminhamento
que serão utilizadas pelo plano de dados para encaminhar o
tráfego entre portas de entrada e saída de um dispositivo.
• Routing Information Base (RIB): conjunto de dados utilizado
para armazenar a topologia da rede
• Forwarding Information Base (FIB) : tabela com entradas dos
encaminhamentos . A FIB é programada uma vez que a RIB
for considerada consistente e estável.
Nível Aplicação
13
Plano de Dados
Um datagrama correto é processado no plano de dados
realizando buscas na FIB que são programadas
antecipadamente pelo plano de controle.
• A pesquisa de encaminhamento do plano de dados resulta
em ações programadas, como por exemplo Encaminhar (ou
replicar em casos como multicast), descartar ou contar.
Algumas destas ações podem ser combinadas.
Nível Aplicação
14
Controle e Dados em Rede típica
Situação no interno de um
switch:
Chegou um pacote no plano
de dados (1) que não se
sabe o MAC – é passado
para o plano de controle (4):
aprende informação,
atualiza RIB (C). Devolve ao
plano de dados (2),
eventualmente alterando a
FIB, encaminha o pacote (3).
OBS: Esquema semelhante
para tratar questões do
Nível 3.
Nível Aplicação
15
Benefícios da Separação
Fatores beneficiados com a separação:
• Escalabilidade e inovação: cada parte pode crescer e inovar
independente da outra (com menos amarras);
• Custo: deve ser reavaliado – hardware mais barato pois menos
especializado, software mais sofisticado.
• Evolução: possibilidade de desenvolver novas soluções
independentes de fabricante.
• Estabilidade: código em expansão se torna “colcha de retalho”,
sendo complexo e frágil; espera-se código menor e portanto mais
estável.
• Complexidade: o número de “executores” de protocolo em um
modelo consistente de controle distribuído pode criar
complexidade de gerência e operações. ( quanto tempo vai levar
para o plano de controle estabilizar a respeito de uma rede livre
Nível Aplicação
16
de loops? )
Lógico x Literal
A centralização literal traz as dificuldades:
• Escalabilidade: como um ponto central daria conta de sessões
com cada equipamento gerenciado?
• Alta disponibilidade: se um único ponto falhar, a rede toda
falhará;
• Distância geográfica: Manter um ponto próximo facilita operação
e minimiza atrasos.
Plano de controle centralizado logicamente faz mais sentido que
centralizado literalmente: algum protocolo deve sincronizar os
controladores fisicamente distribuídos.
Nível Aplicação
17
Arquitetura Openflow
Alguns aplicativos de
controle estão no
topo do controlador
emulando o
comportamento dos
aplicativos de
controle tradicionais.
Nível Aplicação
18
OF - Operation
Nível Aplicação
19
Controlador
No mundo OF, o controlador é o rei! Um Controlador adiciona e ou
remove entradas da tabela de fluxos em nome da aplicação:
• Controladores estáticos: estaticamente estabelecem fluxos que
interliguem um cjto de comps de teste durante um experimento.
• Controladores dinâmicos: mais sofisticados adicionam / removem
fluxos enquanto a experiência progride.
Existem diversas maneiras para customizar o experimento OF:
• Fazer o Download, e configurar um controlador existente.
• Ler as Especificações do OpenFlow e fazer tudo do zero :
Escrever o seu proprio controlador para manipular cerca de 20
mensagens do protocolo OpenFlow;
• Mais Recomendavel: extender um controlador existente.
Ex. Escrever um Modulo para NOX : www.noxrepo.org
Nível Aplicação
20
Ferramenta - Mininet (1)
• Grande ferramenta de testes e desenvolvimento, ideal para
fase de prototipação. Google usa algo como mininet antes da
implantação.
• Rede Virtual na Comodidade da sua Maquina (Espaço do
usuário => leve)
• Topologias e Quantidades de Nós Arbitrárias
mininet.org:
“Mininet is distributed as a virtual machine (VM) image with all
dependencies pre-installed, runnable on common virtual
machine monitors such as VMware, Xen and VirtualBox. This
provides a convenient container for distribution; once a
prototype has been developed, the VM image may be
distributed to others to run, examine and modify.”
Nível Aplicação
21
Passos da instalação
• Criar a VM mininet2-2 (baixar de
• www.comp.ita.br/~cecilia/ces-35/Mininet compactado )
• Talvez precise atualizar o openvswitch que vem na máquina
• Instalar o ryu na VM com os pacotes de pré-requisito:
(http://osrg.github.io/ryu/)
$sudo apt-get update
$sudo apt-get install python-eventlet python-routes pythonwebob python-paramiko
$git clone git://github.com/osrg/ryu.git
$cd ryu
$git pull
Nível Aplicação
22
Alternativa para instalação do Ryu
Dica do André:
$ sudo apt-get install python-pip
$ sudo pip install oslo.config
$ PYTHONPATH=.
Livro explicando detalhes do Ryu:
https://osrg.github.io/ryu-book/en/Ryubook.pdf
Nível Aplicação
23
Mininet (2)
•
É possível escrever scripts para ativá-lo:
A API de Mininet permite criar redes customizadas com
algumas poucas linhas de Python:
from mininet.net import Mininet
from mininet.topolib import TreeTopo
tree4 = TreeTopo(depth=2,fanout=2)
net = Mininet(topo=tree4)
net.start()
h1, h4 = net.hosts[0], net.hosts[3]
print h1.cmd('ping -c1 \%s' \% h4.IP())
net.stop()
Cria uma pequena rede (4 hosts, 3 switches), e realiza pings de
um host para o outro (por cerca de 4 segundos)
Nível Aplicação
24
Mininet (3)
Exemplo: ativando o Mininet para criar um switch com OF 1.3
1) No VirtualBox, ative a VM Mininet atual – interface texto.
Login: mininet, Senha:mininet;
2) Peça IP para a interface host-only: sudo dhclient eth1;
3) Na hospedeira, ative um servidor de janelas do padrão X11. O
programa é o Xming.
4) Faça um ssh da hospedeira para a hóspede (endereço
fornecido pelo dhclient do passo 2) marcando que quer enviar
a saída x11 para o servidor X11 da hospedeira: Programa
putty, coloque o IP do host only e marque na opção X11
forwarding como Enable . Faça novamente o log como usuário
mininet.
5) Nesta nova janela chame o emulador de terminal em
background: xterm&
Nível Aplicação
25
Mininet (4)
5) Ativar o programa mininet que veio na máquina virtual do mininet:
$ sudo mn --topo single,3 --mac --controller remote --switch ovsk,
protocols=OpenFlow13
6) Fazer o ovsk também usar o OF 1.3
$ sudo ovs-vsctl set bridge s1 protocols=OpenFlow13
7) Tente fazer com que um host pingue o outro. Há conectividade? Nem
subiu o controlador... No mininet:
> h1 ping h2
8) Iniciar o controlador Ryu com o script que cria um switch que
aprende e emite algumas regras adequadas para este switch:
$ ./ryu/bin/ryu-manager –verbose ./ryu/ryu/app/simple_switch_13.py
Nível Aplicação
26
Mininet (4)
9) Em outra janela, liste os fluxos existentes até o momento (as
regras pré-instaladas)
$ sudo ovs-ofctl dump-flows s1 –O OpenFlow13
10) Tendo ativado o controlador , faça o ping novamente no mn
> h1 ping h2
11) Veja agora como está a tabela de fluxos:
$ sudo ovs-ofctl dump-flows s1 –O OpenFlow13
Inspecione o script simple_switch_13.py
Nível Aplicação
27
Hands On
•
Escrever um script em python para que diferentes fluxos
possam seguir simultaneamente por diferentes caminhos.
• Se existirem dois fluxos da mesma origem para o mesmo
destino não necessariamente seguirão a mesma rota. Dois
caminhos de igual custo tem que ter um critério para
decisão entre eles.
• A decisão de rota deve basear-se no volume de dados em
trânsito na rede atualmente..
• Propor uma estratégia para que a banda seja melhor
aproveitada na rede, ou seja, maximizar a banda total.
Nível Aplicação
28