Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
EN ESTA PÁGINA
 

Calidad de la experiencia de la aplicación

Calidad de la experiencia de la aplicación (AppQoE)

Introducción a la calidad de la experiencia de la aplicación

El crecimiento incesante de la computación en la nube, la movilidad y las aplicaciones basadas en web requiere que la red identifique y controle el tráfico a nivel de aplicación y maneje cada tipo de aplicación por separado para proporcionar calidad de experiencia (QoE) a los usuarios. Para garantizar la QoE específica de la aplicación (AppQoE), debe priorizar, segregar y enrutar eficazmente el tráfico de las aplicaciones sin comprometer el rendimiento ni la disponibilidad.

AppQoE utiliza (o emplea) las capacidades de dos servicios de seguridad de aplicaciones: identificación de aplicaciones (AppID) y enrutamiento avanzado basado en políticas (APBR). Utiliza AppID para identificar aplicaciones específicas en su red y enrutamiento avanzado basado en políticas (APBR) para especificar una ruta para determinado tráfico mediante la asociación de perfiles de SLA a una instancia de enrutamiento en la que se envía el tráfico de la aplicación según las reglas de APBR.

Uno de los requisitos importantes de una WAN definida por software (SD-WAN) es medir la calidad de las rutas de red subyacentes y, en función de los resultados, determinar las mejores rutas a utilizar para la entrega de cada paquete. AppQoE supervisa el rendimiento de las aplicaciones críticas para el negocio y, en función de la puntuación, selecciona el mejor vínculo posible para ese tráfico de aplicaciones con el fin de cumplir con los requisitos de rendimiento especificados en el SLA (acuerdo de nivel de servicio).

La presencia de una regla de SLA en la configuración de APBR desencadena la funcionalidad AppQoE; Si no hay perfiles de SLA disponibles, el APBR funciona sin activar AppQoE.

Caso de uso admitido

Puede configurar AppQoE de forma óptima mediante Contrail Service Orchestration (CSO). Le recomendamos que use CSO para configurar AppQoE para la solución Contrail SD-WAN de Juniper Networks. Para obtener más información, vea Descripción general de la calidad de la experiencia de la aplicación y Configuración y supervisión de la calidad de la experiencia de la aplicación.

Dispositivos compatibles de la serie SRX

AppQoE es compatible con topologías radiales y de malla completa en despliegues de SD-WAN.

Puede configurar instancias de vSRX, dispositivos de línea SRX300 SRX550M como dispositivos radiales y SRX1500, SRX4100 y SRX4200 como dispositivos de concentrador.

Puede configurar una AppQoE entre dos puntos de conexión de dispositivos de la serie SRX (finalizado por libro) y ambos dispositivos de la serie SRX deben tener la misma versión de la imagen de Junos OS.

A partir de Junos OS versión 15.1X49-D160 y en Junos OS 19.1R1, los dispositivos SRX4100 y SRX4200 admiten AppQoE cuando los dispositivos están en modo de clúster de chasis. Puede configurar el dispositivo para que funcione tanto en modo activo/activo como activo/pasivo e implementar el dispositivo como dispositivo radial en despliegues de SD-WAN.

Beneficios de la calidad de la experiencia de la aplicación

  • Permite una QoE rentable al proporcionar monitoreo en tiempo real del tráfico de las aplicaciones para proporcionar un nivel de servicio consistente y predecible.

  • Aumenta la retención y la satisfacción del cliente al proporcionar un SLA garantizado para la entrega de cierto tráfico (como el tráfico de video). AppQoE garantiza que el tráfico aprobado reciba la prioridad adecuada y el ancho de banda necesarios para garantizar la mejor calidad de experiencia para el usuario.

Limitaciones

La implementación de AppQoE en dispositivos de seguridad tiene las siguientes limitaciones:

  • Todas las diferentes rutas al destino a través de diferentes interfaces deben tener configuradas las mismas preferencias, peso y métricas. Todas las rutas deben agregarse como rutas ECMP para el destino y también deben formar parte de la misma tabla de reenvío.

  • Se admite el servicio de SLA AppQoE solo entre puntos de conexión de dos dispositivos de seguridad (finalizado por libro). No se admite el servicio de SLA AppQoE de extremo a extremo.

  • AppQoE solo se puede aplicar si todas las interfaces forman parte de la misma zona.

  • AppQoE no se puede aplicar para el tráfico inverso.

  • AppQoE no influye en el cambio en el destino de una sesión.

  • AppQoE no admite encapsulación de sonda IPv6/UDP, GRES, clúster de chasis (ISSU, alta disponibilidad, CPE dual de alta disponibilidad, alta disponibilidad en modo Z) ni sistemas lógicos.

  • AppQoE no admite la selección de rutas preferidas y no se admite el enrutamiento y reenvío virtual de tránsito (VRF).

  • AppQoE no admite el sondeo pasivo en paquetes de datos IPv6.

  • Se requiere un filtro de firewall de entrada en las interfaces no WAN para descartar paquetes UDP con el puerto de destino UDP 36000.

  • El dispositivo SRX4600 tiene las siguientes limitaciones:

    • La clase de servicio (CoS) para la encapsulación de enrutamiento genérico (GRE) no se admite cuando se configura AppQoE.

    • Es posible que los detalles de la sonda pasiva no estén disponibles para cada sesión de corta duración.

    • Es posible que la sincronización de los estados de sesión no ocurra en el nodo secundario en el procesamiento de tráfico en modo Z-line cuando el dispositivo funciona en modo de clúster de chasis.

