XDP e eBPF para processamento de pacotes de alto desempenho

O XDP (eXpress Data Path) e o eBPF (extended Berkeley Packet Filter) permitem que o Linux processe pacotes de rede antes que a pilha de rede normal do kernel entre em ação. Em vez de alocar estruturas de memória para cada pacote recebido, o XDP intercepta o tráfego diretamente no controlador da placa de rede (NIC), decide o que fazer com ele e o descarta, encaminha ou redireciona. O resultado é o processamento de milhões de pacotes por segundo por núcleo, com uma fração da sobrecarga da CPU de ferramentas tradicionais como iptables.

Como o eBPF e o XDP funcionam em conjunto

O eBPF é uma máquina virtual dentro do kernel do Linux. Executa bytecode personalizado que foi verificado quanto à segurança (sem loops infinitos, sem acesso não autorizado à memória) e, em seguida, compilado JIT para instruções nativas da CPU. Os programas têm um âmbito limitado. Não podem chamar funções arbitrárias do kernel, apenas um conjunto de auxiliares predefinidos para tarefas como pesquisas em mapas e redirecionamento de pacotes.

Para a gestão de estado, o eBPF utiliza mapas, que são armazenamentos de chave/valor (tabelas hash, matrizes, árvores LPM) que persistem entre as chegadas de pacotes. Os mapas são legíveis e graváveis a partir do espaço do utilizador, pelo que é possível atualizar listas de bloqueio ou regras de encaminhamento sem recarregar o programa.

O XDP é um ponto de ligação do eBPF. Liga-se ao caminho de receção do controlador da NIC, antes de o kernel alocar uma sk_buff estrutura (o objeto de metadados de 200-300 bytes por pacote do qual a pilha de rede tradicional depende). É ao ignorar essa alocação que se obtém o ganho de desempenho.

O XDP funciona em três modos:

• Modo nativo: funciona dentro do controlador da NIC. Melhor desempenho.
• Modo descarregado: executa-se no ASIC da NIC. Liberta totalmente a CPU.
• Modo genérico: executa-se após sk_buff alocação. Útil para testes em hardware não suportado, mas sem benefício de desempenho.

Após processar cada pacote, o programa XDP devolve um veredicto:

XDP vs iptables: Benchmarks de desempenho

Os números são gritantes. iptables processa cerca de 200 000 pacotes por segundo por núcleo. nftables melhora esse valor para cerca de 400 000 pps. O XDP no modo nativo processa 10 a 40 milhões de pps por núcleo no mesmo hardware.

A razão é simples: um XDP_DROP custa uma verificação de limites e um valor de retorno. Um iptables DROP requer sk_buff alocação, percurso da cadeia do netfilter, pesquisa de rastreamento de conexão, a própria ação DROP e, em seguida, desalocação. A 100 Gbps com pacotes de 64 bytes, um servidor enfrenta 148 milhões de pacotes por segundo, restando cerca de 100 nanossegundos por pacote. Nessa escala, sk_buff a alocação torna-se o gargalo.

A poupança de CPU é igualmente significativa. A mudança de uma lista de bloqueio iptables para o XDP num benchmark reduziu a utilização da CPU por interrupções de software de 28% para 3% a 1 milhão de pps. Esse espaço livre pode ser utilizado para executar processos de aplicações, bases de dados ou máquinas virtuais no mesmo servidor.

Mitigação de DDoS e Segurança

O caso de utilização mais forte do XDP em hospedagem é a mitigação de DDoS. Como opera ao nível do driver, os pacotes maliciosos são descartados antes de atingirem a pilha de rede do kernel. Um único núcleo a executar o XDP pode descartar 26 milhões de pacotes por segundo.

A Cloudflare utiliza um sistema baseado em XDP chamado L4Drop para mitigação de DDoS volumétrico desde, pelo menos, 2018. O sistema processa e rejeita o tráfego de ataque no contexto do XDP, impedindo-o de chegar à camada de aplicação. O Katran da Meta, um balanceador de carga de camada 4 XDP de código aberto, lida com o tráfego do Facebook e do Instagram a mais de 10 milhões de pps por núcleo.

