Entendendo limites de fila e quedas de saída em plataformas do software Cisco IOS

Introduction

Este documento se aplica somente às plataformas do software Cisco IOS®, que geralmente inclui os roteadores Cisco 7200VXR e Cisco ISR 3800, 2800, 1800 Series, assim como os roteadores de acesso Cisco legados, incluindo as séries 3700, 3600, 2600 e 170 roteadores.

Prerequisites

Requirements

A Cisco recomenda que você tenha conhecimento destes tópicos:

• Guia de Configuração de Soluções de Qualidade de Serviço do Cisco IOS

• QoS—Estrutura de Enfileiramento Hierárquico (HQF)

Componentes Utilizados

As informações neste documento são baseadas nestas versões de software:

• Para pré-HQF: Roteadores Cisco que executam o Software Cisco IOS versão 12.3(26)

• Para HQF: Roteadores Cisco que executam o Software Cisco IOS versão 12.4(22)T

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.

Conventions

Consulte as Convenções de Dicas Técnicas da Cisco para obter mais informações sobre convenções de documentos.

Temporizador de enfileiramento moderado ponderado baseado em classe

Em imagens do IOS pré-HQF, em geral, qualquer classe com um comando bandwidth geralmente será priorizada em relação às classes sem largura de banda ou prioridade com base no peso das classes. Para entender o algoritmo de programação CBWFQ (Class-Based Weighted Fair Queueing), você deve primeiro entender o conceito de um peso, que é específico de fluxo para filas justas baseadas em fluxo e específico para filas baseadas em classe individuais dentro da fila moderada ponderada baseada em classe.

A fórmula para derivar o peso de uma Fila Justa Baseada em Fluxo é:

32384 / (IP Prec + 1)

As classes definidas pelo usuário dentro de uma fila baseada em classe e ponderada derivam seus respectivos pesos como uma função do comando bandwidth configurado na classe como uma proporção do SUM de todas as classes de largura de banda na Fila baseada em classe. A fórmula exata é proprietária.

Nas imagens HQF, as filas justas baseadas em fluxo, configuráveis em classes definidas pelo usuário e padrão de classe com fila justa, são igualmente programadas (em vez de por Peso). Além disso, no HQF, a prioridade de agendamento de uma Fila Baseada em Classe é determinada com base no agendador HQF e não na fórmula de Peso legado das classes.

Observação: esta seção não se destina a ser uma análise comportamental abrangente para operações de enfileiramento baseado em classe. A intenção é uma breve educação, pois o CBWFQ se aplica à compreensão dos limites da fila e das quedas de saída.

Entendendo limites de fila e quedas de saída

Classes definidas pelo usuário configuradas com o comando "priority"

Para classes definidas pelo usuário MQC configuradas com qualquer variante do comando priority, incluindo prioridade, prioridade <kbps> e prioridade por cento.

Comportamento pré-HQF

Tecnicamente, embora não exista nenhuma CLI para vê-la, e ela não seja configurável, existe uma fila de sistema "oculta" que é compartilhada por todos os dados de classe de prioridade. Funciona como uma área de retenção para dados de prioridade depois de classificados e depois de permitidos pelo vigilante com reconhecimento de congestionamento. Os pacotes LLQ são colocados nessa fila de sistema "oculta" se não puderem ser colocados diretamente no anel de transmissão da interface de saída durante a interrupção de recebimento, que é chamada de congestionamento funcional. Nessa situação, como existe congestionamento funcional, o pacote é avaliado em relação ao vigilante condicional de LLQ durante a interrupção de recebimento enquanto ainda pertence ao driver da interface de recebimento. Se o pacote não for descartado pelo vigilante condicional do LLQ, ele será colocado nessa fila de sistema LLQ "oculta" e a interrupção de recebimento será liberada. Portanto, todos os pacotes colocados nessa fila de sistema "oculta" estão em conformidade com o vigilante de reconhecimento de congestionamento do LLQ e serão removidos da fila para o anel de transmissão da interface de saída imediatamente pelo programador LLQ/CBWFQ.

Apesar da existência dessa fila, o comportamento é diferente das filas do IOS criadas para dados não-LLQ (como fila justa e filas de largura de banda), pois não haverá latência de enfileiramento adicional (acima da latência do anel de transmissão), pois os pacotes nessa fila serão imediatamente drenados para o anel de transmissão pelo programador LLQ/CBWFQ. Se um pacote de classe de prioridade não for descartado pelo vigilante condicional durante a interrupção de recebimento, esse pacote LLQ existirá nessa fila de sistema "oculta" brevemente antes de ser removido do anel de transmissão da interface de saída. Nesse caso, o agendador LLQ/CBWFQ apresentará imediatamente o pacote ao anel de transmissão da interface de saída. O vigilante condicional foi executado antes de admitir o pacote ao LLQ/CBWFQ, limitando assim o LLQ à taxa de prioridade configurada.