¿Cómo funciona la calidad de la experiencia de las aplicaciones?

AppQoE utiliza las capacidades de AppID y APBR para identificar aplicaciones o grupos de aplicaciones específicos y especificar una ruta para cierto tráfico asociando perfiles de SLA a una instancia de enrutamiento en la que se envía el tráfico de la aplicación según las reglas de APBR.

AppQoE supervisa el rendimiento de las aplicaciones y, en función de la puntuación, selecciona el mejor vínculo posible para ese tráfico de aplicaciones con el fin de cumplir con los requisitos de rendimiento especificados en el SLA (acuerdo de nivel de servicio).

Identificación de aplicaciones o grupos de aplicaciones

Los siguientes pasos intervienen en la identificación de aplicaciones o grupos de aplicaciones:

  1. La identificación de aplicaciones de Junos OS identifica las aplicaciones y, una vez identificadas las aplicaciones, su información se guarda en la caché del sistema de aplicaciones (ASC).

  2. APBR evalúa los paquetes en función de determinar si la sesión es candidata para el enrutamiento basado en aplicaciones (enrutamiento avanzado basado en políticas). Si este es el primer paquete de la nueva sesión y el tráfico no se marca para el enrutamiento basado en aplicaciones, se somete a un procesamiento normal (ruta no APBR) hasta el destino.

  3. Si la sesión necesita enrutamiento basado en aplicaciones, APBR consulta el módulo ASC para obtener los atributos de la aplicación (dirección IP, puerto de destino, tipo de protocolo y servicio).

  4. Si se encuentra la aplicación en ASC, el tráfico se procesa más a fondo para obtener una regla coincidente en el perfil APBR.

    • Si se encuentra una regla coincidente, el tráfico se redirige a la instancia de enrutamiento especificada para la búsqueda de ruta.

      • AppQoE comprueba si un SLA está habilitado para una sesión. Si la sesión es candidata para una medición de SLA, AppQoE inicia sondeos activos y pasivos para medir el rendimiento.

      • Si el SLA no está habilitado para la sesión en la regla APBR, AppQoE ignora esa sesión y se aplica el comportamiento predeterminado de APBR a esas sesiones, es decir, el tráfico se enruta a través de la instancia de enrutamiento especificada para el destino.

    • Si la aplicación no se encuentra en ASC, APBR solicita una inspección profunda del flujo. es decir, el paquete de firmas de aplicación está instalado y la identificación de aplicaciones para la sesión, de modo que ASC se pueda rellenar para su uso por sesiones posteriores para el procesamiento de APBR (consulte el paso 2).

Especificación de ruta de acceso para aplicaciones o grupos de aplicaciones

Los pasos siguientes resumen cómo AppQoE especifica una ruta de acceso para el tráfico de la aplicación de acuerdo con las reglas de SLA.

  1. APBR utiliza los detalles de la aplicación para buscar una regla coincidente en el perfil APBR (perfil de aplicación). El tráfico que coincide con las aplicaciones y los grupos de aplicaciones se reenvía a la ruta estática y a la dirección del salto siguiente, tal como se especifica en la instancia de enrutamiento.

  2. Una regla de SLA adjunta al perfil APBR especifica los parámetros necesarios para medir el SLA e identificar si se ha producido alguna infracción de SLA o no.

  3. El tráfico de aplicaciones se asigna a un vínculo de superposición determinado en función de las métricas de SLA de ese vínculo de superposición medidas mediante sondeo activo.

  4. La infracción del SLA se determina mediante un sondeo pasivo del tráfico de aplicaciones o grupos de aplicaciones en vivo. El mejor vínculo de superposición/ruta para la aplicación/grupo de aplicaciones se determina mediante el algoritmo de selección de ruta.

Selección de ruta de tráfico de aplicación

Los siguientes pasos tienen lugar para enrutar el tráfico de datos desde el origen hasta el destino, específicamente, para seleccionar la mejor ruta,

  • Para el primer paquete de datos de un flujo (primera ruta), si la aplicación ya se conoce (a partir de la búsqueda ASC), se busca la mejor ruta para la aplicación en la base de datos. Si la aplicación no se conoce o es nueva (desde la búsqueda de ASC), se elige una ruta aleatoria o la ruta predeterminada. Esta ruta continúa durante toda la sesión. Más tarde, después de que el DPI detecte la aplicación, la base de datos se actualiza con la mejor ruta para la aplicación.

  • Para el paquete de datos restante de un flujo (ruta rápida), si la aplicación no se conoce inicialmente, entonces la sesión en particular continúa en la misma ruta. Si la aplicación se conoce inicialmente, AppQoE selecciona la mejor ruta para el tráfico de la aplicación.