Para filtragem dinâmica, mapas eBPF como BPF_MAP_TYPE_LPM_TRIE permitem gerir listas de bloqueio de IP que abrangem IPs individuais e sub-redes CIDR numa única pesquisa. As atualizações ocorrem a partir do espaço do utilizador em tempo real, sem necessidade de recarregar o programa. Durante um ataque ativo, é possível enviar novas assinaturas em milésimos de segundo utilizando bpftool:

bpftool map update id <MAP_ID> key <KEY_VALUE> value <VALUE>

Para observabilidade, o eBPF recolhe métricas por aplicação, por IP e por fluxo diretamente do caminho de dados do kernel. O xdp_md contexto fornece telemetria como ingress_ifindex e rx_queue_index, para que possa identificar qual a interface ou fila que está sob pressão. Para monitorização a longo prazo, ferramentas como ebpf_exporter convertem dados brutos do mapa eBPF em métricas compatíveis com o Prometheus para visualização no Grafana.

Ferramentas, Implementação e Requisitos de Hardware

A cadeia de ferramentas começa com o Clang e o LLVM para compilar C restrito em bytecode eBPF. A partir daí, é necessária uma biblioteca de carregamento:

• libbpf: a biblioteca C padrão para uso em produção. Suporta CO-RE (Compile Once, Run Everywhere) para portabilidade entre kernels.
• libxdp: específica para XDP, suporta a execução de vários programas XDP numa única interface.
• cilium/ebpf: uma biblioteca Go pura para pilhas baseadas em Go.

Para gestão, bpftool permite inspecionar programas em tempo real e mapear conteúdos. xdp-loader (da xdp-tools suite) lida com o carregamento e descarregamento. O BCC é útil para prototipagem com front-ends Python/Lua, mas libbpf com o CO-RE é a melhor escolha para produção.

Ative o compilador BPF JIT antes da implementação:

sysctl -w net.core.bpf_jit_enable=1

Para atualizações sem tempo de inatividade, use o XDP_FLAGS_REPLACE sinalizador para trocar atomicamente um programa em execução. Fixe os mapas para /sys/fs/bpf/ para que persistam após o carregador sair.

Compatibilidade de hardware e kernel

O XDP foi introduzido no kernel 4.8, mas recomenda-se a versão 5.x ou posterior para o conjunto completo de funcionalidades. Verifique o seu kernel com uname -r e verifique se o sistema de ficheiros BPF existe em /sys/fs/bpf/.

O seu controlador de NIC determina quais as funcionalidades do XDP que estão disponíveis:

Verifique o seu controlador com ethtool -i <interface>. Se o modo nativo não for suportado, o sistema recorre ao modo genérico, que é executado após sk_buff alocação e não oferece qualquer benefício de desempenho.

Desative o GRO e o LRO antes de ligar um programa XDP, uma vez que estes entram em conflito:

ethtool -K <iface> gro off lro off

O XDP padrão exige que os pacotes caibam numa única página de memória de 4.096 bytes. No i40e e ice , o limite de MTU do x86 é de 3.046 bytes.

Introdução ao XDP

Comece por avaliar o seu ambiente. Execute uname -r para confirmar que o kernel é 4.8+ (preferencialmente 5.x) e ethtool -i <interface> para verificar o suporte nativo ao driver XDP.

Comece pela observabilidade, não pela imposição. Use mapas eBPF para classificar e contar o tráfego, de modo a ter uma linha de base da atividade normal. Depois de compreender os seus padrões de tráfego, passe para a imposição: teste primeiro no xdpgeneric modo e, em seguida, mude para xdpdrv (nativo) para produção.

Tenha em mente que o XDP lida com filtragem ao nível do pacote, não com largura de banda bruta. Para ataques em grande escala a 100 Gbps, combine-o com infraestrutura bare-metal e BGP FlowSpec para gerir o tráfego a montante antes que este chegue ao servidor.

Se estiver a executar cargas de trabalho de alto tráfego que necessitem de filtragem rápida de pacotes, os servidores dedicados da FDC fornecem a base bare-metal para tirar o máximo partido do XDP.