Em resumo, é recomendável descartar dados de LLQ que excedam a taxa de prioridade durante períodos de congestionamento do que incorrer em latência de enfileiramento adicional, que é um componente fundamental de LLQ. Esse mecanismo de vigilância condicional permite uma fila de prioridade estrita sem permitir que a fila de prioridade monopolize todo o PLIM da interface, o que é uma melhoria em relação ao recurso de enfileiramento de prioridade herdado do IOS.

• Limite de fila pré-HQF: NA

• Comportamento de "prioridade" pré-HQF + "detecção aleatória": NA, WRED não permitido em LLQ.

• Comportamento de "prioridade" pré-HQF + "fila justa": NA, fair-queue não é permitido em LLQ.

• Comportamento de "prioridade" pré-HQF + "detecção aleatória" + "fila justa": NA, não há suporte para fair-queue ou random-detect no LLQ.

Comportamento de HQF

Igual ao pré-HQF, exceto que a fila oculta não está mais oculta e o limite da fila agora é configurável e o padrão é 64 pacotes.

• Limite de fila HQF: 64 pacotes

• Comportamento de "prioridade" de HQF + "detecção aleatória": NA, WRED não permitido em LLQ.

• Comportamento de "prioridade" de HQF + "fila justa": NA, fair-queue não é permitido em LLQ.

• Comportamento de "prioridade" de HQF + "detecção aleatória" + "fila justa": NA, não há suporte para fair-queue ou random-detect no LLQ.

Classes definidas pelo usuário configuradas com o comando "bandwidth"

Para classes definidas pelo usuário MQC configuradas com qualquer variante do comando bandwidth, incluindo largura de banda <kbps> , largura de banda por cento e largura de banda restante por cento.

Comportamento pré-HQF

O limite de fila padrão é de 64 pacotes, que é ajustável. Se, durante a interrupção de recebimento, você precisar enfileirar um pacote que resultaria em > 64 pacotes na fila, o pacote será descartado.

• Limite de fila pré-HQF: 64 pacotes, ajustáveis via limite de fila.

• Comportamento de "largura de banda" pré-HQF + "detecção aleatória":

  Exemplo:

  policy-map PRE_HQF_BANDWIDTH_WRED
   class 1
     bandwidth 32
     random-detect

  Se qualquer variante de largura de banda for configurada juntamente com qualquer variante de detecção aleatória, ignore qualquer CLI de limite de fila, que efetivamente remova qualquer limite de buffer na classe. Em outras palavras, detecção aleatória e limite de fila são mutuamente exclusivos em imagens pré-HQF. Usando a detecção aleatória como estratégia de descarte, o tamanho da fila atual é irrestrito e pode, teoricamente, ocupar cada buffer alocado à fila justa baseada em classe, onde esse número de buffers alocados para a fila justa baseada em classe é derivado com base no ponto de anexação da política de serviço:

  • Interface física: 1000 pacotes, ajustáveis com interface CLI hold-queue out

  • PVC ATM: 500 pacotes, ajustáveis com PVC CLI vc-hold-queue

  • Frame-Relay map-class: 600 pacotes, ajustáveis com frame-relay map-class CLI frame-relay holdq

  • Política de modelagem baseada em classe aplicada à (sub)interface (pré-HQF): 1.000 pacotes, ajustáveis com buffers máx de forma CLI de classe MQC.

  Observação: todos os exemplos de modelagem Frame Relay e Class Based presumem que a soma de modeladores não excede a taxa de clock da interface.

  Observação: em imagens pré-HQF, quando uma política de modelagem baseada em classe é aplicada a uma (sub)interface, tenha cuidado com a velocidade da interface física subjacente, pois as interfaces <2Mbps terão como padrão uma fila moderada ponderada e as interfaces >2Mbps terão como padrão FIFO. No pré-HQF, a fila de modelagem alimentará a fila de espera da interface, independentemente de a política de modelagem estar conectada na subinterface ou no nível da interface física.

  Durante a interrupção de recebimento, cada vez que um pacote se torna candidato para uma fila de saída de uma interface, o tamanho médio da fila WRED é calculado usando esta fórmula:

  Average Queue Size = (old_average * (1-1/2^n)) + (current_queue_size * 1/2^n)

  Se o tamanho médio da fila resultante for:

  • Menor que o limiar mínimo WRED, enfileire o pacote e libera a interrupção de recebimento.

  • Entre o limiar mínimo de WRED e o limiar máximo de WRED, possivelmente descarte o pacote com maior probabilidade à medida que o Tamanho médio da fila se aproxima do limiar máximo de WRED. Se o tamanho médio da fila for exatamente igual ao limiar máximo de WRED, o pacote será descartado de acordo com o denominador de probabilidade da marca. O denominador de probabilidade de marca também serve como linha de base para determinar qual porcentagem de pacotes será descartada quando o limite médio de fila não for exatamente igual ao limite máximo de WRED, mas for maior que o limiar mínimo de WRED. Este é um exemplo gráfico:

    

    Se o pacote for descartado, a interrupção de recebimento será liberada e uma queda aleatória será incrementada. Se o pacote não for descartado, ele será enfileirado e a interrupção de recebimento será liberada.

  • Mais alto que o limiar máximo de WRED, descarte o pacote, libera a interrupção de recebimento e incremente uma queda de cauda.