Cuando se detecta una nueva aplicación, el mecanismo de selección de ruta intenta encontrar una ruta que satisfaga todas las métricas de SLA. Si no existe tal ruta, se utiliza la siguiente mejor ruta (según el número de métricas satisfechas). Si hay más de una ruta que satisface las métricas, se selecciona una ruta aleatoria entre las rutas disponibles. La infracción del SLA se detecta cuando se infringe alguna de las métricas o cuando ninguna de las métricas cumple el requisito, según la configuración del perfil.

Cómo la calidad de la experiencia de las aplicaciones mide el rendimiento de las aplicaciones

El rendimiento de la aplicación está determinado por los siguientes indicadores:

  • Latencia: la cantidad de tiempo físico necesario para que los medios viajen dependiendo de la longitud y la distancia del medio que se necesita cubrir.

  • RTT: un tiempo de ida y vuelta requerido para viajar desde el origen hasta el destino y viceversa.

  • Pérdida de paquetes: la pérdida de paquetes refleja el número de paquetes perdidos por cada 100 paquetes enviados por un host.

  • Jitter: Jitter es la diferencia en la latencia de un paquete a otro. La fluctuación de entrada, la fluctuación de salida y la fluctuación bidireccional se pueden especificar para evaluar el rendimiento del vínculo.

AppQoE supervisa el RTT, la fluctuación y la pérdida de paquetes en cada vínculo y, según la puntuación, desvía sin problemas las aplicaciones a la ruta alternativa si el rendimiento del vínculo principal está por debajo de los niveles aceptables especificados por el SLA. La medición y el monitoreo del rendimiento de la aplicación se realizan mediante sondeos activos y pasivos para detectar violaciones de SLA y seleccionar una ruta alternativa para esa aplicación en particular.

AppQoE recopila datos en tiempo real mediante la supervisión continua del tráfico de aplicaciones y la identificación de problemas de red o dispositivo mediante:

  • Supervisión del rendimiento en todos los vínculos de superposición configurados.

  • Usar sondeos pasivos (en línea con la ruta de datos de la aplicación) y sondeos activos (sondeos sintéticos para aplicaciones específicas) para supervisar el rendimiento del tráfico de la aplicación o el grupo de aplicaciones.

  • Enviar todas las métricas o metadatos de rendimiento recopilados para su análisis a un recopilador de registros.

  • Comparar la aplicación especificada con una métrica de rendimiento específica y cambiar dinámicamente la ruta para el tráfico de la aplicación en caso de una infracción de SLA.

  • Compatibilidad con una configuración de métricas de SLA flexible para una aplicación o grupo de aplicaciones determinados.

AppQoE mide el SLA de la aplicación en varios vínculos WAN y asigna el tráfico de la aplicación a una ruta entre los vínculos disponibles, es decir, a la ruta que mejor sirva al requisito de SLA.

Medición del rendimiento de las aplicaciones mediante el uso de sondas activas y pasivas

Las mediciones de sonda activa y pasiva son los dos enfoques utilizados para el análisis de extremo a extremo de la red.

  • Sondeo activo: los sondeos activos miden la calidad del servicio de la aplicación para proporcionar una medición de extremo a extremo del rendimiento de la red.

    En el sondeo activo, se envían paquetes personalizados entre los puntos de radio y de concentrador en todas las rutas múltiples, y el RTT, la latencia, la fluctuación y la pérdida de paquetes se miden entre los puntos de sondeo instalados. Las sondas activas se envían periódicamente en todos los enlaces activos y pasivos. Se recopila un número configurado de muestras y se mide una media para la ruta de sondeo de cada aplicación. Si se detecta una infracción en el tráfico de cualquier aplicación, las métricas del sondeo se evalúan para determinar el mejor vínculo que satisfaga el SLA.

  • Sondeo pasivo: los sondeos pasivos se instalan en los vínculos dentro de la red y supervisan todo el tráfico que fluye a través de esos vínculos.

    El sondeo pasivo monitorea los enlaces para detectar infracciones de SLA en el tráfico de datos en vivo. En una sonda pasiva, los paquetes de datos reales se encapsulan en un encabezado de sonda IP/UDP en el tráfico en vivo entre los puntos de final de libro de la serie SRX, y RTT, la fluctuación y la pérdida de paquetes entre los puntos de instalación de las sondas se miden para calcular la calidad del servicio.

    Si se detecta una infracción en alguna aplicación, se evalúan las métricas de sonda sintética para determinar el mejor vínculo que satisfaga el SLA.

    Nota:

    A partir de Junos OS versión 18.3R1 y Junos OS versión 15.1X49-D150, en todos los dispositivos serie SRX e instancias vSRX compatibles, para detectar si un vínculo o ruta está inactivo debido a sondas pasivas, deben producirse un mínimo de tres solicitudes de sondeo y una pérdida de paquetes del 100 % en un período de muestreo para una sesión determinada a fin de desencadenar la infracción del SLA.
    Nota:

    Cuando el dispositivo funciona en modo de clúster de chasis, si se reinicia el nodo secundario (nodo 1), a través del cual se reenvía el tráfico, se produce una conmutación múltiple del tráfico de la aplicación entre los vínculos a través de vínculos de nodo secundario. Esto sucede cuando los vínculos disponibles en el nodo principal (nodo 0) tienen una puntuación de ruta de SLA de sondeo menos activa en comparación con los vínculos de nodo secundario. Este comportamiento continúa hasta que los resultados de la puntuación de ruta de SLA del sondeo activo AppQoE estén disponibles para indicar que hay una pérdida de paquetes del 100% en todos los vínculos del nodo secundario.

