Dia 29: Rede Definida por Software — SDN, OpenFlow e Open vSwitch

A rede tradicional baseia-se em equipamentos onde o plano de controlo (a decisao de encaminhamento) e o plano de dados (o encaminhamento efectivo) vivem juntos dentro de cada switch ou router. A Rede Definida por Software (SDN) parte desse modelo: separa as duas funcoes e centraliza o controlo num programa externo. Este artigo do curso de redes em 30 dias explora SDN, o protocolo OpenFlow, o Open vSwitch, os controladores SDN, o emulador Mininet e como uma PME pode aproveitar esta abordagem.

Este artigo faz parte da serie Curso de Redes em 30 Dias. Consulte tambem o Dia 22 — VLANs e Segmentacao de Rede, o Dia 4 — Modelo OSI e Encapsulamento e o Dia 17 — DNS Interno com BIND9.

Neste artigo

ℹ O SDN separa o plano de controlo do plano de dados — o controlador decide o encaminho, os switches apenas executam.

1. Introducao ao SDN

SDN (Software-Defined Networking) é um paradigma de arquitectura de rede que separa o plano de controlo (control plane) do plano de dados (data plane). Na rede tradicional, cada switch ou router executa localmente o seu proprio software de encaminhamento (OSPF, BGP, STP) e mantem a sua tabela de encaminhamento. No SDN, essas decisoes sao centralizadas num controlador — uma aplicacao externa que programa todos os switches da rede atraves de um protocolo de gestao.

Esta separacao traz tres vantagens fundamentais:

  • Visao global da rede: o controlador conhece toda a topologia e pode calcular caminhos optimizados em vez de depender de protocolos distribuídos que convergem lentamente.
  • Programabilidade: as regras de encaminhamento sao definidas em software — pode-se escrever lógica customizada em Python, Java ou Go em vez de depender de configuracao estatica por CLI.
  • Automacao: mudancas de politica (QoS, segmentacao, balanco de carga) aplicam-se instantaneamente a todos os switches atraves de uma unica API.

O SDN nao e um produto especifico — e uma arquitectura. Existem varias implementacoes, mas o ecossistema código aberto mais maduro assenta em tres pilares: o protocolo OpenFlow para comunicacao controlador-switch, o Open vSwitch como switch virtual, e o Mininet como emulador para desenvolvimento e teste.

Aspecto Rede Tradicional Rede SDN
Plano de controlo Distribuído em cada switch Centralizado no controlador
Plano de dados No proprio switch No switch (executa regras)
Programabilidade CLI/SNMP por equipamento API centralizada (REST, Python)
Visao da topologia Local (cada no ve os vizinhos) Global (controlador vê toda a rede)
Convergência Segundos a minutos (STP, OSPF) Instantânea (controlador calcula)

A arquitectura SDN divide-se tipicamente em tres camadas: a camada de infra-estrutura (os switches fisicos ou virtuais que encaminham pacotes), a camada de controlo (o controlador SDN que decide as regras) e a camada de aplicacao (programas que implementam lógica de rede — balanceamento, firewalling, monitorizacao). A comunicacao entre a camada de aplicacao e o controlador chama-se Northbound API; a comunicacao entre o controlador e os switches e a Southbound API, tipicamente OpenFlow.

2. OpenFlow — O Protocolo

OpenFlow e o protocolo de comunicacao padronizado entre o controlador SDN e os switches. Foi definido pela Open Networking Foundation (ONF) e a sua especificacao atual e a versao 1.5. Permite que o controlador instale, remova e consulte flows (regras de encaminhamento) nos switches de forma programatica.

Um flow e composto por dois elementos: o match (os criterios de correspondencia — endereco MAC de origem, IP de destino, porta TCP, VLAN, etc.) e a action (o que fazer com os pacotes que correspondem — enviar para uma porta, descartar, modificar campos, enviar ao controlador). Quando um pacote chega a um switch e nao corresponde a nenhum flow instalado, o switch envia-o ao controlador (packet-in) para que este decida o que fazer e instale a regra apropriada (flow-mod).

