Introduction

Este documento fornece informações para ajudá-lo a determinar quais bytes são contados pelo enfileiramento IP para ATM (Asynchronous Transfer Mode Modo de Transferência Assíncrona).

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.

Determine o valor da declaração de largura de banda em uma política de serviço de QoS

P. Preciso determinar o valor da instrução de largura de banda na minha política de serviço de QoS. Em Circuitos virtuais permanentes (PVCs) de ATM, como esse valor é medido? Ele conta todos os 53 bytes das células ATM?

A. Os comandos bandwidth e priority configurados em uma política de serviço para habilitar o CBWFQ (Class-Based Weighted Fair Queueing) e o LLQ (Low Latency Queueing), respectivamente, usam um valor kbps que conta os mesmos bytes de overhead contados pela saída do comando show interface. Especificamente, o sistema de enfileiramento de Camada 3 conta o seguinte:

Campo de carga adicional	Duração	Contado em show policy-map interface
Logical Link Control / Subnetwork Access Protocol (LLC/SNAP)	8 (por pacote)	Yes
Trailer AAL5 (ATM Adaptation Layer 5)	4	Não. O trailer AAL5 e a verificação de redundância cíclica (CRC) são adicionados ao SAR (Segmentation and Reassembly, segmentação e remontagem) e, portanto, nunca são considerados no IOS. Os 4 bytes que são contados são bytes de encapsulamento VC (circuito virtual interno).
Preenchendo para tornar a última célula um múltiplo par de 48 bytes.	Variável	No
Cabeçalhos de célula ATM	5 (por célula)	No

Esta seção mostra como usar os contadores na saída do comando show policy-map interface para determinar quais bytes de overhead são contados pelo sistema de enfileiramento de Camada 3.

Tradicionalmente, os dispositivos Cisco usam estas definições de bytes AAL5PDU e bytes de célula ATM:

• ATM_cell_byte = arredondamento(aal5_pdu/48)*53

• aal5_pdu_byte = ip_size + snap(8)+aal5_ovh(8) = ether_size - 2

Neste teste, 50 pacotes por segundo (pps) de payload IP de 60 bytes para PVC 0/3 são transmitidos, que é configurado para encapsulamento AAL5SNAP:

r1#show policy-map interface 
   ATM5/0.33: VC 0/33 - 
    Service-policy output: llq (1265) 

      Class-map: p5 (match-all) (1267/4) 
        14349 packets, 1033128 bytes 
        30 second offered rate 28000 bps, drop rate 0 bps 
        Match: ip precedence 5  (1271) 
        Weighted Fair Queueing 
          Strict Priority 
          Output Queue: Conversation 136 
          Bandwidth 40 (kbps) Burst 1000 (Bytes) 
          (pkts matched/bytes matched) 0/0 
          (total drops/bytes drops) 0/0

1033128 bytes / 14349 pacotes = 72 bytes por pacote

8 (cabeçalho SNAP) + 60 IP paylod + 4 (4 primeiros bytes do trailer AAL5) = 72

Após o teste, o comando show policy-map int exibe 14349 pacotes e 1033128 bytes. Esses valores contam o número de pacotes que correspondem aos critérios da classe. Os pkts corresponderam/bytes corresponderam os incrementos de valor somente quando o VC está congestionado ou quando o pacote é comutado por processo. Todos os pacotes comutados por processo são enviados ao mecanismo de enfileiramento da camada 3.

Confirme se o comando show interface atm conta os mesmos bytes de sobrecarga. Neste teste, cinco pings de 100 bytes são enviados:

7500-1#ping 192.168.66.70 
Type escape sequence to abort. 
Sending 5, 100-byte ICMP Echos to 192.168.66.70, timeout is 2 seconds: 
!!!!! 
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/4 ms 
7500-1#

A saída do comando show interface atm exibe cinco pacotes de entrada e 540 bytes. Os 40 bytes extras acima dos 500 bytes do payload IP vêm disto:

• 40 bytes/5 pacotes = 8 bytes de overhead por pacote

• 8 bytes de cabeçalho LLC/SNAP

7500-b#show interface atm 4/1/0 
ATM4/1/0 is up, line protocol is up 
  Hardware is cyBus ATM 
  Internet address is 192.168.66.70/30 
  MTU 4470 bytes, sub MTU 4470, BW 155520 Kbit, DLY 80 usec, 
  rely 255/255, load 1/255 
  NSAP address: BC.CDEF01234567890ABCDEF012.345678901334.13 
  Encapsulation ATM, loopback not set, keepalive not supported 
  Encapsulation(s): AAL5, PVC mode 
  2048 maximum active VCs, 1024 VCs per VP, 1 current VCCs 
  VC idle disconnect time: 300 seconds 
  Last input 00:00:03, output 00:00:03, output hang never 
  Last clearing of "show interface" counters 00:00:21 
  Queueing strategy: fifo 
  Output queue 0/40, 0 drops; input queue 0/75, 0 drops 
  5 minute input rate 0 bits/sec, 1 packets/sec 
  5 minute output rate 0 bits/sec, 0 packets/sec 
     5 packets input, 560 bytes, 0 no buffer 
     Received 0 broadcasts, 0 runts, 0 giants, 0 throttles 
     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort 
     5 packets output, 560 bytes, 0 underruns 
     0 output errors, 0 collisions, 0 interface resets 
     0 output buffer failures, 0 output buffers swapped out

