EN ESTA PÁGINA
Descripción del procesamiento de tráfico en dispositivos de seguridad
Descripción del comportamiento de procesamiento predeterminado para el tráfico IPv4
Descripción del procesamiento de tráfico en dispositivos SRX320
Descripción del procesamiento de tráfico en dispositivos SRX4600
Descripción del procesamiento de tráfico en dispositivos de línea SRX5000
Descripción del procesamiento de flujo en dispositivos SRX5K-SPC3
Descripción general del procesamiento de tráfico en los firewalls de la serie SRX
Junos OS para dispositivos de seguridad integra la seguridad de red y las capacidades de enrutamiento de Juniper Networks. Los paquetes que entran y salen de un dispositivo se someten a un procesamiento basado en paquetes y en flujo.
Descripción del procesamiento de tráfico en dispositivos de seguridad
Junos OS para dispositivos de seguridad integra la seguridad de red de primera clase y las capacidades de enrutamiento de Juniper Networks. Junos OS incluye una amplia gama de filtrado basado en paquetes, clasificadores de clase de servicio (CoS) y funciones de modelado de tráfico, así como un conjunto rico y extenso de funciones de seguridad basadas en flujos que incluyen políticas, pantallas, traducción de direcciones de red (TDR) y otros servicios basados en flujos.
El tráfico que entra y sale de un dispositivo de seguridad se procesa de acuerdo con las funciones que configure, como filtros de paquetes, políticas de seguridad y pantallas. Por ejemplo, el software puede determinar:
Si se permite la entrada del paquete en el dispositivo
Qué pantallas de firewall se deben aplicar al paquete
La ruta que toma el paquete para llegar a su destino
Qué CoS aplicar al paquete, si corresponde
Si se debe aplicar TDR para traducir la dirección IP del paquete
Si el paquete requiere una puerta de enlace de capa de aplicación (ALG)
Los paquetes que entran y salen de un dispositivo se someten a un procesamiento basado en paquetes y en flujo:
El procesamiento de paquetes basado en flujo trata a los paquetes relacionados, o a una secuencia de paquetes, de la misma manera. El tratamiento de paquetes depende de las características que se establecieron para el primer paquete de la corriente de paquetes, que se conoce como flujo.
Para la arquitectura de procesamiento distribuido de la puerta de enlace de servicios, todo el procesamiento basado en flujos se produce en la SPU y el muestreo tiene en cuenta varios subprocesos. Se mantiene la secuenciación de paquetes para los paquetes muestreados.
El procesamiento de paquetes basado en paquetes, o sin estado, trata los paquetes de manera discreta. Cada paquete se evalúa individualmente para su tratamiento.
Para la arquitectura de procesamiento distribuido de la puerta de enlace de servicios, algunos procesamientos basados en paquetes, como la formación de tráfico, se producen en la NPU. Algunos procesamientos basados en paquetes, como la aplicación de clasificadores a un paquete, se producen en la SPU.
En este tema, se incluyen las siguientes secciones:
Descripción del procesamiento basado en flujos
Un paquete se somete a un procesamiento basado en flujo después de que se le hayan aplicado filtros basados en paquetes y algunas pantallas. Todo el procesamiento basado en flujo para un solo flujo se produce en una sola unidad de procesamiento de servicios (SPU). Una SPU procesa los paquetes de un flujo de acuerdo con las características de seguridad y otros servicios configurados para la sesión.
En la figura 1, se muestra una vista conceptual de cómo se produce el procesamiento de tráfico basado en flujo en la puerta de enlace de servicios.
basado en flujos
Un flujo es una corriente de paquetes relacionados que cumplen los mismos criterios de coincidencia y comparten las mismas características. Junos OS trata los paquetes que pertenecen al mismo flujo de la misma manera.
Las opciones de configuración que determinan el destino de un paquete, como la política de seguridad que se le aplica, si requiere una puerta de enlace de capa de aplicación (ALG) o si se aplica TDR para traducir la dirección IP de origen o destino del paquete, se evalúan para el primer paquete de un flujo.
Para determinar si existe un flujo para un paquete, la NPU intenta hacer coincidir la información del paquete con la de una sesión existente según los siguientes criterios de coincidencia:
Dirección de origen
Dirección de destino
Puerto de origen
Puerto de destino
Protocolo
Número de token de sesión único para una zona y un enrutador virtual determinados
Zonas y políticas
La política de seguridad que se va a utilizar para el primer paquete de un flujo se almacena en caché en una tabla de flujos para su uso con el mismo flujo y flujos estrechamente relacionados. Las políticas de seguridad están asociadas con zonas. Una zona es una colección de interfaces que definen un límite de seguridad. La zona de entrada de un paquete, determinada por la interfaz a través de la cual llegó, y su zona de salida, determinada por la búsqueda de reenvío, determinan en conjunto qué política se usa para los paquetes del flujo.
Flujos y sesiones
El procesamiento de paquetes basado en el flujo, que tiene estado, requiere la creación de sesiones. Se crea una sesión para el primer paquete de un flujo con los siguientes propósitos:
Almacenar la mayoría de las medidas de seguridad que se aplicarán a los paquetes del flujo.
Para almacenar en caché información sobre el estado del flujo.
Por ejemplo, la información de registro y recuento de un flujo se almacena en caché en su sesión. (Algunas pantallas de firewall con estado se basan en valores de umbral que pertenecen a sesiones individuales o a todas las sesiones).
Asignar los recursos necesarios para el flujo de características como TDR.
Proporcionar un marco para características como ALG y características de firewall.
La mayor parte del procesamiento de paquetes se produce en el contexto de un flujo, entre los que se incluyen:
Gestión de políticas, TDR, zonas y la mayoría de las pantallas.
Gestión de ALG y autenticación.
Descripción del procesamiento basado en paquetes
Un paquete se somete a un procesamiento basado en paquetes cuando se elimina de la cola en su interfaz de entrada y antes de agregarse a la cola en su interfaz de salida.
El procesamiento basado en paquetes aplica filtros de firewall sin estado, funciones de CoS y algunas pantallas a paquetes discretos.
Cuando un paquete llega a una interfaz, se le aplican comprobaciones de cordura, filtros basados en paquetes, algunas funciones de CoS y algunas pantallas.
Antes de que un paquete abandone el dispositivo, se aplican al paquete filtros basados en paquetes, algunas funciones de CoS y algunas pantallas asociadas con la interfaz.
Los filtros y las características de CoS generalmente se asocian con una o más interfaces para influir en qué paquetes pueden transitar por el sistema y para aplicar acciones especiales a los paquetes según sea necesario.
En los temas siguientes se describen los tipos de funciones basadas en paquetes que puede configurar y aplicar al tráfico en tránsito.
Filtros de firewall sin estado
También conocidos como listas de control de acceso (ACL), los filtros de firewall sin estado controlan el acceso y limitan las tasas de tráfico. Evalúan estáticamente el contenido de los paquetes que transitan por el dispositivo desde un origen a un destino, o los paquetes que se originan o están destinados al motor de enrutamiento. Un filtro de firewall sin estado evalúa cada paquete, incluidos los fragmentados.
Puede aplicar un filtro de firewall sin estado a una interfaz de entrada o de salida, o a ambas. Un filtro contiene uno o más términos, y cada término consta de dos componentes: condiciones de coincidencia y acciones. De forma predeterminada, se descarta un paquete que no coincide con un filtro de firewall.
Puede planificar y diseñar filtros de firewall sin estado para utilizarlos con diversos fines, por ejemplo, para limitar el tráfico a determinados protocolos, direcciones IP de origen o destino o velocidades de datos. Los filtros de firewall sin estado se ejecutan en la NPU.
Características de clase de servicio
Las funciones de CoS le permiten clasificar y dar forma al tráfico. Las funciones de CoS se ejecutan en la NPU.
Clasificadores de agregado de comportamiento (BA): estos clasificadores funcionan en los paquetes a medida que ingresan al dispositivo. Mediante el uso de clasificadores de agregado de comportamiento, el dispositivo agrega diferentes tipos de tráfico en una sola clase de reenvío para recibir el mismo tratamiento de reenvío. Los clasificadores de BA permiten establecer la clase de reenvío y la prioridad de pérdida de un paquete en función del valor de Servicio diferenciado (DiffServ).
Modelado del tráfico: puede dar forma al tráfico asignando niveles de servicio con diferentes características de retraso, fluctuación y pérdida de paquetes a aplicaciones particulares atendidas por flujos de tráfico específicos. El modelado de tráfico es especialmente útil para aplicaciones en tiempo real, como la transmisión de voz y video.
Pantallas
Algunos filtros, como los de denegación de servicio (DS), se aplican a un paquete fuera del proceso de flujo. Se ejecutan en la unidad de procesamiento de red (NPU).
Descripción del comportamiento de procesamiento predeterminado para el tráfico IPv4
El modo de procesamiento basado en flujo es necesario para que funcionen las características de seguridad, como zonas, pantallas y políticas de firewall. Para el procesamiento del modo de caída, el tráfico se descarta directamente, no se reenvía. Difiere del procesamiento en modo de paquete para el que se maneja el tráfico pero no se aplican procesos de seguridad.
Use el Explorador de características para confirmar la compatibilidad de plataforma y versión para características específicas.
Revise la sección Descripción del comportamiento de procesamiento predeterminado para el tráfico IPv4 para obtener notas relacionadas con su plataforma.
Configuring an SRX Series Device as a Border Router
Cuando un firewall de la serie SRX de cualquier tipo está habilitado para el procesamiento basado en flujo o el modo de caída, para configurar el dispositivo como un enrutador de borde debe cambiar el modo a procesamiento basado en paquetes para MPLS. En este caso, para configurar el firewall de la serie SRX en modo de paquete para MPLS, utilice la set security forwarding-options family mpls mode packet-based instrucción.
Comportamiento del tráfico IPv4 específico de la plataforma
Use el Explorador de características para confirmar la compatibilidad de plataforma y versión para características específicas.
Utilice la siguiente tabla para revisar el comportamiento específico de la plataforma para su plataforma:
| Plataforma |
Diferencia |
|---|---|
| Firewall de la serie SRX |
|
Descripción del procesamiento de tráfico en dispositivos SRX320
En este tema se describe el proceso que llevan a cabo las puertas de enlace de servicios SRX320 para establecer una sesión para los paquetes que pertenecen a un flujo que transita por el dispositivo. Los servicios de flujo de los dispositivos SRX320 son de un solo subproceso y no distribuidos. Aunque difieren de los otros firewalls de la serie SRX en este aspecto, se sigue el mismo modelo de flujo y se implementa la misma interfaz de línea de comandos (CLI).
Para ilustrar el establecimiento de la sesión y el "paseo" de paquetes, incluidos los puntos en los que se aplican servicios a los paquetes de un flujo, en el ejemplo descrito en las secciones siguientes se utiliza el caso simple de una sesión de unidifusión:
- Descripción del procesamiento de flujo y la gestión de sesiones
- Descripción del procesamiento del primer paquete
- Descripción de la creación de sesiones
- Descripción del procesamiento de ruta rápida
Descripción del procesamiento de flujo y la gestión de sesiones
En este tema, se explica cómo se configura una sesión para procesar los paquetes que componen un flujo. En el tema siguiente, la SPU hace referencia al subproceso del plano de datos del firewall SRX320.
Al principio, el subproceso del plano de datos obtiene el paquete y realiza comprobaciones básicas de cordura en él. Luego, procesa el paquete en busca de filtros sin estado y clasificadores CoS y aplica algunas pantallas.
Descripción del procesamiento del primer paquete
Para determinar si un paquete pertenece a un flujo existente, el dispositivo intenta hacer coincidir la información del paquete con la de una sesión existente según los seis criterios de coincidencia siguientes:
Dirección de origen
Dirección de destino
Puerto de origen
Puerto de destino
Protocolo
Token único de una zona y un enrutador virtual dados
La SPU comprueba si hay una sesión existente en su tabla de sesiones para el paquete. Si no se encuentra ninguna sesión existente, la SPU configura una sesión para el flujo. Si se encuentra una coincidencia de sesión, la sesión ya se creó, por lo que la SPU realiza el procesamiento de ruta rápida en el paquete.
Descripción de la creación de sesiones
Al configurar la sesión, la SPU ejecuta los siguientes servicios para el paquete:
Pantallas
Búsqueda de ruta
Búsqueda de políticas
Búsqueda de servicio
TDR, si es necesario
Después de configurar una sesión, se utiliza para todos los paquetes que pertenecen al flujo. Los paquetes de un flujo se procesan de acuerdo con los parámetros de su sesión. Para el resto de los pasos implicados en el procesamiento de paquetes, continúe con el paso 1 en "Procesamiento de ruta rápida". Todos los paquetes se someten a un procesamiento de ruta rápida.
Descripción del procesamiento de ruta rápida
Si un paquete coincide con una sesión, Junos OS realiza el procesamiento de ruta rápida como se describe en los pasos siguientes. Después de configurar una sesión para el primer paquete de un flujo, también se somete a un procesamiento de ruta rápida. Todos los paquetes se someten a un procesamiento de ruta rápida.
La SPU aplica funciones de seguridad basadas en el flujo al paquete.
Se aplican las pantallas configuradas.
Se realizan comprobaciones TCP.
Se aplican servicios de flujo, como TDR, ALG e IPsec, si es necesario.
La SPU prepara el paquete para el reenvío y lo transmite.
Se aplican filtros de paquetes de enrutamiento.
Se aplica el modelado de tráfico.
Se aplica la priorización de tráfico.
Se aplica la programación del tráfico.
El paquete se transmite.
Descripción del procesamiento de tráfico en dispositivos SRX4600
El firewall SRX4600 de Juniper Networks integra servicios de seguridad y enrutamiento basados en flujos, incluida la seguridad avanzada y la mitigación de amenazas, y la seguridad de firewall de estado tradicional. La infraestructura basada en flujo de Junos OS proporciona la base y el marco para los servicios basados en aplicaciones de la capa 4 a la capa 7. El firewall SRX4600 está diseñado para desplegarse como un firewall integrado en el borde y núcleo del centro de datos de grandes empresas, y en el borde del campus. También se puede desplegar como una puerta de enlace de seguridad LTE y un firewall de Gi/SGi.
En este tema, se incluye el siguiente contenido:
- Descripción de los escenarios de despliegue para el firewall SRX4600 y sus características
- Procesamiento basado en flujos y fundamentos de sesiones
- Componentes subyacentes de flujo y sesión implementados en firewalls de la serie SRX
Descripción de los escenarios de despliegue para el firewall SRX4600 y sus características
El firewall SRX4600 se puede implementar en muchas áreas para proteger su entorno y sus recursos. A menudo se usa para proteger el borde y el núcleo del centro de datos de las siguientes maneras:
-
Despliegue del firewall SRX4600 como firewall de borde de centro de datos
Puede implementar el firewall SRX4600 en el borde de su centro de datos para proporcionar una protección óptima a las aplicaciones y servicios que aloja. Cada centro de datos tiene un punto de entrada para permitir que los clientes accedan a los servicios del centro de datos, pero los agresores malintencionados pueden aprovecharlo para lanzar ataques contra estos servicios. Una gran cantidad del tráfico que ingresa al centro de datos es tráfico de Internet de entrada. Solo por esa razón, es esencial implementar una seguridad sólida y de varias capas en el borde del centro de datos. El firewall SRX4600 bloquea ataques de manera efectiva y confiable, y le permite configurar el sistema para frustrar tipos específicos de ataques. El firewall SRX4600 es compatible con el marco de seguridad de productos definidos por software (SDSN) de Juniper, incluida la nube de prevención de amenazas avanzadas de Juniper (nube ATP), que se basa en inteligencia automatizada y procesable que se puede compartir rápidamente para reconocer y mitigar amenazas. La figura 2 muestra el firewall SRX4600 desplegado en el borde del centro de datos junto con un enrutador MX480 y conmutadores de la serie EX.
Figura 2: Despliegue del firewall SRX4600 en el borde
del centro de datos
-
Despliegue del firewall SRX4600 en el núcleo del centro de datos
Puede implementar el firewall SRX4600 en el núcleo del centro de datos para brindar mayor seguridad y garantizar que se cumplan los requisitos de cumplimiento. El procesamiento del centro de datos se ha vuelto cada vez más dinámico, lo que requiere una definición clara de la red y la aplicación de los requisitos de cumplimiento. Para garantizar el cumplimiento, puede usar el firewall SRX4600 para segmentar su red general en redes de servidores individuales y asegurar el tráfico dentro de ellas. El firewall SRX4600 ofrece alta disponibilidad y automatización, y sus servicios de capa 3 y capa 4 de alto rendimiento cumplen con los requisitos de seguridad del núcleo del centro de datos. La Figura 3 muestra el firewall SRX4600 desplegado como un firewall de múltiples capas en el núcleo del centro de datos.
Figura 3: Despliegue del firewall SRX4600 en el núcleo
del centro de datos
Además de sus funciones antimalware avanzadas, el firewall SRX4600 admite las siguientes características:
-
Firewall de estado
-
Conjunto de seguridad de aplicaciones
-
Seguridad de contenido (Sophos AV, filtrado web, antispam)
-
DPI
-
Alta disponibilidad (clúster de chasis)
-
Puertos de control de alta disponibilidad dual (10 G)
-
Soporte MACsec para puertos HA
-
-
Interfaces Ethernet a través de QSFP28 (modos 100G/40G/4x10G), QSFP+ (modos 40G/4x10G) y SFP+ (modo 10G)
-
VPN IPsec, incluidas AutoVPN y el grupo VPNv2
-
QoS y servicios de red
-
J-Web
-
Políticas de enrutamiento con multidifusión
Procesamiento basado en flujos y fundamentos de sesiones
Para entender el procesamiento de flujo en el firewall SRX4600, es importante entender los fundamentos del flujo.
Un flujo es una corriente de paquetes relacionados que cumplen los mismos criterios de coincidencia y comparten las mismas características. Junos OS trata los paquetes que pertenecen al mismo flujo de la misma manera. La arquitectura de una puerta de enlace de servicios de la serie SRX y la forma en que maneja los flujos de paquetes están estrechamente acopladas. En consecuencia, en parte, el flujo se implementa de manera diferente en toda la familia de firewalls de la serie SRX debido a sus diferencias arquitectónicas.
El procesamiento de paquetes basado en el flujo, que tiene estado, requiere la creación de sesiones. Las sesiones se crean en función del enrutamiento y otra información de clasificación de tráfico para almacenar información y asignar recursos para un flujo. Las sesiones almacenan en caché información sobre el estado del flujo y almacenan la mayoría de las medidas de seguridad que se aplicarán a los paquetes del flujo. Debido a las diferencias arquitectónicas entre los dispositivos, las sesiones también se administran de manera diferente por distintos dispositivos.
Independientemente de estas diferencias, conceptualmente el proceso de flujo es el mismo en todas las puertas de enlace de servicios, y las sesiones tienen los mismos propósitos y tienen las mismas características.
Componentes subyacentes de flujo y sesión implementados en firewalls de la serie SRX
Los firewalls de la serie SRX utilizan los mismos componentes de infraestructura para admitir el flujo y gestionar sesiones, pero no todos los dispositivos los implementan todos.
Para comprender el flujo, es esencial comprender los siguientes componentes y cómo se utilizan:
-
La Unidad de Procesamiento de Servicios (SPU)
Una SPU administra la sesión para un flujo de paquetes. Aplica funciones de seguridad y otros servicios al paquete. También aplica filtros de firewall sin estado basados en paquetes, clasificadores y formadores de tráfico al paquete.
-
El punto central (CP)
El punto central es una SPU que el sistema utiliza para asignar recursos y distribuir la administración de sesiones entre las SPU. Cuando se procesa el primer paquete de un flujo, el punto central determina qué SPU se debe usar para la sesión de ese paquete. El firewall SRX4600 no implementa un punto central.
-
La unidad de procesamiento de red (NPU) y la sesión de procesamiento de red
Una NPU es un procesador que se ejecuta en una tarjeta de E/S (IOC) y procesa los paquetes de manera discreta. Cuando se crea un flujo, los paquetes subsiguientes del flujo se hacen coincidir con la sesión en la NPU. La NPU maneja procesamiento adicional, como la verificación de secuencia TCP, el procesamiento de tiempo de vida (TTL) y la traducción de encabezado de capa 2. Una NPU mejora el rendimiento en el sentido de que se evita el reenvío de paquetes adicionales entre una session-SPU y una hash-SPU. El firewall SRX4600 implementa una NPU.
La arquitectura de flujo del firewall SRX4600 se ha mejorado para optimizar el uso de los procesadores Xeon™ multinúcleo avanzados del dispositivo SRX4600. El firewall SRX4600 implementa el uso de un subproceso de sesión dedicado para eludir problemas como la administración de paquetes fuera de orden en un flujo. Utiliza la sesión de procesamiento de red para garantizar que los paquetes se reenvíen al subproceso dedicado derecho. Los paquetes se distribuyen a diferentes subprocesos de acuerdo con el modelo de distribución de sesiones basado en hash.
Descripción del procesamiento de tráfico en dispositivos de línea SRX5000
Junos OS en SRX5000 dispositivos es un sistema distribuido, de procesamiento paralelo, de alta transferencia de datos y de alto rendimiento. La arquitectura de procesamiento paralelo distribuido de la línea SRX5000 de puertas de enlace de servicios incluye múltiples procesadores para administrar sesiones y ejecutar el procesamiento de seguridad y otros servicios. Esta arquitectura ofrece una mayor flexibilidad y permite una alta transferencia de datos y un rendimiento rápido.
En los dispositivos SRX1400, SRX3400, SRX3600, SRX5400, SRX5600 y SRX5800, las negociaciones de IKE que implican el recorrido de TDR no funcionan si el par de IKE está detrás de un dispositivo TDR que cambiará la dirección IP de origen de los paquetes de IKE durante la negociación. Por ejemplo, si el dispositivo TDR está configurado con DIP, cambia la IP de origen porque el protocolo IKE cambia el puerto UDP de 500 a 4500.
Las tarjetas I/O (IOC) y las tarjetas de procesamiento de servicios (SPC) de los dispositivos de la línea SRX5000 contienen unidades de procesamiento que procesan un paquete a medida que atraviesa el dispositivo. Una IOC tiene una o más unidades de procesamiento de red (NPU) y una SPC tiene una o más unidades de procesamiento de servicios (SPU).
Estas unidades de procesamiento tienen diferentes responsabilidades. Todos los servicios basados en flujo para un paquete se ejecutan en una sola SPU. Las responsabilidades de estas NPU no están claramente delineadas con respecto a los otros tipos de servicios que se ejecutan en ellas. .)
Por ejemplo:
-
Una NPU procesa los paquetes de manera discreta. Realiza comprobaciones de cordura y aplica algunas pantallas configuradas para la interfaz, como las pantallas de denegación de servicio (DS), al paquete.
-
Una SPU administra la sesión para el flujo de paquetes y aplica funciones de seguridad y otros servicios al paquete. También aplica filtros de firewall sin estado basados en paquetes, clasificadores y formadores de tráfico al paquete.
-
Una NPU reenvía un paquete a la SPU mediante el algoritmo hash. Sin embargo, para algunas aplicaciones, como ALG, el sistema deberá consultar el punto central de la aplicación para determinar en qué SPU se debe procesar el paquete.
Cada una de estas partes discretas y cooperantes del sistema, incluido el punto central, almacena la información que identifica si existe una sesión para un flujo de paquetes y la información con la que se compara un paquete para determinar si pertenece a una sesión existente.
Esta arquitectura permite que el dispositivo distribuya el procesamiento de todas las sesiones en varias SPU. También permite a una NPU determinar si existe una sesión para un paquete, comprobar el paquete y aplicar filtros al paquete. La forma en que se maneja un paquete depende de si es el primer paquete de un flujo.
En las siguientes secciones se describe la arquitectura de procesamiento con dispositivos SRX5400, SRX5600 y SRX5800, por ejemplo:
- Descripción del procesamiento del primer paquete
- Descripción del procesamiento de ruta rápida
- Descripción de la ruta de datos para sesiones de unidifusión
- Descripción de las unidades de procesamiento de servicios
- Descripción de las características del programador
- Descripción de la agrupación de procesadores de red
Descripción del procesamiento del primer paquete
La Figura 4 ilustra la ruta que toma el primer paquete de un flujo al entrar en el dispositivo: la NPU determina que no existe sesión para el paquete y la NPU envía el paquete al punto central distribuido para configurar una sesión de punto central distribuido. Luego, el punto central distribuido envía un mensaje al punto central de la aplicación para seleccionar la SPU a fin de configurar una sesión para el paquete y procesar el paquete. Luego, el punto central distribuido envía el paquete a esa SPU. La SPU procesa el paquete y lo envía a la NPU para su transmisión desde el dispositivo. (Esta descripción de alto nivel no aborda la aplicación de características a un paquete.)
del primer paquete
Después de que el primer paquete de un flujo ha atravesado el sistema y se ha establecido una sesión para él, se somete a un procesamiento de ruta rápida.
Los paquetes posteriores en el flujo también se someten a un procesamiento de ruta rápida; en este caso, después de que cada paquete entra en la sesión y la NPU encuentra una coincidencia para él en su tabla de sesiones, la NPU reenvía el paquete a la SPU que administra su sesión.
La Figura 5 ilustra el procesamiento de ruta rápida. Esta es la ruta que toma un paquete cuando ya se ha establecido un flujo para sus paquetes relacionados. (También es la ruta que toma el primer paquete de un flujo después de la sesión, para el flujo que inició el paquete que el paquete inició). Después de que el paquete entra en el dispositivo, la NPU encuentra una coincidencia para el paquete en su tabla de sesión y reenvía el paquete a la SPU que administra la sesión del paquete. Tenga en cuenta que el paquete omite la interacción con el punto central.
Descripción del procesamiento de ruta rápida
En la siguiente sección, se explica cómo se crea una sesión y el proceso que sigue un paquete a medida que transita por el dispositivo.
de ruta rápida
Aquí hay una descripción general de los componentes principales involucrados en la configuración de una sesión para un paquete y el procesamiento de paquetes, tanto discretamente como como parte de un flujo a medida que transitan por los dispositivos SRX5400, SRX5600 y SRX5800.
-
Unidades de procesamiento de red (NPU): las NPU residen en IOC. Se encargan de la comprobación de la cordura de los paquetes y de la aplicación de algunas pantallas. Las NPU mantienen tablas de sesión que usan para determinar si existe una sesión para un paquete entrante o para el tráfico inverso.
La tabla de sesiones de NPU contiene una entrada para una sesión si la sesión se establece en una SPU para un paquete que había ingresado previamente al dispositivo a través de la interfaz y fue procesado por esta NPU. La SPU instala la sesión en la tabla NPU cuando crea la sesión.
Una NPU determina si existe una sesión para un paquete comprobando la información del paquete con su tabla de sesiones. Si el paquete coincide con una sesión existente, la NPU envía el paquete y sus metadatos a la SPU. Si no hay sesión, la NPU envía el paquete a una SPU, que se calcula mediante el algoritmo hash.
-
Unidades de procesamiento de servicios (SPU): los procesadores principales de los dispositivos SRX5400, SRX5600 y SRX5800 residen en SPC. Las SPU establecen y administran flujos de tráfico, y realizan la mayor parte del procesamiento de paquetes en un paquete a medida que transita por el dispositivo. Cada SPU mantiene una tabla hash para una búsqueda rápida de sesiones. La SPU aplica filtros, clasificadores y formadores de tráfico de firewall sin estado al tráfico. Una SPU realiza todo el procesamiento basado en flujo para un paquete y la mayoría del procesamiento basado en paquetes. Cada SPU multinúcleo procesa los paquetes de forma independiente con una interacción mínima entre las SPU en la misma SPC o en una diferente. Todos los paquetes que pertenecen al mismo flujo son procesados por la misma SPU.
La SPU mantiene una tabla de sesiones con entradas para todas las sesiones que estableció y cuyos paquetes procesa. Cuando una SPU recibe un paquete de una NPU, comprueba su tabla de sesiones para asegurarse de que el paquete le pertenece. También comprueba su tabla de sesiones cuando recibe un paquete del punto central distribuido y envía un mensaje para establecer una sesión para ese paquete a fin de comprobar que no existe una sesión para el paquete.
-
Punto central: la arquitectura de punto central se divide en dos módulos, el punto central de la aplicación y el punto central distribuido. El punto central de la aplicación es responsable de la administración global de recursos y el equilibrio de carga, mientras que el punto central distribuido es responsable de la identificación del tráfico (coincidencia global de sesiones). La funcionalidad de punto central de la aplicación se ejecuta en la SPU de punto central dedicada, mientras que la funcionalidad de punto central distribuido se distribuye al resto de las SPU. Ahora, las sesiones de punto central ya no se encuentran en la SPU de punto central dedicada, sino con el punto central distribuido en otras SPU de flujo.
-
Motor de enrutamiento: el motor de enrutamiento ejecuta el plano de control.
Descripción de la ruta de datos para sesiones de unidifusión
En esta sección se describe el proceso para establecer una sesión para los paquetes que pertenecen a un flujo que transita por el dispositivo.
Para ilustrar el establecimiento de la sesión y el "paseo" de paquetes, incluidos los puntos en los que se aplican servicios a los paquetes de un flujo, en este ejemplo se utiliza el caso simple de una sesión de unidifusión.
Este "paseo" de paquetes reúne el procesamiento basado en paquetes y el procesamiento basado en flujo que Junos OS realiza en el paquete.
- Criterios de búsqueda de sesión y coincidencia de paquetes
- Descripción de la creación de sesiones: procesamiento del primer paquete
- Descripción del procesamiento de ruta rápida
Criterios de búsqueda de sesión y coincidencia de paquetes
Para determinar si un paquete pertenece a un flujo existente, el dispositivo intenta hacer coincidir la información del paquete con la de una sesión existente según los seis criterios de coincidencia siguientes:
-
Dirección de origen
-
Dirección de destino
-
Puerto de origen
-
Puerto de destino
-
Protocolo
-
Token único de una zona y un enrutador virtual dados
Descripción de la creación de sesiones: procesamiento del primer paquete
En esta sección, se explica cómo se configura una sesión para procesar los paquetes que componen un flujo. Para ilustrar el proceso, esta sección utiliza un ejemplo con una fuente "a" y una "b" de destino. La dirección desde el origen hasta el destino de los paquetes del flujo se denomina (a ->b). La dirección desde el destino hasta el origen se denomina (b->a).
Paso 1. Un paquete llega a una interfaz en el dispositivo y la NPU lo procesa.
En esta sección se describe cómo se maneja un paquete cuando llega a una IOC de entrada de firewall de la serie SRX.
-
El paquete llega a la IOC del dispositivo y lo procesa la NPU en la IOC.
-
La NPU realiza comprobaciones básicas de cordura en el paquete y aplica algunas pantallas configuradas para la interfaz al paquete.
-
La NPU comprueba su tabla de sesiones para ver si hay una sesión existente para el paquete. (Comprueba la tupla del paquete con la de los paquetes de las sesiones existentes en su tabla de sesiones).
-
Si no se encuentra ninguna sesión existente, la NPU reenvía el paquete a la SPU hash.
-
Si se encuentra una coincidencia de sesión, la sesión ya se creó en una SPU que se le asignó, por lo que la NPU reenvía el paquete a la SPU para su procesamiento junto con el ID de sesión.
-
Example: El paquete (a ->b) llega a NPU1. NPU1 realiza comprobaciones de cordura y aplica filtros de DS al paquete. NPU1 comprueba su tabla de sesiones en busca de una coincidencia de tupla y no se encuentra ninguna sesión existente. NPU1 reenvía el paquete a una SPU.
Paso 2. El punto central distribuido crea una sesión con un estado "pendiente".
Cuando una NPU recibe un paquete, la NPU lo envía al punto central distribuido, según el algoritmo hash. A continuación, el punto central distribuido busca la tabla de sesiones del punto central distribuido y crea una entrada si es necesario.
Este proceso consta de las siguientes partes:
-
El punto central distribuido comprueba su tabla de sesiones para determinar si existe una sesión para el paquete recibido de la NPU. (Una NPU reenvía un paquete al punto central distribuido porque no puede encontrar una sesión existente para el paquete)
-
Si no hay ninguna entrada que coincida con el paquete en la tabla de sesión del punto central distribuido, el punto central distribuido crea un ala pendiente para la sesión. Luego, el punto central distribuido envía un mensaje de consulta al punto central de la aplicación para seleccionar una SPU que se utilizará para la sesión.
-
Al recibir el mensaje de consulta, el punto central de la aplicación comprueba su tabla de puertas para determinar si existe una puerta para el paquete. Si se hace coincidir una puerta o se activa algún otro algoritmo de distribución de sesión, el punto central de la aplicación selecciona otra SPU para procesar el paquete; de lo contrario, se selecciona la SPU (es decir, la SPU de punto central distribuido). Por último, el punto central de la aplicación envía una respuesta de consulta al punto central distribuido.
-
Al recibir la respuesta a la consulta, el punto central distribuido reenvía el primer paquete en flujo a la SPU seleccionada en un mensaje que indica a la SPU que configure una sesión localmente que se utilizará para el flujo de paquetes. Por ejemplo, el punto central distribuido crea un ala pendiente (a ->b) para la sesión. El punto central de la aplicación selecciona SPU1 que se utilizará para ello. El punto central distribuido envía a SPU1 el paquete (a->b) junto con un mensaje para crear una sesión para el punto central distribuido.
Example: El punto central distribuido crea un ala pendiente (a ->b) para la sesión. Selecciona SPU1 para usarlo. Envía a SPU1 el paquete (a->b) junto con un mensaje para crear una sesión para él.
Paso 3. La SPU organiza la sesión.
Cada SPU también tiene una tabla de sesiones, que contiene información sobre sus sesiones. Cuando la SPU recibe un mensaje del punto central distribuido para configurar una sesión, comprueba su tabla de sesiones para asegurarse de que no existe ya una sesión para el paquete.
-
Si no hay ninguna sesión existente para el paquete, la SPU configura la sesión localmente.
-
La SPU envía un mensaje al punto central distribuido para indicarle que instale la sesión.
Nota:Durante el procesamiento del primer paquete, si TDR está habilitado, la SPU asigna recursos de dirección IP para TDR. En este caso, el procesamiento del primer paquete de la sesión se suspende hasta que se complete el proceso de asignación de TDR.
La SPU agrega a la cola cualquier paquete adicional para el flujo que podría recibir hasta que se haya instalado la sesión.
Example: SPU1 crea la sesión para (a ->b) y envía un mensaje al punto central distribuido para indicarle que instale la sesión pendiente.
Paso 4. El punto central distribuido instala la sesión.
El punto central distribuido recibe el mensaje de instalación de la SPU.
-
El punto central distribuido establece el estado del ala pendiente de la sesión en activo.
-
El punto central distribuido instala el ala inversa para la sesión como un ala activa.
Nota:Para algunos casos, como TDR, el ala inversa se puede instalar en un punto central distribuido diferente del punto central distribuido del ala de inicio.
-
Envía un mensaje de confirmación (ACK) a la SPU, lo cual indica que la sesión está instalada.
Example: El punto central distribuido recibe un mensaje de SPU1 para instalar la sesión para el ala (a->b). Establece el estado de sesión del ala (a->b) en activo. Instala el ala inversa (b->a) para la sesión y la activa; Esto permite la entrega de paquetes desde la dirección inversa del flujo: el destino (B) se entregará al origen (A).
Paso 5. La SPU configura la sesión en las NPU de entrada y salida.
Las NPU mantienen información sobre una sesión para el reenvío y la entrega de paquetes. La información de la sesión se configura en las NPU de entrada y salida (que a veces son las mismas) para que los paquetes se puedan enviar directamente a la SPU que gestiona sus flujos y no al punto central distribuido para su redireccionamiento.
Paso 6. Se lleva a cabo un procesamiento de ruta rápida.
Para el resto de los pasos relacionados con el procesamiento de paquetes, continúe con el paso 1 de Descripción del procesamiento de ruta rápida.
La Figura 6 ilustra la primera parte del proceso que experimenta el primer paquete de un flujo después de llegar al dispositivo. En este punto, se configura una sesión para procesar el paquete y el resto de los paquetes que pertenecen a su flujo. Posteriormente, este y el resto de los paquetes en el flujo se someten a un procesamiento de ruta rápida.
del primer paquete
Descripción del procesamiento de ruta rápida
Todos los paquetes se someten a un procesamiento de ruta rápida. Sin embargo, si existe una sesión para un paquete, el paquete se somete a un procesamiento de ruta rápida y omite el proceso del primer paquete. Cuando ya hay una sesión para el flujo del paquete, el paquete no transita por el punto central.
Así es como funciona el procesamiento de ruta rápida: Las NPU en las interfaces de salida y entrada contienen tablas de sesión que incluyen la identificación de la SPU que administra el flujo de un paquete. Dado que las NPU tienen esta información de sesión, todo el tráfico del flujo, incluido el tráfico inverso, se envía directamente a esa SPU para su procesamiento.
Para ilustrar el proceso de ruta rápida, en esta sección se utiliza un ejemplo con una fuente "a" y una "b" de destino. La dirección desde el origen hasta el destino de los paquetes del flujo se denomina (a->b). La dirección desde el destino hasta el origen se denomina (b->a).
Paso 1. Un paquete llega al dispositivo y la NPU lo procesa.
En esta sección se describe cómo se maneja un paquete cuando llega a la IOC de una puerta de enlace de servicios.
-
El paquete llega a la IOC del dispositivo y es procesado por la NPU en la tarjeta.
La NPU realiza comprobaciones de cordura y aplica algunas pantallas, como las de denegación de servicio (DS), al paquete.
-
La NPU identifica una entrada para una sesión existente en su tabla de sesiones con la que coincide el paquete.
-
La NPU reenvía el paquete junto con los metadatos de su tabla de sesiones, incluido el ID de sesión y la información de la tupla del paquete, a la SPU que administra la sesión para el flujo, aplica filtros de firewall sin estado y funciones de CoS a sus paquetes, y maneja el procesamiento del flujo del paquete y la aplicación de seguridad y otras características.
Example: El paquete (a ->b) llega a NPU1. NPU1 realiza comprobaciones de cordura en el paquete, le aplica filtros de DS y comprueba si su tabla de sesiones no coincide con la tupla. Encuentra una coincidencia y que existe una sesión para el paquete en SPU1. NPU1 reenvía el paquete a SPU1 para su procesamiento.
Paso 2. La SPU de la sesión procesa el paquete.
La mayor parte del procesamiento de un paquete se produce en la SPU a la que está asignada su sesión. El paquete se procesa para funciones basadas en paquetes, como filtros de firewall sin estado, formadores de tráfico y clasificadores, si procede. La seguridad basada en flujo configurada y los servicios relacionados, como funciones de firewall, TDR, ALG, etc., se aplican al paquete. (Para obtener información sobre cómo se determinan los servicios de seguridad para una sesión.
-
Antes de procesar el paquete, la SPU comprueba su tabla de sesiones para comprobar que el paquete pertenece a una de sus sesiones.
-
La SPU procesa el paquete para las características y servicios aplicables.
Example: SPU1 recibe el paquete (a->b) de NPU1. SPU1 comprueba su tabla de sesiones para verificar que el paquete pertenece a una de sus sesiones. Luego, procesa el paquete (a ->b) de acuerdo con los filtros de entrada y las funciones de CoS que se aplican a su interfaz de entrada. La SPU aplica las funciones y los servicios de seguridad que se configuran para el flujo del paquete hacia ella, según su zona y políticas. Si se configura alguno, aplica filtros de salida, formadores de tráfico y filtros adicionales al paquete.
Paso 3. La SPU reenvía el paquete a la NPU.
-
La SPU reenvía el paquete a la NPU.
-
La NPU aplica cualquier pantalla aplicable asociada con la interfaz al paquete.
Example: SPU1 reenvía el paquete (a ->b) a NPU2 y NPU2 se aplica DS pantallas.
Paso 4. La interfaz transmite el paquete desde el dispositivo.
Example: La interfaz transmite el paquete (a->b) desde el dispositivo.
Paso 5. Un paquete de tráfico inverso llega a la interfaz de salida y la NPU lo procesa.
Este paso refleja exactamente el Paso 1 a la inversa. Consulte el paso 1 de esta sección para obtener más información.
Example: El paquete (b->a) llega a NPU2. NPU2 comprueba si hay una coincidencia de tupla en su tabla de sesiones. Encuentra una coincidencia y que existe una sesión para el paquete en SPU1. NPU2 reenvía el paquete a SPU1 para su procesamiento.
Paso 6. La SPU de la sesión procesa el paquete de tráfico inverso.
Este paso es el mismo que el paso 2, con la diferencia de que se aplica al tráfico inverso. Consulte el paso 2 de esta sección para obtener más información.
Example: SPU1 recibe el paquete (b->a) de NPU2. Comprueba su tabla de sesiones para verificar que el paquete pertenece a la sesión identificada por NPU2. A continuación, aplica las características basadas en paquetes configuradas para la interfaz de la NPU1 al paquete. Procesa el paquete (b->a) de acuerdo con las características de seguridad y otros servicios que se configuran para su flujo, con base en su zona y políticas.
Paso 7. La SPU reenvía el paquete de tráfico inverso a la NPU.
Este paso es el mismo que el paso 3, con la excepción de que se aplica al tráfico inverso. Consulte el paso 3 de esta sección para obtener más información.
Example: SPU1 reenvía el paquete (b->a) a NPU1. NPU1 procesa cualquier pantalla configurada para la interfaz.
8. La interfaz transmite el paquete desde el dispositivo.
Este paso es el mismo que el paso 4, con la diferencia de que se aplica al tráfico inverso. Consulte el paso 4 de esta sección para obtener más información.
Ejemplo: La interfaz transmite el paquete (b->a) desde el dispositivo.
La Figura 7 ilustra el proceso al que pasa un paquete cuando llega al dispositivo y existe una sesión para el flujo al que pertenece el paquete.
de rutas rápidas
Descripción de las unidades de procesamiento de servicios
Para una interfaz física dada, la SPU recibe paquetes de entrada de todos los procesadores de red en el paquete de procesadores de red asociado con la interfaz física. La SPU extrae información del paquete de procesadores de red de la interfaz física y utiliza el mismo algoritmo hash de 5 tuplas para asignar un flujo a un índice de procesador de red. Para determinar el procesador de red, la SPU realiza una búsqueda en el índice del procesador de red en el paquete de procesadores de red. La SPU envía paquetes de salida al módulo de interfaz física (PIM) local de la interfaz física para el tráfico de salida.
El procesador de red y la SPU utilizan el mismo algoritmo hash de 5 tuplas para obtener los valores hash de los paquetes.
Descripción de las características del programador
Para los dispositivos SRX5400, SRX5600 y SRX5800, la IOC admite las siguientes características jerárquicas del programador:
-
IFL: la configuración del paquete de procesadores de red se almacena en la estructura de datos de la interfaz física. Por ejemplo, los dispositivos SRX5400, SRX5600 y SRX5800 tienen un máximo de 48 PIM. La interfaz física puede usar una máscara de bits de 48 bits para indicar el PIM, o bien se distribuye el tráfico del procesador de red desde esta interfaz física además del procesador de red principal de la interfaz física.
En los dispositivos de línea SRX5000, la funcionalidad iflset no se admite para interfaces agregadas como reth.
-
IFD: la interfaz lógica asociada con la interfaz física de un paquete de procesadores de red se pasa a todas las IOC que tienen un PIM en el paquete de procesadores de red.
Descripción de la agrupación de procesadores de red
La función de agrupación de procesadores de red está disponible en los dispositivos de la línea SRX5000. Esta característica permite la distribución del tráfico de datos desde una interfaz a varios procesadores de red para el procesamiento de paquetes. Se asigna un procesador de red primario para una interfaz que recibe el tráfico de entrada y distribuye los paquetes a varios otros procesadores de red secundarios. Un único procesador de red puede actuar como procesador de red principal o como procesador de red secundario para varias interfaces. Un solo procesador de red puede unirse a un solo paquete de procesadores de red.
Limitaciones de la agrupación de procesadores de red
La funcionalidad de agrupación de procesadores de red tiene las siguientes limitaciones:
-
La agrupación de procesadores de red permite un total de 16 PIM por paquete y 8 sistemas de paquetes de procesadores de red diferentes.
-
Debe reiniciar el dispositivo para aplicar los cambios de configuración en el paquete.
-
La agrupación de procesadores de red se encuentra por debajo de la interfaz reth en la arquitectura general. Puede elegir una o ambas interfaces del paquete de procesadores de red para formar la interfaz reth.
-
Si se elimina el IOC de un paquete de procesadores de red, se pierden los paquetes reenviados al PIM en ese IOC.
-
Cuando el paquete de procesador de red está habilitado, los umbrales de inundación de sincronización ICMP, UDP y TCP ya no se aplican a una interfaz. Los paquetes se distribuyen a múltiples procesadores de red para su procesamiento. Estos umbrales se aplican a cada procesador de red del paquete de procesadores de red.
-
La agrupación de procesadores de red no se admite en el modo de capa 2.
-
Debido a las restricciones de memoria en el procesador de red, el número de puertos agrupados en el procesador de red que se admiten por PIM es limitado. Dentro del paquete de procesadores de red, cada puerto debe tener un índice de puerto global. El índice global de puertos se calcula mediante la siguiente fórmula:
Global_port_index = (global_pic * 16) + port_offset
-
Los grupos de agregación de vínculos (LAG) y los LAG de interfaz Ethernet redundantes en implementaciones de clústeres de chasis pueden coexistir con la agrupación de procesadores de red. Sin embargo, ni los LAG ni los LAG de interfaz Ethernet redundantes pueden superponerse o compartir vínculos físicos con un paquete de procesador de red.
Descripción de la caché de sesiones
- Descripción general
- Instalación selectiva de caché de sesiones
- Mejora de la afinidad de sesión de VPN IPsec mediante la caché de sesión
- Orden de paquetes de fragmentación mediante la caché de sesión NP
Descripción general
Las SRX5K-MPC (IOC2), SRX5K-MPC3-100G10G (IOC3) y SRX5K-MPC3-40G10G (IOC3) en dispositivos SRX5400, SRX5600 y SRX5800 admiten la caché de sesiones y la instalación selectiva de la caché de sesiones.
La caché de sesión se utiliza para almacenar en caché una conversación entre el procesador de red (NP) y la SPU en una IOC. Una conversación puede ser una sesión, tráfico de túnel GTP-U, tráfico de túnel VPN IPsec, etc. Una conversación tiene dos entradas de caché de sesión, una para el tráfico entrante y la otra para el tráfico inverso. Dependiendo de dónde estén los puertos de entrada y salida del tráfico, dos entradas pueden residir en el mismo procesador de red o en procesadores de red diferentes. Las IOC admiten caché de sesiones para sesiones IPv6.
Una entrada de caché de sesión también se denomina ala de sesión.
La caché de sesiones en el IOC aprovecha la funcionalidad de Express Path (anteriormente conocida como descarga de servicios) y ayuda a prevenir problemas como alta latencia y caída del rendimiento de IPsec.
Una entrada de caché de sesión registra:
A qué SPU se debe reenviar el tráfico de la conversión
A qué puerto de salida se debe reenviar el tráfico de la conversión en modo Express Path
Qué procesamiento hacer para el tráfico de salida, por ejemplo, traducción TDR en modo Express Path
El resto del tráfico se cifraba a las SPU en función de la información de su clave de 5 tuplas. El tráfico VPN empleó el concepto de SPU anclado, que no necesariamente coincidió con las funciones de la SPU de flujo. El procesador de red solo podía reenviar los paquetes a la SPU de flujo según el hash de 5 tuplas. Luego, la SPU de flujo reenvió el paquete a la SPU anclada. Esto creó un salto adicional para el tráfico VPN, lo que desperdició el ancho de banda de la estructura de conmutación y redujo la transferencia de datos VPN aproximadamente a la mitad. Esta reducción del rendimiento se produjo porque el tráfico todavía tenía que volver a la SPU de flujo después del procesamiento en la SPU anclada.
La tabla de caché de sesiones ahora se extiende en IOC para admitir las sesiones NP. El tráfico de ruta rápida y el tráfico NP comparten la misma tabla de caché de sesión en las IOC. El tráfico de Express Path es reenviado por el propio IOC localmente o a otro IOC, ya que el tráfico no requiere ningún servicio de la SPU. El tráfico NP se reenvía a la SPU especificada en la caché de sesión para su posterior procesamiento. Todas las entradas de caché de sesión son compartidas por el tráfico de sesión de Express Path y el tráfico NP.
Para habilitar la caché de sesiones en las IOC, debe ejecutar el set chassis fpc <fpc-slot> np-cache comando.
La IOC2 y la IOC3 utilizan el mecanismo de eliminación de sesiones de retraso. Las mismas sesiones (sesiones con las mismas cinco tuplas) que se eliminan y luego se vuelven a instalar inmediatamente no se almacenan en caché en las IOC.
Instalación selectiva de caché de sesiones
Para evitar la alta latencia, mejorar el rendimiento de IPSec y utilizar mejor los valiosos recursos, se aplican ciertos mecanismos de prioridad tanto al módulo de flujo como al IOC.
Las IOC mantienen y supervisan los niveles de umbral de uso de la caché de la sesión. Las IOC también comunican el uso de caché de sesión a la SPU, de modo que cuando se alcanza un determinado umbral de uso de caché de sesión, la SPU solo envía solicitudes de instalación de caché de sesión para sesiones de tráfico selectivas de alta prioridad.
Las aplicaciones como DPI, ALG necesitan procesar los paquetes en orden. Una SPU tiene varios subprocesos de flujo para manejar paquetes que pertenecen a una sesión, el orden de los paquetes del subproceso de equilibrio de carga (LBT) y el de los subprocesos de orden de paquetes (POT) pueden garantizar que el tráfico pase a través del firewall en orden, no puede garantizar que la aplicación procese paquetes que pertenecen a la misma sesión en orden. La serialización de flujo proporciona el método por el cual solo un subproceso de flujo SPU que procesa paquetes pertenecen a la misma sesión a la vez, para que las aplicaciones puedan recibir, procesar y enviar paquetes en orden. Otros subprocesos de flujo pueden realizar el procesamiento de serialización de flujo para otras sesiones al mismo tiempo.
Los siguientes cuatro niveles de prioridad se utilizan para determinar qué tipo de tráfico puede instalar la caché de sesión en las IOC:
Priority 1 (P1)— Tráfico calificado para IPSec y Express Path
Priority 2 (P2)— Orden de fragmentación
Priority 3 (P3)— Tráfico de tráfico TDR/SZ (serialización de sesión)
Priority 4(P3)— Todos los demás tipos de tráfico
Las IOC mantienen y monitorean los niveles de umbral para el uso de la caché de sesión y actualizan el uso actual de la caché de sesión en tiempo real a la SPU. La SPU solicita al IOC que instale la caché de sesión para ciertas sesiones de tráfico de alta prioridad. El uso de la caché de sesión para las sesiones de tráfico de alta prioridad se define en la tabla:
Tipo de tráfico |
0 % < utilización < 25 % |
25 % < utilización < 50 % |
50 % < utilización < 75 % |
75 % < utilización < 100 % |
|---|---|---|---|---|
Tráfico IPsec y Express Path |
Sí |
Sí |
Sí |
Sí |
Fragmentación Ordenar el tráfico |
Sí |
Sí |
Sí |
No |
Tráfico TDR/SZ |
Sí |
Sí |
No |
No |
Otro tráfico |
Sí |
No |
No |
No |
Para conservar las entradas de sesión en el IOC, el módulo de flujo instala selectivamente las sesiones en el IOC. Para facilitar la selección de instalación de la sesión, la IOC mantiene los umbrales correspondientes para proporcionar una indicación al módulo de flujo (sobre el grado de llenado de la tabla de caché de sesión en las IOC). Se agregan dos bits en el encabezado meta para indicar el estado actual de utilización de la tabla de caché. Todos los paquetes que vayan a la SPU llevarán estos dos bits de estado para informar al módulo de flujo de la utilización de la tabla de caché en el IOC.
Mejora de la afinidad de sesión de VPN IPsec mediante la caché de sesión
Los firewalls de la serie SRX son sistemas totalmente distribuidos, y un túnel IPsec se asigna y ancla a una SPU específica. Todo el tráfico que pertenece a un túnel IPsec se cifra y descifra en su SPU anclada al túnel. Con el fin de lograr un mejor rendimiento de IPsec, la IOC mejora el módulo de flujo para crear sesiones para el tráfico basado en túnel IPsec (antes del cifrado y después del descifrado) en su SPU anclada al túnel e instala la caché de sesiones para las sesiones, de modo que la IOC pueda redirigir los paquetes directamente a la misma SPU para minimizar la sobrecarga de reenvío de paquetes. El tráfico de ruta rápida y el tráfico NP comparten la misma tabla de caché de sesión en las IOC.
Debe habilitar la caché de sesiones en las IOC y establecer la política de seguridad para determinar si una sesión es para el modo Express Path (anteriormente conocido como descarga de servicios) en el concentrador de PIC flexible (FPC) seleccionado.
Para habilitar la afinidad VPN IPsec, use el set security flow load-distribution session-affinity ipsec comando.
Para habilitar la afinidad VPN de IPsec, también debe habilitar la caché de sesión en IOC mediante el set chassis fpc <fpc-slot> np-cache comando.
Orden de paquetes de fragmentación mediante la caché de sesión NP
Una sesión puede constar de paquetes normales y fragmentados. Con la distribución basada en hash, se pueden usar claves de 5 tuplas y 3 tuplas para distribuir paquetes normales y fragmentados a diferentes SPU, respectivamente. En los firewalls de la serie SRX, todos los paquetes de la sesión se reenvían a una SPU de procesamiento. Debido a la latencia de reenvío y procesamiento, es posible que la SPU de procesamiento no garantice el orden de los paquetes de la sesión.
La caché de sesiones en las IOC garantiza el orden de los paquetes de una sesión con paquetes fragmentados. Se asigna una entrada de caché de sesión para los paquetes normales de la sesión y se utiliza una clave de 3 tuplas para buscar los paquetes fragmentados. Al recibir el primer paquete fragmentado de la sesión, el módulo de flujo permite que el IOC actualice la entrada de caché de sesión para recordar los paquetes fragmentados para la SPU. Más tarde, IOC reenvía todos los paquetes subsiguientes de la sesión a la SPU para garantizar el orden de los paquetes de una sesión con paquetes fragmentados.
Configuración de la asignación de IOC a NPC
Una asignación de tarjeta de entrada/salida (IOC) a tarjeta de procesamiento de red (NPC) requiere que asigne una IOC a un NPC. Sin embargo, puede asignar varios IOC a un solo NPC. Para equilibrar la potencia de procesamiento en el NPC en las puertas de enlace de servicios SRX3400 y SRX3600, el proceso de chasis (daemon) ejecuta un algoritmo que realiza la asignación. Asigna un IOC a un NPC que tiene la menor cantidad de IOC asignados. También puede utilizar la interfaz de línea de comandos (CLI) para asignar una IOC específica a un NPC específico. Cuando configure la asignación, el proceso del chasis utilizará primero su configuración y, luego, aplicará el algoritmo NPC de número mínimo para el resto de las IOC.
La compatibilidad de plataforma depende de la versión de Junos OS en su instalación.
Para configurar la asignación de IOC a NPC:
[edit]
set chassis ioc-npc-connectivity {
ioc slot-number npc (none | slot-number);
}
Debe reiniciar el control de chasis después de confirmar el set chassis ioc-npc-connectivity comando.
Descripción del procesamiento de flujo en dispositivos SRX5K-SPC3
La tarjeta de procesamiento de servicios SRX5K-SPC3 se presenta para mejorar el rendimiento de los servicios de seguridad en la puerta de enlace de servicios de seguridad SRX5000. La tarjeta SPC3 admite una mayor transferencia de datos, mantiene su confiabilidad ya que conserva la funcionalidad del clúster de chasis y la escalabilidad para el procesamiento del servicio.
La tarjeta SPC3 es compatible con las siguientes funciones de seguridad:
-
Puerta de enlace de la capa de aplicación (ALG). [Ver descripción general del ALG]
-
Anti-malware avanzado (Juniper ATP Cloud). [Consulte Administración de Juniper Sky Advanced Threat Prevention]
-
Paquete de seguridad de aplicaciones. [Consulte la Guía del usuario de seguridad de aplicaciones para dispositivos de seguridad]
-
Implementación del procesamiento de paquetes basado en el flujo
-
Protocolo de tunelización GPRS (GTP) y protocolo de transmisión de control de flujo (SCTP). [ Consulte la Guía del usuario del servicio general de paquetes de radio para dispositivos de seguridad]
-
Alta disponibilidad (clúster de chasis). [Consulte la Guía del usuario del clúster de chasis para dispositivos de la serie SRX]
-
Detección y prevención de intrusiones (DPI). [Consulte Descripción general de la detección y prevención de intrusiones]
-
Traducción de direcciones de red (TDR). [ Consulte la Guía del usuario de traducción de direcciones de red para dispositivos de seguridad]
-
Firewall de estado
-
Proxy de SSL. [ Consulte Proxy SSL]
-
Autenticación de usuario de firewall. [Consulte Guía del usuario de autenticación y firewalls de usuario integrados para dispositivos de seguridad]
-
Seguridad de contenido (antivirus, filtrado web, filtrado de contenido y antispam). [Consulte la Guía del usuario de UTM para dispositivos de seguridad]
El flujo de seguridad se ha mejorado para admitir la tarjeta SPC3 con todas las funciones de seguridad existentes que se admiten en la tarjeta SPC2.
Se aplican las siguientes limitaciones para la tarjeta SPC3 en Junos OS versión 18.2R1-S1:
-
No se admite la interoperabilidad de la tarjeta SPC3 y la tarjeta SPC2.
-
La funcionalidad VPN IPsec no es compatible con la tarjeta SPC3.
En los dispositivos de la línea SRX5000, la tarjeta SPC3 interopera con tarjetas E/S (IOC2, IOC3), tarjeta de control de conmutación (SCB2, SCB3), motores de enrutamiento y tarjetas SPC2.
A partir de la versión 18.4R1 de Junos OS, se admite una combinación de tarjetas SPC3 y SPC2 en los dispositivos de la línea SRX5000.
Si va a agregar las tarjetas SPC3 en dispositivos de la línea SRX5000, la nueva tarjeta SPC3 debe instalarse en la ranura con el número más bajo de cualquier SPC. La tarjeta SPC3 instalada en la ranura original con el número más bajo proporciona la funcionalidad de punto central (CP) en modo mixto. Por ejemplo, si la puerta de enlace de servicios contiene una combinación de tarjetas SPC2 y SPC3, una SPC3 debe ocupar la ranura con el número más bajo de cualquier SPC del chasis. Esta configuración garantiza que la funcionalidad de punto central (CP) en modo mixto la realice la tarjeta SPC3.
En los dispositivos de la línea SRX5000 que funcionan en modo mixto, el procesamiento de flujo se comparte entre las tarjetas SPC3 y SPC2. El procesamiento del punto central se lleva a cabo en la ranura SPC del número más bajo para el que está instalada una tarjeta SPC3.
Cuando los firewalls de la serie SRX funcionan en modo de clúster de chasis, las tarjetas SPC3 y SPC2 deben instalarse en las mismas ubicaciones de ranura en cada chasis.
- Descripción de la arquitectura de software SPC3
- Descripción de la distribución de la carga
- Descripción de la sesión NP y la descarga de servicios (SOF)
- Descripción de la compatibilidad con J-Flow en SPC3
- Descripción de la depuración de ruta de datos Compatibilidad con SPU (E2E)
- Descripción del manejo de fragmentación, ISSU y compatibilidad con ISHU
Descripción de la arquitectura de software SPC3
La arquitectura de flujo de SPC3 es la misma que la arquitectura de CP-Lite. La SPC3 tiene físicamente dos unidades de procesamiento de servicios (SPU) y cada SPU tiene dos CPU.
Cuando se instalan una o dos SPC3, el procesamiento de tráfico utiliza el 75 % de la primera SPC. Cuando se instalan tres o más SPC3, el procesamiento de tráfico utiliza el 50 % de la primera SPC.
Se cambia la forma en que el IOC aplica hash a los paquetes para procesar el flujo. La figura muestra el flujo de paquetes del firewall de la serie SRX con SPC3.
En SPC3, los paquetes se distribuyen desde IOC a cada núcleo directamente. Dado que el IOC aplica hash directamente a los paquetes al subproceso RT fluido, se elimina el subproceso LBT original. Los paquetes ahora se entregan al subproceso fluido en lugar de a SPU. Si el flujo de seguridad instala sesiones NP, en lugar de un ID de SPU, el IOC utiliza el ID de subproceso de sesión para reenviar paquetes y corregir la asociación de subprocesos con la sesión.
fluido
Descripción de la distribución de la carga
Todos los paquetes que llegan a través de un puerto de ingresos se distribuirán a diferentes SPU según el algoritmo hash, que es el mismo que el hash existente de los dispositivos SRX5000 Line basados en la arquitectura CP-Lite. El método hash varía según los distintos tipos de tráfico. En la tabla siguiente se enumeran los métodos hash.
| Protocolo |
Puertos |
Método hash |
|
|---|---|---|---|
| TCP |
Puerto src L4 y puerto dst |
Hash por 5 tuplas |
|
| UDP |
Normal |
Puerto src L4 y puerto dst |
Hash por 5 tuplas |
| GTP |
Puerto src L4 y puerto dst |
Hash por 5 tuplas |
|
| ICR |
Puerto src L4 y puerto dst |
Hash por par de IP |
|
| ICMP |
|
La información de ICMP se hashea con 5 tuplas; El error de ICMP se hashea con 3 tuplas (sin información de puertos) |
|
| SCTP |
Puerto src L4 y puerto dst |
Hash por 5 tuplas |
|
| ESP |
SPI |
Hash por par de IP |
|
| AH |
SPI |
Hash por par de IP |
|
| GRE |
Si PPTP alg está habilitado, sport = call id; dport = 0 De forma predeterminada, port es 0x00010001 |
Hash por 3 tuplas |
|
| PIM |
De forma predeterminada, los puertos PIM 0x00010001 |
Hash por 3 tuplas |
|
| FRAGMENTO |
El primer fragmento tiene los puertos normales Ni primer fragmento, ni puertos |
Hash por 3 tuplas |
|
| Otro paquete IP |
Puertos 0x00010001 |
Hash por 3 tuplas |
|
| NINGUNA IP |
No aplica |
Hash por dirección MAC y tipo de Ethernet (ID de VLAN) |
|
Descripción de la sesión NP y la descarga de servicios (SOF)
La sesión del procesador de red (NP) es una sesión basada en IOC que permite y establece las sesiones de SPU. Los paquetes que pasan la sesión NP tienen las siguientes ventajas:
-
Evita la búsqueda de sesiones en SPU para obtener un mejor rendimiento.
-
Evita el reenvío de paquetes adicional entre la SPU de sesión y la SPU de hash.
La descarga de servicio es un tipo especial de sesión NP para proporcionar una función de baja latencia para la sesión que necesita un servicio básico de firewall. Los paquetes que llegan a la sesión SOF en una IOC omiten el procesamiento de paquetes en la SPU y son reenviados directamente por la IOC. Los siguientes tipos de tráfico admiten la descarga de servicio:
-
Firewall básico (sin complemento ni fragmentos), IPv4 e IPv6 TCP, tráfico UDP
-
IPv4 TDR
-
1Multidifusión de entrada y 1 salida
-
ALG, como la sesión de datos FTP
Descripción de la compatibilidad con J-Flow en SPC3
J-Flow es la versión de Juniper del mecanismo de monitoreo de tráfico estándar de la industria. Proporciona una función para exportar instantáneas de estadísticas de tráfico de red al servidor remoto para monitoreo de red y procesamiento posterior de datos. J-Flow admite los formatos v5, v8 y v9. Estas tres versiones son compatibles con SPC3.
Descripción de la depuración de ruta de datos Compatibilidad con SPU (E2E)
La depuración de ruta de datos proporciona una función de depuración de paquetes de extremo a extremo (E2E) basada en filtros en dispositivos de línea SRX5000. Rastrea la ruta del paquete y volca el contenido del paquete.
En SPC3, JEXEC es el único tipo de evento E2E compatible y se admiten los siguientes tipos de acción E2E:
-
Recuento
-
Volcado
-
Rastrear
-
Resumen de trazas
Descripción del manejo de fragmentación, ISSU y compatibilidad con ISHU
En SPC3, los paquetes fragmentados se reenvían al "núcleo de fragmento" en una PFE específica en función de sus valores de tupla de encabezado. Después de recibir un paquete fragmentado, flow realiza la desfragmentación y reenvía el paquete a su núcleo de sesión. La lógica de flujo no cambia y sigue siendo la misma.
Al realizar la ISSU, las SPU virtuales se sincronizan con los ID de SPU virtuales relacionados. El soporte de ISHU se basa en la arquitectura CP-Lite. Básicamente, se admiten dos operaciones de ISHU:
-
Inserte una nueva SPC en el nodo secundario.
-
Reemplace una SPC en el nodo secundario y el número de SPC debe ser el mismo que el del nodo principal.
Tabla de historial de cambios
La compatibilidad de la función depende de la plataforma y la versión que utilice. Utilice el Explorador de características para determinar si una característica es compatible con su plataforma.