• Observação: IP Precedence based (default) e DSCP-based WRED permitem que o limiar mínimo, limiar máximo e o denominador de probabilidade de marca sejam definidos diferentemente para valores diferentes. É aqui que o componente Ponderado da Detecção Antecipada Aleatória é evidente. Você pode proteger determinados valores de ToS relativos a outros valores por meio do ajuste de seus limiares relativos e dos denominadores de probabilidade de marca.

  Quando a detecção aleatória e a largura de banda são configuradas juntas, o Tamanho da Fila Atual pode ser maior que o limiar máximo WRED em qualquer momento específico. Isso ocorre porque os limites mínimo e máximo de WRED só tomam medidas com base no tamanho médio (não atual) da fila. Isso oferece uma oportunidade de expirar todos os buffers alocados para a Fila Baseada em Classe, o que pode resultar em descartes sem buffer ocorrendo em qualquer lugar dentro da Fila Justa Baseada em Classe (consulte o bug da Cisco ID CSCsm94757).

• Comportamento de "largura de banda" pré-HQF + "fila justa": NA, fair-queue não é permitido na classe de largura de banda.

• Comportamento de "largura de banda" pré-HQF + "detecção aleatória" + "fila justa": NA, fair-queue não é permitido na classe de largura de banda

Comportamento de HQF

O comportamento é o mesmo descrito na seção Pre-HQF.

• Limite de fila HQF: 64 pacotes, ajustáveis via limite de fila.

  Isso é o mesmo que no pré-HQF.