Puede configurar una regla de SLA con parámetros de sondeo activos y pasivos y asociar la regla de SLA con el perfil APBR. El perfil APBR también incluye una regla APBR. Las reglas se asocian a una o varias aplicaciones o grupos de aplicaciones, y el tráfico que coincide con la regla se redirige a la instancia de enrutamiento

AppQoE activa las solicitudes de sondeo a todas las rutas de sondeo de la aplicación. Las sondas activas y pasivas monitorean la red en busca de áreas o puntos de fallas o congestión.

AppQoE recopila estadísticas de clase de tráfico para aplicaciones aprendidas mediante sondeos activos y pasivos y realiza las siguientes acciones:

  1. Mida el rendimiento del SLA: las métricas en tiempo real proporcionadas por las sondas se utilizan para calificar la calidad del servicio de acuerdo con el SLA de una aplicación y determinar si la ruta de la aplicación no cumple los requisitos del SLA. Es decir, si se detecta una infracción en cualquier aplicación, las métricas sintéticas del sondeo se evalúan para determinar el mejor vínculo alternativo para el tráfico de la aplicación que satisfaga el SLA.

  2. Redireccionar tráfico: cambia el tráfico de aplicaciones entre los dos vínculos, es decir, cuando un vínculo tiene problemas de rendimiento, el tráfico se enruta al otro vínculo durante la misma sesión.

Nota:

Si se puede acceder al tráfico de la aplicación a través de varios vínculos, debe configurar todas las rutas accesibles como rutas de superposición y adjuntar las rutas de superposición a la regla de SLA de la aplicación.

Cambio de tráfico de aplicaciones a una ruta alternativa

Puede habilitar o deshabilitar la conmutación del tráfico de la aplicación a otra ruta (local para el dispositivo) durante una infracción de SLA. Cuando la conmutación de ruta local está habilitada, se habilita la conmutación del tráfico de la aplicación a una ruta alternativa y también está disponible la funcionalidad de supervisión e informes de SLA. Incluso cuando la opción para cambiar el tráfico de la aplicación a una ruta alternativa está deshabilitada en la configuración de la regla de SLA, AppQoE resuelve las infracciones de SLA--- por ejemplo, cambiando el tráfico de la aplicación a una nueva ruta

Cuando la conmutación de ruta local está deshabilitada, solo está disponible la funcionalidad de supervisión e informes de SLA y la conmutación del tráfico de la aplicación a la ruta diferente debido a una infracción de SLA se desactiva.

Cuando el tráfico de una aplicación cambia a una ruta alternativa, habrá un breve período de tiempo durante el cual el tráfico de la aplicación no se podrá volver a cambiar a otra ruta en caso de infracción del SLA. Este período de tiempo ayuda a evitar el aleteo del tráfico a través de los enlaces.

Descripción de los límites de configuración de AppQoE

A partir de Junos OS versión 15.1X49-D160 y en Junos OS versión 19.1R1, AppQoE aplica el límite de configuración para rutas superpuestas, perfiles de métrica, parámetros de sondeo y reglas de SLA por perfil cuando se configuran reglas de SLA específicas de la aplicación y asocia las reglas de SLA a un perfil APBR.

Si configura los parámetros más que el límite permitido, se mostrarán mensajes de error al confirmar la configuración.

Ejemplos de mensajes de error:

Los siguientes mensajes de error de ejemplo provienen del dispositivo SRX4100 y SRX4200. Es posible que el valor del límite de configuración no refleje el número exacto admitido; Los números pueden diferir entre los dispositivos compatibles

Selección de la ruta de acceso de la aplicación según la preferencia y prioridad del vínculo

Uno de los requisitos importantes de una WAN definida por software (SD-WAN) es medir la calidad de las rutas de red subyacentes y, en función de los resultados, determinar las mejores rutas a utilizar para la entrega de cada paquete.

A partir de Junos OS versión 18.4R1 y Junos OS versión 15.1X49-D160, puede configurar la calidad de experiencia (AppQoE) específica de la aplicación para seleccionar la ruta de acceso de la aplicación en función de la prioridad del vínculo y el tipo de vínculo cuando haya varias rutas disponibles que cumplan los requisitos del SLA.