A especificacao completa do OpenFlow esta disponivel no site da Open Networking Foundation.

Os campos de match suportados pelo OpenFlow cobrem os headers das varias camadas do modelo OSI:

  • Camada 2: endereco MAC de origem e destino, VLAN ID, prioridade VLAN, tipo de Ethernet.
  • Camada 3: endereco IP de origem e destino, tipo de protocolo (TCP, UDP, ICMP), DSCP/TOS.
  • Camada 4: porta TCP/UDP de origem e destino, flags TCP (SYN, ACK, FIN).
  • Metadata: portas de entrada do switch, metadados definidos por flows anteriores (pipeline).

As accoes possíveis incluem: output:PORTA (enviar para uma porta), drop (descartar), controller (enviar ao controlador), mod_dl_dst (alterar MAC destino), mod_nw_dst (alterar IP destino) e group (aplicar accoes de grupo — usado para multipath e failover).

Um flow tem tambem prioridade, timeout idle (segundos sem match apos os quais o flow expira) e timeout hard (tempo maximo de vida independentemente de match). Isto permite que o switch remova regras obsoletas automaticamente sem intervencacao do controlador.

3. Open vSwitch (OVS)

O Open vSwitch (OVS) e um switch virtual código aberto que implementa o protocolo OpenFlow. E o switch mais utilizado em ambientes de virtualizacao e nuvem — esta integrado no KVM, Xen, Proxmox VE, e e a base de rede do OpenStack. Corre em Linux e suporta as principais funcionalidades de um switch fisico: VLANs, bonding, QoS, mirror de portas, sFlow/NetFlow para monitorizacao e, naturalmente, OpenFlow.

O OVS organiza-se em torno de bridges (switches virtuais) as quais se ligam portas (interfaces de rede fisicas, tap devices para VMs, ou interfaces internas). A configuracao persiste numa base de dados propria (OVSDB) é gerida atraves do comando ovs-vsctl para configuracao da bridge e ovs-ofctl para manipular flows OpenFlow directamente.

# Instalar Open vSwitch
apt install openvswitch-switch
# Criar bridge OVS
ovs-vsctl add-br br0
ovs-vsctl add-port br0 eth0
ovs-vsctl add-port br0 eth1
# Verificar
ovs-vsctl show
# Configurar flow (OpenFlow)
ovs-ofctl add-flow br0 "ip,nw_dst=192.168.1.0/24,actions=output:1"
ovs-ofctl dump-flows br0
# Mininet — topologia simples
mn --topo single,3 --controller remote
# Mininet — topologia em arvore
mn --topo tree,depth=2,fanout=2
# Verificar links OVS
ovs-vsctl list interface
ovs-appctl fdb/show br0

O comando ovs-vsctl show lista todas as bridges, portas e interfaces configuradas. O ovs-ofctl dump-flows br0 mostra todos os flows OpenFlow actualmente instalados na bridge — essencial para depurar regras de encaminhamento. O ovs-appctl fdb/show br0 apresenta a tabela de aprendizagem de MAC (forwarding database) útil para verificar se o switch esta a aprender os enderecos correctamente.

Para ligar o OVS a um controlador remoto, usa-se ovs-vsctl set-controller br0 tcp:192.168.1.100:6633. A partir desse momento, o controlador passa a gerir os flows da bridge. Se o controlador cair, o OVS pode funcionar em modo fail-secure (mantem os flows existentes) ou fail-standalone (comporta-se como um switch L2 tradicional com aprendizagem de MAC).

4. Controladores SDN

O controlador SDN e o cerebro da rede — mantem a visao global da topologia, responde a eventos dos switches (packet-in, port-status, link-down) e instala flows atraves da southbound API. As aplicacoes de rede correm por cima do controlador atraves da northbound API e implementam a lógica de encaminhamento, QoS, firewall, balanceamento de carga, entre outras.

