Bonjour Gautier, Quand tu parles de « désactiver un vdom » : tu as fait quoi exactement ? Tu n’as pas indiqué non plus le modèle du FG et les features activés.
L’idéal aurait été d’avoir une capture du trafic envoyé par le serveur pour comprendre ce qui s’est passé. Ma supposition est que tu avais une saturation CPU. Quand tu dis que la charge cpu est passée à 40%, l’info n’est pas précise parce que je suppose que c’est une moyenne (tu peux avoir des pics à 100% qui disparaissent de tes graphes) et si ton fg est multicpu : on n’a pas l’info précise par CPU. Tu peux avoir des CPU qui pioncent et un CPU qui sature … il suffit que le CPU qui sature soit le CPU qui gère le routage dynamique + processus kernel & userspace (a priori cpu0) et c'est tout ton boitier qui trinque. Un problème courant serait que ton serveur attaqué génère du trafic qui nécessite d’être traité par le FW en CPU (le NPU envoi les interruption au même CPU sans les ventiler correctement. Si ce CPU est le cpu0 : tu impactes ta ha, ton routage dynamique et autres "processus mgmt"). La fragmentation, les tempêtes de broadcast, etc. sont par exemple traités en CPU. (Et je ne parle pas de L7) Commandes utiles : 1) #diag hardware sysinfo interrupts (pour voir les interruptions NPU => CPU et la répartition) 2) #conf sys npu #set dedicated-management-cpu enable #end (pour que les interruption NPU ne soient plus envoyées au CPU0 et n’impacte pas les processus « user-space et kernel » qui consomment le CPU0) Bon courage @+ Stephane --------------------------- Liste de diffusion du FRnOG http://www.frnog.org/