Puede seleccionar un vínculo MPLS o de Internet como la ruta preferida, asignar la prioridad entre 1 y 255 con un valor inferior que indica un vínculo más preferido. Un valor de uno (1) indica la prioridad más alta. Si hay varias rutas disponibles, se selecciona la ruta que tenga la prioridad más alta.

Por ejemplo, si se selecciona una ruta MPLS para el tráfico VoIP y se produce una degradación de la calidad durante una llamada debido a la fluctuación de fase o la pérdida de paquetes, los paquetes se envían a través de otra ruta (Internet) que cumple los requisitos del SLA. Ahora el tráfico de la aplicación se envía a través de la ruta de Internet y, si la calidad de la ruta de Internet se degrada, la ruta se vuelve a cambiar a MPLS.

Puede configurar la prioridad del vínculo y el tipo de vínculo de cada interfaz subyacente en una regla de enrutamiento avanzado basado en políticas (APBR), y la superposición correspondiente hereda los mismos parámetros. En este caso, una interfaz subyacente es la interfaz de salida final en la topología de enrutamiento para la superposición.

Por ejemplo, en una infraestructura de red, si la capa subyacente es una conexión LTE de cuarta generación (4G), la interfaz del marcador se puede configurar como la interfaz subyacente para AppQoE. Del mismo modo, si la capa subyacente es una conexión DSL, la interfaz correspondiente del protocolo punto a punto a través de Ethernet (PPPoE) se puede configurar como la interfaz subyacente para AppQoE.

A partir de Junos OS versión 21.2R1, el mecanismo de selección de ruta AppQoE se mejora con la configuración personalizada de etiquetas de vínculo, el cambio de tráfico de aplicaciones al vínculo de mayor prioridad de las etiquetas preferidas, la implementación basada en métricas que no son SLA y las funciones de preferencia de atributos de interfaz superpuesta.

Ventajas de la preferencia y prioridad de las rutas de acceso de la aplicación

  • Proporciona flexibilidad para seleccionar la mejor ruta para el tráfico de aplicaciones.

  • Permite el enrutamiento del tráfico de las aplicaciones a través de la opción de conectividad rentable, a la vez que garantiza el cumplimiento de los requisitos de SLA (latencia y fluctuación).

  • Admite la conmutación de ruta dinámica si la ruta de acceso de la aplicación seleccionada experimenta una degradación de la calidad.

Mecanismo de selección de ruta

El tráfico de la aplicación se enruta a través de vínculos independientes según la preferencia del vínculo de la siguiente manera:

  • El mecanismo de selección de ruta de AppQoE incluye una lista de las mejores rutas a un destino específico que cumple los requisitos del SLA. En esta lista, AppQoE selecciona una ruta que coincida con la preferencia de vínculo configurada por el usuario.

  • Si hay varias rutas de este tipo, se selecciona la ruta que tenga la prioridad más alta.

  • Si no hay ninguna prioridad o preferencia de tipo de vínculo configurada, se selecciona una ruta aleatoria o la ruta predeterminada.

  • Si no hay enlaces disponibles que cumplan con los requisitos de SLA, se selecciona el mejor enlace disponible en términos de la puntuación de SLA más alta y la preferencia de tipo de enlace, en caso de que se configure una afinidad estricta.

  • Si hay varios vínculos disponibles que cumplan los requisitos del SLA, se selecciona el que tenga la prioridad más alta.

Mensajes de registro del sistema para AppQoE

A partir de Junos OS versión 19.2R1, la compatibilidad con el registro a nivel de aplicación está disponible para AppQoE en dispositivos de la serie SRX. Esta característica se introdujo para reducir el impacto en CSO o dispositivo recopilador de registros mientras se procesa una gran cantidad de mensajes de registro del sistema generados a nivel de sesión. El dispositivo de seguridad mantiene la información de nivel de sesión y proporciona mensajes de registro del sistema para el nivel de sesión. Con el registro a nivel de aplicación reemplazando al registro a nivel de sesión, la sobrecarga en el dispositivo de seguridad disminuye y el rendimiento del registro AppQoE aumenta.

AppQoE envía los siguientes mensajes de registro del sistema:

  • APPQOE_SLA_METRIC_VIOLATION: Cuando se detecta una infracción en una sesión y cuando la ruta de una sesión se resuelve como resultado de pasar a un nuevo vínculo.

  • APPQOE_BEST_PATH_SELECTED: Cuando una sesión cambia la ruta de su tráfico de datos.

Con el registro a nivel de aplicación, todos los registros de nivel de sesión se admiten en el nivel de aplicación. La funcionalidad AppQoE de enviar sondeos en tiempo real, medir las métricas de SLA, detectar infracciones y cambiar de ruta continúa en el nivel de sesión. Sin embargo, como parte de la característica de resumen a nivel de aplicación, las sesiones de ruta de datos notifican las métricas de SLA, la información de infracción y el cambio de ruta a la base de datos AppQoE. La información así recibida de la ruta de datos se agrega a nivel de aplicación y luego se envía en forma de registros del sistema al dispositivo recopilador.