⚠ Um controlador SDN sem redundancia e um ponto unico de falha — sempre implementar controladores em cluster.

Os controladores mais relevantes no ecossistema código aberto sao:

  • OpenDaylight (ODL): plataforma modular em Java, mantida pela Linux Foundation. Suporta OpenFlow, NETCONF, RESTCONF. Muito utilizada em ambientes empresariais e proveedores de cloud.
  • ONOS (Open Network Operating System): optimizado para alta disponibilidade e escalabilidade — suporte nativo para clustering. Muito usado em redes de operadores (carrier-grade).
  • Ryu: controlador leve em Python, ideal para desenvolvimento e prototipagem. A API Python permite escrever aplicacoes SDN em poucas linhas de codigo.
  • Floodlight: controlador em Java, código aberto, com comunidade activa. Simples de instalar e com REST API completa.

A escolha do controlador depende do caso de uso: Ryu para aprendizagem e prototipos, ONOS para producao carrier-grade, OpenDaylight para integracao empresarial com multiples protocolos southbound. Em todos os casos, a alta disponibilidade e obrigatoria em producao — um unico controlador e um ponto unico de falha que derruba toda a rede se cair.

Exemplo de uma aplicacao Ryu simples que implementa aprendizagem de MAC (learning switch) em menos de 50 linhas de Python: o controlador recebe packet-in quando um switch nao tem flow para um MAC destino, aprende a porta de origem, instala um flow, e faz flood se o destino ainda for desconhecido. Este e o padrao basico de quase todas as aplicacoes SDN.

5. Mininet — Emulador de Redes

Mininet e um emulador de redes que cria topologias realistas usando processos Linux e namespaces de rede. Cada nó da topologia (hospedeiro, switch, controlador) e um processo isolado que partilha o kernel Linux — por isso, o desempenho e proximo de rede real, ao contrario de simuladores que modelam o comportamento matematicamente. Mininet utiliza OVS como switch por defeito e permite ligar controladores externos (Ryu, ONOS, OpenDaylight) ou usar o controlador interno de referencia.

As topologias mais comuns para teste sao:

  • mn --topo single,3 — um switch com 3 hosts (topologia minima para testar flows basicos).
  • mn --topo tree,depth=2,fanout=2 — arvore com 2 niveis e 2 ramos por no (3 switches, 4 hosts).
  • mn --topo linear,3 — 3 switches em linha, 1 host por switch (testar encaminhamento multi-salto).
  • mn --controller remote — liga a um controlador externo (essencial para testar aplicacoes SDN).

Dentro da CLI do Mininet, comandos como pingall (testa conectividade entre todos os pares de hosts), iperf h1 h2 (mede largura de banda entre dois hosts), dpctl dump-flows (mostra flows em todos os switches) e py net.addHost('h4') (manipula a topologia em Python) permitem validar o comportamento da rede em tempo real.

Mininet e a ferramenta padrao para desenvolver e testar aplicacoes SDN antes de implementar em hardware real. Permite criar, destruir e recriar topologias complexas em segundos — algo impossivel com switches fisicos. Para alem disso, scripts Python do Mininet podem ser versionados em git, permitindo testes reprodutiveis.

6. SDN para PME

Para uma PME, o SDN pode parecer uma tecnologia de operador ou de grandes centros de dados, mas ha varios casos de uso praticos onde traz valor imediato. O OVS vem pre-instalado em praticamente todas as plataformas de virtualizacao (Proxmox, KVM, OpenStack), o que significa que muitas PME ja tem SDN sem saber.

