A creuser. Concernant ta supervision : si c'est du SNMP, elle ne sera peut être pas révélatrice du problème parce que si ton cpu0 est saturé, le processus SNMP du FG sera lui aussi impacté.
Quoiqu'il en soit, c'est compliquer de faire autre chose que des suppositions sans traces. La source du problème peut être malheureusement multiple. Le jeu 20 nov. 2014 16:20, Gautier Avril <[email protected]> a écrit : > Bonjour Stéphane > > > Quand tu parles de « désactiver un vdom » : tu as fait quoi exactement ? > > Depuis l'interface graphique VDOM->VDOM->Edit->Disable > > > Tu n’as pas indiqué non plus le modèle du FG et les features activés. > > En l'occurence il s'agit d'un fortigate 100-D. Pour le client en question, > aucune feature spécifique n'est activé (il matche une règle du type any-any > accept).D'autres IP du subnet ont l'IPS d'activé. > > > Ma supposition est que tu avais une saturation CPU. > > J'avais écarté cette supposition que je m'étais faite (cf. suite) > > > 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) > > Cette hypothèse est peu probable : on a une supervision assez agressive > sur l'état du(des) CPU(s). Cette ci se déclence notamment dès que l'on se > connecte sur l'interface graphique et que tous les graphes s'affichent (ce > qui n'a pas d'impact sur le trafic). On aurait eu des alarmes sans aucun > doute si il était monté, même temporairement, à 100% > > > et si ton fg est multicpu : on n’a pas l’info précise par CPU. > > Ma supposition est que tu avais une saturation CPU. (bis) > > Je reviens sur cette supposition, pendant l'attaque la charge CPU était > environ 20-25% supérieure à l'habitude. Pour un firewall qui a 4 CPU, la > valeur est troublante. J'aurais donc le CPU0 à 100% et les 3 autres qui ne > font rien? > > Piste très intéressante. > > Gautier AVRIL > > ________________________________________ > De : [email protected] [[email protected]] de la part de > Stéphane C. [[email protected]] > Envoyé : jeudi 20 novembre 2014 15:41 > À : [email protected] > Objet : Le: [FRnOG] [TECH] Comportement étrange Firewall / routeur > > 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 CROISY > > --------------------------- > Liste de diffusion du FRnOG > http://www.frnog.org/ > --------------------------- Liste de diffusion du FRnOG http://www.frnog.org/
