QoS de aplicación

Beneficio de la QoS de aplicación

AppQoS brinda la capacidad de priorizar y medir el tráfico de aplicaciones para brindar un mejor servicio al tráfico de aplicaciones críticas para el negocio o de alta prioridad.

Clases de reenvío únicas y asignaciones de cola

La clase de reenvío proporciona tres funciones:

• Agrupa paquetes con características similares

• Asigna colas de salida

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

Los nombres de clase de reenvío únicos protegen el remarcado de AppQoS para que no se sobrescriba con reglas de reescritura basadas en interfaces. Un reescritor basado en filtros de firewall remarca el valor DSCP de un paquete si la clase de reenvío del paquete coincide con una clase definida específicamente para este reescritor. Si la clase de reenvío del paquete no coincide con ninguna de las clases del reescritor basado en filtros de firewall, no se marca el valor DSCP. Por lo tanto, para evitar que los valores de AppQoS se sobrescriban, use nombres de clase de reenvío que no sean desconocidos para el regrabador basado en filtros de firewall.

Cada clase de reenvío se asigna a una cola de salida que proporciona el grado adecuado de procesamiento mejorado o estándar. Muchas clases de reenvío se pueden asignar a una sola cola. Por lo tanto, cualquier cola definida para el dispositivo puede ser utilizada por reescritores basados en filtros de DPI, AppQoS y firewall. Es el nombre de la clase de reenvío, no la cola, lo 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 cómo configurar colas y programadores.)

Configuración de punto de código DSCP y prioridad de pérdida que prioriza las aplicaciones

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

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

Cuadro 1: Alias y valores de bits estándar de CoS

Alias	Valor de bit
ef	101110
AF11	001010
af12	001100
af13	001110
AF21	010010
AF22	010100
AF23	010110
af31	011010
af32	011100
af33	011110
AF41	100010
af42	100100
af43	100110
ser	000000
cs1	001000
cs2	010000
CS3	011000
CS4	100000
CS5	101000
NC1/CS6	110000
NC2/CS7	111000

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

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

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

• high

• medium-high

• medium-low

• low

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

Limitadores de velocidad y perfiles

Cuando se produce una congestión, AppQoS implementa la limitación de velocidad en todas las PIC de salida del dispositivo. Si los paquetes superan las limitaciones asignadas, se descartan. Los limitadores de velocidad mantienen un nivel consistente de sensibilidad a la transferencia de datos y a la pérdida de paquetes para diferentes clases de tráfico. Todas las PIC 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 con limitador de velocidad para la PIC puede aprovisionar hasta 2 Gbps. Por lo tanto, el límite superior de la anchura de banda para la limitación de velocidad es de 2³¹ bps.

Un perfil de limitador de velocidad define las limitaciones. Es una combinación única de bandwidth-limit y burst-size-limit especificaciones. Define bandwidth-limit el número máximo de kilobits por segundo que pueden atravesar el puerto. Define burst-size-limit el número máximo de bytes que pueden atravesar el puerto en una sola ráfaga. Reduce burst-size-limit la inanición del 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:

Nombre del limitador de velocidad	Perfil
	límite de ancho de banda	límite de tamaño de ráfaga
limitador-1	200	26000
Limitador-2	200	26000
limitador-3	200	26000
limitador-4	400	52000
limitador-5	400	52000

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 mediante limitadores de velocidad se realiza a nivel de paquete, independientemente de la dirección del tráfico. Por ejemplo: considere un caso en el que solo tiene un limitador de velocidad de 10G configurado, si el tráfico de entrada y salida es de 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 10G y no de 20G. Sin embargo, si el dispositivo es compatible con IOC (tarjetas E/S [IOC]) y el tráfico de entrada se realiza a través de una IOC y el tráfico de salida a través de otra IOC, entonces con un único limitador de velocidad de 10G configurado, puede esperar una transferencia de datos de 20G.

