Qualidade da experiência do aplicativo
Qualidade de experiência de aplicativos (AppQoE)
- Introdução à qualidade da experiência do aplicativo
- Benefícios da qualidade da experiência do aplicativo
- Limitações
- Como funciona a qualidade da experiência do aplicativo?
- Como a qualidade da experiência do aplicativo mede o desempenho do aplicativo
- Comutação do tráfego de aplicativos para um caminho alternativo
Introdução à qualidade da experiência do aplicativo
O crescimento implacável da computação em nuvem, da mobilidade e dos aplicativos baseados na Web exige que a rede identifique e controle o tráfego no nível do aplicativo e manipule cada tipo de aplicativo separadamente para oferecer qualidade de experiência (QoE) aos usuários. Para garantir a QoE específica do aplicativo (AppQoE), você precisa priorizar, segregar e rotear efetivamente o tráfego do aplicativo sem comprometer o desempenho ou a disponibilidade.
O AppQoE utiliza (ou emprega) os recursos de dois serviços de segurança de aplicativos - identificação de aplicativos (AppID) e roteamento avançado baseado em políticas (APBR). Ele usa o AppID para identificar aplicativos específicos em sua rede e o roteamento avançado baseado em políticas (APBR) para especificar um caminho para determinado tráfego associando perfis de SLA a uma instância de roteamento na qual o tráfego do aplicativo é enviado de acordo com as regras do APBR.
Um dos requisitos importantes de uma WAN definida por software (SD-WAN) é medir a qualidade dos caminhos de rede subjacentes e, com base nos resultados, determinar os melhores caminhos a serem usados para a entrega de cada pacote. O AppQoE monitora o desempenho de aplicativos críticos para os negócios e, com base na pontuação, seleciona o melhor link possível para o tráfego desse aplicativo, a fim de atender aos requisitos de desempenho especificados como SLA (acordo de nível de serviço).
A presença de uma regra de SLA na configuração do APBR aciona a funcionalidade AppQoE; Se não houver perfis de SLA disponíveis, o APBR funciona sem acionar o AppQoE.
Caso de uso suportado
Você pode configurar o AppQoE de forma otimizada usando o Contrail Service Orchestration (CSO). Recomendamos que você use o CSO para configurar o AppQoE para a solução Contrail SD-WAN da Juniper Networks. Para obter mais detalhes, consulte Visão geral da qualidade da experiência do aplicativo e Configurar e monitorar a qualidade da experiência do aplicativo.
Opções de configuração suportadas
O AppQoE é suportado em topologias hub-and-spoke e full mesh em implantações de SD-WAN.
Você pode configurar um AppQoE entre dois endpoints de firewall do Junos OS (book-ended), e ambos os firewalls devem ter a mesma versão da imagem do Junos OS.
Benefícios da qualidade da experiência do aplicativo
-
Permite uma QoE econômica, fornecendo monitoramento em tempo real do tráfego de aplicativos para fornecer um nível de serviço consistente e previsível.
-
Aumenta a retenção e a satisfação do cliente, fornecendo um SLA garantido para a entrega de determinado tráfego (como o tráfego de vídeo). O AppQoE garante que o tráfego aprovado receba a prioridade apropriada e a largura de banda necessária para garantir a melhor qualidade de experiência para o usuário.
Limitações
A implementação do AppQoE em dispositivos de segurança tem as seguintes limitações:
-
Todas as diferentes rotas para o destino por diferentes interfaces devem ter a mesma preferência, o mesmo peso e as mesmas métricas configuradas. Todas as rotas devem ser adicionadas como caminhos ECMP para o destino e também devem fazer parte da mesma tabela de encaminhamento.
-
O serviço AppQoE SLA somente entre dois endpoints de dispositivos de segurança (book-ended) são suportados. O serviço de SLA AppQoE de ponta a ponta não é suportado.
-
O AppQoE só pode ser aplicado se todas as interfaces fizerem parte da mesma zona.
-
AppQoE não pode ser aplicado para tráfego reverso.
-
O AppQoE não influencia na mudança no destino de uma sessão.
-
O AppQoE não oferece suporte ao encapsulamento de sondagem IPv6/UDP, GRES, cluster de chassi (ISSU, alta disponibilidade, alta disponibilidade de CPE duplo, alta disponibilidade de modo Z) e sistemas lógicos.
-
O AppQoE não oferece suporte à seleção de caminho preferencial e ao roteamento e encaminhamento virtual de trânsito (VRF).
-
O AppQoE não oferece suporte à sondagem passiva em pacotes de dados IPv6.
-
Um filtro de firewall de entrada é necessário nas interfaces não-WAN para descartar pacotes UDP com a porta de destino UDP 36000.
Como funciona a qualidade da experiência do aplicativo?
O AppQoE utiliza os recursos AppID e APBR para identificar aplicativos/grupos de aplicativos específicos e especificar um caminho para determinado tráfego, associando perfis de SLA a uma instância de roteamento na qual o tráfego do aplicativo é enviado de acordo com as regras do APBR.
O AppQoE monitora o desempenho dos aplicativos e, com base na pontuação, seleciona o melhor link possível para o tráfego desse aplicativo, a fim de atender aos requisitos de desempenho especificados como SLA (acordo de nível de serviço).
- Identificando aplicativos ou grupos de aplicativos
- Especificando o caminho para aplicativos ou grupos de aplicativos
- Seleção de caminho de tráfego do aplicativo
Identificando aplicativos ou grupos de aplicativos
As etapas a seguir estão envolvidas na identificação de aplicativos ou grupos de aplicativos:
-
A identificação de aplicativos do Junos OS identifica aplicativos e, uma vez que um aplicativo é identificado, suas informações são salvas no cache do sistema de aplicativos (ASC).
-
O APBR avalia os pacotes com base para determinar se a sessão é candidata ao roteamento baseado em aplicativos (roteamento avançado baseado em políticas). Se este for o primeiro pacote da nova sessão e o tráfego não for sinalizado para roteamento baseado em aplicativo, ele passará por processamento normal (rota não APBR) para o destino.
-
Se a sessão precisar de roteamento baseado em aplicação, o APBR consulta o módulo ASC para obter os atributos da aplicação (endereço IP, porta de destino, tipo de protocolo e serviço).
-
Se o aplicativo no ASC for encontrado, o tráfego será processado ainda mais para uma regra de correspondência no perfil APBR.
-
Se uma regra de correspondência for encontrada, o tráfego será redirecionado para a instância de roteamento especificada para a pesquisa de rota.
-
O AppQoE verifica se um SLA está habilitado para uma sessão. Se a sessão for candidata a uma medição de SLA, o AppQoE iniciará sondas ativas e passivas para medições de desempenho.
-
Se o SLA não estiver habilitado para a sessão na regra APBR, o AppQoE ignorará essa sessão e o comportamento padrão do APBR será aplicado a essas sessões, ou seja, o tráfego será roteado por meio da instância de roteamento especificada para o destino.
-
-
Caso a aplicação não seja encontrada no ASC, a APBR solicita uma inspeção profunda do fluxo. Ou seja, o pacote de assinatura do aplicativo é instalado e a identificação do aplicativo para a sessão é habilitada, para que o ASC possa ser preenchido para uso por sessões subsequentes para processamento de APBR (consulte a etapa 2).
-
Especificando o caminho para aplicativos ou grupos de aplicativos
As etapas a seguir resumem como o AppQoE especifica um caminho para o tráfego do aplicativo de acordo com as regras do SLA.
-
O APBR usa os detalhes do aplicativo para procurar uma regra de correspondência no perfil APBR (perfil do aplicativo). O tráfego que corresponde aos aplicativos e grupos de aplicativos é encaminhado para a rota estática e o endereço do próximo salto, conforme especificado na instância de roteamento.
-
Uma regra de SLA anexada ao perfil APBR especifica parâmetros necessários para medir o SLA e identificar se ocorreu alguma violação de SLA ou não.
-
O tráfego de aplicativos é atribuído a um link de sobreposição específico com base nas métricas de SLA desse link de sobreposição medidas usando sondagem ativa.
-
A violação do SLA é determinada por meio da sondagem passiva do tráfego de aplicativos/grupo de aplicativos ao vivo. O melhor link de caminho/sobreposição para o aplicativo/grupo de aplicativos é determinado por meio do algoritmo de seleção de caminho.
Seleção de caminho de tráfego do aplicativo
As etapas a seguir são executadas para rotear o tráfego de dados da origem para o destino, especificamente, para selecionar o melhor caminho,
-
Para o primeiro pacote de dados de um fluxo (primeiro caminho), se o aplicativo já for conhecido (da pesquisa do ASC), o melhor caminho para o aplicativo será pesquisado no banco de dados. Se o aplicativo não for conhecido ou for novo (da pesquisa do ASC), um caminho aleatório ou o caminho padrão será escolhido. Esse caminho continua por toda a sessão. Posteriormente, depois que o aplicativo é detectado pelo DPI, o banco de dados é atualizado com o melhor caminho para o aplicativo.
-
Para o pacote de dados restante de um fluxo (caminho rápido), se o aplicativo não for conhecido inicialmente, a sessão específica continuará no mesmo caminho. Se o aplicativo for conhecido inicialmente, o AppQoE selecionará o melhor caminho para o tráfego do aplicativo.
Quando um novo aplicativo é detectado, o mecanismo de seleção de caminho tenta encontrar um caminho que satisfaça todas as métricas de SLA. Se esse caminho não existir, o próximo melhor caminho (com base no número de métricas atendidas) será usado. Se houver mais de um caminho que atenda às métricas, um caminho aleatório entre os caminhos disponíveis será selecionado. A violação de SLA é detectada quando qualquer uma das métricas é violada ou nenhuma das métricas atende ao requisito, com base na configuração do perfil.
Como a qualidade da experiência do aplicativo mede o desempenho do aplicativo
O desempenho do aplicativo é determinado pelos seguintes indicadores:
-
Latência — A quantidade de tempo fisicamente necessária para a mídia viajar, dependendo do comprimento e da distância da mídia que precisa ser coberta
-
RTT— Um tempo de ida e volta necessário para viajar da origem ao destino e vice-versa.
-
Perda de pacotes — A perda de pacotes reflete o número de pacotes perdidos por 100 pacotes enviados por um host.
-
Jitter — Jitter é a diferença na latência de pacote para pacote. O jitter de entrada, o jitter de saída e o jitter bidirecional podem ser especificados para avaliar o desempenho do link.
O AppQoE monitora RTT, jitter e perda de pacotes em cada link e, com base na pontuação, desvia perfeitamente os aplicativos para o caminho alternativo se o desempenho do link principal estiver abaixo dos níveis aceitáveis, conforme especificado pelo SLA. A medição e o monitoramento do desempenho do aplicativo são feitos usando sondas ativas e passivas para detectar violações de SLA e selecionar um caminho alternativo para esse aplicativo específico.
O AppQoE coleta dados em tempo real, monitorando continuamente o tráfego do aplicativo e identificando problemas de rede ou dispositivo:
-
Monitoramento do desempenho em todos os links de sobreposição configurados.
-
Usar sondas passivas (em linha com o caminho de dados do aplicativo) e sondas ativas (sondas sintéticas para um aplicativo específico) para monitorar o desempenho do tráfego para o aplicativo ou grupo de aplicativos.
-
Enviar todas as métricas de desempenho ou metadados coletados para análise a um coletor de logs.
-
Comparar o aplicativo especificado com uma métrica de desempenho específica e alterar o caminho do tráfego do aplicativo dinamicamente em caso de violação de SLA.
-
Suporte à configuração flexível de métricas de SLA para um determinado aplicativo ou grupo de aplicativos.
O AppQoE mede o SLA do aplicativo em vários links de WAN e mapeia o tráfego do aplicativo para um caminho entre os links disponíveis, ou seja, para o caminho que melhor atende ao requisito do SLA.
Medição do desempenho de aplicativos usando sondas ativas e passivas
As medições de sonda ativa e passiva são as duas abordagens usadas para análise de ponta a ponta da rede.
-
Sondagem ativa — as sondas ativas medem a qualidade do serviço do aplicativo para fornecer uma medição de ponta a ponta do desempenho da rede.
Na sondagem ativa, os pacotes personalizados são enviados entre os pontos spoke e hub em todas as várias rotas e o RTT, latência, jitter e perda de pacotes são medidos entre os pontos de sondagem instalados. As sondas ativas são enviadas periodicamente em todos os links ativos e passivos. Um número configurado de amostras é coletado e uma média de execução para o caminho de sondagem de cada um desses aplicativos é medida. Se uma violação for detectada em qualquer tráfego de aplicativo, as métricas da sondagem serão avaliadas para determinar o melhor link que atenda ao SLA.
-
Sonda passiva — as sondas passivas são instaladas em links dentro da rede e as sondas monitoram todo o tráfego que flui por esses links.
A sondagem passiva monitora os links em busca de violações de SLA no tráfego de dados em tempo real. Em uma sondagem passiva, os pacotes de dados reais são encapsulados em um cabeçalho de sondagem IP/UDP no tráfego ao vivo entre os pontos finalizados do dispositivo. A sondagem mede o RTT, o jitter e a perda de pacotes entre os pontos de instalação das sondas para calcular a qualidade do serviço.
Se uma violação for detectada para qualquer aplicativo, as métricas de sondagem sintética serão avaliadas para determinar o melhor link que atenda ao SLA.
Observação:Para detectar se um link ou caminho está inativo por sondas passivas, um mínimo de três solicitações de sondagem e 100% de perda de pacotes devem ocorrer em um período de amostragem para uma determinada sessão para desencadear a violação do SLA.
Observação:Quando o dispositivo está operando no modo de cluster de chassi, se o nó secundário (nó 1), através do qual o tráfego é encaminhado, é reinicializado, ocorre uma comutação múltipla do tráfego do aplicativo entre os links através de links de nó secundário. Isso acontece quando os links disponíveis no nó primário (nó 0) estão tendo menos pontuação de caminho de SLA de sondagem ativa em comparação com os links de nó secundário. Esse comportamento continua até que os resultados da pontuação do caminho do SLA de sonda ativa do AppQoE estejam disponíveis para indicar que há 100% de perda de pacotes em todos os links no nó secundário.
Você pode configurar uma regra de SLA com parâmetros de sondagem ativos e passivos e associar a regra de SLA ao perfil APBR. O perfil APBR também inclui uma regra APBR. As regras estão associadas a um ou mais de um aplicativo ou grupos de aplicativos e o tráfego correspondente à regra é redirecionado para a instância de roteamento
O AppQoE aciona as solicitações de sondagem para todos os caminhos de sondagem do aplicativo. Sondagens ativas e passivas monitoram a rede em busca de áreas ou pontos de falhas ou congestionamento.
O AppQoE coleta estatísticas de classe de tráfego para aplicativos aprendidos usando sondas ativas e passivas e executa as seguintes ações:
-
Medir o desempenho do SLA — as métricas em tempo real fornecidas pelas sondas são usadas para pontuar a qualidade do serviço de acordo com o SLA de um aplicativo e determinar se o caminho do aplicativo não atende aos requisitos do SLA. Ou seja, se houver uma violação detectada para qualquer aplicativo, as métricas de sondagem sintética serão avaliadas para determinar o melhor link alternativo para o tráfego de aplicativos que atenda ao SLA.
-
Redirecionar tráfego — alterne o tráfego da aplicação entre os dois links, ou seja, quando um link tem problemas de desempenho, o tráfego é roteado para o outro link durante a mesma sessão.
Se o tráfego do aplicativo puder ser alcançado por meio de vários links, você deverá configurar todos os caminhos alcançáveis como caminhos de sobreposição e anexar os caminhos de sobreposição à regra de SLA do aplicativo.
Comutação do tráfego de aplicativos para um caminho alternativo
Você pode habilitar ou desabilitar a comutação do tráfego do aplicativo para outra rota (local para o dispositivo) durante uma violação de SLA. Quando a comutação de rota local está habilitada, a comutação do tráfego do aplicativo para uma rota alternativa é habilitada e a funcionalidade de monitoramento e relatório de SLA também está disponível. Mesmo quando a opção de comutação do tráfego do aplicativo para um caminho alternativo está desabilitada na configuração da regra de SLA, o AppQoE resolve violações de SLA, por exemplo, alternando o tráfego do aplicativo para um novo caminho.
Quando a comutação de rota local é desativada, apenas a funcionalidade de monitoramento e relatório de SLA está disponível e a comutação do tráfego do aplicativo para a rota diferente devido a uma violação de SLA é desativada.
Quando um tráfego de aplicativo muda para um caminho alternativo, haverá um curto período de tempo durante o qual o tráfego do aplicativo não pode ser comutado novamente para outro caminho em caso de violação de SLA. Esse período ajuda a evitar o flapping do tráfego entre os links.
Entendendo os limites de configuração do AppQoE
O AppQoE aplica o limite de configuração para caminhos de overlay, perfis de métricas, parâmetros de sondagem e regras de SLA por perfil quando você configura regras de SLA específicas do aplicativo e associa as regras de SLA a um perfil APBR.
Se você configurar os parâmetros mais do que o limite permitido, mensagens de erro serão exibidas quando você confirmar a configuração.
Exemplos de mensagens de erro:
O valor do limite de configuração pode não refletir o número exato com suporte; Os números podem diferir entre os dispositivos suportados
[edit security advance-policy-based-routing]
'sla-rule sla0'
Cannot configure more than 32 sla rules
error: configuration check-out failed
[edit security advance-policy-based-routing]
'overlay-path grep2'
Cannot configure more than 2000 overlay paths
error: configuration check-out failed
[edit security advance-policy-based-routing]
'metrics-profile m0'
Max metrics for this system is 32
error: configuration check-out failed
[edit security advance-policy-based-routing]
'active-probe-params pr0'
Cannot configure more than 64 probe params
error: configuration check-out failed
Seleção do caminho do aplicativo com base na preferência e prioridade do link
Um dos requisitos importantes de uma WAN definida por software (SD-WAN) é medir a qualidade dos caminhos de rede subjacentes e, com base nos resultados, determinar os melhores caminhos a serem usados para a entrega de cada pacote.
Você pode configurar a qualidade de experiência específica do aplicativo (AppQoE) para selecionar o caminho do aplicativo com base na prioridade e no tipo de link quando vários caminhos que atendem aos requisitos do SLA estiverem disponíveis.
Você pode selecionar um link MPLS ou Internet como o caminho preferencial, atribuir a prioridade entre 1 e 255 com um valor mais baixo indicando um link mais preferencial. Um valor de um (1) indica a prioridade mais alta. Quando vários caminhos estão disponíveis, aquele com a prioridade mais alta é escolhido.
Por exemplo, se um caminho MPLS for selecionado para tráfego VoIP e a degradação da qualidade ocorrer durante uma chamada devido a jitter ou perda de pacotes, os pacotes serão enviados por outro caminho (Internet) que atenda aos requisitos do SLA. Agora, o tráfego do aplicativo é enviado pelo caminho da Internet e, se a qualidade do caminho da Internet for degradada, o caminho será alternado de volta para o MPLS.
Você pode configurar a prioridade e o tipo de link de cada interface subjacente em uma regra de roteamento avançado baseado em políticas (APBR), e os mesmos parâmetros são herdados pela sobreposição correspondente. Uma interface underlay, nesse caso, é a interface de saída final na topologia de roteamento para a sobreposição.
Por exemplo, em uma infraestrutura de rede, se a underlay for uma conexão LTE de quarta geração (4G), a interface do discador poderá ser configurada como a interface underlay para AppQoE. Da mesma forma, se a underlay for uma conexão DSL, a interface Point-to-Point Protocol over Ethernet (PPPoE) correspondente pode ser configurada como a interface underlay para AppQoE.
O mecanismo de seleção de caminho do AppQoE é aprimorado com configuração de tag de link personalizada, switch de tráfego de aplicativo para o link de prioridade mais alta das tags preferenciais, implantação baseada em métricas não SLA e recursos de preferência de atributo de interface overlay.
Benefícios da preferência e prioridade do caminho do aplicativo
-
Fornece flexibilidade para selecionar o melhor caminho para o tráfego de aplicativos.
-
Permite o roteamento do tráfego de aplicativos pela opção de conectividade econômica, garantindo que os requisitos de SLA (latência e jitter) sejam atendidos.
-
Oferece suporte à comutação dinâmica de caminho se o caminho do aplicativo selecionado sofrer uma degradação na qualidade.
Mecanismo de seleção de caminho
O tráfego do aplicativo é roteado por links separados com base na preferência de link da seguinte forma:
-
O mecanismo de seleção de caminho do AppQoE inclui uma lista dos melhores caminhos para um destino específico que atenda aos requisitos do SLA. Nessa lista, o AppQoE seleciona um caminho que corresponde à preferência de link configurada pelo usuário.
-
Se vários desses caminhos estiverem disponíveis, o caminho que tem a prioridade mais alta entre todos os caminhos será selecionado.
-
Se nenhuma prioridade ou preferência de tipo de link estiver configurada, um caminho aleatório ou o caminho padrão será selecionado.
-
Se nenhum link que atenda aos requisitos de SLA estiver disponível, o melhor link disponível em termos de pontuação de SLA mais alta e preferência de tipo de link, caso a afinidade estrita esteja configurada, será selecionado.
-
Se vários links que atendem aos requisitos do SLA estiverem disponíveis, aquele com a prioridade mais alta será selecionado.
Para obter um exemplo de configuração, consulte Configurar o link da WAN com o backup LTE no modo ativo/ativo.
Mensagens de log do sistema para AppQoE
O registro no nível do aplicativo é introduzido para reduzir o impacto no CSO ou no dispositivo coletor de logs durante o processamento de um grande número de mensagens de log do sistema geradas no nível da sessão. O dispositivo de segurança mantém informações no nível da sessão e fornece mensagens de log do sistema para o nível da sessão. Com o registro no nível do aplicativo substituindo o registro no nível da sessão, a sobrecarga no dispositivo de segurança diminui e a taxa de taxa de transferência do log do AppQoE aumenta.
O AppQoE envia as seguintes mensagens de log do sistema:
-
APPQOE_SLA_METRIC_VIOLATION: Quando uma violação é detectada para uma sessão e quando o caminho de uma sessão é resolvido como resultado da mudança para um novo link.
-
APPQOE_BEST_PATH_SELECTED: Quando uma sessão alterna o caminho para seu tráfego de dados.
Com o log no nível do aplicativo, todos os logs no nível da sessão têm suporte no nível do aplicativo. A funcionalidade AppQoE de enviar sondas em tempo real, medir as métricas de SLA, detecção de violações e troca de caminho continua no nível da sessão. No entanto, como parte do recurso de resumo no nível do aplicativo, as sessões de caminho de dados notificam as métricas de SLA, as informações de violação e a mudança de caminho para o banco de dados AppQoE. As informações assim recebidas do datapath são agregadas no nível do aplicativo e, em seguida, enviadas na forma de logs do sistema para o dispositivo coletor.
A Tabela 1 fornece detalhes sobre os novos logs no nível do aplicativo que são suportados.
| Mensagem de log do sistema |
Descrição |
|---|---|
| APPQOE_APP_SLA_METRIC_VIOLATION |
|
| APPQOE_APP_BEST_PATH_SELECTED |
|
| APPQOE_APP_PASSIVE_SLA_METRIC_REPORT |
|
O registro no nível do aplicativo introduz as seguintes alterações na funcionalidade do AppQoE:
-
A sonda ativa mantém e usa apenas valores RTT e jitter em tempo real. Para perda de pacotes, refere-se à causa da sessão anterior porque a perda de pacotes pode ser calculada apenas no final da janela.
-
Durante a confirmação da configuração, a sonda ativa define os valores de RTT e jitter para o valor mais alto de 32 bits para todas as entradas.
-
A sonda ativa retém os valores da sessão anterior até que um valor adequado em tempo real das métricas esteja disponível.
-
Quando uma perda de pacote de 100% é experimentada na sondagem ativa, todas as outras métricas são definidas como o valor mais alto de 32 bits.
Relatório de valores inválidos para RTT e jitter
Quando os dados de RTT e Jitter não estão disponíveis, as mensagens de log enviadas com um valor inválido de 0xFFFFFFFF e podem ser ignoradas pelo coletor de logs. A Tabela 2 fornece alguns cenários possíveis quando o RTT e o Jitter inválidos são enviados.
| Cenário |
Logs do sistema afetados |
|---|---|
| 100% de perda de pacotes: |
APPQOE_APP_PASSIVE_SLA_METRIC_REPORT APPQOE_APP_SLA_METRIC_VIOLATION |
| Perda de pacotes maior que 0 e menor que 100%: |
APPQOE_APP_PASSIVE_SLA_METRIC_REPORT APPQOE_APP_SLA_METRIC_VIOLATION |
| Sem perda de pacotes |
APPQOE_APP_SLA_METRIC_VIOLATION APPQOE_APP_PASSIVE_SLA_METRIC_REPORT |
Desativar o registro do AppQoE
Por padrão, o tipo de log do AppQoE é definido como log do sistema. Se você quiser desabilitar o AppQoE, configure o tipo de log como desabilitado na seguinte configuração:
Qualidade da experiência de aplicativos (AppQoE) com base nos bits DSCP do tráfego de entrada
O AppQoE oferece suporte à seleção de caminho baseada em SLA para o tráfego de entrada com base no valor do DSCP. O AppQoE seleciona o melhor link possível para o tráfego do aplicativo com base na assinatura do aplicativo ou no valor de DSCP ou na combinação de identificação do aplicativo e valor de DSCP.
Suporte a DSCP em APBR
Quando você configura o DSCP e o aplicativo dinâmico em uma regra APBR, a regra é considerada como correspondência se o tráfego corresponder a todos os critérios especificados na regra. Quando há vários valores de DSCP presentes na regra APBR, se qualquer um dos critérios corresponder, ele será considerado como correspondência.
Um perfil APBR pode conter várias regras, cada regra com uma variedade de condições de correspondência.
No caso de várias regras APBR em um perfil APBR, a pesquisa de regra usa a seguinte ordem de prioridade:
-
Regra com DSCP + aplicação dinâmica
-
Regra com aplicação dinâmica
-
Regra com valor de DSCP
O Network Service Orchestrator pode mapear a aplicação para o valor de DSCP na função de serviço externo e o mesmo é aprovisionado no roteador de gateway para mapear o DSCP para o perfil SLA pretendido.
A Figura 1 mostra um cenário em que o AppQoE executa a seleção de caminho com base em SLA para o tráfego de entrada com base no valor de DSCP e na assinatura do aplicativo em um caso de uso de roteador de gateway.
Para o tráfego baseado no valor de DSCP, o AppQoE funciona da seguinte maneira:
-
Todo o tráfego que entra no roteador gateway a partir da LAN passa pela identificação do aplicativo. Até que o DPI identifique um aplicativo, o sistema encaminha o fluxo de tráfego para uma instância padrão de roteamento e encaminhamento virtual (VRF). O VRF inclui uma interface de saída associada.
-
A identificação de aplicativos do Junos OS identifica aplicativos e, uma vez que um aplicativo é identificado, suas informações são salvas no cache do sistema de aplicativos (ASC).
-
O sistema continua a verificar se alguma informação do aplicativo está disponível na classificação de DPI ou ASC.
-
O mecanismo APBR classifica sessões com base em assinaturas de aplicativos bem conhecidos e valores de DSCP e usa políticas para identificar a melhor rota possível para o aplicativo. A política APBR mapeia o tráfego do aplicativo para um VRF específico.
-
A presença de uma regra de SLA na configuração do APBR aciona a funcionalidade AppQoE; O AppQoE executa a seleção de caminho com base em SLA para o tráfego com base no valor do aplicativo ou DSCP.
Um único DSCP inclui várias categorias de aplicativos agrupadas nele. Diferentes categorias de aplicativos têm seu padrão de tráfego individual. Nesse cenário, a detecção de violação usando sondas passivas e aplicando-a a todas as sessões pode causar falso negativo e falso positivo. Como solução alternativa, evite usar a sondagem passiva quando tiver configurado a regra de SLA baseada em DSCP. Você pode usar sondas ativas para o grupo de caminhos de destino para o qual o tráfego é encaminhado.
Limitações
As implantações do AppQoE com regras baseadas em DSCP no modo de cluster de chassi do dispositivo têm as seguintes limitações:
-
Se a correspondência de regra for concluída antes que a identificação do aplicativo seja concluída e o AppQoE mover a sessão para o outro nó, a identificação do aplicativo não será concluída. Essa condição ocorre quando a regra baseada em DSCP é configurada.
-
Se você configurou duas regras APBR — 1) com valor DSCP 2) com DSCP e aplicativo dinâmico, e atribuiu um mesmo valor DSCP em ambas as regras, ao receber o primeiro pacote, o APBR corresponde à regra DSCP. Caso o melhor caminho seja identificado no outro nó, a sessão será movida para o outro nó. Nesse cenário, as sessões do aplicativo são comparadas com a regra DSCP e não com a regra APP+DSCP.
Políticas de APBR para AppQoE
O AppQoE aproveita o aprimoramento do APBR e seleciona o melhor link possível para o tráfego de aplicativos enviado pelo APBR para atender aos requisitos de desempenho especificados no SLA. O AppQoE utiliza a funcionalidade de correspondência de regras granulares fornecida pelo APBR para fornecer a qualidade da experiência (QoE) com base no tráfego do aplicativo.
Por exemplo, você deseja encaminhar o tráfego Telnet e HTTPS que chega à zona de confiança para um dispositivo ou interface específica por meio de um melhor link disponível. Quando o tráfego chega à zona de confiança, o APBR combina o tráfego com os critérios de correspondência endereço de origem, endereço de destino e aplicativos definidos nas políticas de APBR. Se o tráfego corresponder à política, os perfis APBR correspondentes serão aplicados.
O APBR usa os detalhes do aplicativo para procurar uma regra correspondente no perfil. Se uma regra de correspondência for encontrada, o tráfego será redirecionado para a instância de roteamento especificada, conforme definido na regra.
Multihoming AppQoE com implantação ativa-ativa
O AppQoE foi aprimorado para oferecer suporte a multihoming com implantação ativa-ativa. Anteriormente, o AppQoE suportava multihoming com implantação de espera ativa.
Na implantação ativa-ativa, o dispositivo spoke se conecta a vários dispositivos de hub. O tráfego do aplicativo pode transitar por qualquer um dos dispositivos de hub se o link para o dispositivo de hub atender aos requisitos de SLA. O tráfego do aplicativo pode alternar perfeitamente entre os dispositivos de hub em caso de violação de SLA ou o dispositivo de hub ativo não está respondendo
A Figura 1 mostra uma topologia de malha. Nessa topologia, um ponto final pode ser alcançado por meio de mais de um nó.
de malha
Para habilitar o multihoming no modo ativo-ativo, você deve configurar o BGP multipath para permitir que o dispositivo selecione vários caminhos BGP de custo igual para alcançar um determinado destino.
Quando você habilita o BGP multipath, o dispositivo seleciona vários caminhos BGP de custo igual para alcançar um determinado destino, e todos esses caminhos são instalados na tabela de encaminhamento. O AppQoE conclui a pesquisa de rota e obtém os detalhes da rota do próximo salto junto com os links de sobreposição correspondentes. O AppQoE obtém a propriedade overlay-link do grupo de caminhos de destino configurado.
Com base nos requisitos de SLA do aplicativo e nas preferências de link, o AppQoE determina o melhor link entre todos os links nesse grupo de caminho de destino. Em caso de violação do SLA, com base na pontuação do SLA e nas preferências do link, o AppQoE seleciona links alternativos em todo o grupo de caminhos de destino configurado se o ponto final puder ser alcançado por meio desses links.
Para obter mais informações sobre a configuração do BGP multipath, consulte Exemplos: Configuração do BGP Multipath.
Limitação
Em determinados cenários, quando o ID do próximo salto para a rota é alterado, as sessões existentes permanecem no link violado pelo SLA, mesmo que outro link que atenda aos requisitos do SLA esteja disponível. No entanto, as novas sessões não são afetadas nesse caso e são roteadas pelos links que atendem aos requisitos do SLA.
Suporte para aplicativos SaaS
Estendemos o suporte à qualidade da experiência de aplicativos (AppQoE) para aplicativos de Software como serviço (SaaS).
O AppQoE realiza medições de contrato de nível de serviço (SLA) nos links de WAN disponíveis, como underlay, GRE, IPsec ou MPLS sobre GRE. Em seguida, ele envia os dados do aplicativo SaaS pelo link mais compatível com SLA para fornecer um serviço consistente.
Suporte para tráfego IPv6
-
Você pode usar endereços IPv6 nas configurações do AppQoE. O suporte inclui:
- Configuração de endereço IPv6 no caminho de overlay
- Sessões de sondagem ativas usando endereços IPv6 como endereço de origem e destino.
- Tráfego IPv4 e IPv6 do lado do cliente
- Empilhamento duplo de IPv4 e IPv6 no lado da LAN
- Endereço IPv6 no lado da LAN para sondagem de SaaS (software como serviço).
Para sondagem de SaaS, certifique-se de configurar os endereços IPv4 e IPv6 para a interface de entrada para interoperabilidade IPv4 e IPv6.
Informações adicionais da plataforma
Use o AppQoE Feature Explorer para confirmar o suporte à plataforma e à versão para recursos específicos.
Use a tabela a seguir para analisar o comportamento específico da sua plataforma:
| Plataforma |
Diferença |
|---|---|
| Série SRX |
A configuração do dispositivo spoke é recomendada para SRX300, SRX320, SRX345, SRX340, SRX550M e vSRX. |
| Série SRX |
A configuração de dispositivo de hub é recomendada para SRX1500, SRX4100 e SRX4200. |
| Série SRX |
No SRX4600, o AppQoE não oferece suporte a CoS para GRE, os detalhes da sondagem passiva podem estar indisponíveis para sessões de curta duração e a sincronização do estado da sessão pode falhar no nó secundário no processamento de tráfego do modo Z quando no modo de cluster de chassi. |
Tabela de histórico de alterações
A compatibilidade com recursos é determinada pela plataforma e versão utilizada. Use o Explorador de recursos para determinar se um recurso é compatível com sua plataforma.