Contents

Introduction

Prerequisites

Requirements

Componentes Utilizados

Conventions

Diagrama de Rede

Como definir o limite de toque de transmissão

Impacto da transmissão de limite de anel

Exemplo A

Exemplo B

Como calcular o peso

Como calcular o tempo de agendamento

Como funciona o WFQ

O que é uma partícula?

Teste A

Teste B

Estágio 1

Estágio 2

Estágio 3

Estágio 4

Summary

Informações Relacionadas

Introduction

Este documento fornece uma introdução ao enfileiramento de tráfego que usa a tecnologia WFQ (Weighted Fair Queuing).

O WFQ foi introduzido para permitir enlaces de velocidade lenta, como enlaces seriais, para proporcionar um tratamento justo para todos os tipos de tráfego. Para fazer isso, o WFQ classifica o tráfego em diferentes fluxos (também conhecidos como conversas) com base nas informações das camadas três e quatro, como endereços IP e portas TCP. Ele faz isso sem a exigência de você para definir listas de acesso. Isso significa que o tráfego de baixa largura de banda tem efetivamente prioridade sobre o tráfego de alta largura de banda porque o tráfego de alta largura de banda compartilha a mídia de transmissão proporcionalmente ao peso atribuído.

Mas o WFQ tem certas limitações:

- Não é escalável se a quantidade de fluxo aumentar consideravelmente.

- O WFQ nativo não está disponível em interfaces de alta velocidade como as interfaces ATM.

O CBWFQ (Enfileiramento moderado ponderado baseado em classe) fornece uma solução para essas limitações.

A contrário do WFQ padrão, o CBWFQ permite definir classes de tráfego. Você também pode aplicar parâmetros, como largura de banda e limites de fila, a eles. A largura de banda atribuída a uma classe é usada para calcular o peso dessa classe. O peso de cada pacote que atende aos critérios de classe também é calculado a partir disso. O WFQ é então aplicado às classes, que podem incluir vários fluxos, em vez dos próprios fluxos.

Consulte estes documentos para obter mais informações sobre como configurar o CBWFQ:

- Enfileiramento moderado ponderado por classe por VC (CBWFQ por VC) nos roteadores Cisco 7200, 3600 e 2600

- Per-VC Class-Based, Weighted Fair Queuing em plataformas baseadas em RSP

As interfaces ATM não suportam WFQ baseado em fluxo nativo configurado diretamente em uma interface com o comando fair-queue. Mas, com o software que suporta CBWFQ, você pode configurar o WFQ baseado em fluxo dentro da classe padrão, como mostrado neste exemplo:

policy-map test

class class-default

fair-queue

!

interface ATMx/y.z point-to-point

ip address a.b.c.d M.M.M.M

pvc A/B

service-policy output test

Prerequisites

Requirements

Não existem requisitos específicos para este documento.

Componentes Utilizados

Este documento não se restringe a versões de software e hardware específicas.

Conventions

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

Diagrama de Rede

Use esta configuração para ilustrar como o WFQ funciona:

Nessa configuração, os pacotes podem ser armazenados em uma destas duas filas:

- A fila de hardware first in first out (FIFO) no adaptador de porta e no módulo de rede

- A fila no software Cisco IOS®, na memória de entrada/saída [E/S] do roteador, onde os recursos de Qualidade de Serviço (QoS), como CBWFQ, podem ser aplicados

A fila de FIFO no adaptador de porta armazena os pacotes que eles sejam segmentados em células para transmissão. Quando a fila está cheia, o adaptador de porta ou o módulo de rede sinaliza para o software IOS que a fila está congestionada. Esse mecanismo é chamado de contrapressão. Ao receber esse sinal, o roteador para de enviar pacotes para a fila FIFO da interface e armazena os pacotes no software IOS até que a fila fique descongestionada novamente. Quando os pacotes são armazenados no IOS, o sistema pode aplicar a QoS.

Como definir o limite de toque de transmissão

Um problema com esse mecanismo de enfileiramento é que, quanto maior a fila de FIFO na interface, maior o atraso antes que os pacotes do final dessa fila possam ser transmitidos. Isso pode causar problemas sérios de desempenho no tráfego sensível a retardos, como tráfego de voz.

O comando tx-ring-limit do Circuito Virtual Permanente (PVC) possibilita reduzir o tamanho da fila de FIFO.

