Modo de transferencia asíncrona (ATM) : Clase de servicio IP a ATM

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

18 Octubre 2015 - Traducción Automática
Otras Versiones: PDFpdf | Inglés (22 Agosto 2015) | Comentarios


Contenido


Introducción

Este documento proporciona la información para ayudarle a determinar qué bytes son contados por el IP a la espera del Asynchronous Transfer Mode (ATM).

prerrequisitos

Requisitos

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 para la sentencia de ancho de banda en una política de servicio de QoS

P.. Necesito determinar el valor para 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 enteros de las células ATM?

R. Los comandos bandwidth and priority configurados en una política de servicio para habilitar el Mecanismo de cola de espera equitativo y ponderado basado en clases (CBWFQ) y el low latency queueing (LLQ), utilizan respectivamente un valor del kbps que cuente los mismos bytes de tara contados por la salida del comando show interface. Específicamente, el sistema de espera de la capa 3 cuenta éstos:

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)
Cola de capa 5 de adaptación ATM (AAL5) 4 No El remolque AAL5 y la verificación por redundancia cíclica (CRC) se agrega en el Segmentation And Reassembly (SAR), y por lo tanto nunca se considera en el IOS. Los 4 bytes se cuentan que son bytes de encapsulación internos del virtual circuit (VC).
Relleno para lograr que la última celda sea un múltiplo par de 48 bytes. Variable No
Encabezados de célula ATM 5 (por celda) No

Esta sección le muestra cómo utilizar los contadores en el comando show policy-map interface hecho salir para determinar qué bytes de tara son contados por el sistema de espera de la capa 3.

Tradicionalmente, los dispositivos de Cisco utilizan estas definiciones de los bytes AAL5PDU y de los bytes de la célula ATM:

  • ATM_cell_byte = roundup(aal5_pdu/48)*53

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

En esta prueba, 50 paquetes por segundo (pps) de la carga útil IP 60-byte al PVC 0/3 se transmiten, que se configura para la encapsulación del 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 pkts matched/el valor correspondido con los bytes incrementa solamente cuando se congestiona el VC o cuando el paquete es process-switched. Todos los paquetes process-switched se envían al motor de espera de la capa 3.

Confirme que el comando show interface atm cuenta los mismos bytes de tara. En esta prueba, cinco ping de 100 bytes se envían:

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. El suplemento 40 bytes sobre los 500 bytes de carga útil IP viene de esto:

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

  • 8 bytes de la 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

Esto es una prueba hecha sobre una interfaz de 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 cargas útiles IP + 2 * 6 (MAC Address de origen y destino) + 2 (Tipo de protocolo) = 74

De este cálculo, usted puede ver que el Ethernet CRC no está incluido en tampoco las salidas de la interfaz o del comando show policy-map de la demostración. Importantemente, ambos valores son constantes adentro independientemente de si el CRC es incluido.

Finalmente, aquí están los bytes contados en una interfaz serial que utilice el High-Level Data Link Control (HDLC) Encapsulation. En esta prueba, cinco paquetes de 100 bytes se transmiten:

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

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

Aquí están las definiciones de los bastidores del HDLC de Cisco:

/image/gif/paws/10420/bytes_counted.gif

  • indicador — comience o final del bastidor = de 0x7E

  • direccionamiento — campo del tipo de trama:

    • 0x0F — Trama de unidifusión

    • 0x80 — Trama de broadcast

    • 0x40 — Trama completada

    • 0x20 — Trama comprimida

  • protocolo — Tipo Ethernet de los datos encapsulados, tales como 0x0800 para el IP

La salida del comando show policy interface para la prueba serial visualiza 520 bytes. Los cuatro bytes adicionales por la trama no incluyen los Indicadores de trama del principio y de la conclusión. En lugar, los bytes incluyen los campos del direccionamiento, del control y del protocolo. Importantemente, 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 espera de la capa 3 y el número de octetos que sean utilizados realmente por un paquete una vez él alcanza la Capa física. El ancho de banda real usado por el paquete 64-bytes es mucho mayor en una interfaz ATM que en una interfaz de Ethernet. Específicamente, el CBWFQ y el LLQ no explican estos dos conjuntos de los gastos indirectos Específicos del ATM:

  • El completar — Hace la célula más reciente de un paquete un incluso múltiple de 48 bytes. Este padding (relleno) es agregado por el SAR una vez que el paquete alcanza la capa ATM.

  • encabezado de célula ATM 5-byte

Es decir la estimación CBWFQ y LLQ 64 bytes en 64 bytes, pero el paquete ocupa 106 bytes y utiliza realmente dos células en la atmósfera y las Capas físicas. En todas las interfaces, los indicadores y un CRC están también presentes, pero no son incluidos por el sistema de espera de la capa 3.

El Id. de bug Cisco CSCdt85156 (clientes registrados solamente) es una petición de la característica de contar el CRC. Sostiene que toda la capa fija y fiable 2 de arriba, por ejemplo un CRC, se debe incluir en la sentencia de prioridad para hacer esta configuración tan exacta y cercana como sea posible a qué es consumida realmente por un flujo cuando golpea el alambre físico.

Discusiones relacionadas de la comunidad de soporte de Cisco

La Comunidad de Soporte de Cisco es un foro donde usted puede preguntar y responder, ofrecer sugerencias y colaborar con colegas.


Información Relacionada


Document ID: 10420