Asynchronous Transfer Mode (ATM) : Classe de serviço IP à ATM

Compreendendo a classe baseada em Weighted Fair Queuing em ATM

19 Setembro 2015 - Tradução por Computador
Outras Versões: Versão em PDFpdf | Inglês (22 Agosto 2015) | Feedback


Índice


Introdução

Este documento fornece uma introdução ao enfileiramento de tráfego, usando a tecnologia Class-Based Weighted Fair Queuing (CBWFQ).

O Enfileiramento moderado ponderado (WFQ) habilita enlaces de baixa velocidade, como enlaces seriais, para fornecer um tratamento moderado a todos os tipos de tráfego. Ele classifica o tráfego em fluxos diferentes (também conhecidos como conversações) com base nas informações da camada três e da camada quatro, como endereços IP e portas TCP. Ele faz isto sem que seja necessário definir listas de acesso. Isto significa que o tráfego da largura de banda baixa tem eficazmente a prioridade sobre o tráfego de largura de banda elevada porque o tráfego de largura de banda elevada compartilha dos meios de transmissão em proporção a seu peso atribuído. Entretanto, o WFQ tem determinadas 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 fornece uma solução para essas limitações. Ao contrário do padrão WFQ, o CBWFQ permite definir as classes de tráfego e aplicar parâmetros, como largura de banda e limites de fila a estas classes. A largura de banda atribuída a uma classe é utilizada para calcular o “peso” daquela classe. O peso de cada pacote que atende aos critérios de classe também é calculado a partir disso. O WFQ é aplicado preferencialmente às classes (que podem incluir vários fluxos) do que aos próprios fluxos.

Para obter mais informações sobre como configurar CBWFQ, clique nos links a seguir:

Class-Based Weighted Fair Queuing por VC (CBWFQ por VC) em Roteadores Cisco 7200, 3600 e 2600.

Per-VC Class-Based Weighted Fair Queuing on RSP-based Platforms.

Antes de Começar

Convenções

Para obter mais informações sobre convenções de documento, consulte as Convenções de dicas técnicas Cisco.

Pré-requisitos

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.

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 você estiver trabalhando em uma rede ativa, certifique-se de que entende o impacto potencial de qualquer comando antes de utilizá-lo.

Diagrama de Rede

Para ilustrar como o WFQ funciona, utilizaremos a seguinte configuração:

/image/gif/paws/10406/wfq_illustrated.gif

Na configuração usada aqui, os pacotes podem ser armazenados em uma das duas filas a seguir:

  • A fila de primeiro a entrar primeiro a sair (FIFO) de hardware no adaptador de porta e no módulo de rede.

  • A fila no software de Cisco IOS� (na memória do [I/O] do entrada/saída do roteador) onde as características do Qualidade de Serviço (QoS) tais como o CBWFQ podem ser aplicadas.

A fila de FIFO no adaptador de porta armazena os pacotes antes que estejam segmentados em células para transmissão. Quando a fila estiver cheia, o adaptador de porta ou o módulo de rede sinalizará para o software IOS que a fila está congestionada. Esse mecanismo é chamado de contrapressão. Ao receber esse sinal, o roteador pára de enviar pacotes para a fila FIFO da interface e armazena os pacotes no software IOS até que a fila esteja descongestionada novamente. Quando os pacotes são armazenados no IOS, o sistema pode aplicar recursos QoS; por exemplo, CBWFQ.

Definindo o limite de anel 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 limite (x) que pode ser especificado aqui é um número de pacotes (para Cisco 2600 e 3600 routers) ou uma quantidade de partículas (para Cisco 7200 e 7500 routers).

A redução do tamanho do anel de transmissão tem duas vantagens:

  • Reduz o tempo total que os pacotes têm de esperar na fila FIFO antes de serem segmentados.

  • Acelera o uso do QoS no software IOS.

Impacto da transmissão de limite de anel

Vejamos o impacto do limite do anel de transmissão usando a configuração mostrada no diagrama de rede acima. Nós podemos supor o seguinte:

  • O gerador de tráfego está enviando tráfego (pacotes de 1.500 bytes) para o dispositivo coletor e esse tráfego está sobrecarregando o PVC 0/102 entre o roteador 1 e o roteador 2.

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

  • O CBWFQ é permitido no roteador2.

Agora vamos observar duas configurações usando limites de anéis de transmissão diferentes para ver o impacto que isso tem.

Exemplo A

Nesse exemplo, configuramos o anel de transmissão para três (tx-ring-limit=3). É aqui o que nós vemos quando nós sibilamos o roteador1 do roteador3.

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

Exemplo B