interface ATMx/y.z point-to-point

ip address a.b.c.d M.M.M.M

PVC A/B

tx-ring-limit

service-policy output test

O <tamanho> que você pode especificar aqui é um número de pacotes, para os roteadores Cisco 2600 e 3600, ou uma quantidade de partículas, para os roteadores Cisco 7200 e 7500.

A redução do tamanho do anel de transmissão tem dois benefícios:

- Reduz a quantidade de tempo que os pacotes aguardam na fila FIFO antes de serem segmentados.

- Acelera o uso do QoS no software IOS.

Impacto da transmissão de limite de anel

Examine o impacto do limite do anel de transmissão que usa a configuração mostrada no diagrama de rede anterior. Considere estes:

- O gerador de tráfego envia tráfego (pacotes de 1.500 bytes) para o dispositivo de coleta e esse tráfego sobrecarrega o PVC 0/102 entre o roteador 1 e o roteador 2.

- O Roteador 3 tenta o ping para o Roteador 1.

- O WFQ está habilitado no roteador 2.

Examine duas configurações que usam diferentes limites do anel de transmissão para ver o impacto que isso tem.

Exemplo A

Neste exemplo, você define o anel de transmissão como três (tx-ring-limit=3). Isso é o que você vê ao fazer ping no roteador 1 a partir do roteador 3:

pound#ping ip

Target IP address: 6.6.6.6

Repeat count [5]: 100000

Datagram size [100]:

Timeout in seconds [2]:

Extended commands [n]:

Sweep range of sizes [n]:

Type escape sequence to abort.

Sending 100000, 100-byte ICMP Echos to 6.6.6.6, timeout is 2 seconds:

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!![snip]

Success rate is 98 percent (604/613), round-trip min/avg/max = 164/190/232 ms

router2#show queue atm 4/0.102

Interface ATM4/0.102 VC 0/102

Queuing strategy: weighted fair

Total output drops per VC: 1505772

Output queue: 65/512/64/1505772 (size/max total/threshold/drops)

Conversations  2/3/16 (active/max active/max total)

Reserved Conversations 0/0 (allocated/max allocated)

(depth/weight/discards/tail drops/interleaves) 1/32384/0/0/0

Conversation 2, linktype: ip, length: 58

source: 8.0.0.1, destination: 6.6.6.6, id: 0x2DA1, ttl: 254, prot: 1

!--- ping

(depth/weight/discards/tail drops/interleaves) 64/32384/1505776/0/0

Conversation 15, linktype: ip, length: 1494

source: 7.0.0.1, destination: 6.6.6.6, id: 0x0000, ttl: 63, prot: 255

!--- This is traffic from the traffic generator.

Exemplo B

Neste exemplo, você define o anel de transmissão como 40 (tx-ring-limit=40). Isso é o que você vê quando usa o mesmo ping do Exemplo A:

pound#ping ip

Target IP address: 6.6.6.6

Repeat count [5]: 10000

Datagram size [100]: 36

Timeout in seconds [2]: 10

Extended commands [n]:

Sweep range of sizes [n]:

Type escape sequence to abort.

Sending 10000, 36-byte ICMP Echos to 6.6.6.6, timeout is 10 seconds:

!!!!!!!!!!!!.

Success rate is 92 percent (12/13), round-trip min/avg/max = 6028/6350/6488 ms

Como você pode observar aqui, quanto maior o limite do anel de transmissão, maior será o tempo de RTT (ping round trip). Você pode deduzir disso que um grande limite de anel de transmissão pode levar a atrasos significativos na transmissão.

Como calcular o peso

Na saída show queue atm no Exemplo A, você vê que um peso é atribuído a cada conversação. Veja isso com mais detalhes:

router2#show queue ATM 4/0.102

Interface ATM4/0.102 VC 0/102

Queuing strategy: weighted fair

Total output drops per VC: 1505772

Output queue: 65/512/64/1505772 (size/max total/threshold/drops)

Conversations  2/3/16 (active/max active/max total)

Reserved Conversations 0/0 (allocated/max allocated)

(depth/weight/discards/tail drops/interleaves) 1/32384/0/0/0

Conversation 2, linktype: ip, length: 58

source: 8.0.0.1, destination: 6.6.6.6, id: 0x2DA1, ttl: 254, prot: 1

