Entender os Limites da Fila e as Quedas de Saída nas Plataformas de Software IOS

Introdução

Este documento descreve os Limites de Fila e Quedas de Saída nas plataformas do Cisco IOS® Software e nos roteadores de acesso legados.

Pré-requisitos

Requisitos

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

• Guia de configuração das soluções de qualidade de serviço do Cisco IOS®

• QoS—Estrutura Hierárquica de Enfileiramento (HQF - Hierarchical Queueing Framework);

Componentes Utilizados

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

• Para Pre-HQF: Roteadores Cisco que executam o Cisco IOS Software Release 12.3(26)

• Para HQF: Cisco routers que executam o Cisco IOS Software Release 12.4(22)T

As informações neste documento foram criadas a partir de dispositivos em um ambiente de laboratório específico. Todos os dispositivos utilizados neste documento foram iniciados com uma configuração (padrão) inicial. Se a rede estiver ativa, certifique-se de que você entenda o impacto potencial de qualquer comando.

Conventions

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

Informações de Apoio

Este documento aplica-se somente às plataformas do Cisco IOS® Software, que geralmente inclui os roteadores Cisco 7200VXR e Cisco ISR 3800, 2800, 1800 Series e os roteadores Cisco Access legados que incluem os roteadores das séries 3700, 3600, 2600 e 1700.

Cronômetro de Enfileiramento Moderado Ponderado Baseado em Classe

Em imagens Cisco IOS pré-HQF, qualquer classe com um bandwidth comando pode geralmente ser priorizada em relação a 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 moderadas baseadas em fluxo e específico de classe 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 em uma fila moderada ponderada baseada em classe derivam seus respectivos pesos como uma função do bandwidth comando configurado na classe como uma proporção da SOMA de todas as classes de largura de banda na fila baseada em classe. A fórmula exata é proprietária.

