Aplicación QoS

Beneficios de las aplicaciones QoS

AppQoS proporciona la capacidad de priorizar y medir el tráfico de la aplicación para proporcionar un mejor servicio para vitales para el negocio tráfico de aplicaciones de alta prioridad.

Clases de reenvío únicas y asignaciones de colas

La clase de reenvío proporciona tres funciones:

• Agrupa paquetes con características similares

• Asigna colas de salida

• Resuelve los conflictos con los reescritores Junos OS firewall existentes basados en filtros

Los nombres de clase de reenvío únicos protegen que los comentarios de AppQoS no se sobrescriban mediante reglas de reescritura basadas en interfaces. Una reescritura basada en filtros de firewall comentarios sobre el valor DSCP de un paquete si la clase de reenvío del paquete coincide con una clase definida específicamente para esta reescritura. Si la clase de reenvío del paquete no coincide con ninguna de las clases de reescritura basadas en filtros del firewall, no se comenta el valor DSCP. Por lo tanto, para proteger los valores de AppQoS de que no se sobrescriban, utilice nombres de clase de reenvío desconocidos para la reescritura basada en filtros del firewall.

Cada clase de reenvío se asigna a una cola de salida que proporciona el grado adecuado de procesamiento mejorado o estándar. Se pueden asignar muchas clases de reenvío a una sola cola. Por lo tanto, cualquier cola definida para el dispositivo se puede utilizar DPI, AppQoS y reescritores basados en filtros de firewall. Es el nombre de clase de reenvío, no la cola, el que distingue la prioridad de transmisión. (Consulte la Guía del usuario de clase de servicio (dispositivos de seguridad) para obtener información acerca de la configuración de colas y programadores.)

Para SRX5400, SRX5600 y SRX5800, los nombres de clase y las asignaciones de colas de reenvío de AppQoS se definen con el comando class-of-service CLI configuración:

Para los dispositivos SRX300, SRX320, SRX340, SRX345, SRX380, SRX550M, SRX1500, SRX4100, SRX4200 y SRX4600 y vSRX, los nombres de clase y las asignaciones de colas de reenvío de AppQoS se definen con el comando de configuración class-of-service CLI:

Configuración de punto de código y prioridad de pérdida de DSCP que está al tanto de las aplicaciones

Para AppQoS, el tráfico se agrupa según reglas que asocian una clase de reenvío definida a las aplicaciones seleccionadas. Los criterios de coincidencia de la regla incluyen una o más aplicaciones. Cuando el tráfico de una aplicación que coincide encuentra con la regla, la acción de la regla establece la clase de reenvío y señala el valor DSCP y la prioridad de pérdida a los valores adecuados para la aplicación.

Un valor de punto de código de servicios diferenciados (DiffServ) (DSCP) se especifica en la regla ya sea mediante un valor de mapa de bits de 6 bits o por un alias definido por el usuario o predeterminado. La tabla 1 proporciona una lista de nombres Junos OS de alias DSCP predeterminados y valores de mapa de bits.

Consulte Valores y alias CS predeterminados para obtener más detalles.

El programador de la cola utiliza la prioridad de pérdida para controlar el descarte de paquetes durante períodos de congestión mediante la asociación de perfiles de pérdida con valores de prioridad de pérdida determinados. (Consulte la Guía del usuario de clase de servicio (dispositivos de seguridad) para obtener información acerca de la configuración de colas y programadores.)

La regla aplica una prioridad de pérdida a los grupos de tráfico. Una prioridad de pérdida elevada significa una alta probabilidad de que el paquete se pueda perder durante un período de congestión. Hay cuatro niveles de prioridad de pérdida disponibles:

• high

• medium-high

• medium-low

• low

El conjunto de reglas se define en el class-of-service application-traffic-control comando de configuración:

Limitadores de velocidad y perfiles

Cuando se produce una congestión, AppQoS implementa la limitación de velocidad en todas las CPC de salida del dispositivo. Si los paquetes superan las limitaciones asignadas, se descartan. Los limitadores de velocidad mantienen un nivel coherente de transferencia de datos y sensibilidad de pérdida de paquetes para diferentes clases de tráfico. Todas las CPC de salida emplean el mismo esquema de limitación de velocidad.