Diferentes reglas de 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 hay 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 pueden asignar los limitadores de velocidad definidos en la sección anterior. Por ejemplo, un conjunto de reglas podría reutilizar un limitador de velocidad en varias reglas y en una o ambas direcciones de flujo:

• conjunto de reglas 1

  • regla 1A

    • limitador de cliente a servidor 1

    • limitador de servidor a cliente-1

  • regla 1B

    • limitador de cliente a servidor 1

    • limitador de servidor a cliente-1

Si se necesitan los mismos perfiles en varios conjuntos de reglas, se debe definir un número suficiente de limitadores de velocidad especificando el mismo bandwidth-limit y burst-size-limit. Los dos conjuntos de reglas del ejemplo siguiente implementan los mismos perfiles mediante la asignación de limitadores de velocidad diferentes, pero comparables.

• conjunto de reglas 2

  • regla 2A

    • limitador de cliente a servidor 2

    • Limitador de servidor a cliente-2

  • regla 2B

    • limitador de cliente a servidor 2

    • Limitador de servidor a cliente-4

• conjunto de reglas 3

  • regla 3A

    • Limitador de cliente a servidor 3

    • Limitador de servidor a cliente-3

  • regla 3B

    • Limitador de cliente a servidor 3

    • Limitador de servidor a cliente-5

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

Si AppQoS y la limitación de velocidad basada en filtros de firewall se implementan en la PIC de salida, se tienen en cuenta ambos. Primero se considera la limitación de la tasa de AppQoS. La limitación de velocidad basada en filtros de firewall ocurre después de eso.

Nota:

Si se quitan paquetes de una PIC, el dispositivo no envía notificaciones al cliente ni al servidor. Las aplicaciones de nivel superior en los dispositivos cliente y servidor son responsables de la retransmisión y el manejo de errores.

Acción del limitador de velocidad

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

• Descartar

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

  • Este es el tipo de acción predeterminado y no es necesario configurarlo.

  • Esta opción se admite en todos los dispositivos de seguridad

• Prioridad de pérdida alta

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

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

  • Esta opción se admite en dispositivos seleccionados. Consulte la tabla de comportamiento de AppQoS específica de la plataforma .

Configuración de la 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 de aplicación predeterminadas para políticas unificadas

Puede configurar un conjunto de reglas predeterminado de AppQoS para administrar 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 directivas presentes en la lista de directivas potenciales que contienen diferentes conjuntos de reglas de AppQoS, el dispositivo de seguridad aplica el conjunto de reglas de AppQoS predeterminado hasta que se produzca una coincidencia más explícita.

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

En la tabla 2 se resume el uso del conjunto de reglas de AppQoS predeterminado en diferentes escenarios en una política unificada.

Tabla 2: Uso de conjuntos de reglas de AppQoS en políticas unificadas

Estado de identificación de la aplicación	Uso del conjunto de reglas de AppQoS	Acción
Sin conflicto de política de seguridad.	La regla AppQoS establecida en la jerarquía [edit class-of-service application-traffic-control] se aplica cuando el tráfico coincide con la política de seguridad.	AppQoS se aplica como en el conjunto de reglas de AppQoS.
El conflicto de políticas de seguridad y las políticas en conflicto tienen conjuntos de reglas de AppQoS distintos.	El conjunto de reglas de AppQoS predeterminado no está configurado o no se encuentra.	La sesión se ignora porque el perfil de AppQoS predeterminado no está configurado. Como resultado, incluso si la directiva coincidente final en el escenario de conflicto de directiva tiene un conjunto de reglas AppQoS, este conjunto de reglas no se aplica. Le recomendamos que configure un conjunto de reglas de AppQoS predeterminado para administrar los conflictos de políticas de seguridad.
	Se configura el conjunto de reglas de AppQoS predeterminado.	AppQoS se aplica como en el conjunto de reglas de AppQoS predeterminado.
