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 SRX210 y SRX320
Descripción del procesamiento de tráfico en la línea SRX3000 y dispositivos SRX1400
Descripción del procesamiento de tráfico en dispositivos SRX4600
Descripción del procesamiento de tráfico en dispositivos de la línea SRX5000
Descripción del procesamiento de flujo en dispositivos SRX5K-SPC3
Descripción general del procesamiento de tráfico en dispositivos de la serie SRX
Junos OS para dispositivos de seguridad integra las capacidades de enrutamiento y seguridad de red 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 las capacidades de enrutamiento y seguridad de red de clase mundial de Juniper Networks. Junos OS incluye una amplia gama de filtrado basado en paquetes, clasificadores de clase de servicio (CoS) y funciones de formación de tráfico, así como un rico y extenso conjunto de funciones de seguridad basadas en el flujo, incluyendo políticas, pantallas, traducción de direcciones de red (TDR) y otros servicios basados en flujo.
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 lo siguiente:
Si el paquete está permitido en el dispositivo
Qué pantallas de firewall se aplicarán al paquete
La ruta que toma el paquete para llegar a su destino
Qué CoS se aplicará al paquete, si lo hubiera
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 flujos trata los paquetes relacionados, o 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 secuencia de paquetes, lo 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 es consciente de varios subprocesos. La secuenciación de paquetes se mantiene 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 el tratamiento.
Para la arquitectura de procesamiento distribuido de la puerta de enlace de servicios, se produce algún procesamiento basado en paquetes, como la formación de tráfico, en la NPU. Algunos procesamientos basados en paquetes, como la aplicación de clasificadores a un paquete, se produce en la SPU.
Este tema incluye 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 flujos 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.
La Figura 1 muestra una vista conceptual de cómo se produce el procesamiento de tráfico basado en flujos en la puerta de enlace de servicios.
Un flujo es un flujo 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 aplica a él, si requiere una puerta de enlace de capa de aplicación (ALG), 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 determinada y enrutador virtual
Zonas y políticas
La política de seguridad que se 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 las zonas. Una zona es una colección de interfaces que definen un límite de seguridad. La zona de entrada de un paquete, según lo determinado por la interfaz a través de la cual llegó, y su zona de salida, según lo determinado por la búsqueda de reenvío, en conjunto determinan qué política se utiliza para los paquetes del flujo.
Flujos y sesiones
El procesamiento de paquetes basado en flujos, que es de 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 conteo 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 en todas las sesiones.)
Para asignar los recursos necesarios para el flujo para funciones como TDR.
Para proporcionar un marco para funciones como ALG y funciones de firewall.
La mayoría del procesamiento de paquetes se produce en el contexto de un flujo, lo que incluye:
Administració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 agregarlo 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 salga del dispositivo, se aplican al paquete todos los filtros basados en paquetes, algunas funciones de CoS y algunas pantallas asociadas con la interfaz.
Los filtros y las funciones de CoS suelen asociarse con una o más interfaces para influir en qué paquetes se les permite transitar por el sistema y 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 de tránsito.
Filtros de firewall sin estado
También conocidas 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 paquetes que transitan por el dispositivo desde un origen hasta un destino, o paquetes que se originan en o están destinados al motor de enrutamiento. Un filtro de firewall sin estado evalúa todos los paquetes, incluidos los fragmentados.
Puede aplicar un filtro de firewall sin estado a una interfaz de entrada o salida, o a ambas. Un filtro contiene uno o varios términos, y cada término consta de dos componentes: condiciones y acciones de coincidencia. De forma predeterminada, se descarta un paquete que no coincida con un filtro de firewall.
Puede planificar y diseñar filtros de firewall sin estado que se usarán para diversos fines, por ejemplo, para limitar el tráfico a ciertos protocolos, direcciones de origen o destino IP o tasas 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 paquetes a medida que ingresan al dispositivo. Mediante el uso de clasificadores agregados 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 BA le permiten establecer la clase de reenvío y la prioridad de pérdida de un paquete según el valor de Servicio diferenciado (DiffServ).
Formación de tráfico: puede dar forma al tráfico mediante la asignación de 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. La formación del tráfico es especialmente útil para aplicaciones en tiempo real, como la transmisión de voz y video.
Pantallas
Algunas pantallas, como las pantallas de denegación de servicio (DoS), 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 las funciones de seguridad, como las zonas, las pantallas y las políticas de firewall funcionen. De forma predeterminada, el dispositivo de la serie SRX está habilitado para el reenvío basado en flujo para el tráfico IPv4 en todos los dispositivos, excepto en los dispositivos serie SRX300 y SRX550M que están configurados en el modo de caída. A partir de Junos OS versión 15.1X49-D70 y Junos OS versión 17.3R1, para los dispositivos serie SRX1500, SRX4100, SRX4200, SRX5400, SRX5600, SRX5800 y vSRX, no es necesario reiniciar el dispositivo cuando está cambiando los modos entre el modo de flujo, el modo de paquete y el modo de caída. Para los dispositivos serie SRX300 y SRX550M, debe reiniciar el dispositivo cuando cambie entre el modo de flujo, el modo de paquete y el modo de caída.
SRX300 Series and SRX550M
Para la serie SRX300 y los dispositivos SRX550M, el modo de procesamiento predeterminado se establece en modo de caída debido a restricciones de memoria. En este caso, debe reiniciar el dispositivo después de cambiar el modo de procesamiento del modo de caída predeterminado al modo de procesamiento basado en flujo o el modo de procesamiento basado en paquetes, es decir, entre los modos en estos dispositivos.
Para el procesamiento del modo de caída, el tráfico se cae 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.
Configuring an SRX Series Device as a Border Router
Cuando un dispositivo serie SRX de cualquier tipo está habilitado para el procesamiento basado en flujo o el modo de caída, para configurar el dispositivo como enrutador de borde debe cambiar el modo a procesamiento basado en paquetes para MPLS. En este caso, para configurar el dispositivo SRX en modo de paquete para MPLS, utilice la set security forwarding-options family mpls mode packet-based instrucción.
Como se mencionó anteriormente, para la serie SRX300 y los dispositivos SRX550M, siempre que cambie los modos de procesamiento, debe reiniciar el dispositivo.
Descripción del procesamiento de tráfico en dispositivos SRX210 y SRX320
En este tema se describe el proceso que llevan a cabo las puertas de enlace de servicios SRX210 y SRX320 para establecer una sesión para paquetes que pertenecen a un flujo que transita el dispositivo. Los servicios de flujo de los dispositivos SRX210 y SRX320 son de un solo subproceso y no están distribuidos. Aunque difieren de los otros dispositivos de la serie SRX en este sentido, se sigue el mismo modelo de flujo y se implementa la misma interfaz de línea de comandos (CLI).
Para ilustrar el establecimiento de sesión y el "paseo" de paquetes, incluidos los puntos en los que se aplican los servicios a los paquetes de un flujo, el ejemplo descrito en las siguientes secciones utiliza el caso simple de una sesión de unidifusión:
- Descripción del procesamiento de flujo y la administració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 administració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 de la puerta de enlace de servicios SRX210 o SRX320.
Al principio, el subproceso del plano de datos recupera el paquete y realiza comprobaciones básicas de cordura en él. Luego procesa el paquete para 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 siguientes criterios de seis coincidencias:
Dirección de origen
Dirección de destino
Puerto de origen
Puerto de destino
Protocolo
Token único de una zona determinada y enrutador virtual
La SPU comprueba la tabla de sesión de una sesión existente para el paquete. Si no se encuentra ninguna sesión, 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 según los parámetros de su sesión. Para el resto de los pasos que implica el procesamiento de paquetes, proceda al 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 en 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 flujos al paquete.
Se aplican pantallas configuradas.
Se realizan comprobaciones TCP.
Si es necesario, se aplican servicios de flujo, como TDR, ALG e IPsec.
La SPU prepara el paquete para su reenvío y lo transmite.
Se aplican filtros de paquetes de enrutamiento.
Se aplica la formación del tráfico.
Se aplica la priorización del tráfico.
Se aplica la programación de tráfico.
El paquete se transmite.
Descripción del procesamiento de tráfico en la línea SRX3000 y dispositivos SRX1400
Junos OS para las puertas de enlace de servicios SRX1400, SRX3400 y SRX3600 integra las capacidades de enrutamiento y seguridad de red de clase mundial de Las redes de Juniper. Junos OS para estas puertas de enlace de servicio incluye la amplia gama de servicios de seguridad, incluyendo políticas, pantallas, traducción de direcciones de red, clasificadores de clase de servicio y el amplio y extenso conjunto de servicios basados en flujos que también se admiten en los otros dispositivos de las puertas de enlace de servicios.
La arquitectura de procesamiento en paralelo distribuida de los dispositivos SRX1400, SRX3400 y SRX3600 incluye varios 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 las siguientes secciones se describe la arquitectura de procesamiento con dispositivos SRX3400 y SRX3600 como ejemplo:
En este tema, se incluye la siguiente información:
- Componentes que intervienen en la configuración de una sesión
- Descripción de la ruta de datos para sesiones de unidifusión
- Criterios de búsqueda de sesión y coincidencia de paquetes
- Descripción de la creación de sesión: primer procesamiento de paquetes
- Descripción del procesamiento de ruta rápida
Componentes que intervienen en la configuración de una sesión
Esta es una descripción general de los principales componentes que intervienen en la configuración de una sesión para un paquete y el procesamiento de los paquetes a medida que transitan por los dispositivos SRX3400 y SRX3600:
Unidades de procesamiento de servicios (SPU): los procesadores principales de los dispositivos SRX3400 y SRX3600 residen en tarjetas de procesamiento de servicios (SPC). Establecen y administran flujos de tráfico y realizan la mayor parte del procesamiento de paquetes en un paquete a medida que transita el dispositivo. Cada SPU mantiene una tabla hash para una búsqueda rápida de la sesión. La SPU realiza todo el procesamiento basado en flujos para un paquete, incluyendo la aplicación de servicios de seguridad, clasificadores y formadores de tráfico. La misma SPU procesa todos los paquetes que pertenecen al mismo flujo.
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 sesión para asegurarse de que el paquete pertenece a ella.
Para los dispositivos SRX3400 y SRX3600, una SPU actúa en conjunto realizando sus funciones regulares de administración de sesiones y procesamiento de flujo, y actuando como un punto central en el que arbitra sesiones y asigna recursos. Cuando una SPU funciona de esta manera, se dice que está en modo combinado.
Punto central: el punto central se utiliza para asignar la administración de sesión a SPU según criterios de equilibrio de carga. Distribuye las sesiones de manera inteligente para evitar ocurrencias en las que varias SPU podrían manejar erróneamente el mismo flujo. El punto central sigue los criterios de equilibrio de carga a la hora de asignar sesiones a SPU. Si la sesión existe, el punto central reenvía paquetes para ese flujo a la SPU que la aloja. También redirige los paquetes a la SPU correcta en caso de que la NPU no lo haga.
Para los dispositivos SRX3400 y SRX3600, una SPU siempre se ejecuta en lo que se conoce como modo combinado en el que implementa tanto la funcionalidad del punto central como la funcionalidad de administración de flujo y sesión. En el modo combinado, la SPU y el punto central comparten la misma infraestructura de subproceso de equilibrio de carga (LBT) y subproceso de pedido de paquetes (POT). .
Motor de enrutamiento (RE): el motor de enrutamiento ejecuta el plano de control y administra el procesador de plano de control (CPP).
Descripción de la ruta de datos para sesiones de unidifusión
Junos OS para las puertas de enlace de servicios SRX3400 y SRX3600 es un sistema de procesamiento en paralelo distribuido de alta transferencia de datos y alto rendimiento. En este tema se describe el proceso de establecer una sesión para paquetes que pertenecen a un flujo que transita el dispositivo.
Para ilustrar el establecimiento de sesión y el "paseo" de paquetes, incluidos los puntos en los que se aplican los servicios a los paquetes de un flujo, en el siguiente ejemplo se utiliza el caso simple de una sesión de unidifusión. Este "paseo" de paquete combina 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
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 siguientes criterios de seis coincidencias:
Dirección de origen
Dirección de destino
Puerto de origen
Puerto de destino
Protocolo
Token único de una zona determinada y enrutador virtual
Descripción de la creación de sesión: primer procesamiento de paquetes
En este tema se explica cómo se configura una sesión para procesar los paquetes que componen un flujo. Para ilustrar el proceso, en este tema 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).
Un paquete llega a una interfaz en el dispositivo y la IOC lo procesa.
La IOC elimina el paquete y lo envía a la NPU con la que se comunica.
La NPU recibe el paquete de la IOC y lo procesa.
La NPU realiza comprobaciones básicas de cordura en el paquete y aplica algunas pantallas configuradas para la interfaz al paquete.
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.
Ejemplo: El paquete (un ->b) llega a NPU1 desde IOC1. NPU1 realiza comprobaciones de cordura y aplica pantallas DoS al paquete. NPU1 comprueba en su tabla de sesión una coincidencia de tupla y no se encuentra ninguna sesión existente. NPU1 reenvía el paquete al punto central de la SPU1 para su asignación a una SPU.
El punto central crea una sesión con un estado "Pendiente".
El punto central mantiene una tabla de sesiones global que incluye entradas para todas las sesiones que existen en todas las SPU en el dispositivo. Participa en la creación de sesiones y delega y arbitra la asignación de recursos de sesión.
Este proceso incluye las siguientes partes:
El punto central comprueba su tabla de sesión y su tabla de puerta para determinar si existe una sesión o una puerta para el paquete que recibe de la NPU. (Una NPU reenvía un paquete al punto central porque su tabla indica que no hay sesión para él. El punto central verifica esta información antes de asignar una SPU para la sesión.)
Si no hay ninguna entrada que coincida con el paquete en ninguna tabla, el punto central crea un ala pendiente para la sesión y selecciona una SPU que se utilizará para la sesión, según su algoritmo de equilibrio de carga.
El punto central reenvía el primer paquete del flujo a la SPU seleccionada en un mensaje que le indica que configure una sesión localmente que se utilizará para el flujo de paquetes.
Ejemplo: El punto central crea un ala pendiente (un ->b) para la sesión. Selecciona SPU1 que se utilizará en la sesión. Envía SPU1 el paquete (a->b) junto con un mensaje para crear una sesión para él. (Sucede que la SPU1 es la SPU que se ejecuta en modo combinado. Por lo tanto, sus servicios de administración de sesión y procesamiento de flujo se utilizan para la sesión.
La SPU configura 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 desde el punto central 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 la configura localmente.
La SPU envía un mensaje al punto central, diciéndole que instale la sesión.
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 para la sesión se suspende hasta que se complete el proceso de asignación TDR.
La SPU agrega a la cola cualquier paquete adicional para el flujo que pueda recibir hasta que se haya instalado la sesión.
Ejemplo: SPU1 crea la sesión para (un ->b) y envía un mensaje al punto central (implementado en la misma SPU) diciéndole que instale la sesión pendiente.
El punto central instala la sesión.
Establece el estado para que el ala pendiente de la sesión se active.
Instala el ala inversa para la sesión como un ala activa.
Envía un mensaje ACK (reconocimiento) a la SPU, que indica que la sesión está instalada.
Ejemplo: El punto central recibe un mensaje de SPU1 para instalar la sesión para (a->b). Establece el estado de la sesión para (a->b) en activo. Instala el ala inversa (b->a) para la sesión y la hace activa; esto permite que la entrega de paquetes desde la dirección inversa del flujo: destino (b) se entregue al origen (a).
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 sesión se configura en las NPU de salida y entrada (que a veces son las mismas) para que los paquetes se puedan enviar directamente a la SPU que administra sus flujos y no al punto central para la redirección.
Se lleva a cabo un procesamiento de ruta rápida.
Para el resto de los pasos que implica el procesamiento de paquetes, proceda al paso 1 en "Descripción del procesamiento de ruta rápida".
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 evita 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 rutas rápidas: las NPU de las interfaces de salida e 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.
En dispositivos SRX1400, SRX3400 y SRX3600, la funcionalidad iflset no se admite para interfaces agregadas como reth.
Descripción del procesamiento de tráfico en dispositivos SRX4600
La puerta de enlace de servicios SRX4600 de Juniper Networks integra servicios de enrutamiento y seguridad basados en flujo, lo que incluye seguridad avanzada y mitigación de amenazas, y seguridad tradicional de estado de firewall. La infraestructura basada en flujos de Junos OS proporciona la base y el marco para los servicios basados en aplicaciones de capa 4 a capa 7. La puerta de enlace de servicios SRX4600 está diseñada para implementarse como un firewall integrado en el borde y el núcleo del centro de datos de grandes empresas, y en el borde del campus. También se puede implementar como una puerta de enlace de seguridad LTE y un firewall Gi/SGi.
Este tema incluye el siguiente contenido:
- Descripción de escenarios de despliegue para la puerta de enlace de servicios SRX4600 y sus características
- Procesamiento basado en flujos y fundamentos de sesión
- Componentes subyacentes de flujo y sesión implementados en las puertas de enlace de servicios de la serie SRX
Descripción de escenarios de despliegue para la puerta de enlace de servicios SRX4600 y sus características
La puerta de enlace de servicios SRX4600 se puede implementar en muchas áreas para proteger su entorno y sus recursos. A menudo se utiliza para proteger el borde y el núcleo del centro de datos de las siguientes maneras:
Implementación de la puerta de enlace de servicios SRX4600 como firewall de borde de centro de datos
Puede implementar la puerta de enlace de servicios 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 que permite a los clientes acceder a los servicios del centro de datos, pero los agresores maliciosos pueden aprovecharlo para lanzar ataques contra estos servicios. Una gran cantidad de tráfico que entra en el centro de datos es tráfico de entrada a Internet. Solo por esa razón, es esencial implementar una seguridad sólida y de varias capas en el borde del centro de datos. La puerta de enlace de servicios SRX4600 bloquea los ataques de manera eficaz y dependiente, y le permite configurar el sistema para frustrar tipos específicos de ataques. La puerta de enlace de servicios SRX4600 es compatible con el marco de la red segura definida por software (SDSN) de Juniper, que incluye Sky Advanced Threat Prevention (Sky ATP), que se basa en inteligencia automatizada y procesable que se puede compartir rápidamente para reconocer y mitigar amenazas. La Figura 2 muestra la puerta de enlace de servicios SRX4600 desplegada en el borde del centro de datos junto con un enrutador MX480 y conmutadores de la serie EX.
Figura 2: Implementación de la puerta de enlace de servicios SRX4600 en el borde
del centro de datos
Implementación de la puerta de enlace de servicios SRX4600 en el núcleo del centro de datos
Puede implementar la puerta de enlace de servicios SRX4600 en el núcleo del centro de datos para ofrecer una seguridad mejorada 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 necesita una definición clara de la red y el cumplimiento de requisitos de cumplimiento. Para garantizar el cumplimiento, puede usar la puerta de enlace de servicios SRX4600 para segmentar su red en general en redes de servidores individuales y proteger el tráfico dentro de ellas. La puerta de enlace de servicios SRX4600 ofrece alta disponibilidad y automatización, y sus servicios de alto rendimiento de capa 3 y capa 4 cumplen con los requisitos de seguridad del núcleo del centro de datos. La Figura 3 muestra la puerta de enlace de servicios SRX4600 desplegada como un firewall de varias capas en el núcleo del centro de datos.
Figura 3: Implementación de la puerta de enlace de servicios SRX4600 en el núcleo del centro
de datos
Además de sus funciones avanzadas contra el malware, la puerta de enlace de servicios SRX4600 admite las siguientes funciones:
Firewall de estado
Conjunto de seguridad de aplicaciones
UTM (Sophos AV, filtrado web, antispam)
IDP
Alta disponibilidad (clúster de chasis)
Puertos de control de AD duales (10G)
Soporte MACsec para puertos de AD
Interfaces Ethernet mediante QSFP28 (modos 100G/40G/4x10G), QSFP+ (modos 40G/4x10G) y SFP+ (modo 10G)
VPN IPsec, incluyendo AutoVPN y VPNv2 de grupo
QoS y servicios de red
J-Web
Políticas de enrutamiento con multidifusión
Procesamiento basado en flujos y fundamentos de sesión
Para comprender el procesamiento del flujo en la puerta de enlace de servicios SRX4600, es importante comprender los fundamentos del flujo.
Un flujo es un flujo 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 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 puertas de enlace de servicios serie SRX debido a sus diferencias arquitectónicas.
El procesamiento de paquetes basado en flujos, que es de estado, requiere la creación de sesiones. Las sesiones se crean según el 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 dispositivos, las sesiones también se administran de manera diferente mediante dispositivos diferentes.
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 las puertas de enlace de servicios de la serie SRX
Las puertas de enlace de servicios de la serie SRX usan los mismos componentes de infraestructura para admitir el flujo y administrar sesiones, pero no todos los dispositivos implementan todos ellos.
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 sesión entre SPU. Cuando se procesa el primer paquete de un flujo, el punto central determina qué SPU se utilizará para la sesión de ese paquete. La puerta de enlace de servicios 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 posteriores del flujo se emparejan con la sesión en la NPU. La NPU controla el procesamiento adicional, como la comprobación de secuencia TCP, el procesamiento de tiempo de vida (TTL) y la traducción de encabezados de capa 2. Una NPU mejora el rendimiento en ese reenvío de paquetes adicional entre una SPU de sesión y una SPU hash se evita. La puerta de enlace de servicios SRX4600 implementa una NPU.
La arquitectura de flujo de la puerta de enlace de servicios SRX4600 se ha mejorado para optimizar el uso de los procesadores Xeon™ de múltiples núcleos avanzados del dispositivo SRX4600. La puerta de enlace de servicios SRX4600 implementa el uso de un hilo de sesión dedicado para evitar 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ían al hilo adecuado y dedicado. Los paquetes se distribuyen a diferentes subprocesos de acuerdo con el modelo de distribución de sesión basado en hash.
Descripción del procesamiento de tráfico en dispositivos de la línea SRX5000
Junos OS en dispositivos SRX5000 es un sistema distribuido, de procesamiento paralelo, de alta transferencia de datos y alto rendimiento. La arquitectura de procesamiento en paralelo distribuida de la línea de puertas de enlace de servicios SRX5000 incluye varios procesadores para administrar sesiones y ejecutar la seguridad y el procesamiento de 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 recorrido 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 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 E/S (IOC) y las tarjetas de procesamiento de servicios (SPC) en 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 flujos para un paquete se ejecutan en una sola SPU. Las responsabilidades de estas NPU no están claramente definidas 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 (DoS), 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 necesitará consultar el punto central de la aplicación para determinar en qué SPU se debe procesar el paquete.
Estas partes discretas y cooperantes del sistema, incluido el punto central, almacenan la información que identifica si existe una sesión para una secuencia de paquetes y la información con la que se hace coincidir 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 que una NPU determine si existe una sesión para un paquete, comprobarlo y aplicar pantallas 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 que utiliza los dispositivos SRX5400, SRX5600 y SRX5800 como 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 muestra la ruta que toma el primer paquete de un flujo a medida que entra en el dispositivo. La NPU determina que no existe ninguna 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 para configurar una sesión para el paquete y procesarlo. 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 funciones 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 sesión, la NPU reenvía el paquete a la SPU que administra su sesión.
La Figura 5 ilustra el procesamiento de la 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 en el que se ha configurado el paquete iniciado.) 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 cómo se somete un paquete a medida que transita el dispositivo.
de ruta rápida
Esta es una descripción general de los principales componentes que intervienen en la configuración de una sesión para un paquete y el procesamiento de paquetes de forma discreta y 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. Manejan la verificación de cordura de paquetes y la aplicación de algunas pantallas. Las NPU mantienen tablas de sesión que utilizan para determinar si existe una sesión para un paquete entrante o para el tráfico inverso.
La tabla de sesión NPU contiene una entrada para una sesión si la sesión se establece en una SPU para un paquete que había entrado anteriormente en el 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 mediante la comprobación de la información del paquete en su tabla de sesión. Si el paquete coincide con una sesión existente, la NPU envía el paquete y los metadatos para él a la SPU. Si no hay ninguna sesión, las NPU envían 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 la sesión. La SPU aplica filtros de firewall sin estado, clasificadores y formadores de tráfico al tráfico. Una SPU realiza todo el procesamiento basado en flujos para un paquete y la mayoría del procesamiento basado en paquetes. Cada SPU multinúcleo procesa paquetes de forma independiente con una interacción mínima entre SPU en la misma SPC o diferente. La misma SPU procesa todos los paquetes que pertenecen al mismo flujo.
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 sesión para asegurarse de que el paquete pertenece a ella. También comprueba su tabla de sesión 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 hay una sesión existente para el paquete.
Punto central: la arquitectura del punto central está dividida 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 de recursos globales y el equilibrio de carga, mientras que el punto central distribuido es responsable de la identificación del tráfico (coincidencia global de sesión). La funcionalidad del punto central de aplicación se ejecuta en la SPU de punto central dedicado, mientras que la funcionalidad de punto central distribuido se distribuye al resto de las SPU. Ahora, las sesiones de punto central ya no están en la SPU de punto central dedicada, sino en 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 de establecer una sesión para paquetes que pertenecen a un flujo que transita el dispositivo.
Para ilustrar el establecimiento de sesión y el "paseo" de paquetes, incluidos los puntos en los que se aplican los servicios a los paquetes en un flujo, en este ejemplo se utiliza el caso simple de una sesión de unidifusión.
Este "paseo" de paquete une 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 sesión: 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 siguientes criterios de seis coincidencias:
Dirección de origen
Dirección de destino
Puerto de origen
Puerto de destino
Protocolo
Token único de una zona determinada y enrutador virtual
Descripción de la creación de sesión: 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, 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 (un ->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 un dispositivo de la serie SRX que entra en la IOC.
El paquete llega a la IOC del dispositivo y es procesado por 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 en su tabla de sesiones una sesión existente para el paquete. (Comprueba la tupla del paquete con la de los paquetes para 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 (un ->b) llega a NPU1. NPU1 realiza comprobaciones de cordura y aplica pantallas DoS al paquete. NPU1 comprueba su tabla de sesión para 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. Luego, el punto central distribuido busca la tabla de sesión de puntos centrales distribuidos y crea una entrada si es necesario.
Este proceso incluye las siguientes partes:
El punto central distribuido comprueba su tabla de sesión 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 de 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 una puerta coincide 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, la SPU (es decir, la SPU del punto central distribuido) está seleccionada. Por último, el punto central de la aplicación envía una respuesta de consulta al punto central distribuido.
Al recibir la respuesta de la consulta, el punto central distribuido reenvía el primer paquete del flujo a la SPU seleccionada en un mensaje que dirige a la SPU a configurar una sesión localmente que se utilizará para el flujo de paquetes. Por ejemplo, el punto central distribuido crea un ala pendiente (un ->b) para la sesión. El punto central de aplicación selecciona la SPU1 que se utilizará para ella. El punto central distribuido enví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 (un ->b) para la sesión. Selecciona la SPU1 que se utilizará para ella. Envía SPU1 el paquete (a->b) junto con un mensaje para crear una sesión para él.
Paso 3. La SPU configura 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 la configura localmente.
La SPU envía un mensaje al punto central distribuido para 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 para la sesión se suspende hasta que se complete el proceso de asignación TDR.
La SPU agrega a la cola cualquier paquete adicional para el flujo que pueda recibir hasta que se haya instalado la sesión.
Example: La SPU1 crea la sesión para (un ->b) y envía un mensaje al punto central distribuido para 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 para que el ala pendiente de la sesión se active.
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 en el ala de init.
Envía un mensaje de reconocimiento (ACK) a la SPU, que 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 para que el ala (a->b) se active. Instala el ala inversa (b->a) para la sesión y la hace activa; esto permite que la entrega de paquetes desde la dirección inversa del flujo: destino (b) se entregue 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 sesión se configura en las NPU de salida y entrada (que a veces son las mismas) para que los paquetes se puedan enviar directamente a la SPU que administra sus flujos y no al punto central distribuido para la redirección.
Paso 6. Se lleva a cabo el procesamiento de ruta rápida.
Para el resto de los pasos que implica el procesamiento de paquetes, pase al paso 1 en Descripción del procesamiento de ruta rápida.
La figura 6 muestra la primera parte del proceso a la que se somete 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, él y el resto de los paquetes en el flujo se someten a un procesamiento de ruta rápida.
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 evita 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 rutas rápidas: las NPU de las interfaces de salida e 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, esta sección utiliza un ejemplo con una "a" de origen 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 pantallas de denegación de servicio (DoS), al paquete.
La NPU identifica una entrada para una sesión existente en su tabla de sesiones que el paquete coincide.
La NPU reenvía el paquete junto con los metadatos de su tabla de sesión, incluido el ID de sesión y la información de tupla de 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 controla el procesamiento del flujo del paquete y la aplicación de seguridad y otras características.
Example: El paquete (un ->b) llega a NPU1. NPU1 realiza comprobaciones de cordura en el paquete, le aplica pantallas DoS y comprueba que su tabla de sesión coincida 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 para la sesión procesa el paquete.
La mayor parte del procesamiento de un paquete se produce en la SPU a la que se asigna 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 corresponde. La seguridad configurada basada en flujos 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 que procese el paquete, la SPU comprueba su tabla de sesión para comprobar que el paquete pertenece a una de sus sesiones.
La SPU procesa el paquete para las funciones y servicios correspondientes.
Example: SPU1 recibe el paquete (a->b) de NPU1. La SPU1 comprueba su tabla de sesión para comprobar que el paquete pertenece a una de sus sesiones. Luego procesa el paquete (un ->b) según los filtros de entrada y las funciones de CoS que se aplican a su interfaz de entrada. La SPU aplica las características y servicios de seguridad que están configurados para el flujo del paquete, según su zona y políticas. Si hay alguno configurado, aplica filtros de salida, formadores de tráfico y pantallas 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 correspondiente asociada con la interfaz al paquete.
Example: La SPU1 reenvía el paquete (un ->b) a NPU2 y NPU2 aplica pantallas DoS.
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 el paso 1 exactamente al revés. Consulte el paso 1 de esta sección para obtener más información.
Example: El paquete (b->a) llega a NPU2. NPU2 comprueba que su tabla de sesión coincida con la tupla. 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, excepto que se aplica al tráfico inverso. Consulte el paso 2 de esta sección para obtener más detalles.
Example: La SPU1 recibe el paquete (b->a) de NPU2. Comprueba su tabla de sesión para comprobar que el paquete pertenece a la sesión identificada por NPU2. Luego, aplica funciones basadas en paquetes configuradas para la interfaz de NPU1 al paquete. Procesa el paquete (b->a) de acuerdo con las funciones de seguridad y otros servicios que están configurados para su flujo, según 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, excepto que se aplica al tráfico inverso. Consulte el paso 3 de esta sección para obtener más información.
Example: La 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, excepto 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 muestra el proceso al que se somete un paquete cuando llega al dispositivo y existe una sesión para el flujo al que pertenece el paquete.
de ruta rápida
Descripción de las unidades de procesamiento de servicios
Para una interfaz física determinada, la SPU recibe paquetes de entrada de todos los procesadores de red en el paquete de procesador de red asociado con la interfaz física. La SPU extrae la información del paquete de procesador 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 procesador 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 usan 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 procesador 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 PIC. La interfaz física puede usar una máscara de bits de 48 bits para indicar el PIM, o el tráfico del procesador de red desde esta interfaz física se distribuye además del procesador de red principal de la interfaz física.
En dispositivos de la 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 procesador de red se pasa a todas las IOC que tienen una PIM en el paquete de procesador de red.
Descripción de la agrupación de procesadores de red
La función de agrupación del procesador de red está disponible en 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 principal para una interfaz que recibe el tráfico de entrada y distribuye los paquetes a varios otros procesadores de red secundarios. Un solo procesador de red puede actuar como procesador de red principal o como procesador de red secundario para varias interfaces. Un solo procesador de red solo puede unirse a un paquete de procesador de red.
Limitaciones de agrupación del procesador 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 paquete de procesador de red diferentes.
Debe reiniciar el dispositivo para aplicar los cambios de configuración en el paquete.
La agrupación del procesador de red se encuentra por debajo de la interfaz de reth en la arquitectura general. Puede elegir una o ambas interfaces del paquete de procesador de red para formar la interfaz reth.
Si se elimina la IOC de un paquete de procesador de red, los paquetes reenviados a la PIM en esa IOC se pierden.
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 varios procesadores de red para su procesamiento. Estos umbrales se aplican a cada procesador de red en el paquete de procesador de red.
No se admite la agrupación del procesador de red en el modo de capa 2.
Debido a limitaciones de memoria en el procesador de red, la cantidad de puertos agrupados para el procesador de red que se admiten por PIM es limitada. Dentro del paquete de procesador de red, cada puerto debe tener un índice de puerto global. El índice de puerto global 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 redundante pueden superponerse con o compartir vínculos físicos con un paquete de procesador de red.
Descripción de la caché de sesión
- Visión general
- Instalación de caché de sesión selectiva
- Mejora de la afinidad de sesión vpn IPsec mediante la caché de sesión
Visión general
SrX5K-MPC (IOC2), SRX5K-MPC3-100G10G (IOC3) y SRX5K-MPC3-40G10G (IOC3) en dispositivos SRX5400, SRX5600 y SRX5800 admiten la caché de sesión y la instalación selectiva de la caché de sesión.
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 podría 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 distintos procesadores de red. Las IOC admiten caché de sesión para sesiones IPv6.
Una entrada de la caché de sesión también se denomina ala de sesión.
La caché de sesión en la IOC aprovecha la funcionalidad de Express Path (antes conocida como descarga de servicios) y ayuda a prevenir problemas como la alta latencia y la caída del rendimiento de IPsec.
Una entrada en 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 Ruta express
Qué procesamiento hacer para el tráfico de salida, por ejemplo, traducción TDR en modo ruta express
A partir de Junos OS versión 15.1X49-D10 y Junos OS versión 17.3R1, la caché de sesión de las sesiones en la IOC ayuda a resolver ciertos problemas de rendimiento. La SPU ahora puede instruir a la caché de sesión de IOC que reenvíe el tráfico subsiguiente a una SPU de anclaje específica.
A partir de Junos OS versión 15.1X49-D10, SRX5K-MPC (IOC2) y IOC3 admiten afinidad de sesión VPN a través de módulos de flujo mejorados y caché de sesión. A partir de Junos OS versión 12.3X48-D30, en IOC2, se admite la afinidad de sesión de VPN mediante la caché de sesión.
Otro tráfico se hashizó a SPU según su información clave de 5 tuplas. El tráfico vpn empleó el concepto de la SPU anclada, que no necesariamente coincide 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. A continuación, la SPU de flujo reenvía el paquete a la SPU anclada. Esto creó un salto adicional para el tráfico de VPN, que desabasió el ancho de banda de la estructura del conmutador y redujo la transferencia de datos de VPN aproximadamente a la mitad. Esta reducción del rendimiento se produjo porque el tráfico aún tenía que volver a la SPU de flujo después de procesarla en la SPU anclada.
La tabla de caché de sesiones ahora se extiende en IOC para admitir las sesiones NP. El tráfico de Express Path 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 la propia IOC localmente o a otra 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 procesamiento posterior. Todas las entradas de la 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 sesión 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 retraso de sesiones. Las mismas sesiones (sesiones con los mismos cinco tuplas) que se eliminan y, luego, se vuelven a instalar inmediatamente no se almacenan en caché en las IOC.
Instalación de caché de sesión selectiva
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 monitorean los niveles de umbral de uso de la caché de sesión. Las IOC también comunican el uso de la 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 selectivas de tráfico de alta prioridad.
Las aplicaciones como IDP, ALG necesitan procesar paquetes en orden. Una SPU tiene varios subprocesos de flujo para manejar paquetes que pertenecen a una sesión, subproceso de equilibrio de carga (LBT) y el orden de paquetes de subproceso de pedido de paquetes (POT) puede asegurarse de 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 de que solo un paquete de procesamiento de subprocesos de flujo de SPU pertenece a la misma sesión a la vez, de modo que las aplicaciones puedan recibir, procesar y enviar paquetes en orden. Otros subprocesos de flujo pueden hacer 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 de 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 a la 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 sesiones de tráfico de alta prioridad se define en la tabla:
Tipo de tráfico |
Utilización del 0 % < < del 25 % |
Utilización del 25 % < < del 50 % |
Utilización del 50 % < < del 75 % |
Utilización del 75 % < < del 100 % |
|---|---|---|---|---|
Tráfico de IPsec y Express Path |
Sí |
Sí |
Sí |
Sí |
Fragmentación Orden de 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 la IOC, el módulo de flujo instala selectivamente las sesiones en la IOC. Para facilitar la selección de la instalación de la sesión, la IOC mantiene los umbrales correspondientes para proporcionar una indicación al módulo de flujo (sobre qué tan completa está la tabla de caché de sesión en las IOC). Se agregan dos bits en el encabezado de la meta para indicar el estado actual de utilización de la tabla de caché. Todos los paquetes que van 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 la IOC.
Mejora de la afinidad de sesión vpn IPsec mediante la caché de sesión
Los dispositivos serie SRX son sistemas completamente 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 en túnel. Para lograr un mejor rendimiento de IPsec, IOC mejora el módulo de flujo para crear sesiones para el tráfico basado en túneles IPsec (antes del cifrado y después del descifrado) en su SPU anclada en túnel, e instala la caché de sesión 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 Express Path y el tráfico NP comparten la misma tabla de caché de sesión en las IOC.
Debe habilitar la caché de sesión en las IOC y establecer la política de seguridad para determinar si una sesión es para el modo Ruta express (anteriormente conocida como descarga de servicios) en el concentrador de PIC flexible (FPC) seleccionado.
Para habilitar el uso de afinidad VPN IPsec, el set security flow load-distribution session-affinity ipsec comando.
Para habilitar la afinidad VPN IPsec, también debe habilitar la caché de sesión en IOC mediante el set chassis fpc <fpc-slot> np-cache comando.
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 varias 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 (demonio) ejecuta un algoritmo que realiza la asignación. Asigna una IOC a una NPC que tiene la menor cantidad de IOC asignada. También puede usar 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 de chasis primero utilizará su configuración y, luego, aplicará el algoritmo NPC de menor número para el resto de las IOC.
La compatibilidad de la 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);
}
Consulte la tabla 2 para ver una descripción de las set chassis ioc-npc-connectivity opciones.
Opción |
Descripción |
|---|---|
Ioc slot-number |
Especifique el número de ranura IOC. El rango es de 0 a 7 para dispositivos SRX3400 y de 0 a 12 para dispositivos SRX3600. |
Npc slot-number |
Especifique el número de ranura NPC. El rango es de 0 a 7 para dispositivos SRX3400 y de 0 a 12 para dispositivos SRX3600 y SRX 4600. |
Ninguno |
El proceso de chasis asigna la conexión para la IOC en particular. |
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 mientras conserva la funcionalidad y escalabilidad del clúster de chasis para el procesamiento de servicios.
La tarjeta SPC3 ofrece soporte para las siguientes funciones de seguridad:
Puerta de enlace de capa de aplicación (ALG). [Consulte Descripción general de ALG]
Antimalware avanzado (Juniper Sky ATP). [Ver Administración de Sky Advanced Threat Prevention de Juniper]
Conjunto de seguridad de aplicaciones. [Consulte La guía del usuario de seguridad de aplicaciones para dispositivos de seguridad]
Implementación de procesamiento de paquetes basado en flujos
Protocolo de tunelización GPRS (GTP) y protocolo de transmisión de control de flujo (SCTP). [Consulte la Guía general del usuario del servicio de radio de paquetes 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 (IDP). [Consulte Descripción general de detección y prevención de intrusiones]
Traducción de direcciones de red (TDR). [Consulte Guía del usuario de traducción de direcciones de red para dispositivos de seguridad]
Firewall de estado
Proxy 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]
AUA (antivirus, filtrado web, filtrado de contenido y antispam). [Consulte la Guía del usuario de la UTM para dispositivos de seguridad]
El flujo de seguridad se mejora para admitir la tarjeta SPC3 con todas las funciones de seguridad existentes compatibles con la tarjeta SPC2.
Las siguientes limitaciones se aplican a 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 se admite con la tarjeta SPC3.
A partir de Junos OS versión 18.2R1-S1, se introduce una nueva tarjeta de procesamiento de servicios (SPC3) para los dispositivos de la serie SRX5000. La introducción de la nueva tarjeta mejora la escalabilidad y el rendimiento del dispositivo, y mantiene su confiabilidad, ya que conserva la funcionalidad del clúster de chasis. La tarjeta SPC3 admite una mayor transferencia de datos y escalabilidad para el procesamiento de servicios.
En los dispositivos de la serie SRX5000, la tarjeta SPC3 interopera con tarjetas de E/S (IOC2, IOC3), tarjeta de control de conmutador (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 dispositivos de la serie SRX5000.
Si va a agregar las tarjetas SPC3 en la línea de dispositivos SRX5000, la nueva tarjeta SPC3 debe instalarse en la ranura con el número más bajo de cualquier SPC. La tarjeta SPC3 se instala en la ranura original con el número más bajo, lo que 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 del punto central (CP) en modo mixto se realice mediante la tarjeta SPC3.
En los dispositivos de la serie 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 de número más bajo para la que está instalada una tarjeta SPC3.
Cuando los dispositivos de la serie SRX funcionan en modo de clúster de chasis, las tarjetas SPC3 y SPC2 se deben instalar en las mismas ubicaciones de ranura de cada chasis.
- Descripción de la arquitectura de software de SPC3
- Descripción de la distribución de carga
- Descripción de la descarga de sesión y servicio de NP (SOF)
- Descripción de la compatibilidad de J-Flow en SPC3
- Descripción de la compatibilidad de SPU de depuración de ruta de datos (E2E)
- Descripción del manejo de fragmentación, ISSU y soporte de ISHU
Descripción de la arquitectura de software de SPC3
La arquitectura de flujo SPC3 es igual 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 instala uno o dos SPC3, el procesamiento de tráfico utiliza el 75 % de la primera SPC. Cuando instala tres o más SPC3, el procesamiento de tráfico utiliza el 50 % de la primera SPC.
Cambia la forma en que el hash IOC utiliza los paquetes para procesar el flujo. La figura muestra el flujo de paquetes del dispositivo SRX con SPC3.
En SPC3, los paquetes se distribuyen desde IOC a cada núcleo directamente. Dado que la IOC hace hash directamente los paquetes al subproceso RT fluyedo, se elimina el subproceso LBT original. Los paquetes ahora se entregan en el subproceso fluyedo en lugar de SPU. Si el flujo de seguridad instala sesiones NP, en lugar del ID de SPU, IOC utiliza el ID de subproceso de sesión para reenviar paquetes para corregir el subproceso asociado con la sesión.
fluyedo
Descripción de la distribución de carga
Todos los paquetes que lleguen 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 dispositivos de la línea SRX5000 basado en la arquitectura de CP-Lite. El método hash varía según los distintos tipos de tráfico. La siguiente tabla enumera los métodos hash.
Protocolo |
Puertos |
Método hash |
|
|---|---|---|---|
TCP
|
Puerto src L4 y puerto dst |
Hashed por 5-tuple |
|
UDP |
Normal |
Puerto src L4 y puerto dst |
Hashed por 5-tuple |
GTP |
Puerto src L4 y puerto dst |
Hashed por 5-tuple |
|
IKE |
Puerto src L4 y puerto dst
|
Hash por par de IP |
|
ICMP |
|
La información de ICMP se hasha por 5-tupla; El error de ICMP se hasha por 3-tupla (sin información de puertos) |
|
SCTP |
Puerto src L4 y puerto dst |
Hashed por 5-tuple |
|
ESP |
SPI |
Hash por par de IP |
|
AH |
SPI |
Hash por par de IP |
|
GRE |
Si pptp alg está habilitado, sport = id de llamada; dport = 0 De forma predeterminada, el puerto está 0x00010001 |
Hashed por 3-tuple |
|
PIM |
De forma predeterminada, los puertos PIM 0x00010001 |
Hashed por 3-tuple |
|
FRAGMENTO |
El primer fragmento tiene los puertos normales Ningún primer fragmento, ningún puerto |
Hashed por 3-tuple |
|
Otro paquete IP |
puertos 0x00010001 |
Hashed por 3-tuple |
|
NINGUNA IP |
No aplicable |
Hashed por dirección Mac y tipo de Ethernet (ID de Vlan) |
|
Descripción de la descarga de sesión y servicio de NP (SOF)
La sesión de 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 sesión en SPU para obtener un mejor rendimiento.
Evita el reenvío de paquetes adicional entre la SPU de sesión y la SPU hash.
La descarga del servicio es un tipo especial de sesión NP para proporcionar una función de baja latencia para las sesiones que necesitan un servicio básico de firewall. Los paquetes que afectan a la sesión DE SOF en una IOC pasan por alto el procesamiento de paquetes en SPU y son reenviados directamente por IOC. Los siguientes tipos de tráfico admiten la descarga del servicio:
Firewall básico (sin plugin ni fragmentos), TCP IPv4 e IPv6, tráfico UDP
TDR IPv4
1 Multidifusión de entrada y 1Afinación
ALG, como la sesión de datos FTP
Descripción de la compatibilidad de J-Flow en SPC3
J-Flow es la versión 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 la supervisión de red y el procesamiento adicional de datos. J-Flow admite formatos v5, v8 y v9. Estas tres versiones son compatibles con SPC3.
Descripción de la compatibilidad de SPU de depuración de ruta de datos (E2E)
La depuración de datapath ofrece una función de depuración de paquetes de extremo a extremo (E2E) basada en filtros en dispositivos de la línea SRX5000. Rastrea la ruta de los paquetes y vuelca 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:
Contar
Descarga
Rastro
Resumen de seguimiento
Descripción del manejo de fragmentación, ISSU y soporte de ISHU
En SPC3, los paquetes fragmentados se reenvían a "núcleo de fragmento" en una PFE específica según sus valores de tupla de encabezado. Después de recibir un paquete fragmentado, el flujo 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.
Mientras se realiza el ISSU, las SPU virtuales se sincronizan con los IDENTIFICA de SPU virtuales relacionados. El soporte de ISHU se basa en la arquitectura de CP-Lite. Básicamente, se admiten dos operaciones DE ISHU:
Inserte una nueva SPC al nodo secundario.
Reemplace una SPC en un nodo secundario, y el número de SPC debe ser el mismo que el del nodo principal.