Este é um teste feito em uma interface Ethernet, que envia 100 pacotes de 74 bytes:

louve(TGN:OFF,Et3/0:2/2)#show pack 
Ethernet Packet:  74 bytes 
      Dest Addr: 0050.73d1.6938,   Source Addr: 0010.2feb.b854 
      Protocol: 0x0800 

IP    Version: 0x4,  HdrLen: 0x5,  TOS: 0x00 
      Length: 60,   ID: 0x0000,   Flags-Offset: 0x0000 
      TTL: 60,   Protocol: 1 (ICMP),   Checksum: 0x74B8 (OK) 
      Source: 0.0.0.0,     Dest: 5.5.5.5 

ICMP  Type: 0,   Code: 0  (Echo Reply) 
      Checksum: 0x0EFF (OK) 
      Identifier: 0000,  Sequence: 0000 
Echo Data: 
    0 : 0001 0203 0405 0607 0809 0A0B 0C0D 0E0F 1011 1213  .................... 
   20 : 1415 1617 1819 1A1B 1C1D 1E1F                      ............

Ambos os comandos show policy-map interface e show interface ethernet contaram 740 bytes.

few#show policy-map interface ethernet 2/2 
 Ethernet2/2 
  Service-policy output: a-test 

    Class-map: icmp (match-all) 
      10 packets, 740 bytes 

few#show interface ethernet 2/2 
     10 packets output, 740 bytes, 0 underruns(0/0/0)

60 payload IP + 2 * 6 (endereço MAC origem e destino) + 2 (tipo de protocolo) = 74

A partir desse cálculo, você pode ver que o CRC Ethernet não está incluído nas saídas do comando show interface ou show policy-map. O importante é que ambos os valores são consistentes quanto à inclusão ou não do CRC.

Finalmente, aqui estão os bytes contados em uma interface serial que usa encapsulamento HDLC (controle de enlace de dados de alto nível). Neste teste, cinco pacotes de 100 bytes são transmitidos:

r3#show policy interface 
  Serial4/2:0 
    Service-policy output: test 

      Class-map: icmp (match-all) 
        5 packets, 520 bytes

Aqui estão as definições dos quadros Cisco HDLC:

• flag—início ou fim do quadro = 0x7E

• endereço—campo tipo de quadro:

  • 0x0F—Quadro Unicast

  • 0x80—Quadro de Broadcast

  • 0x40—Quadro preenchido

  • 0x20—Quadro compactado

• protocolo—tipo Ethernet dos dados encapsulados, como 0x0800 para IP

A saída do comando show policy interface para o teste serial exibe 520 bytes. Os quatro bytes adicionais por quadro não incluem os flags de quadro inicial e final. Em vez disso, os bytes incluem os campos de endereço, controle e protocolo. O importante é que os bytes não incluem a sequência de verificação de quadro (FCS).

Conclusão

É importante entender que há uma diferença no número de octetos contados pelo sistema de enfileiramento de Camada 3 e no número de octetos que realmente são usados por um pacote quando ele chega à camada física. A largura de banda real usada pelo pacote de 64 bytes é muito maior em uma interface ATM do que em uma interface Ethernet. Especificamente, CBWFQ e LLQ não consideram estes dois conjuntos de overhead específico de ATM:

• Preenchimento—Torna a última célula de um pacote um múltiplo par de 48 bytes. Este preenchimento é incluído pelo SAR assim que o pacote alcança a camada ATM.

• Cabeçalho de célula ATM de 5 bytes

Em outras palavras, CBWFQ e LLQ estimam 64 bytes em 64 bytes, mas o pacote na verdade ocupa 106 bytes e usa duas células nas camadas ATM e física. Em todas as interfaces, flags e um CRC também estão presentes, mas não são incluídos pelo sistema de enfileiramento da camada 3.

A ID de bug da Cisco CSCdt85156 (somente clientes registrados) é uma solicitação de recurso para contar o CRC. Ele argumenta que toda a sobrecarga fixa e previsível da Camada 2, como um CRC, deve ser incluída na instrução de prioridade para tornar essa configuração o mais precisa e próxima possível do que é realmente consumido por um fluxo quando ele atinge o fio físico.

Informações Relacionadas

• Voz sobre IP - Consumo de largura de banda por chamada
• Enfileiramento de latência baixa
• Recursos de Modo de Transferência Assíncrona (ATM - Asynchronous Transfer Mode)
• Suporte a Produtos de LAN
• Suporte Técnico e Documentação - Cisco Systems