(depth/weight/discards/tail drops/interleaves) 64/32384/1505776/0/0

Conversation 15, linktype: ip, length: 1494

source: 7.0.0.1, destination: 6.6.6.6, id: 0x0000, ttl: 63, prot: 255

Ao usar o WFQ, você pode calcular o peso de cada conversação com o uso desta fórmula:

- weight=32384/(precedence+1) - para o Cisco IOS Software Release 12.0(5)T e posterior.

- weight=4096/(precedence+1) - para Cisco IOS Software Releases anteriores a 12.0(5)T.

Como calcular o tempo de agendamento

Agora você pode usar esses pesos para calcular o tempo de agendamento de cada pacote, quando o pacote é encaminhado da fila do IOS para o adaptador de porta ou a fila FIFO do módulo de rede.

Você pode calcular o tempo de programação de saída com o uso desta fórmula, em que queue_tail_time é o tempo de programação atual:

output scheduling time= queue_tail_time + pktsize*weight

Como funciona o WFQ

Esta seção explica como o WFQ funciona. O princípio do WFQ é que os pacotes com um peso pequeno, ou pacotes pequenos, devem ter prioridade quando são enviados.

Crie um fluxo que inclua dez pacotes grandes e quatro pacotes menores (de 82 bytes) que usem um gerador de tráfego para verificar isso.

Neste exemplo, o roteador 2 é um roteador Cisco 7200 com um PA-A3 (adaptador de porta ATM). Isso é importante porque o tamanho da fila FIFO de saída no adaptador de porta é expresso em partículas e não em pacotes. Consulte o que é uma partícula? para obter mais informações.

O que é uma partícula?

Em vez da alocação de uma parte da memória contígua para um buffer, o buffer de partículas aloca pedaços de memória não contíguos (dispersos), chamados de partículas, e os une para formar um buffer de pacote lógico. Isso é chamado de um buffer de partícula. Em tal esquema, um pacote pode então se espalhar em várias partículas.

No roteador 7200, o tamanho da partícula é de 512 bytes.

Use o comando show buffers para verificar se os roteadores Cisco 7200 usam partículas:

router#show buffers

[snip]

Private particle pools:

FastEthernet0/0 buffers, 512 bytes (total 400, permanent 400):

0 in free list (0 min, 400 max allowed)

400 hits, 0 fallbacks

400 max cache size, 271 in cache

ATM2/0 buffers, 512 bytes (total 400, permanent 400):

0 in free list (0 min, 400 max allowed)

400 hits, 0 fallbacks

400 max cache size, 0 in cache

Teste A

Estes são alguns testes para ilustrar a funcionalidade WFQ. Neste primeiro teste, verifique se a largura de banda pode ser compartilhada entre diferentes conversações.

Neste teste, você fez com que o gerador de tráfego enviasse o tráfego com rapidez suficiente para sobrecarregar o PVC 0/102 entre o roteador 1 e o roteador 2. Execute um ping do roteador 3 para o roteador 1 através do mesmo PVC:

pound#ping ip

Target IP address: 6.6.6.6

Repeat count [5]: 100000

Datagram size [100]:

Timeout in seconds [2]:

Extended commands [n]:

Sweep range of sizes [n]:

Type escape sequence to abort.

Sending 100000, 100-byte ICMP Echos to 6.6.6.6, timeout is 2 seconds:

......... (WFQ is enabled here)!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!.[break]

Success rate is 98 percent (604/613), round-trip min/avg/max = 164/190/232 ms

Como você pode ver na saída mostrada, até que o WFQ seja ativado na interface, o tráfego impede que outro tráfego passe e a linha chegue à frente. Assim que o WFQ for habilitado, o ping será bem-sucedido.

Você pode ver a partir disso que, com o uso do WFQ, a largura de banda pode ser compartilhada entre diferentes conversas sem que uma bloqueie as outras.

Teste B

É assim que a largura de banda é compartilhada.

O fluxo que o gerador de tráfego envia é um burst composto de dez pacotes grandes, seguido por quatro pacotes menores de 82 bytes. Você envia isso a 100 Mbps para o roteador 2. Quando você envia a intermitência, a fila de saída na interface ATM do roteador 2 está vazia. O Roteador 2 envia esses pacotes através de um PVC de 10 KB (este é um PVC muito lento) para garantir que o congestionamento ocorra na fila de saída.

