QoS de aplicativos
O AppQoS permite identificar e controlar o acesso a aplicativos específicos e fornece a granularidade da base de regras de firewall stateful para corresponder e aplicar a qualidade de serviço (QoS) na camada de aplicativo. Para obter mais informações, consulte os seguintes tópicos:
Entendendo a Qualidade de Serviço de Aplicativos (AppQoS)
O recurso de qualidade de serviço de aplicativos (AppQoS) expande a capacidade da classe de serviço (CoS) do Junos OS para incluir a marcação de valores de DSCP com base em tipos de aplicativos de Camada 7, honrando o tráfego baseado em aplicativos por meio de configurações de prioridade de perda e controlando as taxas de transferência em PICs de saída com base em tipos de aplicativos de Camada 7.
Há quatro maneiras de marcar os valores de DSCP no dispositivo de segurança:
Reescritores de DSCP baseados em ação de ataque de IDP
Regravadores de DSCP baseados em aplicativos de camada 7
Regravadores de DSCP baseados em ALG
Regravadores de DSCP baseados em filtro de firewall
A remarcação de IDP é realizada na porta de entrada com base nas regras de IDP. A remarcação do aplicativo é realizada na porta de saída com base nas regras do aplicativo. A remarcação baseada em interface também ocorre na porta de saída com base nas regras de filtro do firewall. (Consulte o Guia do Usuário da Classe de Serviço (Dispositivos de Segurança) para uma descrição detalhada dos recursos de CoS do Junos OS.)
As decisões de remarcação desses três reescritores podem ser diferentes. Se um pacote acionar todos os três, o método que tem precedência será baseado em quão profundamente no conteúdo do pacote a correspondência é conduzida. A remarcação de IDP tem precedência sobre a remarcação de aplicativo, que tem precedência sobre a remarcação baseada em interface.
Se um pacote acionar regravadores DSCP baseados em AppQoS e ALG, o AppQoS terá precedência sobre os regravadores DSCP baseados em ALG.
O regravador DSCP do AppQoS transmite a qualidade de serviço de um pacote por meio da classe de encaminhamento e de uma prioridade de perda. Os parâmetros de limitação de taxa do AppQoS controlam a velocidade e o volume de transmissão para suas filas associadas.
- Benefício da QoS do aplicativo
- Classes de encaminhamento exclusivas e atribuições de fila
- Configurações de ponto de código DSCP com reconhecimento de aplicativos e prioridade de perda
- Limitadores de taxa e perfis
- Atribuição do limitador de taxa
- Ação do limitador de taxa
- Configuração da política de Segurança do AppQoS
Benefício da QoS do aplicativo
O AppQoS oferece a capacidade de priorizar e medir o tráfego de aplicativos para fornecer um melhor serviço ao tráfego de aplicativos crítico para os negócios ou de alta prioridade.
Classes de encaminhamento exclusivas e atribuições de fila
A classe de encaminhamento fornece três funções:
Agrupa pacotes com características semelhantes
Atribui filas de saída
Resolve conflitos com regravadores existentes baseados em filtro de firewall do Junos OS
Nomes de classe de encaminhamento exclusivos protegem a remarcação do AppQoS de ser substituída por regras de reescrita baseadas em interface. Um regravador baseado em filtro de firewall observa o valor DSCP de um pacote se a classe de encaminhamento do pacote corresponder a uma classe definida especificamente para esse regravador. Se a classe de encaminhamento do pacote não corresponder a nenhuma das classes do regravador baseado em filtro de firewall, o valor de DSCP não será observado. Para proteger os valores do AppQoS de serem substituídos, portanto, use nomes de classe de encaminhamento desconhecidos para o regravador baseado em filtro de firewall.
Cada classe de encaminhamento é atribuída a uma fila de saída que fornece o grau apropriado de processamento aprimorado ou padrão. Muitas classes de encaminhamento podem ser atribuídas a uma única fila. Portanto, todas as filas definidas para o dispositivo podem ser usadas por regravadores baseados em filtro de IDP, AppQoS e firewall. É o nome da classe de encaminhamento, não a fila, que distingue a prioridade de transmissão. (Consulte o Guia do Usuário da Classe de Serviço (Dispositivos de Segurança) para obter informações sobre a configuração de filas e agendadores.)
Configurações de ponto de código DSCP com reconhecimento de aplicativos e prioridade de perda
Para o AppQoS, o tráfego é agrupado com base em regras que associam uma classe de encaminhamento definida a aplicativos selecionados. Os critérios de correspondência para a regra incluem um ou mais aplicativos. Quando o tráfego de um aplicativo correspondente encontra a regra, a ação da regra define a classe de encaminhamento e observa o valor do DSCP e a prioridade de perda para os valores apropriados para o aplicativo.
Um valor de ponto de código (DSCP) de Serviços Diferenciados (DiffServ) é especificado na regra por um valor de bitmap de 6 bits ou por um alias definido pelo usuário ou padrão. A Tabela 1 fornece uma lista de nomes de alias DSCP padrão do Junos OS e valores de bitmap.
Pseudônimo |
Valor do 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 e aliases de CoS padrão para obter mais detalhes.
O agendador da fila usa a prioridade de perda para controlar o descarte de pacotes durante períodos de congestionamento, associando perfis de queda a valores específicos de prioridade de perda. (Consulte o Guia do Usuário da Classe de Serviço (Dispositivos de Segurança) para obter informações sobre a configuração de filas e agendadores.)
A regra aplica uma prioridade de perda aos grupos de tráfego. Uma alta prioridade de perda significa uma alta probabilidade de que o pacote possa ser descartado durante um período de congestionamento. Quatro níveis de prioridade de perda estão disponíveis:
highmedium-highmedium-lowlow
O conjunto de regras é definido no class-of-service application-traffic-control comando de configuração:
[edit class-of-service] user@host# set application-traffic-control rule-sets ruleset-name rule rule-name1 match application application-name application-name ... user@host# set application-traffic-control rule-sets ruleset-name rule rule-name1 match application-group application-group-name application-group-name ... user@host# set application-traffic-control rule-sets ruleset-name rule rule-name1 then forwarding-class fc-name user@host# set application-traffic-control rule-sets ruleset-name rule rule-name1 then dscp-code-point bitmap user@host# set application-traffic-control rule-sets ruleset-name rule rule-name1 then loss-priority loss-pri-value
Limitadores de taxa e perfis
Quando ocorre congestionamento, o AppQoS implementa a limitação de taxa em todos os PICs de saída no dispositivo. Se os pacotes excederem as limitações atribuídas, eles serão descartados. Os limitadores de taxa mantêm um nível consistente de sensibilidade à taxa de transferência e à perda de pacotes para diferentes classes de tráfego. Todos os PICs de saída empregam o mesmo esquema de limitação de taxa.
A largura de banda total de um PIC é de cerca de 10 Gbps. O hardware do limitador de taxa para o PIC pode provisionar até 2 Gbps. Portanto, o limite superior de largura de banda para limitação de taxa é de 231 bps.
Um perfil de limitador de taxa define as limitações. É uma combinação única de bandwidth-limit e burst-size-limit especificações. O bandwidth-limit define o número máximo de kilobits por segundo que podem atravessar a porta. O burst-size-limit define o número máximo de bytes que podem atravessar a porta em uma única intermitência. Isso burst-size-limit reduz a privação de tráfego de prioridade mais baixa, garantindo um tamanho finito para cada intermitência.
O AppQoS permite até 16 perfis e até 1000 limitadores de taxa por dispositivo. Vários limitadores de taxa podem usar o mesmo perfil. No exemplo a seguir, cinco limitadores de taxa são definidos usando dois perfis:
Nome do limitador de taxa |
Perfil |
|
|---|---|---|
limite de largura de banda |
limite de tamanho de intermitência |
|
limitador-1 |
200 |
26000 |
limitador-2 |
200 |
26000 |
limitador-3 |
200 |
26000 |
limitador-4 |
400 |
52000 |
limitador-5 |
400 |
52000 |
Os limitadores de taxa são definidos com o class-of-service application-traffic-control comando de configuração.
[edit class-of-service] user@host# set application-traffic-control rate-limiters rate-limiter-name bandwidth-limit value-in-Kbps burst-rate-limit value-in-bytes
Atribuição do limitador de taxa
Os limitadores de taxa são aplicados em regras baseadas na aplicação do tráfego. Dois limitadores de taxa são aplicados para cada sessão: client-to-server e server-to-client. Esse uso permite que o tráfego em cada direção seja provisionado separadamente.
O processamento da largura de banda do tráfego por limitadores de taxa é feito no nível do pacote, independentemente da direção do tráfego. Por exemplo: considere um caso em que você tem apenas um limitador de taxa de 10G configurado, se o tráfego de entrada e saída for da mesma placa de linha, a taxa de transferência (tráfego máximo das direções de entrada e saída combinadas) só poderá ser de até 10G e não de 20G. No entanto, se o dispositivo tiver suporte a IOC (placas de E/S (IOCs)) e o tráfego de entrada for por meio de um IOC e o tráfego de saída por outro IOC, com um único limitador de taxa de 10G configurado, você poderá esperar uma taxa de transferência de 20G.
Diferentes regras do AppQoS dentro do mesmo conjunto de regras podem compartilhar um limitador de taxa. Nesse caso, os aplicativos dessas regras compartilham a mesma largura de banda. Não há limitações quanto ao número de regras em um conjunto de regras que podem atribuir o mesmo limitador de taxa.
Os exemplos a seguir mostram como os limitadores de taxa definidos na seção anterior podem ser atribuídos. Por exemplo, um conjunto de regras pode reutilizar um limitador de taxa em várias regras e em uma ou ambas as direções de fluxo:
conjunto de regras 1
regra-1A
limitador de cliente para servidor-1
limitador de servidor para cliente-1
regra 1B
limitador de cliente para servidor-1
limitador de servidor para cliente-1
Se os mesmos perfis forem necessários em vários conjuntos de regras, um número suficiente de limitadores de taxa precisará ser definido especificando o mesmo bandwidth-limit e burst-size-limit. Os dois conjuntos de regras no exemplo a seguir implementam os mesmos perfis atribuindo limitadores de taxa diferentes, mas comparáveis.
conjunto de regras 2
regra-2A
limitador de cliente para servidor-2
limitador de servidor para cliente-2
regra-2B
limitador de cliente para servidor-2
limitador de servidor para cliente-4
conjunto de regras 3
regra-3A
limitador de cliente para servidor-3
limitador de servidor para cliente-3
regra-3B
limitador de cliente para servidor-3
limitador de servidor para cliente-5
Um limitador de taxa é aplicado usando o edit class-of-service application-traffic-control rule-sets comando da mesma forma que uma classe de encaminhamento, valor DSCP e prioridade de perda são definidos.
[edit class-of-service] user@host# set application-traffic-control rule-sets rule-set-name rule rule-name1 then rate-limit client-to-server rate-limiter1 server-to-client rate-limiter2
Se o AppQoS e a limitação de taxa baseada em filtro de firewall forem implementados no PIC de saída, ambos serão levados em consideração. A limitação de taxa do AppQoS é considerada primeiro. A limitação de taxa baseada em filtro de firewall ocorre depois disso.
Se os pacotes forem descartados de um PIC, o dispositivo não enviará notificações ao cliente ou ao servidor. Os aplicativos de nível superior nos dispositivos cliente e servidor são responsáveis pela retransmissão e tratamento de erros.
Ação do limitador de taxa
Com base no tipo de dispositivo de segurança, as regras do AppQoS podem ser configuradas com diferentes ações do limitador de taxa:
Descarte
Quando essa opção é selecionada, os pacotes fora de perfil são simplesmente descartados.
Esse é o tipo de ação padrão e não precisa ser configurado.
Esta opção é suportada em todos os dispositivos de segurança
Prioridade de perda alta
Quando essa opção é selecionada, ela eleva a prioridade de perda para o máximo. Em outras palavras, é uma queda atrasada; ou seja, a decisão de descarte é tomada no nível da fila de saída de saída. Se não houver congestionamento, ele permite o tráfego mesmo com prioridade de perda máxima. Mas se ocorrer congestionamento, ele descartará esses pacotes de prioridade de perda máxima primeiro.
Essa opção deve ser configurada dentro da regra do AppQoS (para substituir a ação padrão) usando o seguinte comando:
[edit] user@host# set class-of-service application-traffic-control rule-sets rset-01 rule r1 then rate-limit loss-priority-high
-
Esta opção é suportada em dispositivos selecionados. Consulte a tabela de comportamento do AppQoS específico da plataforma .
Configuração da política de Segurança do AppQoS
O conjunto de regras do AppQoS pode ser implementado em uma política existente ou em uma política de aplicativo específica.
[edit security policies from-zone zone-name to-zone zone-name]
user@host# set policy policy-name match source-address IP-address
user@host# set policy policy-name match destination-address IP-address
user@host# set policy policy-name match application application-name application-name
user@host# set policy policy-name then permit application-services application-traffic-control rule-set app-rule-set-name
Veja também
Exemplo: configurar a qualidade de serviço do aplicativo
Este exemplo mostra como habilitar a priorização e a limitação de taxa do AppQoS em uma política.
Requerimentos
Nenhuma configuração especial além da inicialização do dispositivo é necessária antes de configurar esse recurso.
Visão geral
Neste exemplo, o AppQoS é implementado para que os aplicativos FTP sejam restritos a um nível abaixo da taxa de transferência especificada, enquanto outros aplicativos são transmitidos em um nível mais convencional de velocidade e prioridade de perda.
Configuração
Tramitação processual
Para configurar rapidamente este exemplo, copie os seguintes comandos, cole-os em um arquivo de texto, remova quaisquer quebras de linha, altere todos os detalhes necessários para corresponder à sua configuração de rede e, em seguida, copie e cole os comandos na CLI no nível de [edit] hierarquia.
set class-of-service forwarding-classes queue 4 my-app-fc set class-of-service application-traffic-control rate-limiters test-rl bandwidth-limit 100 set class-of-service application-traffic-control rate-limiters test-rl burst-size-limit 13000 set class-of-service application-traffic-control rate-limiters test-r2 bandwidth-limit 200 set class-of-service application-traffic-control rate-limiters test-r2 burst-size-limit 26000 set class-of-service application-traffic-control rule-sets app-test1 rule 0 match application junos:FTP set class-of-service application-traffic-control rule-sets app-test1 rule 0 match application junos:HTTP set class-of-service application-traffic-control rule-sets app-test1 rule 0 then forwarding-class my-app-fc set class-of-service application-traffic-control rule-sets app-test1 rule 0 then dscp-code-point af22 set class-of-service application-traffic-control rule-sets app-test1 rule 0 then loss-priority low set class-of-service application-traffic-control rule-sets app-test1 rule 0 then rate-limit client-to-server test-r2 set class-of-service application-traffic-control rule-sets app-test1 rule 0 then rate-limit server-to-client test-r2 set class-of-service application-traffic-control rule-sets app-test1 rule 0 then log set class-of-service application-traffic-control rule-sets app-test1 rule 1 match application-any set class-of-service application-traffic-control rule-sets app-test1 rule 1 then rate-limit client-to-server test-r2 set class-of-service application-traffic-control rule-sets app-test1 rule 1 then rate-limit server-to-client test-r2 set class-of-service application-traffic-control rule-sets app-test1 rule 1 then log set security policies from-zone trust to-zone untrust policy p1 match source-address any set security policies from-zone trust to-zone untrust policy p1 match destination-address any set security policies from-zone trust to-zone untrust policy p1 match application any set security policies from-zone trust to-zone untrust policy p1 then permit application-services application-traffic-control rule-set ftp-test1
Procedimento passo a passo
Para configurar um AppQoS em seu dispositivo de segurança:
-
Defina uma ou mais classes de encaminhamento dedicadas à marcação do AppQoS. Neste exemplo, uma única classe de encaminhamento, my-app-fc, é definida e atribuída à fila 4.
[edit] user@host# set class-of-service forwarding-classes queue 4 my-app-fc
[edit] user@host# set class-of-service forwarding-classes class my-app-fc queue 4
Os dispositivos da Juniper Networks oferecem suporte a oito filas (0 a 7). As filas padrão de 0 a 3 são atribuídas a classes de encaminhamento padrão. As filas 4 a 7 não têm atribuições padrão para FCs e não são mapeadas. Para usar as filas de 4 a 7, você deve criar nomes de FC personalizados e mapeá-los para as filas. Para obter mais detalhes, consulte Visão geral das classes de encaminhamento.
Defina limitadores de taxa. Neste exemplo, dois limitadores de taxa são definidos.
[edit] user@host# set class-of-service application-traffic-control rate-limiters test-rl bandwidth-limit 100 user@host# set class-of-service application-traffic-control rate-limiters test-rl burst-size-limit 13000 user@host# set class-of-service application-traffic-control rate-limiters test-r2 bandwidth-limit 200 user@host# set class-of-service application-traffic-control rate-limiters test-r2 burst-size-limit 26000
-
Definir regras do AppQos e critérios de correspondência de aplicativos.
[edit] user@host# set class-of-service application-traffic-control rule-sets app-test1 rule 0 match application junos:FTP user@host# set class-of-service application-traffic-control rule-sets app-test1 rule 0 match application junos:HTTP user@host# set class-of-service application-traffic-control rule-sets app-test1 rule 0 then forwarding-class my-app-fc user@host# set class-of-service application-traffic-control rule-sets app-test1 rule 0 then dscp-code-point af22 user@host# set class-of-service application-traffic-control rule-sets app-test1 rule 0 then loss-priority low user@host# set class-of-service application-traffic-control rule-sets app-test1 rule 0 then rate-limit client-to-server test-r1 user@host# set class-of-service application-traffic-control rule-sets app-test1 rule 0 then rate-limit server-to-client test-r1 user@host# set class-of-service application-traffic-control rule-sets app-test1 rule 0 then log
Neste exemplo, quando uma correspondência é feita, o pacote é marcado com a classe de encaminhamento my-app-fc, o valor de DSCP de af22 e uma prioridade de perda de low. Atribuímos o mesmo limitador de taxa em ambas as direções.
Você pode atribuir um limitador de taxa a uma ou ambas as direções de tráfego em uma única regra. Você também pode atribuir um mesmo limitador de taxa a outras regras dentro de um conjunto de regras. No entanto, você não pode atribuir um mesmo limitador de taxa a um conjunto de regras diferente.
-
Defina outra regra para lidar com pacotes de aplicativos que não correspondem à regra anterior. Neste exemplo, uma segunda e última regra se aplica a todos os aplicativos restantes.
[edit] user@host# set class-of-service application-traffic-control rule-sets app-test1 rule 1 match application-any user@host# set class-of-service application-traffic-control rule-sets app-test1 rule 1 then rate-limit client-to-server test-r2 user@host# set class-of-service application-traffic-control rule-sets app-test1 rule 1 then rate-limit server-to-client test-r2 user@host# set class-of-service application-traffic-control rule-sets app-test1 rule 1 then log
-
Adicione a configuração AppQoS à política de segurança.
[edit] user@host# set security policies from-zone trust to-zone untrust policy p1 match source-address any user@host# set security policies from-zone trust to-zone untrust policy p1 match destination-address any user@host# set security policies from-zone trust to-zone untrust policy p1 match application any user@host# set security policies from-zone trust to-zone untrust policy p1 then permit application-services application-traffic-control rule-set app-test1
Resultados
No modo de configuração, confirme a configuração da política inserindo o show security policies comando e show class-of-service . Se a saída não exibir a configuração pretendida, repita as instruções neste exemplo para corrigir a configuração.
Para resumir, essa show saída de comando inclui apenas a configuração relevante para este exemplo. Qualquer outra configuração no sistema foi substituída por reticências (...).
...
policy p1 {
match {
source-address any;
destination-address any;
application any;
}
then {
permit {
application-services {
application-traffic-control {
rule-set app-test1
}
}
}
}
}
...
user@host# show class-of-service
forwarding-classes {
queue 4 my-app-fc;
}
application-traffic-control {
rate-limiters test-rl {
bandwidth-limit 100;
burst-size-limit 13000;
}
rate-limiters test-r2 {
bandwidth-limit 200;
burst-size-limit 26000;
}
rule-sets app-test1 {
rule 0 {
match {
application [junos:FTP junos:HTTP];
}
then {
forwarding-class my-app-fc;
dscp-code-point af22;
loss-priority low;
rate-limit {
client-to-server test-r2;
server-to-client test-r2;
}
log;
}
}
rule 1 {
match {
application-any;
}
then {
rate-limit {
client-to-server test-r2;
server-to-client test-r2;
}
log;
}
}
}
}
Se você terminar de configurar o dispositivo, entre no commit modo de configuração.
Verificação
Confirme se a configuração está funcionando corretamente.
- Verificando a configuração da sessão de fluxo
- Verificando as estatísticas da sessão
- Verificando as estatísticas do limitador de taxa
- Verificando estatísticas de regras
Verificando a configuração da sessão de fluxo
Finalidade
Verifique se o AppQoS está habilitado.
Ação
Do modo operacional, insira o show security flow session application-traffic-control extensive comando.
user@host> show security flow session application-traffic-control extensive
Session ID: 3729, Status: Normal, State: Active
Flag: 0x40
Policy name: p1
Source NAT pool: Null
Dynamic application: junos:FTP
Application traffic control rule-set: app-test1, Rule: rule0
Maximum timeout: 300, Current timeout: 276
Session State: Valid
Start time: 18292, Duration: 603536
In: 192.0.2.1/1 --> 203.0.113.0/1;pim,
Interface: reth1.0,
Session token: 0x1c0, Flag: 0x0x21
Route: 0x0, Gateway: 192.0.2.4, Tunnel: 0
Port sequence: 0, FIN sequence: 0,
FIN state: 0,
Pkts: 21043, Bytes: 1136322
Out: 203.0.113.0/1 --> 192.0.2.0/1;pim,
Interface: .local..0,
Session token: 0x80, Flag: 0x0x30
Route: 0xfffd0000, Gateway: 192.0.2.0, Tunnel: 0
Port sequence: 0, FIN sequence: 0,
FIN state: 0,
Pkts: 0, Bytes: 0
Significado
A entrada para controle de tráfego do aplicativo identifica o conjunto de regras e a regra da sessão atual.
Verificando as estatísticas da sessão
Finalidade
Verifique se as estatísticas de sessão do AppQoS estão sendo acumuladas em cada nó de saída.
Ação
Do modo operacional, insira o show class-of-service application-traffic-control counter comando.
user@host> show class-of-service application-traffic-control counter pic: 2/1 Counter type Value Sessions processed 300 Sessions marked 200 Sessions honored 0 Sessions rate limited 100 Client-to-server flows rate limited 100 Server-to-client flows rate limited 100 pic: 2/0 Counter type Value Sessions processed 400 Sessions marked 300 Sessions honored 0 Sessions rate limited 200 Client-to-server flows rate limited 200 Server-to-client flows rate limited 200
Significado
As estatísticas do AppQoS são mantidas somente se o serviço de controle de tráfego de aplicativos estiver ativado. O número de sessões processadas, marcadas e honradas mostra que as sessões estão sendo direcionadas com base nos recursos configurados do AppQoS. As estatísticas de limitação de taxa contam o número de fluxos de sessão direcionais que foram limitados por taxa.
Verificando as estatísticas do limitador de taxa
Finalidade
Verifique se a largura de banda está sendo limitada conforme o esperado quando o aplicativo FTP é encontrado.
Ação
Do modo operacional, insira o show class-of-service application-traffic-control statistics rate-limiter comando.
user@host> show class-of-service application-traffic-control statistics rate-limiter pic: 2/1 Ruleset Application Client-to-server Rate(kbps) Server-to-client Rate(kbps) app-test1 HTTP test-r2 200 test-r2 200 app-test1 HTTP test-r2 200 test-r2 200 appp–test1 FTP test-r1 100 test-r1 100
Significado
As informações de limite de largura de banda do aplicativo em tempo real para cada PIC são exibidas por conjunto de regras. Esse comando fornece uma indicação dos aplicativos que estão sendo limitados por taxa e do perfil que está sendo aplicado.
Verificando estatísticas de regras
Finalidade
Verifique se a regra corresponde às estatísticas da regra.
Ação
Do modo operacional, insira o show class-of-service application-traffic-control statistics rule comando.
user@host>show class-of-service application-traffic-control statistics rule pic: 2/1 Ruleset Rule Hits app-test1 0 100 app-test1 1 200 ... pic: 2/0 Ruleset Rule Hits app-test1 0 100 app-test1 1 200
Significado
Esse comando fornece informações sobre o número de ocorrências (de sessão) para uma regra em cada conjunto de regras.
Qualidade de serviço do aplicativo Suporte para políticas unificadas
Políticas unificadas são as políticas de segurança que permitem que você use aplicativos dinâmicos como parte das condições de correspondência existentes de 5 ou 6 tuplas (5 tuplas com um firewall do usuário) para detectar alterações de aplicativos ao longo do tempo.
A qualidade de serviço do aplicativo (AppQoS) é suportada quando o dispositivo de segurança é configurado com políticas unificadas. Você pode configurar um conjunto de regras padrão do AppQoS para gerenciar conflitos de políticas unificados se várias políticas de segurança corresponderem ao tráfego.
Os conjuntos de regras do AppQoS são incluídos na política unificada para implementar o controle de qualidade de serviço com reconhecimento de aplicativos. Você pode configurar um conjunto de regras com regras na application-traffic-control opção e anexar o conjunto de regras do AppQoS a uma política de segurança unificada como um serviço de aplicativo. Se o tráfego corresponder ao aplicativo dinâmico especificado e a ação de política for permissão, a qualidade de serviço com reconhecimento de aplicativos será aplicada.
Observe a seguinte funcionalidade do AppQoS em políticas unificadas:
Atualização da política de segurança tradicional para uma política unificada — em uma política unificada, quando você configura a
dynamic-applicationopção comonone, o conjunto de regras do AppQoS é aplicado durante a correspondência da política de segurança e o AppQoS procura a regra correspondente para o tráfego identificado. Esse é o mesmo comportamento para a funcionalidade do AppQoS nas versões do Junos OS anteriores à versão 18.2R1.Regra do AppQoS com uma política unificada — Na configuração do controle de tráfego do aplicativo, o conjunto de regras do AppQoS é configurado com a condição de correspondência como
application-anye na política unificada, um aplicativo dinâmico específico é usado como a condição de correspondência e, em seguida, a funcionalidade do AppQoS funciona de acordo com a regra na política unificada.
- Noções básicas sobre o conjunto de regras de qualidade de serviço de aplicativo padrão para políticas unificadas
- Conjunto de regras de qualidade de serviço de aplicativo padrão em diferentes cenários
- Limitação de AppQoS com políticas unificadas
Noções básicas sobre o conjunto de regras de qualidade de serviço de aplicativo padrão para políticas unificadas
Você pode configurar um conjunto de regras padrão do AppQoS para gerenciar conflitos de política de segurança.
A fase inicial de pesquisa de política ocorre antes da identificação de um aplicativo dinâmico. Se houver várias políticas presentes na lista de políticas potenciais que contenham diferentes conjuntos de regras do AppQoS, o dispositivo de segurança aplicará o conjunto de regras padrão do AppQoS até que ocorra uma correspondência mais explícita.
Você pode definir um AppQoS como um conjunto de regras padrão do AppQoS no nível de edit security ngfw hierarquia. O conjunto de regras padrão do AppQoS é aproveitado de um dos conjuntos de regras do AppQoS existentes, que são configurados no [edit class-of-service application-traffic-control] nível de hierarquia.
A Tabela 2 resume o uso do conjunto de regras padrão do AppQoS em diferentes cenários em uma política unificada.
Status de identificação do aplicativo |
Uso do conjunto de regras do AppQoS |
Ação |
|---|---|---|
Nenhum conflito de política de segurança. |
A regra do AppQoS definida na |
O AppQoS é aplicado como no conjunto de regras do AppQoS. |
O conflito de políticas de Segurança e as políticas conflitantes têm conjuntos de regras do AppQoS distintos. |
O conjunto de regras padrão do AppQoS não está configurado ou não foi encontrado. |
A sessão é ignorada porque o perfil padrão do AppQoS não está configurado. Como resultado, mesmo que a política correspondente final no cenário de conflito de política tenha um conjunto de regras do AppQoS, esse conjunto de regras não será aplicado. Recomendamos configurar um conjunto de regras padrão do AppQoS para gerenciar conflitos de política de segurança. |
O conjunto de regras padrão do AppQoS está configurado. |
O AppQoS é aplicado como no conjunto de regras padrão do AppQoS. |
|
A aplicação final é identificada |
A política de segurança correspondente tem um conjunto de regras do AppQoS, que é o mesmo que o conjunto de regras padrão do AppQoS. |
O AppQoS é aplicado como no conjunto de regras padrão do AppQoS. |
A política de segurança correspondente não tem um conjunto de regras do AppQoS. |
O conjunto de regras padrão do AppQoS não é aplicado e o AppQoS não é aplicado à sessão. |
|
A política de segurança Matching tem um conjunto de regras do AppQoS diferente do conjunto de regras padrão do AppQoS, que já está aplicado. |
O conjunto de regras padrão do AppQoS permanece como o conjunto de regras padrão do AppQoS. |
Quando um conjunto de regras padrão do AppQoS é aplicado no tráfego e a política de segurança final tem um conjunto de regras do AppQoS diferente, nesses casos, não há suporte para a mudança do conjunto de regras padrão do AppQoS para o conjunto de regras do AppQoS na política de segurança final.
Conjunto de regras de qualidade de serviço de aplicativo padrão em diferentes cenários
Os links a seguir são para exemplos que discutem os conjuntos de regras padrão do AppQoS em diferentes cenários:
A Tabela 3 mostra diferentes conjuntos de regras do AppQoS configurados para políticas unificadas com aplicativos dinâmicos como condição de correspondência.
Política de Segurança |
Zona de origem |
Endereço IP de origem |
Zona de destino |
Endereço IP de destino |
Número da porta |
Protocolo |
Aplicativo dinâmico |
Serviço |
Conjunto de regras do AppQoS |
|---|---|---|---|---|---|---|---|---|---|
Política-P1 |
S1 |
50.1.1.1 |
D1 |
Qualquer |
Qualquer |
Qualquer |
AppQoS |
AppQoS-1 |
|
Política-P2 |
S1 |
50.1.1.1 |
D1 |
Qualquer |
Qualquer |
Qualquer |
AppQoS |
AppQoS-2 |
|
Política-P3 |
S1 |
50.1.1.1 |
D1 |
Qualquer |
Qualquer |
Qualquer |
YouTube (em inglês) |
AppQoS |
AppQoS-3 |
Neste exemplo, qualquer conjunto de regras do AppQoS (AppQoS-1, AppQoS-2, AppQoS-3) pode ser configurado como um conjunto de regras padrão do [security ngfw] AppQoS no nível de hierarquia. Não é necessário que um conjunto de regras padrão faça parte de uma configuração de política de segurança. Qualquer conjunto de regras do [edit class-of-service application-traffic-control] AppQoS no nível de hierarquia pode ser atribuído como o conjunto de regras padrão do AppQoS.
- Sem conflito de políticas — todas as políticas têm o mesmo conjunto de regras do AppQoS
- Sem conflito de política — todas as políticas têm o mesmo conjunto de regras do AppQoS e a política final não tem um conjunto de regras do AppQoS
- Conflito de política — nenhum conjunto de regras do AppQoS está configurado para a política final
- Conflito de política — conjunto de regras padrão do AppQoS e um conjunto de regras do AppQoS diferente para a política final
Sem conflito de políticas — todas as políticas têm o mesmo conjunto de regras do AppQoS
Todas as políticas correspondentes têm o mesmo conjunto de regras do AppQoS, conforme mostrado na Tabela 4.
Política de Segurança |
Zona de origem |
Endereço IP de origem |
Zona de destino |
Endereço IP de destino |
Número da porta |
Protocolo |
Aplicativo dinâmico |
Serviço |
Conjunto de regras do AppQoS |
|---|---|---|---|---|---|---|---|---|---|
Política-P1 |
S1 |
Qualquer |
D1 |
Qualquer |
Qualquer |
Qualquer |
AppQoS |
AppQoS-1 |
|
Política-P2 |
S1 |
Qualquer |
D1 |
Qualquer |
Qualquer |
Qualquer |
AppQoS |
AppQoS-1 |
Nesse cenário, as políticas Policy-P1 e Policy-P2 têm o mesmo conjunto de regras do AppQoS; ou seja, AppQoS-1. O conjunto de regras AppQoS-1 é aplicado. O Policy-P3 não está configurado neste cenário.
Se você configurou o conjunto de regras AppQoS-2 como o conjunto de regras padrão, ele não será aplicado. Isso ocorre porque não há conflito nos conjuntos de regras do AppQoS nas políticas conflitantes (Policy-P1 e Policy-P2).
Sem conflito de política — todas as políticas têm o mesmo conjunto de regras do AppQoS e a política final não tem um conjunto de regras do AppQoS
Todas as políticas correspondentes têm o mesmo conjunto de regras do AppQoS, conforme mostrado na Tabela 5 , e a política final não tem nenhum conjunto de regras do AppQoS.
Política de Segurança |
Zona de origem |
Endereço IP de origem |
Zona de destino |
Endereço IP de destino |
Número da porta |
Protocolo |
Aplicativo dinâmico |
Serviço |
Conjunto de regras do AppQoS |
|---|---|---|---|---|---|---|---|---|---|
Política-P1 |
S1 |
Qualquer |
D1 |
Qualquer |
Qualquer |
Qualquer |
AppQoS |
AppQoS-1 |
|
Política-P2 |
S1 |
Qualquer |
D1 |
Qualquer |
Qualquer |
Qualquer |
AppQoS |
AppQoS-1 |
|
Política-P3 |
S1 |
50.1.1.1 |
D1 |
Qualquer |
Qualquer |
Qualquer |
YouTube (em inglês) |
Outros |
Nenhum |
Nesse cenário, a Policy-P1 e a Policy-P2 têm o mesmo conjunto de regras do AppQoS, ou seja, AppQoS-1. Nesse caso, o conjunto de regras AppQoS-1 é aplicado.
Quando a política final Policy-P3 é correspondida, o AppQoS ignora a sessão, porque o conjunto de regras do AppQoS não está configurado para Policy-P3.
Se a política de segurança final não tiver nenhuma regra do AppQoS definida, o AppQoS não será aplicado ao tráfego. Todas as configurações do AppQoS aplicadas no estágio de pré-correspondência são revertidas para os valores originais.
Conflito de política — nenhum conjunto de regras do AppQoS está configurado para a política final
O conjunto de regras padrão do AppQoS (neste cenário, AppQoS-1) é aplicado durante a possível correspondência de políticas, conforme mostrado na Tabela 6. A política final Policy-P3 não tem nenhuma regra do AppQoS definida.
Política de Segurança |
Zona de origem |
Endereço IP de origem |
Zona de destino |
Endereço IP de destino |
Número da porta |
Protocolo |
Aplicativo dinâmico |
Serviço |
Conjunto de regras do AppQoS |
|---|---|---|---|---|---|---|---|---|---|
Política-P1 |
S1 |
50.1.1.1 |
D1 |
Qualquer |
Qualquer |
Qualquer |
AppQoS |
AppQoS-1 |
|
Política-P2 |
S1 |
50.1.1.1 |
D1 |
Qualquer |
Qualquer |
Qualquer |
AppQoS |
AppQoS-2 |
|
Política-P3 |
S1 |
50.1.1.1 |
D1 |
Qualquer |
Qualquer |
Qualquer |
YouTube (em inglês) |
Outros |
NA |
O AppQoS ignora a sessão se a política de correspondência final Policy-P3 for aplicada.
Se a política de segurança final não tiver nenhuma regra do AppQoS definida, o AppQoS não será aplicado ao tráfego. Nesse caso, todas as configurações do AppQoS aplicadas no estágio de pré-correspondência são revertidas para os valores originais.
Conflito de política — conjunto de regras padrão do AppQoS e um conjunto de regras do AppQoS diferente para a política final
O conjunto de regras AppQoS-1 é configurado como um conjunto de regras padrão e é aplicado quando o aplicativo final ainda não foi identificado. A política final Policy-P3 tem um conjunto de regras AppQoS diferente (AppQoS-3), conforme mostrado na Tabela 7.
Política de Segurança |
Zona de origem |
Endereço IP de origem |
Zona de destino |
Endereço IP de destino |
Número da porta |
Protocolo |
Aplicativo dinâmico |
Serviço |
Conjunto de regras do AppQoS |
|---|---|---|---|---|---|---|---|---|---|
Política-P1 |
S1 |
50.1.1.1 |
D1 |
Qualquer |
Qualquer |
Qualquer |
AppQoS |
AppQoS-1 |
|
Política-P2 |
S1 |
50.1.1.1 |
D1 |
Qualquer |
Qualquer |
Qualquer |
AppQoS |
AppQoS-2 |
|
Política-P3 |
S1 |
50.1.1.1 |
D1 |
Qualquer |
Qualquer |
Qualquer |
YouTube (em inglês) |
AppQoS |
AppQoS-3 |
Quando o aplicativo final é identificado, a política Policy-P3 é correspondida e aplicada. Nesse caso, o conjunto de regras AppQoS-3 não é aplicado. Em vez disso, o conjunto de regras AppQoS-1 é aplicado como o conjunto de regras padrão e permanece como o conjunto de regras padrão.
Limitação de AppQoS com políticas unificadas
Quando uma política de segurança é aplicada ao tráfego correspondente, o conjunto de regras do AppQoS é aplicado ao tráfego permitido. Se a política de segurança e o conjunto de regras do AppQoS aplicado tiverem aplicações dinâmicas diferentes, poderá ocorrer um conflito, conforme mostrado no exemplo a seguir:
user@host#set class-of-service application-traffic-control rule-sets AQ2 rule 1 match application junos:GOOGLEuser@host#set class-of-service application-traffic-control rule-sets AQ2 rule 1 then forwarding-class network-controluser@host#set class-of-service application-traffic-control rule-sets AQ2 rule 1 then dscp-code-point 110001user@host#set class-of-service application-traffic-control rule-sets AQ2 rule 1 then loss-priority high
user@host#set security policies from-zone trust to-zone untrust policy 1 match source-address anyuser@host#set security policies from-zone trust to-zone untrust policy 1 match destination-address anyuser@host#set security policies from-zone trust to-zone untrust policy 1 match application anyuser@host#set security policies from-zone trust to-zone untrust policy 1 match dynamic-application junos:FTPuser@host#set security policies from-zone trust to-zone untrust policy 1 then permit application-services application-traffic-control rule-set AQ2
Neste exemplo, a regra de controle de tráfego do aplicativo está configurada para junos:GOOGLE e a condição de correspondência da política de segurança para o aplicativo dinâmico é junos: FTP. Nesses casos, podem ocorrer conflitos quando a política final é aplicada.
Veja também
Exemplo: configuração da qualidade de serviço do aplicativo com política unificada
Este exemplo mostra como habilitar a qualidade de serviço do aplicativo (AppQoS) em uma política unificada para fornecer priorização e limitação de taxa para o tráfego.
Requerimentos
Este exemplo usa os seguintes componentes de hardware e software:
Firewall da Série SRX executando o Junos OS versão 18.2R1 e posterior. Este exemplo de configuração foi testado para o Junos OS Release 18.2R1.
Nenhuma configuração especial além da inicialização do dispositivo é necessária antes de configurar esse recurso.
Visão geral
Neste exemplo, você configura um conjunto de regras do AppQoS e invoca o AppQoS como um serviço de aplicativo na política de segurança do aplicativo do Facebook.
Você define um conjunto de regras padrão do AppQoS no nível de hierarquia [edit security ngfw] para gerenciar conflitos de política de segurança, se houver.
Configuração
Tramitação processual
Procedimento passo a passo
Para configurar o AppQoS com uma política unificada:
Definir um conjunto de regras do AppQoS.
[edit] user@host# set class-of-service application-traffic-control rule-sets RS1 rule 1 match application junos:FACEBOOK-APP user@host# set class-of-service application-traffic-control rule-sets RS1 rule 1 then forwarding-class fc-appqos loss-priority medium-low dscp-code-point 101110 log user@host# set class-of-service application-traffic-control rule-sets RS1 rule 1 then rate-limit client-to-server Ratelimit1 user@host# set class-of-service application-traffic-control rate-limiters Ratelimit1 bandwidth-limit 1000
Configure um conjunto de regras padrão do AppQoS. Selecione o conjunto
RS1de regras criado no controle de tráfego do aplicativo como o conjunto de regras padrão do AppQoS.[edit] user@host# set security ngfw default-profile application-traffic-control rule-set RS1
Associe o conjunto de regras de classe de serviço à política unificada.
[edit] user@host# set security policies from-zone untrust to-zone trust policy from_internet match source-address any user@host# set security policies from-zone untrust to-zone trust policy from_internet match destination-address any user@host# set security policies from-zone untrust to-zone trust policy from_internet match application any user@host# set security policies from-zone untrust to-zone trust policy from_internet match dynamic-application junos:FACEBOOK-APP user@host# set security policies from-zone untrust to-zone trust policy from_internet then permit application-services application-traffic-control rule-set RS1
Resultados
No modo de configuração, confirme a configuração da política digitando o show security policies comando. Se a saída não exibir a configuração pretendida, repita as instruções neste exemplo para corrigir a configuração.
Para resumir, essa show saída de comando inclui apenas a configuração relevante para este exemplo. Qualquer outra configuração no sistema foi substituída por reticências (...).
...
policies {
from-zone trust to-zone untrust {
policy permit-all {
match {
source-address any;
destination-address any;
application any;
dynamic-application junos:FACEBOOK-APP;
}
then {
permit {
application-services {
application-traffic-control {
rule-set RS1;
}
}
}
}
}
}
}
...
ngfw {
default-profile {
application-traffic-control {
rule-set RS1;
}
}
}
Se você terminar de configurar o dispositivo, entre no commit modo de configuração.
Verificação
Confirme se a configuração está funcionando corretamente.
Verificando a configuração da sessão de fluxo
Finalidade
Exibir estatísticas da sessão do AppQoS.
Ação
Do modo operacional, insira o show class-of-service application-traffic-control counter comando.
Saída de amostra
nome do comando
pic: 0/0 Counter type Value Sessions processed 2 Sessions marked 1 Sessions honored 1 Sessions rate limited 1 Client-to-server flows rate limited 0 Server-to-client flows rate limited 1 Session default ruleset hit 1 Session ignored no default ruleset 1
Significado
A saída exibe o número de sessões processadas, marcadas e honradas. As estatísticas de limitação de taxa contam o número de fluxos de sessão direcionais que foram limitados por taxa.
Verificando estatísticas de regras
Finalidade
Exiba as estatísticas de regra do AppQoS.
Ação
Do modo operacional, insira o show class-of-service application-traffic-control statistics rule comando.
user@host>show class-of-service application-traffic-control statistics rule
pic: 0/0
Ruleset Rule Hits
RS1 1 1
Significado
A saída fornece informações sobre o número de sessões correspondentes para a regra em cada conjunto de regras do AppQoS.
HTTP2: Suporte a AppQoS DSCP
O suporte a pontos de código de serviços diferenciados (DSCP) de qualidade de serviço (AppQoS) HTTP/2 aprimora a aplicação de regras de qualidade de serviço (QoS) em sessões HTTP/2 aproveitando as classificações de primeiro fluxo. Esse aprimoramento permite a aplicação de regras de QoS a sessões HTTP/2, garantindo que o tráfego seja classificado e priorizado de acordo com o tipo de aplicativo. Esse recurso permite que você aplique políticas granulares do AppQoS no tráfego HTTP/2, o que é crítico ao lidar com vários fluxos categorizados em diferentes aplicativos. Ao aplicar regras do AppQoS com base na classificação da primeira sessão de fluxo, você garante um gerenciamento consistente de QoS, mesmo quando a lógica de fallback é invocada devido a regras não especificadas. O recurso se integra às estruturas de gerenciamento de tráfego HTTP/2 existentes, abordando cenários em casos de política tradicionais e unificados e mantendo a aplicação de QoS eficaz em sessões criptografadas sem qualquer configuração de CLI adicional.
Visão geral
O tráfego HTTP/2 agora herda as regras do AppQoS HTTP para marcação DSCP quando a regra HTTP/2 específica está ausente, garantindo um comportamento de QoS consistente.
O HTTP é um aplicativo abrangente em que vários aplicativos (por exemplo, facebook, twitter) aparecem como sessões separadas e são classificados de forma independente, com o AppQoS aplicado por sessão. Anteriormente, as sessões HTTP/2 eram classificadas apenas como http2, sem qualquer classificação de aplicativo de fluxo filho
Ou seja, para sessões HTTP/2, somente a regra AppQoS da sessão pai pode ser aplicada. No entanto, o HTTP/2 usa vários fluxos, cada um classificado como aplicativos diferentes. As classificações de sessão filho foram ignoradas para correspondência de regras do AppQoS.
Com a nova atualização, a classificação do aplicativo da primeira sessão de fluxo é usada para corresponder e aplicar a regra do AppQoS à sessão pai HTTP/2. Se o aplicativo classificado final do primeiro fluxo não tiver uma regra do AppQoS, a sessão retornará à regra do AppQoS HTTP/2 pai.
Exemplo:
Considere a sessão HTTP/2 que inclui vários fluxos.
- A primeira transmissão é identificada como twitter.
- A regra AppQoS para twitter é aplicada.
- Cada fluxo da sessão pai HTTP/2 herda a regra.
Aqui, os pacotes não vão mais para uma fila http2 genérica; eles vão inteiramente para a fila de aplicativos do primeiro fluxo (Twitter).
Lógica de fallback
O tráfego HTTP/2 é tratado como parte do tráfego HTTP. Se uma regra HTTP/2 estiver ausente, o tráfego retornará à regra HTTP AppQoS para marcação DSCP. Para obter esse fallback, os caminhos de classificação são ajustados conforme mostrado no exemplo a seguir:
Sessão pai
- Comportamento anterior:
ip.tcp.ssl.http2 - Novo comportamento:
ip.tcp.ssl.http.http2
Sessão filho
- Comportamento anterior:
ip.tcp.ssl.http.facebook - Novo comportamento:
ip.tcp.ssl.http.http2.facebook
Lógica de classificação
O AppQoS para HTTP/2 usa uma pesquisa de regra de cima para baixo, começando pelo aplicativo mais específico e voltando por HTTP2, HTTP, SSL e application-any. A classificação da primeira sessão de stream agora é usada para correspondência de regras de sessão pai, garantindo atribuição e registro de QoS precisos.
Mapeamento de conjuntos de regras e aplicativos- Cada política de segurança usa um conjunto de regras com regras específicas do AppQoS para diferentes aplicativos (por exemplo, http, http2, facebook).
- Cada regra atribui uma classe de encaminhamento (Melhor Esforço, Encaminhamento Garantido, Encaminhamento Acelerado, Controle de Rede) e uma fila COS.
- A pesquisa de regras do AppQoS começa no aplicativo mais específico (aplicativo aninhado) e sobe na hierarquia. As sessões (pai/filho) são classificadas usando um caminho hierárquico (exemplo:
ip.tcp.ssl.http.http2.facebook).No exemplo, a sequência de pesquisa é a seguinte:
- Se o aplicativo aninhado (
facebook-chat) não estiver configurado no conjunto de regras, ahttp2regra será aplicada. - Se
http2não estiver configurado, ahttpregra será aplicada. - Se
httpnão estiver configurado, asslregra será aplicada. - Se não houver nenhuma regra do AppQoS para aplicativos classificados, a
application-anyregra será aplicada. - Se
application-anynão estiver configurado, a sessão continuará com a regra DSCP aplicada anteriormente.
Essa classificação garante que as sessões HTTP/2 nunca sejam ignoradas e sempre recebam tratamento de QoS.
- Se o aplicativo aninhado (
Exemplo: um perfil do AppQoS contém regras para aplicativos específicos, além de uma regra abrangente "Qualquer". Por exemplo, o perfil inclui conjuntos de regras para HTTP, Facebook, Yahoo e Any, e o primeiro fluxo é classificado como: Http.http2.twitter
Caso A — "qualquer" regra configurada
- Não existe nenhuma regra explícita do Twitter.
- Como a regra Qualquer está presente, o AppQoS seleciona Qualquer.
- Resultado: a regra Qualquer é aplicada.
Caso B — "qualquer" regra não configurada
- Não existe nenhuma regra explícita do Twitter.
- Nenhuma regra está disponível.
- Nesse caso, o sistema retorna para a próxima melhor correspondência em ordem decrescente de especificidade:
- Regra http2 (se presente)
- Se nenhuma regra http2 → voltar para http
- Se nenhuma regra http → usar a fila padrão
- Resultado: a regra de correspondência mais próxima é selecionada com base na ordem de fallback acima.
- Sessão pai: normalmente classificada em um nível mais alto (exemplo: http2).
- Sessão filho: classificada com aplicativos aninhados mais específicos (exemplo: facebook, twitter).
A classificação da primeira sessão de fluxo agora é considerada para correspondência de regras na sessão pai.
Encaminhamento e registro- O tráfego de cada sessão recebe uma classe de encaminhamento e uma fila com base na regra correspondente.
- As entradas do Syslog refletem a classificação e a correspondência de regra para o fechamento de sessão e fluxo
Limitações
- Para HTTP/2, somente a classificação de aplicativo do primeiro fluxo é usada para correspondência de regras do AppQoS na sessão pai.
- Em sessões de longa duração, as alternâncias de aplicativo midstream (HTTP/1 ou HTTP/2) podem causar alterações na fila de CoS, levando à reordenação de pacotes. A remontagem de TCP em dispositivos finais lida com isso usando números de sequência.
- O HTTP/2 para AppQoS não é suportado em cenários de alta disponibilidade de cluster de chassis e de vários nós.
- Os limitadores de taxa do AppQoS não estão funcionando corretamente para tráfego HTTPS em configurações de tráfego HTTP/1.1 e HTTP/2 quando o proxy de encaminhamento SSL está configurado.
Tráfego criptografado HTTP2
No caso de tráfego criptografado, o módulo HTTP/2 é desabilitado, portanto, nenhuma sessão filho HTTP/2 é criada. O AppQoS é aplicado somente na sessão pai.
Comportamento do AppQoS específico da plataforma
Use o AppQoS e o Explorador de Recursos 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 |
SRX5400, SRX5600 e SRX5800, use a seguinte declaração de configuração para definir nomes de classe de encaminhamento e atribuições de filas: [edit class-of-service] user@host# set forwarding-classes class forwarding-class-name queue-num queue-number |
| Série SRX | SRX300, SRX320, SRX340, SRX345, SRX380, SRX400, SRX440, SRX550M, SRX1500, SRX4100, SRX4200, SRX4600 e vSRX, use a seguinte instrução de configuração para definir nomes de classe de encaminhamento e atribuições de fila: [edit class-of-service] user@host# set forwarding-classes queue queue-number forwarding-class-name |
| Série SRX | SRX300, SRX320, SRX340, SRX345, SRX400, SRX440 usam a loss-priority-highopção na regra do AppQoS para substituir a ação padrão.[edit] user@host# set class-of-service application-traffic-control rule-sets rset-01 rule r1 then rate-limit loss-priority-high |
| Série SRX | SRX5400, SRX5600 e SRX5800 suportam até 1000 limitadores de taxa por dispositivo. No entanto, ele permite apenas 16 perfis distintos, cada um definido por uma combinação exclusiva de limite de largura de banda e parâmetro de limite de tamanho de intermitência. |
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.