Se identifica la solicitud final	La directiva de seguridad coincidente tiene un conjunto de reglas de AppQoS, que es el mismo que el conjunto de reglas de AppQoS predeterminado.	AppQoS se aplica como en el conjunto de reglas de AppQoS predeterminado.
	La política de seguridad coincidente no tiene un conjunto de reglas de AppQoS.	El conjunto de reglas de AppQoS predeterminado no se aplica y AppQoS no se aplica para la sesión.
	La directiva de seguridad Coincidencia tiene un conjunto de reglas de AppQoS diferente del conjunto de reglas de AppQoS predeterminado, que ya se ha aplicado.	El conjunto de reglas de AppQoS predeterminado permanece como el conjunto de reglas de AppQoS predeterminado.

Cuando se aplica un conjunto de reglas de AppQoS predeterminado en el tráfico y la política de seguridad final tiene un conjunto de reglas de AppQoS diferente, en tales casos no se admite el cambio del conjunto de reglas de AppQoS predeterminado al conjunto de reglas de AppQoS en la política de seguridad final.

Conjunto de reglas predeterminadas de calidad del servicio de la aplicación en diferentes escenarios

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

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

Tabla 3: Diferentes conjuntos de reglas de AppQoS en políticas unificadas

Política de seguridad	Zona de origen	Dirección IP de origen	Zona de destino	Dirección IP de destino	Número de puerto	Protocolo	Aplicación dinámica	Servicio	Conjunto de reglas de AppQoS
Política P1	Temporada 1	50.1.1.1	D1	Cualquiera	Cualquiera	Cualquiera	Facebook (en inglés)	AppQoS	AppQoS-1
Política P2	Temporada 1	50.1.1.1	D1	Cualquiera	Cualquiera	Cualquiera	Google	AppQoS	AppQoS-2
Política P3	Temporada 1	50.1.1.1	D1	Cualquiera	Cualquiera	Cualquiera	YouTube (en inglés)	AppQoS	AppQoS-3

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

• 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 ningún conjunto de reglas de AppQoS
• Conflicto de política: no hay ningún conjunto de reglas de AppQoS configurado para la política final
• Conflicto de políticas: conjunto de reglas de AppQoS predeterminadas y un conjunto de reglas de 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 coincidente, el conjunto de reglas de 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, es posible que se produzca un conflicto, como se muestra en el siguiente ejemplo:

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 la política de seguridad para la aplicación dinámica es junos: FTP. En tales casos, pueden producirse conflictos cuando se aplica la política final.

Descripción general

El tráfico HTTP/2 ahora hereda las reglas de AppQoS HTTP para el marcado DSCP cuando no hay una regla HTTP/2 específica, lo que garantiza un comportamiento de QoS coherente.

HTTP es una aplicación general en la que varias aplicaciones (por ejemplo, facebook, twitter) aparecen como sesiones separadas y se clasifican de forma independiente, con AppQoS aplicada por sesión. Anteriormente, las sesiones HTTP/2 solo se clasificaban como http2, sin ninguna clasificación de aplicación secundaria

Es decir, para las sesiones HTTP/2, solo se podía aplicar la regla AppQoS de la sesión principal. Sin embargo, HTTP/2 utiliza varias secuencias, cada una clasificada como aplicaciones diferentes. Las clasificaciones de sesiones secundarias se ignoraron para la coincidencia de reglas de AppQoS.

Con la nueva actualización, la clasificación de aplicaciones de la primera sesión de transmisión se usa para hacer coincidir y aplicar la regla AppQoS a la sesión principal HTTP/2. Si la aplicación clasificada final de la primera secuencia no tiene una regla AppQoS, la sesión vuelve a la regla AppQoS HTTP/2 principal.

Ejemplo:

Considere la sesión HTTP/2 que incluye varias secuencias.

• La primera transmisión se identifica como twitter.
• Se aplica la regla AppQoS para Twitter.
• Cada secuencia de la sesión principal HTTP/2 hereda la regla.

Aquí, los paquetes ya no van a una cola http2 genérica; van completamente a la cola de aplicaciones de First Stream (Twitter).

Lógica de clasificación