En la tabla 1 se proporcionan detalles de los nuevos registros a nivel de aplicación compatibles desde Junos OS versión 19.2R1 en adelante.

Tabla 1: Mensajes de registro a nivel de aplicación

Mensaje de registro del sistema

Descripción

APPQOE_APP_SLA_METRIC_VIOLATION

  • Este mensaje de registro del sistema se genera la primera vez que se infringe la aplicación.

  • Las métricas de SLA se miden para cada sesión de aplicación en la ruta de datos. Las métricas de infracción de SLA se siguen midiendo solo a nivel de sesión. Sin embargo, todas las sesiones de datos de esa aplicación envían las métricas o los datos relacionados con la infracción del SLA a la base de datos AppQoE cuando se infringe su SLA.

  • En el caso de CPE dual, el nodo que está activo para la aplicación genera el informe APPQOE_APP_SLA_METRIC_VIOLATION.

APPQOE_APP_BEST_PATH_SELECTED

  • Este mensaje de registro del sistema se genera cuando una aplicación pasa por un conmutador de ruta. Este informe de registro también se genera para borrar la infracción ocurrida debido a la autorreparación (cuando la infracción del SLA se borra por sí sola antes de cualquier cambio en el vínculo)

  • Para el registro a nivel de aplicación, una vez que una aplicación o un vínculo cambia a una ruta alternativa, AppQoE envía el mensaje de registro APPQOE_APP_BEST_PATH_SELECTED al dispositivo recopilador.

APPQOE_APP_PASSIVE_SLA_METRIC_REPORT

  • Este mensaje de registro del sistema se genera para los datos de métricas de SLA de sonda pasiva. Este mensaje se genera una vez que el número de muestras recogidas cumple con el factor de exportación SLA.

  • Con el soporte del registro a nivel de aplicación, cada sesión candidata a sondeo envía información a AppQoE, donde las métricas se agregan y promedian antes de enviarla al recopilador. Por lo tanto, el informe de SLA pasivo agregado a nivel de aplicación incluye los datos promediados de todas esas sesiones de datos de aplicación.

El registro en el nivel de aplicación introduce los siguientes cambios en la funcionalidad AppQoE:

  • La sonda activa mantiene y utiliza solo valores RTT y jitter en tiempo real. Para la pérdida de paquetes, se refiere a la causa de la sesión anterior porque la pérdida de paquetes solo se puede calcular al final de la ventana.

  • Durante la confirmación de configuración, la sonda activa establece los valores de RTT y fluctuación en el valor máximo de 32 bits para todas las entradas.

  • La sonda activa conserva los valores de la sesión anterior hasta que se disponga del valor adecuado en tiempo real de las métricas.

  • Cuando se experimenta una pérdida de paquetes del 100% en el sondeo activo, todas las demás métricas se establecen en el valor más alto de 32 bits.

Notificación de valores no válidos para RTT y jitter

Cuando los datos de RTT y Jitter no están disponibles, los mensajes de registro enviados con un valor no válido de 0xFFFFFFFF y el recopilador de registros puede ignorarlos. En la Tabla 2 se proporcionan algunos escenarios posibles en los que se envía el RTT y la fluctuación no válidos.

Tabla 2: Mensajes de registro a nivel de aplicación afectados por datos no válidos para RTT y jitter

Escenario

Registros del sistema afectados

100% de pérdida de paquetes:

APPQOE_APP_PASSIVE_SLA_METRIC_REPORT

APPQOE_APP_SLA_METRIC_VIOLATION

Pérdida de paquetes mayor que 0 e inferior al 100%:

APPQOE_APP_PASSIVE_SLA_METRIC_REPORT

APPQOE_APP_SLA_METRIC_VIOLATION

Sin pérdida de paquetes

APPQOE_APP_SLA_METRIC_VIOLATION

APPQOE_APP_PASSIVE_SLA_METRIC_REPORT

Deshabilitar el registro de AppQoE

De forma predeterminada, AppQoE, log-type se establece como registro del sistema. Si desea deshabilitar AppQoE, configure el tipo de registro como deshabilitado en la siguiente configuración:

  1. Deshabilitar el registro de AppQoE
  2. Habilitar el registro de AppQoE

Calidad de experiencia de la aplicación (AppQoE) basada en los bits DSCP del tráfico entrante

Para superar este escenario, a partir de Junos OS versión 19.4R1, AppQoE admite la selección de rutas basada en SLA para el tráfico entrante en función del valor DSCP. AppQoE selecciona el mejor vínculo posible para el tráfico de la aplicación en función de la firma de la aplicación o el valor DSCP o una combinación de identificación de la aplicación y valor DSCP. Ver

Compatibilidad con DSCP en APBR

