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

Compreendendo a Weighted Fair Queuing em ATM

14 Outubro 2016 - 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 que use a tecnologia do Weighted Fair Queuing (WFQ).

O WFQ foi introduzido a fim permitir os links da velocidade lenta, tais como enlaces serial de fornecer o tratamento justo para todos os tipos de tráfego. A fim fazer isto, o WFQ classifica o tráfego nos fluxos diferentes (igualmente conhecidos como conversações) baseou na informação da camada três e da camada quatro, tal como endereços IP de Um ou Mais Servidores Cisco ICM NT e portas TCP. Faz este sem a exigência de você 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.

Mas, 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 (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ê pode igualmente aplicar parâmetros, tais como a largura de banda e os limites de fila, a eles. A largura de banda que você atribui a uma classe é usada a fim 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 é aplicado então às classes, que podem incluir diversos fluxos, um pouco do que os fluxos eles mesmos.

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

As interfaces ATM não apoiam o WFQ com base no fluxo nativo configurado diretamente em uma relação com o comando fair-queue. Mas, com o software que apoia o CBWFQ, você pode configurar o WFQ com base no fluxo dentro da classe padrão, segundo as indicações deste 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

Pré-requisitos

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.

Convenções

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 instalação a fim ilustrar como o WFQ trabalha:

/image/gif/paws/10049/wfq_illustrated.gif

Nesta instalação, os pacotes podem ser armazenados em uma destas duas filas:

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

  • A fila no software do½ do¿Â do 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 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. No recibo deste sinal, o roteador para para enviar pacotes à fila de FIFO da relação e armazena os pacotes no IOS Software até que a fila esteja uncongested outra vez. Quando os pacotes são armazenados nos IO, o sistema pode aplicar QoS.

Como ajustar o transmitir limite de anel

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 <size>

  service-policy output test

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

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

  • Reduz a quantidade de tempo dos pacotes espera na fila de FIFO antes que esteja segmentada.

  • Acelera o uso do QoS no software IOS.

Impacto da transmissão de limite de anel

Olhe o impacto do transmitir limite de anel que usa a instalação mostrada no diagrama da rede precedente. Supõe estes:

  • O gerador de tráfego envia o tráfego (1500 pacotes de bytes) ao dispositivo do dissipador, e este tráfego sobrecarrega o PVC 0/102 entre o roteador1 e o roteador2.

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

  • O WFQ está habilitado no roteador 2.

Olhe duas configurações que usa transmitir limite de anel diferentes a fim ver que o impacto que isto tem.

Exemplo A

Neste exemplo, você ajustou o transmitir anel a três (tx-ring-limit=3). Este é o que você vê quando você sibila 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   

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ê ajustou o transmitir anel a 40 (tx-ring-limit=40). Este é o que você vê quando você usa o mesmo sibilo que 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 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 deste que um grande transmitir limite de anel pode conduzir aos atrasos significativos na transmissão.

Como calcular o peso

Na fila atm da mostra output no exemplo A, você vê que um peso está atribuído a cada conversação. Olhe isto com maiores 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  

Quando você usa 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 Mais Recente.

  • weight=4096/(precedence+1) - para Cisco IOS Software Release antes de 12.0(5)T.

Como calcular o agendamento de tempo

Você pode agora usar estes pesos a fim calcular o agendamento de tempo de cada pacote, quando o pacote é enviado da fila IO à fila de FIFO do adaptador ou do módulo de rede da porta.

Você pode calcular o agendamento de tempo de saída com o uso desta fórmula, onde o queue_tail_time é o agendamento de tempo atual:

output scheduling time= queue_tail_time + pktsize*weight

Como funciona o WFQ

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

Crie um fluxo que compreenda grandes pacotes dos dez pacotes e quatro pacotes menores (de 82 bytes) esses usam um gerador de tráfego a fim verificar este.

Neste exemplo, o roteador2 é um Cisco 7200 Router com um PA-A3 (adaptador da porta ATM). Isto é importante porque o tamanho da fila de FIFO da saída no adaptador da porta é expressado nas partículas e não em uns pacotes. Veja o que é uma partícula? seção para mais informações.

O que é uma partícula?

Em vez da atribuição de uma parte de memória contígua para um buffer, a proteção da partícula atribui as partes (dispersadas) discontiguous de memória, chamadas partículas, e liga-as então junto a fim formar um buffers de pacotes 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 7200 Router, o tamanho de partícula é 512 bytes.

Use o comando show buffers a fim verificar se os Cisco 7200 Router 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 a fim ilustrar a Funcionalidade de WFQ. Neste primeiro teste, olhe se a largura de banda pode ser compartilhada entre conversações diferentes.

Neste teste, você fez o gerador de tráfego enviar o tráfego rapidamente bastante para sobrecarregar o PVC 0/102 entre o roteador1 e o roteador2. Execute um sibilo do roteador3 ao roteador1 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 da saída mostrada, até que o WFQ esteja permitido na relação, o tráfego impede que o outro tráfego vá completamente e morre de fome a linha. Assim que o WFQ for habilitado, o ping será bem-sucedido.

Você pode ver deste de que, com o uso do WFQ, a largura de banda pode ser compartilhada entre conversações diferentes sem a uma que obstrui a outro.

Teste B

Isto é como a largura de banda é compartilhada.

O fluxo que o gerador de tráfego envia é uma explosão composta de dez grandes pacotes, seguido por quatro pacotes menores de 82 bytes. Você envia este no 100 Mbps ao roteador2. Quando você envia a explosão, a fila de saída na interface ATM do roteador2 está vazia. O roteador2 envia estes pacotes com um 10 KB PVC (este é um PVC muito lento) a fim assegurar-se de que a congestão ocorra na fila de saída.

Conduza este teste em diversas fases a fim 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 do dissipador:

   .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 82-byte, que devem normalmente obter a prioridade. Eis porque 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. Desde que os pacotes do 482-byte chegam numa altura em que não há nenhuma congestão, porque há um sem tráfego, um pacote é enfileirado imediatamente ao Segmentation And Reassembly do adaptador da porta (SAR) a ser chunked em pilhas e enviado sobre o fio. Em outras palavras, o anel de transmissão ainda está vazio.

Você pode calcular que o tempo necessário para enviar um pacote do 482-byte é maior do que o momento necessário para o gerador de tráfego a fim enviar a explosão total. Você pode consequentemente supor que, quando o primeiro pacote do 482-byte é enfileirado ao adaptador da porta, mais pacotes do 482-byte da explosão estão já atuais no roteador. Portanto, mais pacotes de 482 bytes podem ser colocados em fila para o anel de transmissão. Três mais pacotes de 482 bytes são enfileirados com o uso das três partículas livres atuais lá.

Nota: Os pacotes serão enfileirados no anel de transmissão logo que houver uma partícula livre, mesmo que necessitem de mais de uma partícula para serem armazenados.

Neste momento, há uma congestão, desde que as três partículas estão completas. Portanto, o enfileiramento se inicia no IOS. Quando os quatro pacotes 82-byte alcançam finalmente o roteador, há uma congestão. Esses quatro pacotes são enfileirados e o WFQ é utilizado nos dois fluxos. Olhe a fila ATM que usa o comando show queue atm a fim ver esta:

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 no debuga que os primeiros quatro pacotes de 482 bytes estão seguidos pelos pacotes 82-byte. 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 do peso e do agendamento de tempo dadas em calcular a seção do peso a fim verificar isto.

Fase 2

Se você aumenta o transmitir limite de anel a cinco e os grandes pacotes são 482 bytes então, do acordo à saída precedente, você devem ver seis pacotes de 482 bytes antes que a congestão ocorra, seguidos por quatro pacotes de 82 bytes, 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 você pode ver aqui, este é certamente o que acontece.

Fase 3

O tamanho de partícula é 512 bytes. Consequentemente, se o transmitir anel é expressado nas partículas, e você use os pacotes levemente mais grandes do que o tamanho de partícula, cada um toma duas partículas. Isto é ilustrado pelo uso dos pacotes de 582 bytes e de um transmitir anel de três. Com estes parâmetros, você deve ver três pacotes de 582 bytes. Um é enviado sem o tráfego na interface ATM, essa as folhas três partículas livre. 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  

Fase 4

Tome um tamanho do pacote de 1482 (três partículas) e defina um transmitir anel de cinco. Se o transmitir anel é definido nas partículas, você vê algo similar:

  • 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 

Resumo

Dos testes realizados, você pode concluir estes:

  • Em PVC lentos sem WFQ, o tráfego maioria impacta o tráfego pequeno, tal como os sibilos que estão sendo parados até que o WFQ esteja permitido.

  • O tamanho do transmitir anel (TX-anel-limite) determina como rapidamente os começos do mecanismo de filas fazer seu trabalho. Você pode ver o impacto deste com o aumento do sibilo RTT quando o transmitir limite de anel 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 o CBWFQ dá a prioridade certamente a tráfegos pequenos sobre o tráfego maioria.


Informações Relacionadas


Document ID: 10049