¿Qué bytes son contados por IP para la cola de ATM CoS?

Introducción

Este documento proporciona información para ayudarle a determinar qué bytes son contados por IP para la colocación en cola del modo de transferencia asíncrona (ATM).

Prerequisites

Requirements

No hay requisitos específicos para este documento.

Componentes Utilizados

Este documento no tiene restricciones específicas en cuanto a versiones de software y de hardware.

Convenciones

Consulte Convenciones de Consejos TécnicosCisco para obtener más información sobre las convenciones del documento.

Determine el valor de la instrucción Bandwidth en una política de servicio de QoS

P. Necesito determinar el valor de la sentencia de ancho de banda en mi política de servicio de QoS. ¿Cómo se mide este valor en los circuitos virtuales permanentes ATM (PVC)? ¿Cuenta los 53 bytes completos de las celdas ATM?

A. Los comandos bandwidth y priority configurados en una política de servicio para habilitar la colocación en cola equilibrada ponderada (CBWFQ) y la colocación en cola de baja latencia (LLQ) basadas en clase, respectivamente, utilizan un valor de kbps que cuenta los mismos bytes de tara contados por la salida del comando show interface. Específicamente, el sistema de colocación en cola de Capa 3 cuenta lo siguiente:

Campo con overhead	Longitud	Contados en show policy-map interface
Control de link lógico / Protocolo de acceso de subred (LLC/SNAP)	8 (por paquete)	Yes
Cola de capa 5 de adaptación ATM (AAL5)	4	El remolque AAL5 y la verificación de redundancia cíclica (CRC) se agregan en la segmentación y el reensamblado (SAR) y, por lo tanto, nunca se contabilizan en IOS. Los 4 bytes que se cuentan son bytes de encapsulación de circuito virtual interno (VC).
Relleno para lograr que la última celda sea un múltiplo par de 48 bytes.	Variable	No
encabezados de celda ATM	5 (por celda)	No

Esta sección muestra cómo utilizar los contadores en el resultado del comando show policy-map interface para determinar qué bytes de tara son contados por el sistema de colocación en cola de Capa 3.

Tradicionalmente, los dispositivos Cisco utilizan estas definiciones de bytes AAL5PDU y bytes de celda ATM:

• ATM_cell_byte = redondeo(aal5_pdu/48)*53

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

En esta prueba, se transmiten 50 paquetes por segundo (pps) de carga útil IP de 60 bytes a PVC 0/3, que se configura para la encapsulación 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 paquetes = 72 bytes por paquete

8 (encabezado SNAP) + 60 de carga útil IP + 4 (primeros 4 bytes de cola de AAL5) = 72

Luego de la prueba, el comando show policy-map int muestra 14349 paquetes y 1033128 bytes. Estos valores cuentan la cantidad de paquetes que coinciden con los criterios de la clase. El valor pkts coincidentes/bytes coincidentes sólo aumenta cuando el VC está congestionado o cuando el paquete se conmuta por proceso. Todos los paquetes conmutados por proceso se envían al motor de colocación en cola de Capa 3.

Confirme que el comando show interface atm cuente los mismos bytes de sobrecarga. En esta prueba, se envían cinco pings de 100 bytes:

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#

La salida del comando show interface atm muestra cinco paquetes de entrada y 540 bytes. Los 40 bytes adicionales por encima de los 500 bytes de carga útil IP provienen de esto:

• 40 bytes / 5 paquetes = 8 bytes de tara por paquete.

• 8 bytes del encabezado 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

Esta es una prueba realizada sobre una interfaz Ethernet, que envía 100 paquetes 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 comandos show policy-map interface y show interface ethernet contaron 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 carga útil IP + 2 * 6 (dirección MAC de origen y de destino) + 2 (tipo de protocolo) = 74

A partir de este cálculo, puede ver que el CRC Ethernet no se incluye en las salidas del comando show interface o show policy-map. Es importante destacar que ambos valores son consistentes en si se incluye o no la CRC.

Finalmente, aquí están los bytes contados en una interfaz serial que utiliza encapsulación de control de link de datos de alto nivel (HDLC). En esta prueba, se transmiten cinco paquetes de 100 bytes:

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

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

Estas son las definiciones de las tramas HDLC de Cisco:

• indicador: inicio o fin de trama = 0x7E

• dirección: campo de tipo de trama:

  • 0x0F: marco unidifusión

  • 0x80: trama de difusión

  • 0x40: marco agregado

  • 0x20: marco comprimido

• protocolo: tipo Ethernet de los datos encapsulados, como 0x0800 para IP

La salida del comando show policy interface para la prueba serial muestra 520 bytes. Los cuatro bytes adicionales por trama no incluyen los indicadores de trama inicial y final. En su lugar, los bytes incluyen los campos de dirección, control y protocolo. Es importante destacar que los bytes no incluyen la secuencia de verificación de tramas (FCS).

Conclusión

Es importante entender que hay una diferencia en el número de octetos contados por el sistema de colocación en cola de Capa 3 y el número de octetos que realmente son usados por un paquete una vez que alcanza la capa física. El ancho de banda real utilizado por el paquete de 64 bytes es mucho mayor en una interfaz ATM que en una interfaz Ethernet. Específicamente, CBWFQ y LLQ no tienen en cuenta estos dos conjuntos de sobrecarga específica de ATM:

• Relleno: hace que la última celda de un paquete sea un múltiplo par de 48 bytes. Este padding (relleno) es agregado por el SAR una vez que el paquete alcanza la capa ATM.

• Encabezado de celdas ATM de 5 bytes

En otras palabras, CBWFQ y LLQ estiman 64 bytes a 64 bytes, pero el paquete ocupa realmente 106 bytes y utiliza dos celdas en las capas físicas y ATM. En todas las interfaces, los indicadores y un CRC también están presentes, pero no están incluidos en el sistema de colocación en cola de Capa 3.

El Id. de bug Cisco CSCdt85156 (sólo clientes registrados) es una solicitud de función para contar el CRC. Sostiene que todas las sobrecargas fijas y predecibles de Capa 2, como una CRC, deben incluirse en la sentencia de prioridad para hacer que esta configuración sea lo más exacta y cercana posible a lo que realmente consume un flujo cuando llega al cable físico.

Información Relacionada

• Voz sobre IP – Consumo de Ancho de Banda por Llamada
• Cola de tiempo de latencia bajo
• Recursos del modo de transferencia asíncrono (ATM)
• Soporte de Producto de LAN
• Soporte Técnico y Documentación - Cisco Systems