El ancho de banda total de una PIC es de unos 10 Gbps. El hardware de limitador de velocidad para la PIC puede aprovisionar hasta 2 Gbps. Por lo tanto, el límite de ancho de banda superior para la limitación de velocidad es de^{2 31} bps.

Un perfil de limitador de velocidad define las limitaciones. Es una combinación única de y bandwidth-limit burst-size-limit especificaciones. Define bandwidth-limit la cantidad máxima de kilobits por segundo que pueden atravesar el puerto. Define burst-size-limit la cantidad máxima de bytes que pueden atravesar el puerto en una sola ráfaga. Esto burst-size-limit reduce el hambre de tráfico de menor prioridad al garantizar un tamaño finito para cada ráfaga.

AppQoS permite hasta 16 perfiles y hasta 1000 limitadores de velocidad por dispositivo. Varios limitadores de velocidad pueden usar el mismo perfil. En el ejemplo siguiente, se definen cinco limitadores de velocidad mediante dos perfiles:

Los limitadores de velocidad se definen con el class-of-service application-traffic-control comando de configuración.

Asignación de limitador de velocidad

Los limitadores de velocidad se aplican en reglas basadas en la aplicación del tráfico. Se aplican dos limitadores de velocidad para cada sesión: client-to-server y server-to-client . Este uso permite que el tráfico en cada dirección se aprovisione por separado.

El procesamiento del ancho de banda del tráfico por limitadores de velocidad se realiza a nivel del paquete independientemente de la dirección del tráfico. Por ejemplo: considere un caso en el que solo tiene un limitador de velocidad de 10 G configurado, si el tráfico de entrada y salida se encuentra desde la misma tarjeta de línea, entonces la transferencia de datos (tráfico máximo de las direcciones de entrada y salida combinadas) solo puede ser de hasta 10 G y no de 20 G. Sin embargo, si el dispositivo tiene compatibilidad con IOC (en caso de dispositivos de línea SRX5000 y dispositivos SRX4600) y el tráfico de entrada pasa por un IOC y un tráfico de salida a través de otro COI, entonces con un limitador de velocidad único de 10G configurado, puede esperar una transferencia de datos de 20 G.

Diferentes reglas appQoS dentro del mismo conjunto de reglas pueden compartir un limitador de velocidad. En este caso, las aplicaciones de esas reglas comparten el mismo ancho de banda. No existen limitaciones en el número de reglas de un conjunto de reglas que pueden asignar el mismo limitador de velocidad.

En los ejemplos siguientes se muestra cómo se podrían asignar los limitadores de velocidad definidos en la sección anterior. Por ejemplo, un conjunto de reglas puede reutilizar un limitador de velocidad en varias reglas y en una o ambas direcciones de flujo:

• rule-set-1

  • regla 1A

    • limitador de cliente a servidor-1

    • limitador de servidor a cliente-1

  • rule-1B

    • limitador de cliente a servidor-1

    • limitador de servidor a cliente-1

Si se necesitan los mismos perfiles en varios conjuntos de reglas, debe definirse un número suficiente de limitadores de velocidad especificando los bandwidth-limit mismos y burst-size-limit . Las dos reglas del ejemplo siguiente implementan los mismos perfiles asignando limitadores de velocidad diferentes, pero comparables.

• rule-set-2

  • regla 2A

    • limitador de cliente a servidor-2

    • limitador de servidor a cliente-2

  • rule-2B

    • limitador de cliente a servidor-2

    • limitador de servidor a cliente-4

• rule-set-3

  • regla 3A

    • limitador de cliente a servidor-3

    • limitador de servidor a cliente-3

  • rule-3B

    • limitador de cliente a servidor-3

    • limitador de servidor a cliente-5

Se aplica un limitador de velocidad mediante el comando de la misma manera en que se establecen una clase de reenvío, un valor DSCP y una edit class-of-service application-traffic-control rule-sets prioridad de pérdida.

Si tanto AppQoS como la limitación de velocidad basada en filtros de firewall se implementan en la PIC de salida, se tienen en cuenta ambas. La limitación de velocidad de AppQoS se considera la primera. La limitación de velocidad basada en filtros de firewall se produce después de eso.

Medidas de limitación de velocidad

Según el tipo de dispositivo de seguridad, las reglas de AppQoS se pueden configurar con diferentes acciones de limitación de velocidad:

