Eripi2018 p4 tutorial

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

5. INTRODUÇÃO 5

6. Contexto/Motivação 6 @ Infraestrutura das Operadoras de Telecom Source: Ericsson(Adaptado) Acesso Núcleo Nuvem OSS / BSS

7. Crescimento do Tráfego Global 7 Source: Ericsson ExaBytes/month

8. Mudança no paradigma 8

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

12. Programação no Plano de Controle 12

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 ﬂuxos dos equipamentos de rede e fica entre o controlador e switch. 14 Analisa o tráfego de entrada e veriﬁca 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

17. Programação no Plano de Dados Conceitos 17

18. Redes Tradicionais 18 Linux ou Unix

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 Speciﬁc Integrated Circuits (ASIC): Intel Flexpipe, Cisco Doppler, Cavium (Xpliant), Barefoot Toﬁno. • Network Processor Unit (NPU): EZchip, Netronome. • CPU: Open Vswitch, eBPF, DPDK, VPP. • FPGA: Xilinx, Altera. 22

23. Linguagem P4 • Programming Protocol-independent Packet Processors 23 Proposta  Especificação

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); • Reconﬁgurá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. Identiﬁcar 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

49. Desafios 49

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

51. Desempenho 51 Souce: ETSI NFV White Paper 2

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

54. Integração P4, SDN e NFV 54

55. Avanços 55

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

59. Conclusão 59

60. Conclusão • Tradicionais redes são caracterizadas pela forte ligação com hardware ﬁxos 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

61. “ 61 Email: nathansaraiva@gmail.com

62. Backup 62

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

64. Evolução com SDN