Faça este teste em várias etapas para simplificar este processo:

Estágio 1

O grande tráfego compreende dez pacotes de 482 bytes. Como as partículas em PA-A3 são de 512 bytes, cada pacote, seja grande ou pequeno, deve pegar uma partícula quando for armazenado na fila de saída do adaptador da porta. O roteador possui um limite de anel de transmissão de três (limite de anel de TX=3). Este é um exemplo do que você pode ver no dispositivo de dissipação:

.Nov  7 15:39:13.776: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, len 482, rcvd 4

.Nov  7 15:39:13.776: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 482, unknown protocol

.Nov  7 15:39:14.252: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 482, rcvd 4

.Nov  7 15:39:14.252: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 482, unknown protocol

.Nov  7 15:39:14.732: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 482, rcvd 4

.Nov  7 15:39:14.732: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 482, unknown protocol

.Nov  7 15:39:15.208: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 482, rcvd 4

.Nov  7 15:39:15.208: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 482, unknown protocol

!--- Congestion occurs at this point.

.Nov  7 15:39:15.512: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 82, rcvd 4

.Nov  7 15:39:15.516: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 82, unknown protocol

.Nov  7 15:39:15.644: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 82, rcvd 4

.Nov  7 15:39:15.644: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 82, unknown protocol

.Nov  7 15:39:15.776: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 82, rcvd 4

.Nov  7 15:39:15.776: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 82, unknown protocol

.Nov  7 15:39:15.904: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 82, rcvd 4

.Nov  7 15:39:15.904: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 82, unknown protocol

.Nov  7 15:39:16.384: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 482, rcvd 4

.Nov  7 15:39:16.384: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 482, unknown protocol

.Nov  7 15:39:16.860: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 482, rcvd 4

.Nov  7 15:39:16.860: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 482, unknown protocol

.Nov  7 15:39:17.340: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 482, rcvd 4

.Nov  7 15:39:17.340: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 482, unknown protocol

.Nov  7 15:39:17.816: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 482, rcvd 4

.Nov  7 15:39:17.820: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 482, unknown protocol

.Nov  7 15:39:18.296: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 482, rcvd 4

.Nov  7 15:39:18.296: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 482, unknown protocol

.Nov  7 15:39:18.776: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 482, rcvd 4

.Nov  7 15:39:18.776: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 482, unknown protocol

Você pode ver os quatro pacotes de 482 bytes enviados antes dos pacotes de 82 bytes, que normalmente devem ter a prioridade. É por isso que isto acontece.

Como a intermitência é composta principalmente por 10 pacotes de 482 bytes, eles atingem o primeiro roteador, seguido pelo pacote de 82 bytes. Como os pacotes de 482 bytes chegam a um momento em que não há congestionamento, como não há tráfego, um pacote é imediatamente enfileirado para que o SAR (Port Adaptor Segmentation and Reassembly, segmentação e remontagem do adaptador de porta) seja dividido em células e enviado no fio. Em outras palavras, o anel de transmissão ainda está vazio.

Você pode calcular que o tempo necessário para enviar um pacote de 482 bytes é maior que o tempo necessário para o gerador de tráfego para enviar a intermitência total. Portanto, você pode supor que, quando o primeiro pacote de 482 bytes é enfileirado no adaptador de porta, mais pacotes de 482 bytes da intermitência já estão presentes no roteador. Portanto, mais pacotes de 482 bytes podem ser colocados em fila para o anel de transmissão. Mais três pacotes de 482 bytes são enfileirados com o uso das três partículas livres presentes ali.

Observação: os pacotes são enfileirados no anel de transmissão assim que há uma partícula livre, mesmo que precisem armazenar mais de uma partícula.

Nesse ponto há congestionamento, já que as três partículas estão cheias. Portanto, o enfileiramento se inicia no IOS. Quando os quatro pacotes de 82 bytes finalmente chegam ao roteador, há congestionamento. Esses quatro pacotes são enfileirados e o WFQ é utilizado nos dois fluxos. Examine a fila ATM que usa o comando show queue ATM para ver isso:

router2#show queue ATM 4/0.102 vc 0/102

Interface ATM4/0.102 VC 0/102

Queuing strategy: weighted fair

Total output drops per VC: 0

Output queue: 10/512/64/0 (size/max total/threshold/drops)

