El conjunto de documentos para este producto aspira al uso de un lenguaje no discriminatorio. A los fines de esta documentación, "no discriminatorio" se refiere al lenguaje que no implica discriminación por motivos de edad, discapacidad, género, identidad de raza, identidad étnica, orientación sexual, nivel socioeconómico e interseccionalidad. Puede haber excepciones en la documentación debido al lenguaje que se encuentra ya en las interfaces de usuario del software del producto, el lenguaje utilizado en función de la documentación de la RFP o el lenguaje utilizado por un producto de terceros al que se hace referencia. Obtenga más información sobre cómo Cisco utiliza el lenguaje inclusivo.
Cisco ha traducido este documento combinando la traducción automática y los recursos humanos a fin de ofrecer a nuestros usuarios en todo el mundo contenido en su propio idioma. Tenga en cuenta que incluso la mejor traducción automática podría no ser tan precisa como la proporcionada por un traductor profesional. Cisco Systems, Inc. no asume ninguna responsabilidad por la precisión de estas traducciones y recomienda remitirse siempre al documento original escrito en inglés (insertar vínculo URL).
Este documento describe por qué un único flujo no puede consumir todo el rendimiento nominal de un dispositivo Cisco Firepower.
El resultado de cualquier sitio web de pruebas de velocidad de ancho de banda o el resultado de cualquier herramienta de medición de ancho de banda (por ejemplo, iperf) podría no exhibir la clasificación de rendimiento anunciada de los appliances Cisco Firepower. De manera similar, la transferencia de un archivo muy grande sobre cualquier protocolo de transporte no demuestra la clasificación de rendimiento anunciada de un dispositivo Firepower. Ocurre porque el servicio Firepower no utiliza un único flujo de red para determinar su rendimiento máximo.
La tecnología de detección subyacente del servicio Firepower es Snort. La implementación de Snort en el dispositivo Cisco Firepower es un proceso de subproceso único para procesar el tráfico. Un dispositivo se califica para una clasificación específica en función del rendimiento total de todos los flujos que pasan a través del dispositivo. Se espera que los dispositivos se implementen en una red corporativa, generalmente cerca del borde y que funcionen con miles de conexiones.
Firepower Services utiliza el balanceo de carga del tráfico a un número de procesos Snort diferentes con un proceso Snort que se ejecuta en cada CPU del dispositivo. Idealmente, la carga del sistema equilibra el tráfico de manera uniforme en todos los procesos de Snort. Snort debe poder proporcionar un análisis contextual adecuado para las inspecciones de firewall de última generación (NGFW), sistema de prevención de intrusiones (IPS) y protección frente a malware avanzado (AMP). Para asegurarse de que Snort es más efectivo, todo el tráfico de un flujo único se balancea de carga en una instancia de snort. Si todo el tráfico de un único flujo no se equilibraba a una única instancia de resnorte, el sistema podría eludirse y el tráfico se desbordaría de tal manera que una regla de Snort podría coincidir menos o las partes de un archivo no son contiguas para la inspección de AMP. Por lo tanto, el algoritmo de balanceo de carga se basa en la información de conexión que puede identificar de forma única una conexión determinada.
En el dispositivo de seguridad adaptable (ASA) con la plataforma de servicio Firepower y el sistema de prevención de intrusiones de última generación (NGIPS) virtual, el tráfico se equilibra con la carga para realizar el Snort con el uso de un algoritmo de 2 tuplas. Los puntos de datos para este algoritmo son:
En todas las versiones anteriores (5.3 o inferior), el tráfico se balancea de carga a Snort que utiliza un algoritmo de 3 tuplas. Los puntos de datos para este algoritmo son:
Cualquier tráfico con el mismo origen, destino y protocolo IP se equilibra con la carga en la misma instancia de Snort.
En la versión 5.4, 6.0 o posterior, el tráfico se equilibra de carga a Snort con un algoritmo de 5 tuplas. Los puntos de datos que se tienen en cuenta son:
El propósito de agregar puertos al algoritmo es equilibrar el tráfico de manera más uniforme cuando hay pares de origen y destino específicos que representan grandes porciones del tráfico. Además de los puertos, los puertos de origen efímeros de alto orden deben ser diferentes por flujo y deben agregar entropía adicional de manera más uniforme que equilibre el tráfico con diferentes instancias de snort.
El rendimiento total de un dispositivo se mide en función del rendimiento agregado de todas las instancias de sondeo que funcionan al máximo potencial. Las prácticas estándar del sector para medir el rendimiento son para varias conexiones HTTP con varios tamaños de objeto. Por ejemplo, la metodología de prueba de NGFW de NSS mide el rendimiento total del dispositivo con objetos de 44.000, 21.000, 10.000, 4.400 y 1.700. Esto se traduce en un rango de tamaños de paquete promedio de aproximadamente 1 k y bytes a 128 bytes debido a los otros paquetes involucrados en la conexión HTTP.
Puede estimar la calificación de rendimiento de una instancia individual de Snort. Tome el rendimiento nominal del dispositivo y divida eso por el número de instancias de Snort que se ejecutan. Por ejemplo, si un dispositivo se califica a 10 Gbps para IPS con un tamaño medio de paquete de 1.000 bytes y ese dispositivo tiene 20 instancias de Snort, el rendimiento máximo aproximado para una sola instancia sería de 500 Mbps por Snort. Diferentes tipos de tráfico, protocolos de red, tamaños de los paquetes, junto con las diferencias en la política de seguridad general pueden afectar el rendimiento observado del dispositivo.
Cuando se realiza la prueba con cualquier sitio web de pruebas de velocidad o cualquier herramienta de medición del ancho de banda, como, iperf, se genera un flujo TCP de flujo único grande. Este tipo de flujo TCP grande se denomina flujo elefante. Un flujo de elefante es una única sesión, una conexión de red que se ejecuta durante relativamente tiempo y que consume una gran o desproporcionada cantidad de ancho de banda. Este tipo de flujo se asigna a una instancia de Snort, por lo que el resultado de la prueba muestra el rendimiento de una única instancia de snort, no la calificación de rendimiento agregado del dispositivo.
Otro efecto visible de los Flujos de Elefantes puede ser la cpu alta de la instancia de snort. Esto se puede ver a través de "show asp inspect-dp snort", o con la herramienta "top" del shell.
> show asp inspect-dp snort SNORT Inspect Instance Status Info Id Pid Cpu-Usage Conns Segs/Pkts Status tot (usr | sys) -- ---- --------- ----- -------- ---------- 0 48500 30% ( 28%| 1%) 12.4 K 0 READY 1 48474 24% ( 22%| 1%) 12.4 K 0 READY 2 48475 34% ( 33%| 1%) 12.5 K 1 READY 3 48476 29% ( 28%| 0%) 12.4 K 0 READY 4 48477 32% ( 30%| 1%) 12.5 K 0 READY 5 48478 31% ( 29%| 1%) 12.3 K 0 READY 6 48479 29% ( 27%| 1%) 12.3 K 0 READY 7 48480 23% ( 23%| 0%) 12.2 K 0 READY 8 48501 27% ( 26%| 0%) 12.6 K 1 READY 9 48497 28% ( 27%| 0%) 12.6 K 0 READY 10 48482 28% ( 27%| 1%) 12.3 K 0 READY 11 48481 31% ( 30%| 1%) 12.5 K 0 READY 12 48483 36% ( 36%| 1%) 12.6 K 0 READY 13 48484 30% ( 29%| 1%) 12.4 K 0 READY 14 48485 33% ( 31%| 1%) 12.6 K 0 READY 15 48486 38% ( 37%| 0%) 12.4 K 0 READY 16 48487 31% ( 30%| 1%) 12.4 K 1 READY 17 48488 37% ( 35%| 1%) 12.7 K 0 READY 18 48489 34% ( 33%| 1%) 12.6 K 0 READY 19 48490 27% ( 26%| 1%) 12.7 K 0 READY 20 48491 24% ( 23%| 0%) 12.6 K 0 READY 21 48492 24% ( 23%| 0%) 12.6 K 0 READY 22 48493 28% ( 27%| 1%) 12.4 K 1 READY 23 48494 27% ( 27%| 0%) 12.2 K 0 READY 24 48495 29% ( 28%| 0%) 12.5 K 0 READY 25 48496 30% ( 30%| 0%) 12.4 K 0 READY 26 48498 29% ( 27%| 1%) 12.6 K 0 READY 27 48517 24% ( 23%| 1%) 12.6 K 0 READY 28 48499 22% ( 21%| 0%) 12.3 K 1 READY 29 48518 31% ( 29%| 1%) 12.4 K 2 READY 30 48502 33% ( 32%| 0%) 12.5 K 0 READY
31 48514 80% ( 80%| 0%) 12.7 K 0 READY <<< CPU 31 is much busier than the rest, and will stay busy for while with elephant flow. 32 48503 49% ( 48%| 0%) 12.4 K 0 READY 33 48507 27% ( 25%| 1%) 12.5 K 0 READY 34 48513 27% ( 25%| 1%) 12.5 K 0 READY 35 48508 32% ( 31%| 1%) 12.4 K 0 READY 36 48512 31% ( 29%| 1%) 12.4 K 0 READY
$ top PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 69470 root 1 -19 9088m 1.0g 96m R 80 0.4 135:33.51 snort <<<< one snort very busy, rest below 50% 69468 root 1 -19 9089m 1.0g 99m R 49 0.4 116:08.69 snort 69467 root 1 -19 9078m 1.0g 97m S 47 0.4 118:30.02 snort 69492 root 1 -19 9118m 1.1g 97m R 47 0.4 116:40.15 snort 69469 root 1 -19 9083m 1.0g 96m S 39 0.4 117:13.27 snort 69459 root 1 -19 9228m 1.2g 97m R 37 0.5 107:13.00 snort 69473 root 1 -19 9087m 1.0g 96m R 37 0.4 108:48.32 snort 69475 root 1 -19 9076m 1.0g 96m R 37 0.4 109:01.31 snort 69488 root 1 -19 9089m 1.0g 97m R 37 0.4 105:41.73 snort 69474 root 1 -19 9123m 1.1g 96m S 35 0.4 107:29.65 snort 69462 root 1 -19 9065m 1.0g 99m R 34 0.4 103:09.42 snort 69484 root 1 -19 9050m 1.0g 96m S 34 0.4 104:15.79 snort 69457 root 1 -19 9067m 1.0g 96m S 32 0.4 104:12.92 snort 69460 root 1 -19 9085m 1.0g 97m R 32 0.4 104:16.34 snort
Con el algoritmo 5-Tuple descrito anteriormente, un flujo de larga duración siempre se enviará a la misma instancia de snort. Si hay amplias políticas de AVC, IPS, archivos, etc. activas en snort, la CPU puede verse alta (>80%) en una instancia de snort durante algún tiempo. La adición de la política SSL aumentará aún más el uso de la CPU, lo que repercutirá en la naturaleza costosa desde el punto de vista informático de la descifrado SSL.
El uso elevado de la CPU en pocas de las muchas CPU de resoplido no es causa de alarma crítica. Es el comportamiento del sistema NGFW al realizar una inspección profunda de paquetes en un flujo, y esto puede usar naturalmente grandes porciones de una CPU. Como pauta general, el NGFW no se encuentra en una situación crítica de escasez de CPU hasta que la mayoría de las CPU de tubo superan el 95% y permanecen por encima del 95% y se observan caídas de paquetes.
Las siguientes Remediaciones ayudarán a resolver la situación de la CPU debido a los flujos de elefantes.
La versión de software 6.0 introduce una nueva función llamada IAB. Cuando un dispositivo Firepower alcanza un umbral de rendimiento predefinido, la función IAB busca flujos que cumplan criterios específicos para eludir inteligentemente y aliviar la presión sobre los motores de detección.
Consejo: Puede encontrar más información sobre la configuración del IAB aquí.
Los flujos grandes a menudo se relacionan con el uso elevado de tráfico de bajo valor de inspección, por ejemplo, copias de seguridad, replicación de bases de datos, etc. Muchas de estas aplicaciones no pueden beneficiarse de la inspección. Para evitar problemas con flujos grandes, puede identificar los flujos grandes y crear reglas de confianza de control de acceso para ellos. Estas reglas son capaces de identificar de forma única flujos grandes, permitir que estos flujos pasen sin inspeccionar y no se vean limitados por el comportamiento de una sola instancia de sonda.
Nota: Para identificar flujos grandes para las reglas de confianza, comuníquese con el TAC de Cisco Firepower.