Casos de uso concretos para PME:

  • Micro-segmentacao em virtualizacao: em vez de criar VLANs estaticas no switch fisico, usar OVS com flows OpenFlow para isolar VMs individualmente — cada VM so fala com as VMs autorizadas, mesmo na mesma subrede. Isto reduz a superficie de ataque sem hardware adicional.
  • Rede multi-tenant: uma PME que oferece servicos alojados pode usar SDN para criar redes virtuais isoladas por cliente sobre a mesma infra-estrutura fisica, sem precisar de switches caros com suporte VRF.
  • Balanceamento de carga L4: um controlador SDN pode distribuir ligacoes TCP entre varios servidores internos com base na porta de destino — uma alternativa leve ao HAProxy ou a appliances dedicados.
  • Redirecionamento de trafego: enviar todo o trafego web por um proxy de filtragem, ou redirecionar portas para servidores de cópia de segurança durante janelas de manutencao, tudo sem reconfigurar switches fisicos.
  • Monitorizacao centralizada: o controlador tem visao de toda a rede e pode exportar estatisticas via REST API para integracao com Grafana, Zabbix ou Prometheus.

O custo de entrada e baixo: Mininet é gratuito, OVS e código aberto, e controladores como Ryu ou Floodlight nao tem custo de licenca. A curva de aprendizagem e a principal barreira — exige conhecimentos de Python, OpenFlow e conceitos de rede que vao alem da configuracao CLI tradicional. Para uma PME com um administrador de sistemas confortavel com scripting, o SDN e uma evolucao natural.

Uma abordagem pragmatica: comecar com Mininet para aprender os conceitos num ambiente isolado, depois aplicar OVS com flows manuais (ovs-ofctl) numa rede de teste, e finalmente introduzir um controlador (Ryu para simplicidade, ONOS para producao) quando se precisa de automacao dinamica.

7. Erros Comuns e Lista de Verificacao

A transicao da rede tradicional para SDN introduz novos pontos de falha e armadilhas. Estes sao os erros mais frequentes e como evitá-los:

Causa Problema Solucao
Controlador unico Falha total da rede se o controlador cair Cluster de 3+ controladores (ONOS, ODL)
Flows sem timeout Switch fica com regras obsoletas Definir idle_timeout e hard_timeout
Modo fail-secure sem plano Trafego parado quando controlador cai Configurar fail-standalone ou flows backup
Prioridade 0 em tudo Flows especificos ignorados Usar prioridades: regras especificas > gerais
OVSDB nao persiste Configuracao perdida apos reboot Verificar ovsdb-server e ficheiro .conf
Testar direto em producao Flux errado derruba conectividade Validar em Mininet antes de implementar

Lista de verificacao para implementacao SDN:

  • ✓ Controlador em cluster (minimo 3 nós) com quorum configurado.
  • ✓ Endereco IP do controlador documentado e fixo (nao DHCP).
  • ✓ Porta OpenFlow (6633 ou 6653) aberta na firewall entre switches e controlador.
  • ✓ Flows de fallback (prioridade baixa) para manter conectividade se o controlador cair.
  • ✓ idle_timeout definido em flows dinamicos (300-600s tipico).
  • ✓ Monitorizacao do controlador (CPU, memoria, latencia de packet-in).
  • ✓ Backups da configuracao OVSDB (ovs-vsctl --all --backup).
  • ✓ Testes em Mininet antes de aplicar flows em producao.
  • ✓ Documentacao das regras OpenFlow com justificacao de cada flow.
  • ✓ Plano de rollback para rede tradicional em caso de falha critica.

O SDN nao substitui a rede tradicional da noite para o dia — e uma evolucao que comeca com casos de uso especificos (virtualizacao, micro-segmentacao) e cresce conforme a equipa ganha confianca. A chave é começar pequeno em ambiente de teste, documentar exaustivamente, e nunca implementar em producao sem um plano de rollback.

Amanha, no ultimo dia do curso, vamos integrar todos os topicos numa revisao geral do percurso de 30 dias. Se tem duvidas sobre SDN, OpenFlow ou OVS, deixe comentario — respondo a todas as questoes.