Neste exemplo, definimos o anel de transmissão como 40 (TX-ring-limit=40). Isso é o que vemos quando utilizamos o mesmo ping usado no 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

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

Como funciona o CBWFQ

Agora que vimos o impacto do tamanho da fila FIFO de hardware, vamos ver exatamente como o CBWFQ funciona.

O Native WFQ atribui um peso a cada conversação, e programa então o momento transmitir para cada pacote dos fluxos diferentes. O peso é uma função da Precedência IP de cada fluxo, e o agendamento de tempo depende do tamanho do pacote. Clique aqui para mais detalhes no WFQ.

O CBWFQ atribui um peso a cada classe configurada em vez de cada fluxo. Esse peso é proporcional à largura de banda configurada para cada classe. O peso é, mais precisamente, uma função da largura de banda da interface dividida pela largura de banda da classe. Consequentemente, mais grande o parâmetro de largura de banda, menor o peso.

Podemos calcular o tempo de programação do pacote usando a seguinte fórmula:

scheduling tail_time= queue_tail_time + pktsize * weight 

Divisão da largura de banda total da interface

Deixe-nos olhar como o roteador divide a largura de banda total de interface entre as classes diferentes. A fim prestar serviços de manutenção às classes, o roteador usa filas de calendários. Cada uma dessas filas de calendário armazena pacotes que devem ser transmitidos no mesmo valor de scheduling_tail_time. O roteador então serve essas filas de calendário, uma de cada vez. Vamos examinar esse processo:

  1. Se a congestão ocorre no adaptador de porta quando um pacote chega na interface de saída, este causa o enfileiramento em IO (CBWFQ neste caso).

  2. O roteador calcula um tempo de programação para esse pacote que está chegando e o armazena na fila de calendário correspondente a esse tempo de programação. Apenas um pacote por classe pode ser armazenado em uma fila de calendário específica.

  3. Quando é o momento de prestar serviço à fila do calendário na qual o pacote foi armazenado, o IOS esvazia essa fila e envia os pacotes à fila FIFO no próprio adaptador de porta. O tamanho desta fila de FIFO é determinado pelo transmitir limite de anel descrito acima.

  4. Se a fila FIFO for muito pequena para abranger todos os pacotes mantidos na fila baseada em calendário que está sendo atendida, o roteador reagendará os pacotes que não puderem ser armazenados para o próximo agendamento de tempo (conforme sua importância) e os colocará de acordo com a fila baseada em calendário.

  5. Quando todo o isto é feito, o adaptador de porta trata os pacotes em sua fila de FIFO e envia as pilhas no fio e os IO movem-se para a fila de calendários seguinte.

    Graça a esse mecanismo, cada classe recebe estatisticamente uma parte da largura de banda da interface correspondente aos parâmetros configurados para ela.

Mecanismo de fila de calendário versus tamanho do anel de transmissão

Vamos ver o relacionamento entre o mecanismo de fila do calendário e o tamanho do anel de transmissão. Um pequeno anel de transmissão permite que o QoS inicie mais rapidamente e reduz a latência dos pacotes que estão aguardando transmissão (o que é importante para tráfego sensível a retardos, como pacotes de voz). Entretanto, se for muito pequeno pode levar a um ritmo de transferência mais lento para certas classes. Isto é porque muitos pacotes podem ter que ser reprogramado se o transmitir anel não pode os acomodar.

Não há, infelizmente, nenhum valor ideal para o transmitir tamanho de anel e a única maneira de encontrar o melhor valor é experimentando.

Compartilhamento de largura de banda

Podemos analisar o conceito de compartilhamento de largura de banda utilizando a configuração mostrada em nosso diagrama de rede, acima. O gerador de pacotes produz diferentes fluxos e os envia para o dispositivo coletor. A quantidade total de tráfego representada por estes fluxos é bastante para sobrecarregar o PVC. Implementamos o CBWFQ no Roteador 2. Veja abaixo um exemplo da nossa configuração:

access-list 101 permit ip host 7.0.0.200 any 
   access-list 101 permit ip host 7.0.0.201 any 
   access-list 102 permit ip host 7.0.0.1 any 
   ! 
   class-map small 
     match access-group 101 
   class-map big 
     match access-group 102
   !
   policy-map test
   policy-map test 
     small class 
      bandwidth <x>
     big class 
      bandwidth <y>
    interface atm 4/0.102 
     pvc 0/102 
       TX-ring-limit 3 
       service-policy output test 
       vbr-nrt 64000 64000