• Comportamento de "largura de banda" de HQF + "detecção aleatória":

  Exemplo:

  policy-map HQF_BANDWIDTH_WRED
   class 1
     bandwidth 32
     queue-limit 512
     random-detect

  Observação: o limite de fila padrão é de 64 pacotes.

  O comportamento é o mesmo que na seção pré-HQF correspondente, com uma exceção importante. Nas imagens HQF, a detecção aleatória e o limite de fila podem coexistir na mesma classe definida pelo usuário (ou classe padrão) e o limite de fila será ativado e ajustado para 64 pacotes em uma configuração padrão. Como tal, o limite de fila servirá como um tamanho máximo de fila atual em uma classe de detecção aleatória, fornecendo, portanto, um mecanismo para limitar as quedas sem buffer discutidas na seção pré-HQF correspondente. Devido a essa adição, o limite de fila configurado deve ser pelo menos tão grande quanto o limiar máximo de detecção aleatória, em que o limiar máximo de detecção aleatória assumirá como padrão 40 pacotes, caso contrário, o analisador rejeitará a configuração.

  Isso introduz uma verificação de limite de fila atual em classes WRED, em que, mesmo se o cálculo de Profundidade Média da Fila for menor que o limite máximo, se o Tamanho da Fila Atual (não Médio) for maior que o limite da fila, o pacote será descartado, a interrupção de recebimento liberada e uma Queda de Tail registrada. Lembre-se de que, se o limite de fila for ajustado suficientemente alto para esgotar os buffers de enfileiramento agregados para a Fila Baseada em Classe, ainda podem ocorrer quedas de nenhum buffer. Os buffers de enfileiramento agregado para HQF são definidos aqui:

  • Interface física: 1000 pacotes, ajustáveis com interface CLI hold-queue out

  • PVC ATM: 500 pacotes, ajustáveis com PVC CLI vc-hold-queue

  • Frame-Relay map-class: 600 pacotes, ajustáveis com frame-relay map-class CLI frame-relay holdq

  • Política de modelagem baseada em classe aplicada à interface física no código HQF: 1000 pacotes, ajustáveis com uma combinação de interface CLI hold-queue out e child policy queue-limit, em que o limite de filas de políticas filho tem um limite superior de fila de espera da interface.

  • Política de modelagem baseada em classe aplicada à subinterface no código HQF: 512 pacotes, não ajustáveis (investigue com a equipe de plataforma de QoS do NSSTG, caso seja ajustável)

    Observação: todos os exemplos de modelagem Frame Relay e Class Based presumem que a soma de modeladores não excede a taxa de clock da interface.

    Aqui está um exemplo real:

    policy-map JACKLYN
     class 1
        bandwidth 64
        queue-limit 500 packets
         random-detect
         random-detect precedence 1 22 300

    Durante esta saída, nenhum tráfego está sendo gerado através da interface:

    F340.11.25-7200-5_LAC#show policy-map interface | i queue      
          queue limit 500 packets
          (queue depth/total drops/no-buffer drops) 0/387595/0
    
    !--- Current_q_depth is 0
    
            Mean queue depth: 107 packets
    
    !--- last calculation of Average_queue_depth
    
    

    Neste ponto, o tráfego é iniciado. O fluxo não é intermitente a 400PPS, consistindo em quadros de 1.000 bytes:

    F340.11.25-7200-5_LAC#show policy-map interface | i queue
          queue limit 500 packets
          (queue depth/total drops/no-buffer drops) 461/387641/0
    
    !--- 461 is Current_q_depth > Prec 1 max-thresh of 300 !--- but < "queue-limit 500 packets".
    
            Mean queue depth: 274 packets
    
    !--- Avg_q_depth is rising, Mark Prob Denom is being used.
    
      
    F340.11.25-7200-5_LAC#show policy-map interface | i queue
          queue limit 500 packets
          (queue depth/total drops/no-buffer drops) 363/387919/0
    
    !--- 363 is Current_q_depth and it is falling compared to last !--- iteration because WRED is random dropping packets.
    
            Mean queue depth: 351 packets
    
    !--- Avg_q_depth is now above max_thresh, WRED starts to tail-drop !--- in addition to random-drop.
    
       
    F340.11.25-7200-5_LAC#show policy-map interface | i queue
          queue limit 500 packets
          (queue depth/total drops/no-buffer drops) 199/388263/0
            Mean queue depth: 312 packets
      
    F340.11.25-7200-5_LAC#show policy-map interface | i queue
          queue limit 500 packets
          (queue depth/total drops/no-buffer drops) 303/388339/0
            Mean queue depth: 276 packets
        
    F340.11.25-7200-5_LAC#show policy-map interface | i queue
          queue limit 500 packets
          (queue depth/total drops/no-buffer drops) 325/388498/0
            Mean queue depth: 314 packets
    
    F340.11.25-7200-5_LAC#show policy-map interface | i queue
          queue limit 500 packets
          (queue depth/total drops/no-buffer drops) 298/390075/0
            Mean queue depth: 300 packets

    Observe como, eventualmente, com um fluxo não intermitente, a Profundidade Média da Fila WRED será igual à Profundidade da Fila Atual, que é o comportamento esperado.

• Comportamento de "largura de banda" de HQF + "fila justa":

  Quando a largura de banda e a fila justa são aplicadas juntas a uma classe definida pelo usuário HQF, cada fila baseada em fluxo recebe um limite de fila igual a 0,25 * limite de fila. Como o limite de fila padrão é 64 pacotes, cada fila baseada em fluxo em uma fila justa será alocada para 16 pacotes. Se quatro fluxos atravessassem essa classe, por padrão cada fila de fluxo teria 16 pacotes, portanto, você nunca esperaria ver o total de pacotes enfileirados de >64 (4 *16). Todas as quedas traseiras de uma fila de fluxo individual são registradas como quedas de fluxo. Se o número de filas de fluxo era significativamente alto como era o limite de fila, então outra oportunidade para quedas sem buffer. Por exemplo, supondo que o ponto de conexão da política seja uma interface física, onde 1000 buffers agregados são alocados:

  policy-map TEST
   class 1
    bandwidth 32
    fair-queue 1024
    queue-limit 128

  Nesta configuração, o tráfego apreciável em todas as filas de fluxo pode sobrecarregar os buffers de interface agregada e resultar em descartes sem buffer em outras classes definidas pelo usuário (consulte o ID de bug Cisco CSCsw98427). Isso ocorre porque 1024 filas de fluxo, cada uma com um limite de 32 pacotes de fila podem facilmente sobrescrever a alocação de buffer de enfileiramento baseado em classe de interface agregada de 1000.

