15 commentaires
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
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.
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
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.
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.
Laisser une réponse
Vous devez être connecté pour poster un message !
yo la team j'ai un souci bizarre on a un prog eBPF en mode XDP sur nos workers K8s pour des raisons de perf ça devrait juste forwarder mais ça droppe des paquets aléatoirement pour certains pods pas tous c super chiant à débugger. la CNI c cilium en tunnel. des idées ?