Em nosso exemplo, o roteador2 é um Cisco 7200 Router. Isto é importante porque o limite do anel de transmissão é expresso em partículas, não em pacotes. Os pacotes são enfileirados na fila de FIFO de adaptador de porta assim que uma partícula livre estiver disponível, mesmo que mais de uma seja necessária para armazenar o pacote.

O que é uma partícula?

Em vez de alocar uma parte da memória contígua para um buffer, o buffer de partícula aloca partes não contíguas (dispersas) de memória, chamadas partículas, e, em seguida, as conecta para formar um buffer de pacotes lógicos. 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 que estamos usando aqui, o tamanho da partícula é de 512 bytes.

Podemos verificar se os Cisco 7200 routers fazem uso de partículas utilizando o commando show buffers:

router2#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
     ATM4/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

As classes "small" e "big" que estamos utilizando para esse teste são preenchidas da seguinte maneira:

  • Classe pequena - configuramos os parâmetros de largura de banda como 32 kbps. Esta classe armazena dez pacotes de 1500 bytes de 7.0.0.200, seguidos por dez pacotes de 1500 bytes de 7.0.0.201

  • Classe grande – configuramos o parâmetro de largura de banda para 16 kbps. Esta classe armazena um fluxo de dez pacotes 1500-bytes de 7.0.0.1.

O gerador de tráfego envia um estouro de tráfego destinado para o dispositivo do dissipador no 100 Mbps ao roteador2 no seguinte ordem:

  1. Dez pacotes de 7.0.0.1.

  2. Dez pacotes de 7.0.0.200.

  3. Dez pacotes de 7.0.0.201.

Verificando o peso do fluxo

Vamos ver o peso aplicado aos fluxos diferentes. Para fazer isto, podemos utilizar o comando show queue ATM x/y.z.

alcazaba#show queue ATM 4/0.102 
     Interface ATM4/0.102 VC 0/102 
     Queueing strategy: weighted fair 
     Total output drops per VC: 0 
     Output queue: 9/512/64/0 (size/max total/threshold/drops) 
        Conversations  2/3/16 (active/max active/max total)    
        Reserved Conversations 2/2 (allocated/max allocated) 

  (depth/weight/total drops/no-buffer drops/interleaves) 7/128/0/0/0    
     Conversation 25, linktype: ip, length: 1494 
     source: 7.0.0.201, destination: 6.6.6.6, id: 0x0000, ttl: 63, prot: 255  

  (depth/weight/total drops/no-buffer drops/interleaves) 2/256/0/0/0    
     Conversation 26, linktype: ip, length: 1494 
     source: 7.0.0.1, destination: 6.6.6.6, id: 0x0000, ttl: 63, prot: 255

Quando todos os pacotes de 7.0.0.200 foram enfileirados fora do roteador, nós podemos ver o seguinte:

alcazaba#show queue ATM 4/0.102 
     Interface ATM4/0.102 VC 0/102 
     Queueing strategy: weighted fair 
     Total output drops per VC: 0 
     Output queue: 9/512/64/0 (size/max total/threshold/drops) 
        Conversations  2/3/16 (active/max active/max total)    
        Reserved Conversations 2/2 (allocated/max allocated)
 
  (depth/weight/total drops/no-buffer drops/interleaves) 7/128/0/0/0    
     Conversation 25, linktype: ip, length: 1494 
     source: 7.0.0.201, destination: 6.6.6.6, id: 0x0000, ttl: 63, prot: 255
  
  (depth/weight/total drops/no-buffer drops/interleaves) 2/256/0/0/0    
     Conversation 26, linktype: ip, length: 1494 
     source: 7.0.0.1, destination: 6.6.6.6, id: 0x0000, ttl: 63, prot: 255  

Como você pode ver aqui, os fluxos de 7.0.0.200 e 7.0.0.201 têm o mesmo peso (128). Esse peso é metade do peso atribuído ao fluxo de 7.0.0.1 (256). Isto corresponde ao fato de que nossa largura de banda de classe pequena tem duas vezes o tamanho da nossa classe grande.

Verificando a distribuição de largura de banda

Como a distribuição da largura de banda é verificada entre os fluxos diferentes? O método de enfileiramento FIFO é usado em cada classe. Nossa classe pequena está cheia com dez pacotes do primeiro fluxo e dez pacotes do segundo fluxo. O primeiro fluxo é removido da classe pequena, em 32 kbps. Assim que forem enviados, os dez pacotes do outro fluxo são também enviados. Enquanto isso, os pacotes de nossa classe grande são removidos a 16 kbps.

