Cómo solucionar la alta utilización de recursos y la inestabilidad del dispositivo debido al tráfico SFLOW en Fortinet

En este artículo, abordaremos problemas de alta utilización de recursos en dispositivos FortiGate, que pueden manifestarse como mensajes de fallo de apertura del IPS en los registros de fallos, alta carga de CPU, alta SoftIrq en algunos o todos los núcleos vCPU, y respuestas lentas al tráfico. Estos problemas son cruciales ya que pueden afectar el rendimiento de la red y la seguridad. A través de pasos de diagnóstico y solución, este artículo le ayudará a identificar y resolver estas situaciones.

Descripción del problema

Este artículo describe cómo manejar problemas donde un dispositivo puede experimentar alta utilización de recursos, tales como mensajes de fallo de apertura del IPS, alta carga de CPU y alta SoftIrq. Estas situaciones pueden inhibir el rendimiento del dispositivo, causando ralentizaciones en el tráfico. Las causas son múltiples, por lo que este artículo proporciona pasos de solución simples para ayudar a determinar las causas correctas.

Alcance

El artículo es aplicable a todas las versiones compatibles de FortiGate.

Diagnóstico paso a paso

En estas situaciones, obtenga las siguientes salidas:

get system performance status

CPU states: 4% user 0% system 0% nice 53% idle 0% iowait 0% irq 43% softirq
CPU0 states: 0% user 0% system 0% nice 0% idle 0% iowait 0% irq 100% softirq
CPU1 states: 1% user 0% system 0% nice 99% idle 0% iowait 0% irq 0% softirq
CPU2 states: 0% user 0% system 0% nice 1% idle 0% iowait 0% irq 99% softirq
CPU3 states: 0% user 0% system 0% nice 100% idle 0% iowait 0% irq 0% softirq
CPU4 states: 3% user 0% system 0% nice 5% idle 0% iowait 0% irq 92% softirq
CPU5 states: 4% user 1% system 0% nice 95% idle 0% iowait 0% irq 0% softirq
CPU6 states: 4% user 0% system 0% nice 8% idle 0% iowait 0% irq 88% softirq
CPU7 states: 15% user 2% system 0% nice 83% idle 0% iowait 0% irq 0% softirq
CPU8 states: 7% user 1% system 0% nice 21% idle 0% iowait 0% irq 71% softirq
CPU9 states: 7% user 1% system 0% nice 92% idle 0% iowait 0% irq 0% softirq
CPU10 states: 4% user 0% system 0% nice 26% idle 0% iowait 0% irq 70% softirq
CPU11 states: 8% user 2% system 0% nice 90% idle 0% iowait 0% irq 0% softirq
Memory: 16432164k total, 9682308k used (58.9%), 6115808k free (37.2%), 634048k freeable (3.9%)
Average network usage: 8685743 / 8610623 kbps in 1 minute, 8904241 / 8814890 kbps in 10 minutes, 8821108 / 8735910 kbps in 30 minutes
Maximal network usage: 10888036 / 11340676 kbps in 1 minute, 10888036 / 11340676 kbps in 10 minutes, 11270637 / 11340676 kbps in 30 minutes
Average sessions: 786108 sessions in 1 minute, 772779 sessions in 10 minutes, 777503 sessions in 30 minutes
Maximal sessions: 788393 sessions in 1 minute, 788393 sessions in 10 minutes, 817579 sessions in 30 minutes
Average session setup rate: 5923 sessions per second in last 1 minute, 5885 sessions per second in last 10 minutes, 5946 sessions per second in last 30 minutes
Maximal session setup rate: 6270 sessions per second in last 1 minute, 7830 sessions per second in last 10 minutes, 8926 sessions per second in last 30 minutes
Average NPU sessions: 0 sessions in last 1 minute, 0 sessions in last 10 minutes, 0 sessions in last 30 minutes
Maximal NPU sessions: 0 sessions in last 1 minute, 0 sessions in last 10 minutes, 0 sessions in last 30 minutes
Average nTurbo sessions: 0 sessions in last 1 minute, 0 sessions in last 10 minutes, 0 sessions in last 30 minutes
Maximal nTurbo sessions: 0 sessions in last 1 minute, 0 sessions in last 10 minutes, 0 sessions in last 30 minutes
Virus caught: 0 total in 1 minute
IPS attacks blocked: 0 total in 1 minute
Uptime: 258 days, 16 hours, 8 minutes

