eBPF prog en XDP droppe des paquets random sur mon worker K8s

salut ptete un souci d'ordre d'exécution ou un truc avec la CNI. t'as regardé les stats de ton prog avec bpftool prog show ID. et voir si t'as des erreurs ou des drops explicites dans les counters. et un perf record pour les tracepoints réseau ça dirait quoi

c'est cilium en mode xdp native ou generic? des fois ça interagit mal si les chaines sont pas claires. t'as des policy BPF qui pourraient interférer

cilium est en generic mode. les compteurs XDP montrent des drops sur la fonction xdp_drop mais j'arrive pas à voir pourquoi. pas de policy spécifiques à part du routing basique. les paquets droppés sont légitimes c'est pas du random garbage.

hmm generic mode c'est plus compliqué. ton prog s'attend à quoi en fait ? un paquet ethernet pur ? si cilium encapsule avant ton XDP prog voit ptete pas le header eth ou un offset décalé. genre un paquet tunnellisé gre ou vxlan arrive avec un header différent

oui exact j'y pensais. cilium c'est du vxlan en général. donc mon prog simple s'attend à un ethhdr direct. c'est ptete ça le hic. comment on gère ça proprement en xdp ?

faut parser le header du tunnel avant. genre detecter si c'est vxlan u. t'auras un outer eth puis outer ip puis outer udp puis vxlan header puis le inner eth. ton prog doit ignorer tout ça ou décap avant de regarder le inner eth.

struct ethhdr *eth;
struct iphdr *iph;
struct udphdr *udph;
struct vxlanhdr *vnh;

// ... parse outer eth/ip/udp ...

if (udph->dest == bpf_htons(VXLAN_PORT)) {
  // Found VXLAN, now parse inner packet
  eth = (void *)udph + sizeof(struct udphdr) + sizeof(struct vxlanhdr);
  if ((void *)eth + sizeof(struct ethhdr) > data_end)
    return XDP_DROP;

  // Now eth points to the inner Ethernet header
  if (bpf_ntohs(eth->h_proto) == ETH_P_IP)
    return XDP_PASS;
}

ok je vois. c'est un peu plus lourd que prévu. je vais tenter de modifier le prog pour qu'il check les headers vxlan. ça veut dire que pour les paquets non tunnellisés il va se prendre les pieds dans le tapis aussi.

non tu peux faire un check conditionnel. si c vxlan tu pars le tunnel sinon tu pars le header eth normal. faut être précis avec les offsets. c le challenge des progs XDP qui doivent être hyper rapides

ouais et n'oublie pas les bpf_printk pour débugger dans dmesg ça aide énormément quand tu galères avec les offsets

j'ai mis ça en place mais j'ai encore des drops. je pense que mon offset est pas bon après le vxlan hdr. je suis toujours sur la même base

t'as essayé de choper un paquet droppé avec tcpdump sur l'interface avant xdp et un autre après pour comparer les headers? ou bpftrace pour tracer les offsets exacts que ton prog voit

j'ai fait un tcpdump sur la veth des pods et sur l'interface du node. les paquets qui arrivent au node sont bien encapsulés en vxlan mais certains ont un offset bizarre après le vxlan header genre le ethhdr n'est pas là où je l'attends.

c'est quelle version de kernel? et de cilium? des fois il y a des variations dans l'encapsulation ou le hardware offload qui peut foutre le boxon

j'ai trouvé ! c'était ma faute j'avais mal géré la taille du vxlan header dans le calcul de l'offset pour certains cas spécifiques de fragmentation. un petit ajustement et c niquel. putain la galère pour un offset.

tout est rentré dans l'ordre les drops ont disparu. merci à tous pour l'aide ça m'a bien aiguillé sur les offsets et les headers de tunnel. fallait juste que je recalcule ma logique de parsing.