Nós podemos ver que, desde que o gerador de tráfego está enviando uma explosão no 100 Mbps, o PVC estará sobrecarregado. Entretanto, como não há tráfego no PVC quando o teste é iniciado e já que os pacotes de 7.0.0.1 são os primeiros a alcançar o roteador, alguns pacotes de 7.0.0.1 serão enviados antes de o CBWFQ ser iniciado devido a congestionamento (em outras palavras, antes que o anel de transmissão esteja cheio).

Como o tamanho da partícula é de 512 bytes e o tamanho do anel de transmissão é de três partículas, podemos notar que dois pacotes do 7.0.0.1 são enviados antes do congestionamento. Um é imediatamente enviado no fio e o segundo é armazenado em três partículas formando a fila FIFO do adaptador de porta.

Podemos ver as depurações a seguir no dispositivo de depósito (que é simplesmente um roteador):

Nov 13 12:19:34.216: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, len 1482, rcvd 4 
   Nov 13 12:19:34.428: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 

   
!--- congestion occurs here.


   Nov 13 12:19:34.640: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   Nov 13 12:19:34.856: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   Nov 13 12:19:35.068: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   Nov 13 12:19:35.280: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   Nov 13 12:19:35.496: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   Nov 13 12:19:35.708: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   Nov 13 12:19:35.920: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   Nov 13 12:19:36.136: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   Nov 13 12:19:36.348: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   Nov 13 12:19:36.560: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   Nov 13 12:19:36.776: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   Nov 13 12:19:36.988: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   Nov 13 12:19:37.200: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   Nov 13 12:19:37.416: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   Nov 13 12:19:37.628: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   Nov 13 12:19:37.840: IP: s=7.0.0.201 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   Nov 13 12:19:38.056: IP: s=7.0.0.201 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   Nov 13 12:19:38.268: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   Nov 13 12:19:38.480: IP: s=7.0.0.201 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   Nov 13 12:19:38.696: IP: s=7.0.0.201 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   Nov 13 12:19:38.908: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   Nov 13 12:19:39.136: IP: s=7.0.0.201 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   Nov 13 12:19:39.348: IP: s=7.0.0.201 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   Nov 13 12:19:39.560: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   Nov 13 12:19:39.776: IP: s=7.0.0.201 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   Nov 13 12:19:39.988: IP: s=7.0.0.201 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   Nov 13 12:19:40.200: IP: s=7.0.0.201 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   Nov 13 12:19:40.416: IP: s=7.0.0.201 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4  

Como o tamanho dos pacotes para os dois fluxos é o mesmo, com base na fórmula de tempo de programação, deveríamos ver dois pacotes de nossa classe pequena enviados para cada pacote de nossa classe grande. É exatamente isso que podemos conferir nas depurações acima.

Teste B

Para o nosso segundo teste, vamos preencher as classes da seguinte maneira:

  • Classe pequena – configuramos o parâmetro de largura de banda para 32 kbps. Dez pacotes de 500 bytes de 7.0.0.200 são gerados, seguidos por dez pacotes de 1500 bytes de 7.0.0.201.

  • Classe grande – configuramos o parâmetro de largura de banda para 16 kbps. A classe armazena um fluxo de pacotes de 1500 bytes vindos de 7.0.0.1.

O gerador de tráfego envia um burst de tráfego a 100 Mbps para o Roteador 2 na seguinte ordem:

  1. Dez pacotes de 1500 bytes de 7.0.0.1.

  2. Dez pacotes de 500 bytes a partir de 7.0.0.200.

  3. Dez pacotes de 1.500 bytes de 7.0.0.201.

FIFO é configurado em cada classe.

Verificando o peso do fluxo

O passo seguinte é verificar o peso aplicado para os fluxos classificados:

alcazaba#show queue ATM 4/0.102 
   Interface ATM4/0.102 VC 0/102 
   Queueing strategy: weighted fair 
   Total output drops per VC: 0 
   Output queue: 23/512/64/0 (size/max total/threshold/drops) 
      Conversations  2/3/16 (active/max active/max total)  
      Reserved Conversations 2/2 (allocated/max allocated)  

  (depth/weight/total drops/no-buffer drops/interleaves) 15/128/0/0/0    
     Conversation 25, linktype: ip, length: 494 
     source: 7.0.0.200, destination: 6.6.6.6, id: 0x0000, ttl: 63, prot: 255  

  (depth/weight/total drops/no-buffer drops/interleaves) 8/256/0/0/0    
     Conversation 26, linktype: ip, length: 1494 
     source: 7.0.0.1, destination: 6.6.6.6, id: 0x0000, ttl: 63, prot: 255 

   alcazaba#show queue ATM 4/0.102 
   Interface ATM4/0.102 VC 0/102 
   Queueing strategy: weighted fair 
   Total output drops per VC: 0 
   Output queue: 13/512/64/0 (size/max total/threshold/drops) 
        Conversations  2/3/16 (active/max active/max total)    
        Reserved Conversations 2/2 (allocated/max allocated)  

  (depth/weight/total drops/no-buffer drops/interleaves) 8/128/0/0/0    
     Conversation 25, linktype: ip, length: 1494 
     source: 7.0.0.201, destination: 6.6.6.6, id: 0x0000, ttl: 63, prot: 255  

  (depth/weight/total drops/no-buffer drops/interleaves) 5/256/0/0/0    
     Conversation 26, linktype: ip, length: 1494 
     source: 7.0.0.1, destination: 6.6.6.6, id: 0x0000, ttl: 63,