• Deseche

  • Cuando se selecciona esta opción, los paquetes fuera de perfil se descartan.

  • Este es el tipo de acción predeterminado y no se debe configurar.

  • Esta opción se admite en todos los dispositivos de la serie SRX.

• Prioridad máxima de pérdida

  • Cuando se selecciona esta opción, eleva la prioridad de pérdida al máximo. En otras palabras, es una caída retardada; es decir, la decisión de descarte se toma en el nivel de la cola de salida. Si no hay congestión, permite el tráfico incluso con la prioridad máxima de pérdida. Pero si se produce una congestión, primero se pierden estos paquetes de prioridad de pérdida máxima.

  • Esta opción se debe configurar dentro de la regla AppQoS (para anular la acción predeterminada) con el siguiente comando:

  • Esta opción solo se admite en para SRX300, SRX320, SRX340, SRX345.

Configuración de política de seguridad de AppQoS

El conjunto de reglas de AppQoS se puede implementar en una política existente o en una política de aplicación específica.

Descripción del conjunto de reglas de calidad de servicio predeterminadas de las aplicaciones para políticas unificadas

Puede configurar una regla predeterminada de AppQoS para administrar los conflictos de políticas de seguridad.

La fase inicial de búsqueda de políticas se produce antes de identificar una aplicación dinámica. Si hay varias políticas presentes en la lista de políticas potencial que contienen distintos conjuntos de reglas AppQoS, el dispositivo de seguridad aplica el conjunto de reglas appQoS predeterminado hasta que se haya producido una coincidencia más explícita.

Puede establecer una AppQoS como una regla AppQoS predeterminada establecida en el edit security ngfw nivel jerárquico. El conjunto de reglas AppQoS predeterminado se aprovecha de uno de los conjuntos de reglas de AppQoS existentes, los cuales se configuran bajo el [edit class-of-service application-traffic-control] nivel jerárquico.

En la tabla 2 se resume el uso de la regla predeterminada de AppQoS establecida en diferentes escenarios en una política unificada.

Cuando se aplica un conjunto de reglas AppQoS predeterminado al tráfico y la política de seguridad final tiene un conjunto de reglas AppQoS diferente, en tales casos no se admite la conmutación de la regla appQoS predeterminada establecida a la regla AppQoS establecida en la política de seguridad final.

Configuración predeterminada de la calidad de servicio de la aplicación en diferentes escenarios

Los siguientes vínculos son para ejemplos que analizan los conjuntos de reglas de AppQoS predeterminados en diferentes escenarios:

En la tabla 3 se muestran distintos conjuntos de reglas appQoS configurados para políticas unificadas con aplicaciones dinámicas como condición de coincidencia.

En este ejemplo, cualquier conjunto de reglas AppQoS (AppQoS-1, AppQoS-2, AppQoS-3) se puede configurar como una regla AppQoS predeterminada establecida en el nivel [security ngfw] jerárquico. No es necesario que una regla predeterminada establecida forme parte de una configuración de política de seguridad. Cualquier conjunto de reglas AppQoS bajo el nivel de jerarquía se puede asignar como el conjunto predeterminado de [edit class-of-service application-traffic-control] reglas AppQoS.

• Sin conflicto de políticas: todas las políticas tienen el mismo conjunto de reglas de AppQoS
• Sin conflicto de políticas: todas las políticas tienen el mismo conjunto de reglas de AppQoS y la política final no tiene un conjunto de reglas AppQoS
• Conflicto de políticas: no se configura ningún conjunto de reglas appQoS para la política final
• Conflicto de políticas: conjunto de reglas appQoS predeterminada y un conjunto de reglas appQoS diferente para la política final

Limitación de appQoS con políticas unificadas

Cuando se aplica una política de seguridad al tráfico que coincide, la regla AppQoS se aplica al tráfico permitido. Si la política de seguridad y el conjunto de reglas de AppQoS aplicado tienen aplicaciones dinámicas diferentes, puede producirse un conflicto como se muestra en el ejemplo siguiente:

En este ejemplo, la regla de control de tráfico de la aplicación está configurada para junos:GOOGLE y la condición de coincidencia de política de seguridad de la aplicación dinámica es junos: FTP. En tales casos, es posible que ocurran conflictos cuando se aplique la política final.