O conjunto de documentação deste produto faz o possível para usar uma linguagem imparcial. Para os fins deste conjunto de documentação, a imparcialidade é definida como uma linguagem que não implica em discriminação baseada em idade, deficiência, gênero, identidade racial, identidade étnica, orientação sexual, status socioeconômico e interseccionalidade. Pode haver exceções na documentação devido à linguagem codificada nas interfaces de usuário do software do produto, linguagem usada com base na documentação de RFP ou linguagem usada por um produto de terceiros referenciado. Saiba mais sobre como a Cisco está usando a linguagem inclusiva.
A Cisco traduziu este documento com a ajuda de tecnologias de tradução automática e humana para oferecer conteúdo de suporte aos seus usuários no seu próprio idioma, independentemente da localização. Observe que mesmo a melhor tradução automática não será tão precisa quanto as realizadas por um tradutor profissional. A Cisco Systems, Inc. não se responsabiliza pela precisão destas traduções e recomenda que o documento original em inglês (link fornecido) seja sempre consultado.
Este documento descreve os Limites de Fila e Quedas de Saída nas plataformas do Cisco IOS® Software e nos roteadores de acesso legados.
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);
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
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. Se a rede estiver ativa, certifique-se de que você entenda o impacto potencial de qualquer comando.
Consulte as Convenções de Dicas Técnicas da Cisco para obter mais informações sobre convenções de documentos.
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.
Em imagens do Cisco IOS anteriores ao HQF, qualquer classe com um bandwidth
geralmente pode ser priorizado 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
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.
Para classes definidas pelo usuário MQC configuradas com qualquer variante do priority
, com priority
, priority
,e priority percent
incluídos.
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 da 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 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 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 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 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, ele limita 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
Comportamento pré-HQF "priority" + "random-detect": NA, WRED não permitido no LLQ.
Comportamento pré-HQF "priority" + "fair-queue": NA, fair-queue não permitido em LLQ.
Comportamento pré-HQF "priority" + "random-detect" + "fair-queue": NA, nem fair-queue nem random-detect suportados no LLQ.
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
Comportamento "priority" + "random-detect" de HQF: NA, WRED não permitido em LLQ.
Comportamento HQF "priority" + "fair-queue": NA, fair-queue não permitido em LLQ.
Comportamento HQF "priority" + "random-detect" + "fair-queue": NA, nem fair-queue nem random-detect suportados no LLQ.
Para classes definidas pelo usuário MQC configuradas com qualquer variante do bandwidth
, com bandwidth
, bandwidth percent
,e bandwidth remaining percen t
incluídos.
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áveis via queue-limit.
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:
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).
Comportamento pré-HQF "bandwidth" + "fair-queue":NA, fair-queue não permitido na classe de largura de banda.
Comportamento pré-HQF "bandwidth" + "random-detect" + "fair-queue": NA, fair-queue não permitido na classe de largura de banda
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.
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: 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 à 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 isbeing
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.
Comportamento HQF "bandwidth" + "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.
Comportamento de "largura de banda" HQF + "detecção aleatória" + "fila considerável":
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.
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 em um comportamento descrito na seção de comportamento "largura de banda" + "detecção aleatória" do Pre-HQF Behavior - Classes Definidas pelo Usuário Configuradas com o Comando "largura de banda".
Nota:Em pré-HQF, a largura de banda não pode coexistir com fair-queue em class-default.
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 de HQF, consulte a seção Comportamento de 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 comportamento "bandwidth" + "fair-queue" de HQF Behavior - User Defined Classes Configurated with the "bandwidth" Command.
Se fair-queue e random-detect estiverem configurados juntos no Class-Default, o comportamento corresponde à seção de comportamentoHQF "bandwidth" + "random-detect" + "fair-queue" de HQF Behavior - User Defined Classes Configured com o Comando "bandwidth".
Revisão | Data de publicação | Comentários |
---|---|---|
2.0 |
19-Jan-2023 |
Formato atualizado e alertas corretos do CCW. Recertificação. |
1.0 |
26-Aug-2009 |
Versão inicial |