AppQoS para HTTP/2 utiliza una búsqueda de reglas descendente, que comienza desde la aplicación más específica y retrocede a través de HTTP2, HTTP, SSL y application-any. La clasificación de la primera sesión de transmisión ahora se usa para la coincidencia de reglas de sesión principal, lo que garantiza una asignación y registro precisos de QoS.

Asignación de conjuntos de reglas y aplicaciones

• Cada política de seguridad usa un conjunto de reglas con reglas de AppQoS específicas para diferentes aplicaciones (p. ej., http, http2, facebook).
• Cada regla asigna una clase de reenvío (Mejor esfuerzo, Reenvío seguro, Reenvío acelerado, Control de red) y una cola COS.

Ruta de clasificación

• La búsqueda de reglas de AppQoS comienza desde la aplicación más específica (aplicación anidada) y asciende en la jerarquía. Las sesiones (principales/secundarias) se clasifican mediante una ruta jerárquica (ejemplo: ip.tcp.ssl.http.http2.facebook).

  En el ejemplo, la secuencia de búsqueda es la siguiente:

  1. Si la aplicación anidada (facebook-chat) no está configurada en el conjunto de reglas, se aplica la http2 regla.
  2. Si http2 no está configurado, se aplica la http regla.
  3. Si http no está configurado, se aplica la ssl regla.
  4. Si no existe ninguna regla de AppQoS para ninguna aplicación clasificada, se aplica la application-any regla.
  5. Si application-any no está configurado, la sesión continúa con la regla DSCP aplicada anteriormente.

  Esta clasificación garantiza que las sesiones HTTP/2 nunca se ignoren y siempre reciban tratamiento de QoS.

Ejemplo: Un perfil de AppQoS contiene reglas para aplicaciones específicas más una regla general "Cualquiera". Por ejemplo, el perfil incluye conjuntos de reglas para HTTP, Facebook, Yahoo y Any, y la primera transmisión se clasifica como: Http.http2.twitter

Caso A: Regla "cualquier" configurada

• No existe una regla explícita de Twitter.
• Dado que la regla Cualquier está presente, AppQoS selecciona Cualquiera.
• Resultado: Se aplica la regla Cualquiera.

Caso B: Regla "cualquier" no configurada

• No existe una regla explícita de Twitter.
• No hay ninguna regla disponible.
• En este caso, el sistema recurre a la siguiente mejor coincidencia en orden descendente de especificidad:
  • Regla http2 (si está presente)
  • Si no hay una regla http2, → recurrir a http
  • Si ninguna regla http → usar la cola predeterminada
• Resultado: La regla de coincidencia más cercana se selecciona en función del orden de reserva anterior.

Gestión de sesiones principales y secundarias

• Sesión principal: normalmente se clasifica en un nivel superior (ejemplo: http2).
• Sesión secundaria: clasificada con aplicaciones anidadas más específicas (ejemplo: facebook, twitter).

La clasificación de la primera sesión de transmisión ahora se considera para la coincidencia de reglas en la sesión principal.

Reenvío y registro

• Al tráfico de cada sesión se le asigna una clase de reenvío y una cola basadas en la regla coincidente.
• Las entradas de syslog reflejan la clasificación y la coincidencia de reglas tanto para el cierre de la sesión como para el cierre de la transmisión

Limitaciones

• Para HTTP/2, solo se usa la clasificación de aplicación de la primera secuencia para la coincidencia de reglas de AppQoS en la sesión principal.
• En sesiones de larga duración, los conmutadores de aplicaciones midstream (HTTP/1 o HTTP/2) pueden provocar cambios en la cola CS, lo que lleva a un reordenamiento de los paquetes. El reensamblaje de TCP en dispositivos finales controla esto mediante números de secuencia.
• HTTP/2 para AppQoS no se admite en escenarios de alta disponibilidad de clúster de chasis ni de múltiples nodos.
• Los limitadores de velocidad de AppQoS no funcionan correctamente para el tráfico HTTPS en las configuraciones de tráfico HTTP/1.1 y HTTP/2 cuando se configura el proxy de reenvío SSL.