Quali byte vengono conteggiati dall'IP per la coda CoS ATM?

Introduzione

Questo documento offre informazioni per determinare quali byte vengono conteggiati dalla coda IP nella modalità di trasferimento asincrono (ATM).

Prerequisiti

Requisiti

Nessun requisito specifico previsto per questo documento.

Componenti usati

Il documento può essere consultato per tutte le versioni software o hardware.

Convenzioni

Per ulteriori informazioni sulle convenzioni usate, consultare il documento Cisco sulle convenzioni nei suggerimenti tecnici.

Determinare il valore per l'istruzione della larghezza di banda in un criterio del servizio QoS

D. Devo determinare il valore per l'istruzione della larghezza di banda nella mia politica del servizio QoS. Come viene misurato questo valore sui PVC ATM? Conta tutti i 53 byte delle celle ATM?

R. I comandi di larghezza di banda e priorità configurati in una policy del servizio per abilitare, rispettivamente, CBWFQ (Class-Based Weighted Fair Queueing) e LLQ (Low Latency Queueing), utilizzano un valore kbps che conteggia gli stessi byte di sovraccarico contati dall'output del comando show interface. In particolare, il sistema di coda di layer 3 conta quanto segue:

Campo costi comuni	Lunghezza	Conteggiato nell'interfaccia show policy-map
LLC/SNAP (Logical Link Control / Subnetwork Access Protocol)	8 (per pacchetto)	Sì
Rimorchio ATM Adaptation Layer 5 (AAL5)	4	No. Il trailer AAL5 e il controllo di ridondanza ciclico (CRC) vengono aggiunti nella segmentazione e nel riassemblaggio (SAR) e quindi non vengono mai considerati in IOS. I 4 byte conteggiati sono byte di incapsulamento del circuito virtuale interno (VC).
Spaziatura interna per rendere l'ultima cella un multiplo pari di 48 byte	Variabile	No
Intestazioni celle ATM	5 (per cella)	No

Questa sezione illustra come usare i contatori nell'output del comando show policy-map interface per determinare i byte di sovraccarico conteggiati dal sistema di coda di layer 3.

In genere, i dispositivi Cisco usano le seguenti definizioni di byte AAL5PDU e di byte di celle ATM:

• ATM_cell_byte = Arrotondamento (aal5_pdu/48)*53

• aal5_pdu_byte = dimensioni_ip + snap(8)+aal5_ovh(8) = dimensioni_etere - 2

In questo test, vengono trasmessi 50 pacchetti al secondo (pps) di payload IP da 60 byte al PVC 0/3, configurato per l'incapsulamento 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 byte / 14349 pacchetti = 72 byte per pacchetto

8 (intestazione SNAP) + 60 payload IP + 4 (primi 4 byte di sequenza AAL5) = 72

Dopo il test, il comando show policy-map int visualizza 14349 pacchetti e 1033128 byte. Questi valori contano il numero di pacchetti che corrispondono ai criteri della classe. Il valore ping corrispondente/byte corrispondente aumenta solo quando il VC è congestionato o quando il pacchetto è a commutazione di contesto. Tutti i pacchetti a commutazione di contesto vengono inviati al motore di coda di layer 3.

Confermare che il comando show interface atm conteggi lo stesso sovraccarico di byte. Questo test prevede l'invio di cinque ping di 100 byte:

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#

L'output del comando show interface atm visualizza cinque pacchetti di input e 540 byte. I 40 byte aggiuntivi al di sopra dei 500 byte di payload IP derivano da quanto segue:

• 40 byte / 5 pacchetti = sovraccarico di 8 byte per pacchetto

• 8 byte di intestazione 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

Questo è un test fatto su un'interfaccia Ethernet, che invia 100 pacchetti da 74 byte:

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

Sia il comando show policy-map interface che il comando show interface ethernet contano 740 byte.

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 (indirizzo MAC di origine e destinazione) + 2 (tipo di protocollo) = 74

Da questo calcolo, è possibile notare che il CRC Ethernet non è incluso negli output del comando show interface o show policy-map. È importante sottolineare che entrambi i valori sono coerenti indipendentemente dal fatto che il CRC sia incluso o meno.

Infine, di seguito vengono riportati i byte conteggiati su un'interfaccia seriale che utilizza l'incapsulamento HDLC (Data Link Control) di alto livello. In questo test, vengono trasmessi cinque pacchetti da 100 byte:

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

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

Di seguito sono riportate le definizioni dei frame Cisco HDLC:

• flag - inizio o fine del frame = 0x7E

• indirizzo—campo tipo frame:

  • 0x0F—Frame unicast

  • 0x80—Broadcast Frame

  • 0x40 - Cornice imbottita

  • 0x20—Frame compresso

• protocol - Tipo Ethernet dei dati incapsulati, ad esempio 0x0800 per IP

L'output del comando show policy interface per il test seriale visualizza 520 byte. I quattro byte aggiuntivi per frame non includono i flag del frame iniziale e finale. I byte includono invece i campi indirizzo, controllo e protocollo. È importante notare che i byte non includono la sequenza di controllo del frame (FCS).

Conclusioni

È importante capire che c'è una differenza nel numero di ottetti contati dal sistema di coda di layer 3 e nel numero di ottetti che vengono effettivamente usati da un pacchetto una volta raggiunto lo strato fisico. La larghezza di banda effettiva utilizzata da un pacchetto da 64 byte è molto più ampia su un'interfaccia ATM che su un'interfaccia Ethernet. In particolare, CBWFQ e LLQ non tengono conto di questi due gruppi di costi comuni specifici di ATM:

• Spaziatura interna (Padding) - Rende l'ultima cella di un pacchetto un multiplo pari di 48 byte. Questa spaziatura interna viene aggiunta dal SAR quando il pacchetto raggiunge il livello ATM.

• Intestazione cella ATM da 5 byte

In altre parole, CBWFQ e LLQ stimano 64 byte a 64 byte, ma il pacchetto in realtà occupa 106 byte e usa due celle a livello ATM e fisico. Su tutte le interfacce sono presenti anche flag e un CRC, ma non sono inclusi dal sistema di coda di layer 3.

L'ID bug Cisco CSCdt85156 (solo utenti registrati) è una richiesta di funzionalità per contare il CRC. Sostiene che tutti i costi fissi e prevedibili del layer 2, come un CRC, dovrebbero essere inclusi nella dichiarazione di priorità per rendere questa configurazione il più accurata e vicina possibile a ciò che effettivamente viene consumato da un flusso quando colpisce il cavo fisico.

Informazioni correlate

• Voice Over IP - Utilizzo della larghezza di banda per chiamata
• Accodamento a bassa latenza
• Risorse ATM (Asynchronous Transfer Mode)
• Supporto dei prodotti LAN
• Documentazione e supporto tecnico – Cisco Systems