Cuando se configura DSCP y la aplicación dinámica en una regla APBR, la regla se considera coincidente si el tráfico coincide con todos los criterios especificados en la regla. Cuando hay varios valores DSCP presentes en la regla APBR, si algún criterio coincide, se considera como coincidencia.

Un perfil APBR puede contener varias reglas, cada regla con una variedad de condiciones de coincidencia.

En el caso de varias reglas APBR en un perfil APBR, la búsqueda de reglas utiliza el siguiente orden de prioridad:

  1. Regla con DSCP + aplicación dinámica

  2. Regla con aplicación dinámica

  3. Regla con valor DSCP

Network Service Orchestrator puede asignar la aplicación al valor DSCP en la función de servicio externo y el mismo se aprovisiona en el enrutador de puerta de enlace para asignar el DSCP al perfil de SLA deseado.

La figura 1 muestra un escenario en el que AppQoE realiza una selección de ruta basada en SLA para el tráfico entrante en función del valor DSCP y la firma de la aplicación en un caso de uso de enrutador de puerta de enlace.

Figura 1: Selección de ruta para el tráfico según el valor DSCP y la aplicación Path Selection for the Traffic Based on DSCP Value and Application

Para el tráfico basado en el valor DSCP, AppQoE funciona de la siguiente manera:

  • Todo el tráfico que entra en el enrutador de puerta de enlace desde LAN se somete a la identificación de la aplicación. Hasta que DPI identifica una aplicación, el sistema reenvía el flujo de tráfico a una instancia predeterminada de enrutamiento y reenvío virtual (VRF). VRF incluye una interfaz de salida asociada a él.

  • La identificación de aplicaciones de Junos OS identifica las aplicaciones y, una vez identificadas las aplicaciones, su información se guarda en la caché del sistema de aplicaciones (ASC).

  • El sistema continúa verificando si hay información de aplicación disponible ya sea de clasificación DPI o ASC.

  • El mecanismo APBR clasifica las sesiones en función de firmas de aplicaciones conocidas y valores DSCP, y utiliza políticas para identificar la mejor ruta posible para la aplicación. La política APBR asigna el tráfico de la aplicación a un VRF específico.

  • La presencia de una regla de SLA en la configuración de APBR desencadena la funcionalidad AppQoE; AppQoE realiza una selección de ruta basada en SLA para el tráfico en función del valor de la aplicación o DSCP.

Un único DSCP incluye varias categorías de aplicaciones incluidas en él. Las diferentes categorías de aplicaciones tienen su patrón de tráfico individual. En tal escenario, la detección de la infracción mediante sondeos pasivos y su aplicación a todas las sesiones podría causar falsos negativos y falsos positivos. Como solución alternativa, evite el uso del sondeo pasivo cuando haya configurado la regla de SLA basada en DSCP. Puede utilizar sondeos activos para el grupo de rutas de destino al que se reenvía el tráfico.

Limitaciones

Las implementaciones de AppQoE con reglas basadas en DSCP en el modo de clúster de chasis del dispositivo tienen las siguientes limitaciones:

  • Si la coincidencia de reglas se completa antes de que se realice la identificación de la aplicación y AppQoE mueve la sesión al otro nodo, la identificación de la aplicación no se completa. Esta condición se produce cuando se configura la regla basada en DSCP.

  • Si ha configurado dos reglas APBR: 1) con valor DSCP 2) con DSCP y aplicación dinámica, y ha asignado un mismo valor DSCP en ambas reglas, al recibir el primer paquete, APBR coincide con la regla DSCP. En caso de que la mejor ruta se identifique en el otro nodo, la sesión se mueve al otro nodo. En este escenario, las sesiones de aplicación se comparan con la regla DSCP y no con la regla APP+DSCP.

Políticas de APBR para AppQoE

A partir de Junos OS versión 20.1R1, AppQoE utiliza la funcionalidad de coincidencia de reglas granulares proporcionada por APBR para proporcionar la calidad de experiencia (QoE) basada en el tráfico de la aplicación.

En Junos OS versión 18.2R1, APBR admitía la configuración de políticas mediante la definición de direcciones de origen, direcciones de destino y aplicaciones como condiciones de coincidencia. Después de una coincidencia correcta, el perfil APBR configurado se aplica como un servicio de aplicación para la sesión. En Junos OS versión 20.1R1, AppQoE aprovecha la mejora APBR y selecciona el mejor vínculo posible para el tráfico de aplicaciones enviado por APBR para cumplir con los requisitos de rendimiento especificados en el SLA.

Por ejemplo, desea reenviar el tráfico Telnet y HTTPS que llega a la zona de confianza a un dispositivo o interfaz específicos a través del mejor vínculo disponible. Cuando el tráfico llega a la zona de confianza, APBR hace coincidir el tráfico con los criterios coincidentes dirección de origen, dirección de destino y aplicaciones definidas en las políticas de APBR. Si el tráfico coincide con la política, se aplican los perfiles APBR correspondientes.

APBR utiliza los detalles de la aplicación para buscar una regla coincidente en el perfil. Si se encuentra una regla coincidente, el tráfico se redirige a la instancia de enrutamiento especificada tal como se define en la regla.

