SlideShare uses cookies to improve functionality and performance, and to provide you with relevant advertising. If you continue browsing the site, you agree to the use of cookies on this website. See our User Agreement and Privacy Policy.
SlideShare uses cookies to improve functionality and performance, and to provide you with relevant advertising. If you continue browsing the site, you agree to the use of cookies on this website. See our Privacy Policy and User Agreement for details.
Successfully reported this slideshow.
Activate your 14 day free trial to unlock unlimited reading.
1.
1
Uma nova revolução em redes: Programação
do plano de dados com P4
Minicurso 05 – 15 de agosto de 2018
Daniel Laskani
Juan Sebastian Mejia
Nathan Saraiva de Sousa
Christian Esteve Rothenberg
2.
Currículo 2
• Nathan Saraiva
• Titulação
• Tecnólogo em Redes de Comunicação – IFPI
• Especilaista em Redes de Computadores - FSA
• Graduação e Mestrado em Ciência da Computação - UFPI
• Estudante de Doutorado em Engenharia Elétrica/Computação – UNICAMP
• Experiências
• FAPEPI/PoP-RNP
• UESPI (Analista e Professor de Especialização), FAP, INTA, FAESF, CET (Tecnólogo e
Especialização)
• IFPI
• Linhas de Pesquisa
• SDN
• NFV
• Orquestração Multi domínio.
• CV: http://lattes.cnpq.br/6190003234095907
• Email: nsaraiva@dca.fee.unicamp.br
3.
Agenda
• Parte I :: 08:30 – 10:30
○ Introdução
○ Programação no Plano de Controle
• Conceitos
• OpenFlow
○ Programação no Plano de Dados
• Linguagem P4
○ Atividades práticas
• Simple router
• Load Balancing
• Parte II :: 10:30 – 12:00
○ Atividades práticas
• ACL
• NAT
○ Desafios
○ Avanços
○ Conclusão
3
4.
Objetivos
• Apresentar uma visão geral na área de programação do
plano de dados.
• Abordar os princípios do:
○ Plano de dados;
○ Plano de controle;
• Introduzir atividades práticas com:
○ Linguagem P4;
• Versão 14 e 16
• Discutir os principais desafios e avanços.
4
9.
Definindo “Softwarização” de Rede 9
Possibilidade da rede ser
programável e flexível se
adequando às necessidades
dos clientes e do tráfego de
rede.
10.
Softwarização de Rede 10
Network Softwarization
FlexibilidadeEscalabilidadeAutomaçãoAgilidade
Redes Móveis, Redes 5G Internet das Coisas
Network Slicing
11.
Cenário SDN
• SDN: centralizar logicamente as redes e torná-las mais
flexíveis.
○ Protocolo OpenFlow com suporte a multiplos cabeçalhos
○ Não existia uma programabilidade no processamento de pacotes
• A atenção voltou-se para a programação do plano de
dados
○ Linguagem de processamento de pacotes P4 (Programming Protocol-
independent Packet Processors)
11
13.
Definição de SDN
• Separação entre o plano de controle e
plano de dados.
• Logicamente centralizadas através de
um controlador SDN ou Sistema
Operacional de Rede (NOS)
• Objetivo: Redes flexíveis,
programáveis e robustas.
• Interface southbound de referência:
○ OpenFlow
13
14.
OpenFlow
• Primeiro protocolo padrão SDN
• Protocolo que proporciona acesso à tabela de fluxos dos
equipamentos de rede e fica entre o controlador e switch.
14
Analisa o tráfego de
entrada e verifica regras
Controla e gerencia a rede
15.
OpenFlow 1.0 15
Classifier Action
Modify Field
Enqueue
Forward
NORMAL
FLOOD
Virtual
Port
Physical Port
Forward
Mandatory Action
Optional Action
Statistics
Classifier Action Statistics
Classifier Action Statistics
Classifier Action Statistics
…
Ingress
Port
Ethernet
SA DA Type
IP
SA DA Proto
TCP/UDP
Src
VLAN
ID Priority TOS Dst
Virtual
Port
ALL
CONTROLLER
LOCAL
TABLE
IN_PORT
Drop
Tabela de Fluxos
16.
Evolução do OpenFlow
• Limitações do OpenFlow 1.0
○ Número de campos;
○ Definição de regras mais complexas com múltipas tabelas.
• Novas versões:
16
19.
Ciclo para Novas Funcionalidades 19
Network
Equipment
Vendor
Network
Owner
ASIC
Team
Software
Team
Feature
Years
Source: Nick McKeown. “Programmable forwarding planes are here to stay”. In ACM SIGCOMM NetPL 2017
20.
Evolução na rede de dados
• No modelo tradicional, o software era projetado para se
adequar as características do processador.
• Impossibilitava rápidos updates e dificultava a evolução
• Novas direções:
○ (Re)programar o plano de dados para adicionar novos serviços e
funcionalidades
○ Não precisaria trocar os equipamentos
○ Ciclo para novas funcionalidades: dias ou horas
20
21.
Rede Programável 21
Contudo a programação dos
processadores é difícil. Portanto, é
necessário uma linguagem de alto
nível que consiga abstrair o plano de
dados e permita programar como os
equipamentos de rede devem se
comportar.
22.
Tecnologias promissoras
• Nova geração de switches Application Specific Integrated
Circuits (ASIC): Intel Flexpipe, Cisco Doppler, Cavium
(Xpliant), Barefoot Tofino.
• Network Processor Unit (NPU): EZchip, Netronome.
• CPU: Open Vswitch, eBPF, DPDK, VPP.
• FPGA: Xilinx, Altera.
22
24.
Definição da Linguagem P4
• Linguagem para expressar como os pacotes
são processados pelos elementos de rede
programáveis do plano de dados de tais como
switch de hardware e software, Interface de
rede e roteadores.
24
25.
Objetivos do P4
• Independência do protocolo
○ Switch não deve ser atrelado à qualquer protocolo de rede ou formato de
pacote;
• Independência de arquitetura
○ P4 não deve se preocupar com detalhes dos equipamentos de
processamento de pacotes (compilador);
• Reconfigurável em campo
○ Programadores devem ser capaz de alterar o processamento dos pacotes
nos equipamentos de rede mesmo eles já implantados.
25
26.
Modelo de Encaminhamento
• A linguagem P4 se baseia na arquitetura PISA (Protocol-
Independent Switch Architecture).
26
Generaliza como os pacotes são processados em diferentes equipamentos e
em diferrentes tecnologias (PISA, NPU, FPGA).
27.
Programa P4_14 27
Lista de campos
ordenados com
nome e tamanho.
Identificar e extrair
os valores dos
cabeçalhos.
Transformar
pacotes de array
de bytes em
representações
estruturadas.
Funções
customizadas
compostas de
ações primitivas.
Relação entre os
campos dos
pacotes e as ações.
28.
Compilador P4
• Compilador específico para cada dispositivo (hw ou sw).
• Mapeia a descrição do programa em difinições do
equipamento.
• Dois estágios da compilação:
○ Programa P4 é convertido em grafos de dependência;
○ Mapeamento para recursos específicos do equipamento;
• Versão atual: 16
• Informações: http://p4.org
28
29.
Compilador P4
• O compilador pode gerar diferentes arquivos de saída.
○ p4c-bm2-ss: gera arquivos do tipo JSON
○ p4c-ebpf: gera código em C para o target eBNF
○ P4c-graphs: gerar representações gráficas de um program P4
29
30.
P4 versão 16
• Suporte à multiplas arquiteturas:
○ Execução do program em mútiplos dispositivos:
• FPGA
• Placas de redes
• Software switch
• Simplicidade:
○ Simplificou commandos e primitivas
• Ex: add_to_field(a,b) a = a + b
• Compatibilidade:
○ Retro-compatibilidade com futuras versões.
• Extensibilidade:
○ Modulos externos para específicos targets.
30
31.
Limitações do P4 versão 16
• Sem suporte à:
○ Loops (somente nos analisadores – parsers)
○ Função recursiva
○ Alocação de memória
○ Ponteiros ou referências
○ Multicast
○ Deep-packet Inspection
○ Geração de novos pacotes
○ Segmentação de pacotes (TCP)
• Não existe um padrão de comunicação com o plano de
controle
31
32.
Atividade Prática
• Passos Iniciais:
• Acessar a máquina virtual usando as credenciais:
○ Usuário: P4
○ Senha: p4
• Criar as interfaces virtuais
○ $ cd /home/p4/behavioral-model/
○ $ sudo ./tools/veth_setup.sh
32
33.
Atividade Prática::simple_router
• Será utilizado o mininet para simular a topologia
• Objetivo: Roteamento entre as estações
33
34.
Comandos (1/2)
• Compilar o programa P4 e gerar o arquivo do tipo json
para o dispositivo "simple_router" conforme os comandos
abaixo:
○ $ cd behavioral-model/targets/simple_router
○ $ sudo p4c-bmv2 --json simple_router.json simple_router.p4
• Executar o roteador virtual "simple_router" usando o
mininet:
○ $ cd behavioral-model/mininet/
○ $ sudo python 1sw_demo.py --behavioral-exe
../targets/simple_router/simple_router --json
../targets/simple_router/simple_router.json
34
35.
Comandos (2/2)
• CLI do mininet testar o ping entre os dois hosts;
○ > h1 ping h2
• Em um outro terminal, rodar a aplicação para popular as
tabelas do roteador.
○ $ cd behavioral-model/targets/simple_router/
○ $ ./runtime_CLI < commands.txt
• Testar novamente o ping
35
36.
Atividade Prática::simple_switch_lb
• Topologia formada por dois hosts e dois servidores
• Objetivo: Balanceamento de carga para dois servidores
usando um switch
36
37.
Comandos (1/2)
• Compilar o programa P4 e gerar o arquivo do tipo json
para o dispositivo "simple_switch" conforme os comandos
abaixo:
○ $ cd behavioral-model/targets/simple_router_lb
○ $ sudo p4c-bmv2 --json simple_router_lb.json simple_router_lb.p4
• Iniciar o switch com o seguinte comando:
○ $ sudo ./simple_switch -i 0@veth1 -i 0@veth0 -i 1@veth3 simple_router_lb.json
37
38.
Comandos (2/2)
• Em um outro terminal popular as tabelas:
○ $ cd /home/p4/behavioral-model/targets/simple_router_lb
○ $ sudo ./runtime_CLI < commands.txt
• Executar o tcpdump
○ $ sudo tcpdump -XXi veth3
• Gerar um tráfego alterando o IP de origem
○ $ sudo scapy
○ >>> pkt1 = Ether(dst='a2:5e:37:ac:a1:7f',src='fa:4f:e8:df:b1:5f')
○ /IP(dst='10.0.0.10',src='214.1.1.2')
○ >>> pkt2 = Ether(dst='a2:5e:37:ac:a1:7f',src='fa:4f:e8:df:b1:5f')
○ /IP(dst='10.0.0.10',src='213.1.1.1')
○ >>> sendp(pkt1,iface="veth0",count=1);
○ >>> sendp(pkt2,iface="veth0",count=1);
38
39.
Resultado
• Saída do tcpdump
39
Vale ressaltar que o balanceamento aleatório é feito apenas no primeiro acesso
do host, já que uma vez determinado o servidor que atenderá o cliente, esse será
sempre o mesmo.
40.
Atividade Prática::Fluxograma
• Gerar fluxogramas de diferentes
partes do P4
• Exemplo: simple_router
• Comando:
○ $ p4-graphs simple_router.p4
40
Dependências das tabelas
no ingress
41.
Fluxograma dos parser Fluxograma das tabelas
41
42.
Atividade Prática::simple_router+acl
• Topologia similar à primeira atividade prática com a adição
de uma lista de controle de acesso.
• Objetivo: Controle de acesso na porta 80
42
43.
Comandos (1/3)
• Compilar o arquivo .p4 para o formato JSON
○ $ cd ~/minicurso_p4/examples/acl/
○ $ sudo p4c-bm2-ss simple_acl_16.p4 -o ss_acl.json
• Iniciar a topologia usando o mininet:
○ $ cd ~/behavioral-model/mininet/
○ $ sudo python 1sw_demo.py --behavioral-exe
../targets/simple_switch/simple_switch --json
~/minicurso_p4/examples/acl/ss_acl.json
• Popular as tabelas
○ $ cd ~/behavioral-model/targets/simple_switch
○ $ ./runtime_CLI < ~/minicurso_p4/examples/acl/acl_comm.txt
43
44.
Comandos (2/3)
• Inserir teste do ping
○ mininet> h1 ping h2
• Adicionar nova entrada para bloqueio do tráfego
○ $ ./runtime_CLI
○ RuntimeCmd:table_set_default acl _drop
• Testar novamente o ping. O mesmo deve estar bloqueado.
• Console do mininet abrir os terminais do h1 e h2.
○ Mininet> xterm h1 h2
44
45.
Comandos (3/3)
• No terminal do h2 executar:
○ # fuser –k 80/tcp
○ # pushd ~/minicurso_p4/examples/acl/webpage/; python3 -m http.server
80 &
• No terminal do h1 executar:
○ # curl http://10.0.1.10
• Adicionar nova entrada na tabela acl:
○ $ ./runtime_CLI
○ RuntimeCmd: table_set_default acl _nop
• Testar novamente o acesso ao h2 a partir do h1:
○ # curl http://10.0.1.10
45
46.
Atividade Prática::NAT
• O ambiente utilizará o BMv2 e wireshark para similar a
topologia.
• Objetivo: Conectar duas estações através de um servidor
NAT.
46
47.
Comandos (1/2)
• Compilar o arquivo .p4 para o formato JSON
○ $ cd ~/nat
○ $ sudo p4c-bm2-ss nat.p4 -o nat.json
• Iniciar o servidor NAT com target simple_switch:
○ $ sudo simple_switch -i 1@veth1 -i 2@veth3 --thrift-port 9090 --nanolog
ipc:///tmp/bm-0-log.ipc --device-id 0 nat.json
• Popular as tabelas
○ $ ./runtime_CLI < nat_entries.txt
47
48.
Comandos (2/2)
• Executar o wireshark nas interfaces veth1 e veth3:
○ $ sudo wireshark
• Teste de upload:
○ $ sudo python send_packet.py
○ Verificar os pacotes no wireshark
• Teste de download:
○ $ sudo python send_packet.py –-dl
○ Verificar os pacotes no wireshark
48
50.
Desempenho
• Redes estão cada vez mais virtualizadas utilizando
tecnologias como SDN e NFV.
• Um dos primeiros questionamentos é o desempenho. E
isso se reflete no plano de dados.
• O cenário vem mudando e o gap de desempenho entre
hardware e software vem diminuindo.
○ DPDK
○ ClickOS
○ FPGA
50
52.
Segurança
• Outro importante ponto é a segurança.
• Em um ambiente softwarizado isso é mais crítico.
• Então, novos sistemas de autenticação, identidade e
controle de acesso necessitam ser adequados.
• Evitar:
○ Acesso indevidos às tabelas
○ Manipulação de metadados
○ Popular indevidamente os equipamentos
52
53.
Integração P4, SDN e NFV
• Tecnologias propõem diversas
inovações e arquiteturas voltadas
para a programabilidade em redes.
• Elas são tecnologias complementares.
• P4 e SDN são interligadas
○ Não existe uma padronização
• SDN e NFV são tecnologias
independentes.
53
P4
56.
Hardware
• Dois hardwares se destacam em termos de processadores
programáveis.
○ Tofino
• Barefoot Networks (Lideres da organização P4)
• Primeiro switch Ethernet programável
• Atingue velocidade de até 6.5 Tb/s
• Ambiente de Industria
○ FPGA
• Ambiente de pesquisa
• Chegam a mais de 10 Gbps
• Baixa latência
56
57.
Novas aplicações
• Balanceador de carga na camada de transporte
• Controle de congestionamento de baixa latência
• Telemetria de rede in-band
• Melhora no desempenho da velocidade de rede
• Implementação do VxLAN
57
58.
Compiladores
• Devido ao sucesso do P4 novos compiladores estão
surgindo para vários tipos de dispositivos alvos.
○ MACSAD
• Modular multi-arquitetura para plano de dados abstratos
• https://github.com/intrig-unicamp/macsad
○ T4p4s
• Compilador multi-target específico para o P4
• https://github.com/P4ELTE/t4p4s
58
60.
Conclusão
• Tradicionais redes são caracterizadas pela forte ligação
com hardware fixos e proprietários.
• As tecnologias como NFV, SDN e, mais recentemente, a
programação do plano de dados estão proporcionando:
○ Automação,
○ Escalabilidade e
○ Flexibilidade às redes de computadores.
• Embora a linguagem P4 mostra-se bem recente
observamos muitos avanços, e por ter a mesma origem do
SDN espera-se o mesmo sucesso.
60
63.
Definição de SDN 63
“OpenFlow is SDN, but SDN is not OpenFlow” ̶̶̶̶̶̶̶̶̶ Networking community
(Does not say much about SDN)
“Don’t let humans do machines’ work” ̶̶̶̶̶̶̶̶̶ Networking Professional
(probably right…)
“Let’s call SDN whatever we can ship today” ̶̶̶̶̶̶̶̶̶ Vendor X
(aka SDN washing)
“SDN is the magic buzzword that will bring us VC funding” ̶̶̶̶̶̶̶̶̶ Startup Y
(hmmm… N/A, N/C)
“SDN is the magic acronym that will get my paper/grant accepted” ̶̶̶̶̶̶̶̶̶ Researcher Z
(maybe but not at tier 1 conferences / funding agencies)
Redes cuja infraestrutura física e
lógica são separadas em planos de
controles diferentes