• Comportamento de "largura de banda" de HQF + "detecção aleatória" + "fila justa":

  Exemplo:

  policy-map TEST
   class 1
    bandwidth 32
    fair-queue 1024
    queue-limit 128
    random-detect

  Igual à largura de banda e à fila justa na seção, exceto que o tamanho médio da fila WRED é calculado toda vez que um pacote chega para decidir se o pacote deve ser descartado aleatoriamente ou descartado traseiro. Como no pré-HQF, todas as filas de fluxo compartilharão uma instância dos limiares de WRED, o que significa que todos os pacotes enfileirados para todas as filas de fluxo são usados para calcular a profundidade média da fila de WRED. Em seguida, a decisão de descarte aplica os limiares mínimo e máximo de WRED em relação aos pacotes agregados em todas as filas de fluxo. No entanto, outra saída da largura de banda e da fila justa na seção, porque uma instância dos limiares de WRED se aplica a todas as filas baseadas em fluxo, o limite de fila das filas de fluxo individuais ( 0,25 * "limite de fila") é ignorado e, em vez disso, honra o limite de fila agregada de classes para uma verificação de Limite de fila atual.

Comportamento padrão da classe

Comportamento pré-HQF

No pré-HQF, o padrão de Classe é fair queue, todas as filas de fluxo compartilham o limite de fila para a classe (o padrão é 64) e não há reserva de largura de banda. Em outras palavras, o número total de pacotes enfileirados em todas as filas de fluxo nunca excederá o limite da fila. A quantidade de pacotes enfileirados em cada fila de fluxo dependerá do peso calculado da fila de fluxo. Por outro lado, se fair-queue e random-detect forem usados em conjunto no padrão de classe, o queue-limit será ignorado e todas as filas de fluxo compartilharão os mesmos limiares WRED. Como tal, todos os pacotes atualmente enfileirados em todas as filas de fluxo serão usados para calcular o tamanho médio da fila WRED. Como o tamanho da fila atual não tem limite máximo nesta configuração, a oportunidade para quedas sem buffer é alta (consulte o bug da Cisco ID CSCsm94757).

• A adição de largura de banda ao padrão de classe resultará no comportamento descrito na seção Comportamento pré-HQF - Classes definidas pelo usuário configuradas com o comando "bandwidth".

• A adição de largura de banda e detecção aleatória ao padrão de classe resultará no comportamento descrito na seção de comportamento "largura de banda" pré-HQF + "detecção aleatória" de Comportamento pré-HQF - Classes definidas pelo usuário configuradas com o comando "bandwidth".

Observação: no pré-HQF, a largura de banda não pode coexistir com a fila justa no padrão de classe.

Comportamento de HQF

No HQF, o Padrão de Classe assume como padrão uma fila FIFO e recebe uma reserva de pseudolargura de banda com base nas alocações de sobra das Classes Definidas pelo Usuário. Como tal, para o comportamento padrão de classe de HQF classe padrão, consulte a seção Comportamento de HQF - Classes Definidas pelo Usuário Configuradas com o Comando "bandwidth". Em qualquer momento, independentemente da configuração, class class-default em imagens HQF sempre terá uma reserva de largura de banda implícita igual à largura de banda não utilizada da interface não consumida pelas classes definidas pelo usuário. Por padrão, a classe padrão da classe recebe um mínimo de 1% da largura de banda da interface ou da forma pai. Também é possível configurar explicitamente a CLI da largura de banda no padrão da classe.

• Se fair-queue for configurado na classe Class-Default, o comportamento corresponde à seção de comportamento HQF "bandwidth" + "fair-queue" do Comportamento HQF - Classes Definidas pelo Usuário Configuradas com o Comando "bandwidth".

• Se fair-queue e random-detect forem configurados juntos em Class-Default, o comportamento corresponde à seção de comportamento HQF "bandwidth" + "random-detect" + "fair-queue" do HQF Behavior - User Defined Classes Configuradas com o Comando "bandwidth".

Informações Relacionadas

• Guia de configuração de soluções de qualidade de serviço do Cisco IOS, versão 12.2SR
• QoS—Estrutura de Enfileiramento Hierárquico (HQF)
• Suporte da tecnologia de QoS
• Suporte de produto dos roteadores
• Suporte Técnico e Documentação - Cisco Systems