BGP flapping et saturation IRQ sur edge nodes 100G

tes keepalives BGP se font drop car ton noyau arrive pas à traiter les paquets de contrôle assez vite. regarde ton /proc/net/softnet_stat.

regarde aussi si tes interruptions réseau sont pas toutes sur le core 0. par défaut linux fait souvent de la merde avec l'irqbalance.

softnet_stat montre des drops sur la première colonne. et effectivement htop montre un core (cpu 0) à 100% en 'si' alors que les autres glandent.

c'est ton problème. ksoftirqd/0 est saturé. il traite tous les paquets et bird a pas de slot pour envoyer ses keepalives. faut virer irqbalance et pinner tes queues manuellement.

t'as combien de queues sur tes NIC ?

ethtool -l eth0

j'ai 32 queues. mais elles semblent toutes mapper sur les cores 0-31 du premier socket. voilà le retour d'ethtool :

Combined: 32

faut que tu fasses du RSS (Receive Side Scaling) propre. et surtout bind tes process critiques comme bird sur des cores qui font pas d'irq réseau.

je viens de tester un script de pinning manuel des irq sur les cores 1-31. j'ai laissé le core 0 et le core 32 libres.

for i in {0..31}; do
  echo $i > /proc/irq/$(cat /proc/interrupts | grep "eth0-$i" | cut -d: -f1 | tr -d ' ')/smp_affinity_list
done

mieux. mais bird peut toujours se faire squeeze. utilise isolcpus ou cpuset pour dédier des cores au control plane.

vérifie aussi ton buffer ring. si tu prends des bursts à 100G les réglages par défaut sont trop faibles.

ethtool -g eth0

les rings étaient à 1024. je les ai montés à 4096. le nombre de drops dans softnet_stat a l'air de diminuer mais j'ai encore des 'si' élevés sur les cores de tête.

active le RFS (Receive Flow Steering) pour que le traitement remonte au core où l'appli tourne. ça aide pour bird si le socket tcp est bien géré.

et augmente le net.core.netdev_budget. par défaut c'est 300. passe le à 600 ou 1000 pour que le noyau traite plus de paquets par cycle d'interruption.

j'ai appliqué ça :

sysctl -w net.core.netdev_budget=1000
sysctl -w net.core.netdev_max_backlog=5000

depuis les changements sur le budget et le pinning manuel des queues sur les deux sockets les sessions BGP bougent plus. même à 60Gbps constant.

le core 0 respire enfin. le trafic est bien étalé. merci pour le debug bas niveau c'était bien l'irq steering qui foutait la zone sur le control plane.

je vais automatiser ça avec un script udev pour les prochains nodes. sujet clos.