Como você pode ver na saída acima, os fluxos de 7.0.0.200 e 7.0.0.201 receberam a mesma relevância (128). Esse peso é metade do tamanho do peso atribuído ao fluxo a partir de 7.0.0.1. Isso demonstra o fato de que a classe pequena tem uma largura de banda que é o dobro do tamanho da classe grande.

Verificando a distribuição de largura de banda

Podemos gerar as seguintes depurações a partir do dispositivo de depósito:

Nov 14 06:52:01.761: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   Nov 14 06:52:01.973: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 

   
!--- Congestion occurs here.
 

   Nov 14 06:52:02.049: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 482, rcvd 4 
   Nov 14 06:52:02.121: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 482, rcvd 4 
   Nov 14 06:52:02.193: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 482, rcvd 4 
   Nov 14 06:52:02.269: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 482, rcvd 4 
   Nov 14 06:52:02.341: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 482, rcvd 4 
   Nov 14 06:52:02.413: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 482, rcvd 4 
   Nov 14 06:52:02.629: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   Nov 14 06:52:02.701: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 482, rcvd 4 
   Nov 14 06:52:02.773: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 482, rcvd 4 
   Nov 14 06:52:02.849: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 482, rcvd 4 
   Nov 14 06:52:02.921: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 482, rcvd 4 
   Nov 14 06:52:03.149: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   Nov 14 06:52:03.361: IP: s=7.0.0.201 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   Nov 14 06:52:03.572: IP: s=7.0.0.201 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   Nov 14 06:52:03.788: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   Nov 14 06:52:04.000: IP: s=7.0.0.201 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   Nov 14 06:52:04.212: IP: s=7.0.0.201 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   Nov 14 06:52:04.428: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   Nov 14 06:52:04.640: IP: s=7.0.0.201 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   Nov 14 06:52:04.852: IP: s=7.0.0.201 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   Nov 14 06:52:05.068: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   Nov 14 06:52:05.280: IP: s=7.0.0.201 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   Nov 14 06:52:05.492: IP: s=7.0.0.201 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   Nov 14 06:52:05.708: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   Nov 14 06:52:05.920: IP: s=7.0.0.201 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   Nov 14 06:52:06.132: IP: s=7.0.0.201 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   Nov 14 06:52:06.348: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   Nov 14 06:52:06.560: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4

Nesse cenário, os fluxos em nossa pequena classe não têm o mesmo tamanho de pacote. Por isso, a distribuição de pacotes não é tão trivial quando para o Teste A, acima.

Tempos de programação

Analisemos mais atentamente as programações de tempo para cada pacote. O agendamento de tempo para pacotes é calculado usando a seguinte fórmula:

scheduling tail_time= sub_queue_tail_time + pktsize *
     weight

Para tamanhos diferentes de pacotes, o tempo de programação utiliza a seguinte fórmula:

500 bytes (small class): scheduling tail_time = x + 494 * 128
     = x + 63232 
     1500 bytes (small class): scheduling tail_time = x + 1494 *
     128 = x + 191232 
     1500 bytes (big class): scheduling tail_time = x + 1494 *
     256 = x + 382464

Com base nessas fórmulas, podemos ver que seis pacotes de 500 bytes de nossa classe pequena são transmitidos para cada pacote de 1.500 bytes de nossa classe grande (mostrada na saída de depuração acima).

Também podemos ver que os dois pacotes de 1.500 bytes de nossa classe pequena são enviados para um pacote de 1.500 bytes de nossa classe grande (mostrada na saída da depuração acima).

Considerando nossos testes acima, podemos concluir o seguinte:

Discussões relacionadas da comunidade de suporte da Cisco

A Comunidade de Suporte da Cisco é um fórum onde você pode perguntar e responder, oferecer sugestões e colaborar com colegas.


Informações Relacionadas


Document ID: 10406