Em imagens HQF, as fair-queues baseadas em fluxo, configuráveis nas classes definidas pelo usuário e no padrão de classe com fair-queue, são programadas igualmente (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 legada das classes.

Observação: esta seção não pretende ser uma análise comportamental abrangente para operações de enfileiramento com base em classe. A intenção é uma explicação de como o CBWFQ aplica limites de fila e quedas de saída.

Entender os limites da fila e as 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 priority comando, com priority, priority <kbps> e priority percent incluídos.

Comportamento Pré-HQF

Tecnicamente, mesmo que não exista uma CLI para visualizá-la e ela não seja configurável, existe uma fila de sistema oculta que é compartilhada por todos os dados de classe de prioridade. Atua como um repositório temporário para dados de prioridade depois de ter sido classificado e depois de ter sido permitido pelo vigilante sensível a congestionamento. Os pacotes LLQ serão colocados nessa fila oculta do sistema 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 LLQ durante a interrupção de recebimento e enquanto ainda é de propriedade do driver de interface de recebimento. Se o pacote não for descartado pelo vigilante condicional LLQ, ele será colocado nessa fila oculta do sistema LLQ e a interrupção de recebimento será liberada. Portanto, todos os pacotes colocados nessa fila oculta do sistema estão em conformidade com o vigilante de reconhecimento de congestionamento de LLQ e podem ser desenfileirados para o anel de transmissão da interface de saída imediatamente pelo agendador LLQ/CBWFQ.

Apesar da existência dessa fila, o comportamento é diferente das filas do Cisco IOS criadas para dados não LLQ (como filas fair-queue e de largura de banda), pois nenhuma latência de enfileiramento adicional (acima da latência do anel de transmissão) pode ocorrer, pois os pacotes nessa fila podem ser imediatamente drenados para o anel de transmissão pelo agendador 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 poderá existir nessa fila de sistema oculta brevemente antes de ser desenfileirado para o anel de transmissão da interface de saída. Nesse caso, o agendador LLQ/CBWFQ pode 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, portanto, seu limite é o LLQ à taxa de prioridade configurada.

Em resumo, é recomendável descartar dados LLQ que excedam a taxa de prioridade em momentos de congestionamento do que incorrer em latência de enfileiramento adicional, que é um componente fundamental do LLQ. Esse mecanismo de vigilância condicional permite uma fila de prioridade estrita e não permite que a fila de prioridade monopolize toda a PLIM da interface, o que é uma melhoria em relação ao recurso de enfileiramento de prioridade legado do Cisco IOS.

• Limite da fila pré-HQF: NA

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

• Prioridade pré-HQF + comportamento "fair-queue": NA, fair-queue não permitido em LLQ.

• Prioridade pré-HQF + detecção aleatória + comportamento de fila justa: NA, nem a fila justa nem a detecção aleatória são suportadas no LLQ.

Comportamento HQF

O mesmo que Pre-HQF, exceto que a fila oculta não está mais oculta e o limite de fila agora é configurável e assume como padrão 64 pacotes.

• Limite de fila HQF: 64 pacotes

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

• Prioridade HQF + comportamento fair-queue: NA, fair-queue não permitido em LLQ.

• Prioridade HQF + detecção aleatória + comportamento de fila justa: NA, nem a fila justa nem a detecção aleatória são suportadas no LLQ.

Classes definidas pelo usuário configuradas com o comando Bandwidth

Para classes definidas pelo usuário MQC configuradas com qualquer variante do bandwidth comando, com bandwidth <kbps> , bandwidth percent e bandwidth remaining percent incluídas.

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, o que resultaria em mais de 64 pacotes na fila, o pacote será descartado na cauda.

• Pre-HQF queue-limit: 64 pacotes, ajustável via queue-limit.

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

Exemplo:

policy-map PRE_HQF_BANDWIDTH_WRED
 class 1
   bandwidth 32
   random-detect

Se qualquer variante da largura de banda for configurada junto com qualquer variante de detecção aleatória, ignore qualquer CLI de limite de fila, que efetivamente remove qualquer limite de buffer na classe. Em outras palavras, random-detect e queue-limit são mutuamente exclusivos em imagens pré-HQF. com random-detect como estratégia de descarte, o tamanho da fila atual é irrestrito e pode, teoricamente, ocupar cada buffer alocado para a 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 de política de serviço:

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

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

• Classe de mapa do Frame Relay: 600 pacotes, ajustáveis com classe de mapa do Frame Relay CLI frame-relay hold-queue

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

Observação: todos os exemplos de modelagem Frame Relay e Class Based supõem que a soma de modeladores não exceda 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 podem ser padronizadas para uma Fila Moderada Ponderada e as interfaces >2Mbps podem ser padronizadas para FIFO. No pré-HQF, a fila de modelagem pode alimentar a fila de espera da interface, independentemente de a política de modelagem estar anexada à subinterface ou ao 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 interface, o tamanho médio da fila de WRED é calculado com 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 de WRED, enfileire o pacote e libere 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 WRED, o pacote será descartado com base no denominador de probabilidade da marca. O denominador de probabilidade de marca também serve como linha de base para determinar qual porcentagem de pacotes pode ser descartada quando o Limite de fila médio não é exatamente igual ao limiar máximo WRED, mas é maior que o limiar mínimo WRED. Este é um exemplo gráfico:

Limite médio da fila não igual ao limite máximo WRED, mas superior ao limite mínimo WRED

• • 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.

  • Maior que o limiar máximo de WRED, descarte o pacote, libere a interrupção de recebimento e incremente uma queda traseira.

Observação: o WRED baseado em precedência de IP (padrão) e baseado em DSCP permite que o limiar mínimo, limiar máximo e denominador de probabilidade de marca sejam definidos de forma diferente 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 ao ajustar seus limites relativos e marcar denominadores de probabilidade.

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 limite máximo de WRED em qualquer ponto no tempo. Isso ocorre porque os limites mínimo e máximo de WRED atuam apenas com base no tamanho médio (não atual) da fila. Isso fornece uma oportunidade para expirar todos os buffers alocados para a Fila Baseada em Classe, o que poderia resultar em quedas sem buffer que acontecem em qualquer lugar dentro da Fila Moderada Baseada em Classe (consulte o bug da Cisco ID CSCsm94757).

• Largura de banda pré-HQF + comportamento fair-queue: NA, fair-queue não permitido na classe bandwidth.

• Largura de banda pré-HQF + detecção aleatória + comportamento de fila moderada: NA, fila moderada não permitida na classe de largura de banda

Comportamento HQF

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

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

Esta situação é idêntica à do anterior QQG.

• Largura de banda do HQF + comportamento de 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 equivalente pré-HQF, com uma exceção importante. Em imagens HQF, random-detect e queue-limit podem coexistir na mesma classe definida pelo usuário (ou class-default) e queue-limit pode ser habilitado e ajustado para 64 pacotes em uma configuração padrão. Como tal, o limite de fila pode servir como um tamanho máximo de fila atual em uma classe de detecção aleatória, portanto, pode fornecer um mecanismo para limitar quedas sem buffer discutidas na seção equivalente pré-HQF. 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, onde o limiar máximo de detecção aleatória pode assumir o padrão de 40 pacotes, ou então o analisador pode rejeitar a configuração.

Isso introduz uma verificação de limite de fila atual nas classes WRED, por meio da qual, 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 de fila, o pacote poderá ser descartado, a interrupção de recebimento liberada e um Descarte Final registrado. Lembre-se, se o limite de fila for ajustado suficientemente alto para esgotar os buffers de enfileiramento agregados para a Fila Baseada em Classe, as quedas sem buffer ainda poderão ocorrer. Os buffers de enfileiramento agregados para HQF são definidos aqui:

• Interface física: 1000 pacotes, ajustáveis com a 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 hold-queue.

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

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

Observação: todos os exemplos de modelagem Frame Relay e Class Based supõem que a soma de modeladores não exceda 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 essa saída, nenhum tráfego é 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 e consiste em quadros de 1000 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 pode ser igual à Profundidade Atual da Fila, que é o comportamento esperado.

• Largura de banda HQF + comportamento fair-queue:

Quando a largura de banda e a fila considerável são aplicadas juntas a uma classe definida pelo usuário do 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 é de 64 pacotes, cada fila baseada em fluxo em uma fila justa pode receber 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 >64 (4 *16). Todos os descartes traseiros de uma fila de fluxo individual são registrados como descartes de fluxo. Se o número de filas de fluxo fosse significativamente alto como era o limite de fila, então outra oportunidade para quedas sem buffer. Por exemplo, se você assumir que o ponto de anexação de política é 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 considerável em todas as filas de fluxo pode privar os buffers de interface agregados e resultar em quedas sem buffer em outras classes definidas pelo usuário (consulte o bug da Cisco ID CSCsw98427). Isso ocorre porque 1.024 filas de fluxo, cada uma com um limite de fila de 32 pacotes, pode facilmente fazer a assinatura excedente da alocação de buffer do Class Based Queuing da interface agregada 1.000.

• Largura de banda de HQF + detecção aleatória + comportamento de fila moderada:

Exemplo:

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

O mesmo que largura de banda e fair-queue na seção, exceto Tamanho médio da fila de WRED, é calculado toda vez que um pacote chega para decidir se ele deve ser descartado aleatoriamente ou descartado por tail. Como no pré-HQF, todas as filas de fluxo podem compartilhar uma instância de limites 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 e, em seguida, a decisão de descarte aplica os limites 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 moderada na seção, porque uma instância dos limites de WRED se aplica a todas as filas baseadas em fluxo, o limite de fila das filas de fluxo individuais (.25 * "limite de fila") é ignorado e, em vez disso, atende ao limite de fila agregado 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 da 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 pode exceder o limite de fila. A quantidade de pacotes enfileirados em cada fila de fluxo pode depender do peso calculado da fila de fluxo. Por outro lado, se fair-queue e random-detect forem usados juntos no padrão de classe, o limite de fila pode ser ignorado e todas as filas de fluxo podem compartilhar os mesmos limites de WRED. Como tal, todos os pacotes atualmente enfileirados em todas as filas de fluxo podem ser usados para calcular o tamanho médio da fila de WRED. Como o tamanho da fila atual não tem limite superior nessa configuração, a oportunidade para descartes sem buffer é alta (consulte o bug da Cisco ID CSCsm94757).

• Se a largura de banda for adicionada ao padrão de classe, isso poderá resultar no comportamento descrito na seção Comportamento Pré-HQF - Classes Definidas pelo Usuário Configuradas com o Comando "bandwidth".

• Se a largura de banda e a detecção aleatória forem adicionadas à classe padrão, isso poderá resultar no comportamento descrito na seção largura de banda Pre-HQF + comportamento de detecção aleatória de Comportamento Pre-HQF - Classes Definidas pelo Usuário Configuradas com o Comando "bandwidth".

Observação: em pré-HQF, a largura de banda não pode coexistir com fair-queue em class-default.

Comportamento HQF

No HQF, o Padrão de Classe é padronizado para uma fila FIFO e é alocada uma reserva de pseudo largura de banda com base nas alocações restantes das Classes Definidas pelo Usuário. Como tal, para o comportamento padrão de classe HQF, consulte a seção Comportamento HQF - Classes Definidas pelo Usuário Configuradas com o Comando "bandwidth". Em todos os momentos, independentemente da configuração, o padrão de classe em imagens HQF pode sempre ter uma reserva de largura de banda implícita igual à largura de banda da interface não utilizada não consumida por classes definidas pelo usuário. Por padrão, a classe class-default 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 estiver configurado em class Class-Default, o comportamento corresponderá à seção de largura de banda de HQF + comportamento de fair-queue de Comportamento de HQF - Classes Definidas pelo Usuário Configuradas com o Comando "bandwidth".

• Se fair-queue e random-detect estiverem configurados juntos no Class-Default, o comportamento corresponde à seção de largura de banda HQF + random-detect + comportamento de fair-queue de HQF - classes definidas pelo usuário 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 - Hierarchical Queueing Framework) [Sem Suporte]
• Suporte a roteadores
• Suporte técnico e downloads da Cisco