Conversations  2/4/16 (active/max active/max total)

Reserved Conversations 0/0 (allocated/max allocated)

(depth/weight/total drops/no-buffer drops/interleaves) 4/32384/0/0/0

Conversation 6, linktype: ip, length: 82

source: 7.0.0.200, destination: 6.6.6.6, id: 0x0000, ttl: 63, prot: 255

(depth/weight/total drops/no-buffer drops/interleaves) 6/32384/0/0/0

Conversation 15, linktype: ip, length: 482

source: 7.0.0.1, destination: 6.6.6.6, id: 0x0000, ttl: 63, prot: 255

Você pode ver nas depurações que os quatro primeiros pacotes de 482 bytes são seguidos pelos pacotes de 82 bytes. Esses pequenos pacotes saem do roteador antes dos pacotes grandes. Isso indica que, assim que ocorrer um congestionamento, pacotes pequenos terão prioridade sobre pacotes grandes.

Use as fórmulas de peso e tempo de programação fornecidas na seção Cálculo do peso para verificar isso.

Estágio 2

Se você aumentar o limite do anel de transmissão para cinco e os pacotes grandes forem de 482 bytes então, de acordo com a saída anterior, você verá seis pacotes de 482 bytes antes de ocorrer congestionamento, seguidos por quatro pacotes de 82 bytes, e então outros quatro pacotes de 482 bytes:

.Nov  7 15:49:57.365: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 482, rcvd 4

.Nov  7 15:49:57.365: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 482, unknown protocol

.Nov  7 15:49:57.841: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 482, rcvd 4

.Nov  7 15:49:57.845: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 482, unknown protocol

.Nov  7 15:49:58.321: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 482, rcvd 4

.Nov  7 15:49:58.321: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 482, unknown protocol

.Nov  7 15:49:58.797: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 482, rcvd 4

.Nov  7 15:49:58.801: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 482, unknown protocol

.Nov  7 15:49:59.277: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 482, rcvd 4

.Nov  7 15:49:59.277: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 482, unknown protocol

.Nov  7 15:49:59.757: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 482, rcvd 4

.Nov  7 15:49:59.757: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 482, unknown protocol

.Nov  7 15:49:59.973: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 82, rcvd 4

.Nov  7 15:49:59.973: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 82, unknown protocol

.Nov  7 15:50:00.105: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 82, rcvd 4

.Nov  7 15:50:00.105: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 82, unknown protocol

.Nov  7 15:50:00.232: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 82, rcvd 4

.Nov  7 15:50:00.232: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 82, unknown protocol

.Nov  7 15:50:00.364: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 82, rcvd 4

.Nov  7 15:50:00.364: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 82, unknown protocol

.Nov  7 15:50:00.840: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 482, rcvd 4

.Nov  7 15:50:00.844: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 482, unknown protocol

.Nov  7 15:50:01.320: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 482, rcvd 4

.Nov  7 15:50:01.320: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 482, unknown protocol

.Nov  7 15:50:01.796: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 482, rcvd 4

.Nov  7 15:50:01.800: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 482, unknown protocol

.Nov  7 15:50:02.276: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 482, rcvd 4

.Nov  7 15:50:02.276: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 482, unknown protocol

Como podem ver aqui, isto é realmente o que acontece.

Estágio 3

O tamanho da partícula é de 512 bytes. Portanto, se o anel de transmissão for expresso em partículas, e você usar pacotes um pouco maiores que o tamanho da partícula, cada um toma duas partículas. Isso é ilustrado pelo uso de pacotes de 582 bytes e um anel de transmissão de três. Com esses parâmetros, você deve ver três pacotes de 582 bytes. Um é enviado sem tráfego na interface ATM, que deixa três partículas livres. Portanto, mais dois pacotes podem ser enfileirados, seguidos por quarto pacotes de 82 bytes e, em seguida, por sete pacotes de 528 bytes.

.Nov  7 15:51:34.604: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 582, rcvd 4

.Nov  7 15:51:34.604: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 582, unknown protocol

.Nov  7 15:51:35.168: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 582, rcvd 4

.Nov  7 15:51:35.168: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 582, unknown protocol

.Nov  7 15:51:35.732: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 582, rcvd 4

.Nov  7 15:51:35.736: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 582, unknown protocol

.Nov  7 15:51:35.864: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 82, rcvd 4