Multi-homing de AppQoE con despliegue activo-activo

A partir de la versión 20.2R1 de Junos OS, AppQoE se ha mejorado para admitir la multiconexión con despliegue activo-activo. Anteriormente, AppQoE admitía multihoming con despliegue en espera activa.

En la implementación activa-activa, el dispositivo radial se conecta a varios dispositivos concentrador. El tráfico de la aplicación puede transitar por cualquiera de los dispositivos de concentrador si el vínculo al dispositivo de concentrador cumple los requisitos de SLA. El tráfico de aplicaciones puede cambiar sin problemas entre los dispositivos del concentrador en caso de infracción del SLA o de que el dispositivo del concentrador activo no responda

La figura 1 muestra una topología de malla. En esta topología, se puede acceder a un punto de conexión a través de más de un nodo.

Figura 2: Una topología A Sample Mesh Topology de malla de ejemplo

Para habilitar la multiconexión en modo activo-activo, debe configurar la ruta múltiple del BGP para permitir que el dispositivo seleccione varias rutas BGP de igual costo para llegar a un destino determinado.

Cuando se habilita la multiruta BGP, el dispositivo selecciona varias rutas BGP de igual costo para llegar a un destino determinado, y todas estas rutas se instalan en la tabla de reenvío. AppQoE completa la búsqueda de ruta y obtiene los detalles de la ruta del próximo salto junto con los enlaces de superposición correspondientes. AppQoE obtiene la propiedad overlay-link del grupo de ruta de destino configurado.

En función de los requisitos de SLA y las preferencias de vínculos de la aplicación, AppQoE determina el mejor vínculo entre todos los vínculos de ese grupo de ruta de destino. En caso de infracción del SLA, en función de la puntuación del SLA y las preferencias de vínculos, AppQoE selecciona vínculos alternativos en todos los grupos de rutas de destino configurados si se puede acceder al punto final a través de esos vínculos.

Para obtener más información sobre la configuración de múltiples rutas de BGP, consulte Ejemplos: configuración de múltiples rutas de BGP.

Limitación

En determinadas situaciones, cuando cambia el ID del próximo salto para la ruta, las sesiones existentes permanecen en el vínculo infringido por el SLA aunque haya otro vínculo disponible que cumpla los requisitos del SLA. Sin embargo, las nuevas sesiones no se ven afectadas en este caso y se enrutan a través de los vínculos que cumplen los requisitos de SLA.

Soporte para aplicaciones SaaS

A partir de Junos OS versión 20.4R1, hemos ampliado la compatibilidad con la calidad de experiencia de las aplicaciones (AppQoE) para aplicaciones de software como servicio (SaaS).

AppQoE realiza mediciones de acuerdo de nivel de servicio (SLA) en los vínculos WAN disponibles, como subyacente, GRE, IPsec o MPLS sobre GRE. A continuación, envía los datos de la aplicación SaaS a través del vínculo más compatible con los SLA para proporcionar un servicio coherente.

Compatibilidad con tráfico IPv6

  • A partir de Junos OS versión 21.3R1, puede utilizar direcciones IPv6 en configuraciones de AppQoE. El soporte incluye:

    • Dirección IPv6 en configuración de ruta superpuesta
    • Sesiones de sondeo activas que utilizan direcciones IPv6 como dirección de origen y destino.
    • Tráfico IPv4 e IPv6 desde el lado del cliente
    • Apilamiento dual de IPv4 e IPv6 en el lado LAN
    • Dirección IPv6 en el lado LAN para sondeo SaaS (software como servicio).

      Para el sondeo de SaaS, asegúrese de configurar las direcciones IPv4 e IPv6 para la interfaz entrante para la interoperabilidad IPv4 e IPv6.

  • A partir de Junos OS versión 21.4R1, puede usar el apilamiento dual de IPv4 e IPv6 para redes superpuestas y subyacentes en una configuración AppQoE.

Documentación relacionada

Tabla de historial de versiones
Lanzamiento
Descripción
19.4R1
A partir de Junos OS versión 19.4R1, AppQoE admite la selección de ruta basada en SLA para el tráfico entrante en función del valor DSCP
19.2R1
A partir de Junos OS versión 19.2R1, la compatibilidad con el registro a nivel de aplicación está disponible para AppQoE en dispositivos de la serie SRX.
19.1R1
A partir de Junos OS versión 15.1X49-D160 y en Junos OS 19.1R1, AppQoE es compatible con SRX4100 y SRX4200 dispositivo cuando el dispositivo funciona en modo de clúster de chasis
19.1R1
A partir de Junos OS versión 15.1X49-D160 y en Junos OS versión 19.1R1, AppQoE aplica el límite de configuración para rutas superpuestas, perfiles de métrica, parámetros de sondeo y reglas de SLA por perfil cuando se configuran reglas de SLA específicas de la aplicación y asocia las reglas de SLA a un perfil APBR.