En la salida anterior, es observable que no hay sesiones NPU disponibles a pesar de más de 700K sesiones. Esto puede generar preocupación sobre por qué todas las sesiones son procesadas por la CPU en lugar de por la NPU.

Solución recomendada

Los siguientes son conteos de sesiones relacionadas con la NPU, que dan más pruebas:

diagnose npu np6 session-stats 0

qid ins44 ins46 del4 ins64 ins66 del6
ins44_e ins46_e del4_e ins64_e ins66_e del6_e
—————- ———- ———- ———- ———- ———-
0 0 0 0 0 0 0
0 0 0 0 0 0
1 0 0 0 0 0 0
0 0 0 0 0 0
2 2 0 1 0 0 0
0 0 0 0 0 0
3 0 0 0 0 0 0
0 0 0 0 0 0
4 0 0 0 0 0 0
0 0 0 0 0 0
5 0 0 0 0 0 0
0 0 0 0 0 0
—————- ———- ———- ———- ———- ———-
Total 2 0 1 0 0 0
0 0 0 0 0 0
—————- ———- ———- ———- ———- ———-

Es observable que hay una alta SoftIrq y, especialmente, que no hay sesiones NPU. Tener cero sesiones NPU significa que todo el tráfico es manejado por el kernel y la carga en el kernel está causando estos problemas. En estos casos, es necesario investigar por qué el tráfico no se desvía a la NPU. La mejor manera de hacerlo es obteniendo la lista de sesiones y revisando el razón de NO OFFLOAD.

En el siguiente ejemplo, SFLOW ha causado el problema, ya que se ha aplicado SFLOW en muchas interfaces:

session info: proto=6 proto_state=01 duration=58046 expire=3598 timeout=3600 flags=00000000 socktype=0 sockport=0 av_idx=0 use=3
origin-shaper=
reply-shaper=
per_ip_shaper=
class_id=0 ha_id=0 policy_dir=0 tunnel=/ vlan_cos=0/255
state=may_dirty netflow-origin netflow-reply
statistic(bytes/packets/allow_err): org=40171092/250588/1 reply=18432661/246730/1 tuples=2
tx speed(Bps/kbps): 15/0 rx speed(Bps/kbps): 15/0
orgin->sink: org pre->post, reply pre->post dev=69->84/84->69 gwy=x.y.z.p/x.x.x.x
hook=pre dir=org act=noop p.q.r.s:7554->p.p.p.p:22(0.0.0.0:0)
hook=post dir=reply act=noop p.p.p.p:22->p.q.r.s:7554(0.0.0.0:0)
pos/(before,after) 0/(0,0), 0/(0,0)
dst_mac=00:xx:yy:zz:rr:ss
misc=0 policy_id=1019 pol_uuid_idx=15814 auth_info=0 chk_client_info=0 vd=2
serial=00268b69 tos=ff/ff app_list=0 app=0 url_cat=0
rpdb_link_id=00000000 ngfwid=n/a
npu_state=0x020008
no_ofld_reason: sflow <- Razón por la cual no se realiza la descarga en la NPU.

Nota: Cuando se aplica SFLOW en las interfaces, el tráfico no es manejado por la NPU, y todo el tráfico en esa interfaz es gestionado por el kernel. Cuando SFLOW se aplica en todas las interfaces, resultará en que todo el tráfico no se descarga en la NPU, sino que es manejado por el kernel. Esto causará que el kernel esté muy ocupado, lo cual provoca alta CPU, fallos de apertura y otros problemas relacionados con los recursos.

Por lo tanto, es necesario aplicar SFLOW solo en las interfaces donde sea necesario y, especialmente cuando el tráfico es muy alto, se debe ser muy cauteloso.

Desactive SFLOW como se indica a continuación:

config system interface

edit «ToInternet»

set vdom «root»

set ip x.y.z.r 255.255.255.248
set allowaccess ping
set sflow-sampler enable <- Desactive esto.
set alias «Northbound Transit»
set device-identification enable
set monitor-bandwidth enable
set role lan
set snmp-index 56
set interface «port33»
set vlanid 234

next

Después de esto, habrá tráfico descargado por NPU y la utilización de recursos se aliviará, reduciendo el consumo de CPU y evitando fallos de apertura.