.Nov  7 15:51:35.864: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 82, unknown protocol

.Nov  7 15:51:35.996: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 82, rcvd 4

.Nov  7 15:51:35.996: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 82, unknown protocol

.Nov  7 15:51:36.124: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 82, rcvd 4

.Nov  7 15:51:36.124: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 82, unknown protocol

.Nov  7 15:51:36.256: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 82, rcvd 4

.Nov  7 15:51:36.256: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 82, unknown protocol

.Nov  7 15:51:36.820: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 582, rcvd 4

.Nov  7 15:51:36.820: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 582, unknown protocol

.Nov  7 15:51:37.384: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 582, rcvd 4

.Nov  7 15:51:37.388: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 582, unknown protocol

.Nov  7 15:51:37.952: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 582, rcvd 4

.Nov  7 15:51:37.952: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 582, unknown protocol

.Nov  7 15:51:38.604: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 582, rcvd 4

.Nov  7 15:51:38.604: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 582, unknown protocol

.Nov  7 15:51:39.168: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 582, rcvd 4

.Nov  7 15:51:39.168: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 582, unknown protocol

.Nov  7 15:51:39.732: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 582, rcvd 4

.Nov  7 15:51:39.736: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 582, unknown protocol

.Nov  7 15:51:40.300: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 582, rcvd 4

.Nov  7 15:51:40.300: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 582, unknown protocol

Estágio 4

Pegue um tamanho de pacote de 1482 (três partículas) e defina um anel de transmissão de cinco. Se o anel de transmissão estiver definido em partículas, você verá algo semelhante:

- Um pacote transmitido imediatamente

- Um pacote que toma três das cinco partículas

- Um pacote enfileirado porque duas partículas estão livres

.Nov  8 07:22:41.200: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4

.Nov  8 07:22:41.200: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 1482, unknown protocol

.Nov  8 07:22:42.592: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4

.Nov  8 07:22:42.592: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 1482, unknown protocol

.Nov  8 07:22:43.984: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4

.Nov  8 07:22:43.984: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 1482, unknown protocol

.Nov  8 07:22:44.112: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 82, rcvd 4

.Nov  8 07:22:44.112: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 82, unknown protocol

.Nov  8 07:22:44.332: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 82, rcvd 4

.Nov  8 07:22:44.332: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 82, unknown protocol

.Nov  8 07:22:44.460: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 82, rcvd 4

.Nov  8 07:22:44.460: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 82, unknown protocol

.Nov  8 07:22:44.591: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 82, rcvd 4

.Nov  8 07:22:44.591: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 82, unknown protocol

.Nov  8 07:22:45.983: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4

.Nov  8 07:22:45.983: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 1482, unknown protocol

.Nov  8 07:22:47.371: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4

.Nov  8 07:22:47.375: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 1482, unknown protocol

.Nov  8 07:22:48.763: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4

.Nov  8 07:22:48.767: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 1482, unknown protocol

.Nov  8 07:22:50.155: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4

.Nov  8 07:22:50.155: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 1482, unknown protocol

.Nov  8 07:22:51.547: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4

.Nov  8 07:22:51.547: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 1482, unknown protocol

.Nov  8 07:22:53.027: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4

.Nov  8 07:22:53.027: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 1482, unknown protocol

.Nov  8 07:22:54.415: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4

.Nov  8 07:22:54.419: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 1482, unknown protocol

Summary

A partir dos testes realizados, você pode concluir estes:

- Em PVCs lentos sem WFQ, o tráfego em massa afeta o pequeno tráfego, como os pings que estão sendo instalados até que o WFQ esteja ativado.

- O tamanho do anel de transmissão (tx-ring-limit) determina a rapidez com que o mecanismo de enfileiramento começa a realizar seu trabalho. Você pode ver o impacto disso com o aumento do RTT do ping quando o limite do anel de transmissão aumenta. Por isso, se o WFQ ou o LLQ precisarem ser implementados, é recomendável que você reduza o limite do anel de transmissão.

- O WFQ que usa CBWFQ efetivamente prioriza os pequenos tráfegos em relação ao tráfego em massa.

Informações Relacionadas

- Páginas de Suporte da Tecnologia ATM

- Visão geral do gerenciamento de congestionamentos

- Suporte Técnico e Documentação - Cisco Systems