Welche Byte werden nach IP-to-ATM-CoS-Warteschlangenverwaltung gezählt?

Einführung

Dieses Dokument enthält Informationen zur Bestimmung der Bytes, die von der Warteschlange für den IP-to-Asynchronous Transfer Mode (ATM) gezählt werden.

Voraussetzungen

Anforderungen

Für dieses Dokument bestehen keine speziellen Anforderungen.

Verwendete Komponenten

Dieses Dokument ist nicht auf bestimmte Software- und Hardwareversionen beschränkt.

Konventionen

Weitere Informationen zu Dokumentkonventionen finden Sie unter Cisco Technical Tips Conventions (Technische Tipps zu Konventionen von Cisco).

Ermitteln Sie den Wert für die Bandwidth Statement in einer QoS-Service-Richtlinie.

F. Ich muss den Wert für die Bandbreitenanweisung in meiner QoS-Service-Richtlinie bestimmen. Wie wird dieser Wert auf permanenten virtuellen Schaltungen (PVCs) des ATM gemessen? Zählt es die gesamten 53 Byte der ATM-Zellen?

Antwort: Die Befehle Bandbreite und Priorität, die in einer Dienstrichtlinie konfiguriert sind, um Class-Based Weighted Fair Queueing (CBWFQ) bzw. Low Latency Queueing (LLQ) zu ermöglichen, verwenden einen Kbit/s-Wert, der die gleichen Overhead-Bytes zählt, die von der Befehlsausgabe show interface gezählt werden. Das Layer-3-Warteschlangensystem zählt insbesondere Folgendes:

Overhead-Feld	Länge	Zählt in "show policy-map interface"
Logical Link Control/Subnetwork Access Protocol (LLC/SNAP)	8 (pro Paket)	Ja
ATM Adaptation Layer 5 (AAL5)-Trailer	4	Nein. Der AAL5-Trailer und die CRC-Prüfung werden der Segmentierung und Reassemblierung (SAR) hinzugefügt und sind daher in IOS nie berücksichtigt. Die 4 Byte, die gezählt werden, sind interne Virtual Circuit (VC)-Kapselungsbytes.
Padding, um letzte Zelle zu einem selbst Vielfachen von 48 Byte zu machen	variabel	Nein
ATM-Zell-Header	5 (pro Zelle)	Nein

In diesem Abschnitt wird gezeigt, wie Sie die Zähler in der Befehlsausgabe show policy-map interface verwenden, um zu bestimmen, welche Overhead-Bytes vom Layer-3-Warteschlangensystem gezählt werden.

Cisco Geräte verwenden in der Regel folgende Definitionen von AAL5PDU-Byte und ATM-Zellen-Bytes:

• ATM_cell_byte = roundup(aal5_pdu/48)*53

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

In diesem Test werden 50 Pakete pro Sekunde (pps) mit 60-Byte-IP-Nutzlast an PVC 0/3 übertragen, die für die AAL5SNAP-Kapselung konfiguriert ist:

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 Pakete = 72 Byte pro Paket

8 (SNAP-Header) + 60 IP-Payload + 4 (erste 4 Byte AAL5-Trailer) = 72

Nach dem Test zeigt der Befehl show policy-map int 14349 Pakete und 1033128 Byte an. Diese Werte zählen die Anzahl der Pakete, die den Kriterien der Klasse entsprechen. Der Wert für die Übereinstimmung der Pakete/Bytes erhöht sich nur, wenn der VC überlastet ist oder wenn das Paket prozessgeschaltet wird. Alle prozessgesteuerten Pakete werden an die Warteschlangenengine des Layer 3 gesendet.

Vergewissern Sie sich, dass der Befehl show interface atm die gleichen Overhead-Bytes zählt. In diesem Test werden fünf Pings mit 100 Byte gesendet:

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#

In der Ausgabe des Befehls show interface atm werden fünf Eingabepakete und 540 Byte angezeigt. Die zusätzlichen 40 Byte oberhalb der 500 Byte IP-Nutzlast ergeben sich wie folgt:

• 40 Byte/5 Pakete = 8 Byte Overhead pro Paket

• 8 Byte des LLC/SNAP-Headers

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

Dies ist ein Test, der über eine Ethernet-Schnittstelle durchgeführt wird und 100 Pakete mit 74 Byte sendet:

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

Der Befehl show policy-map interface und der Befehl show interface ethernet zählten 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 IP-Payload + 2 * 6 (Quell- und Ziel-MAC-Adresse) + 2 (Protokolltyp) = 74

Aus dieser Berechnung wird ersichtlich, dass das Ethernet-CRC weder in der show interface noch in der show policy-map-Befehlsausgabe enthalten ist. Wichtig ist, dass beide Werte konsistent sind, ob das CRC enthalten ist oder nicht.

Und schließlich sind hier die Byte aufgeführt, die auf einer seriellen Schnittstelle gezählt werden, die die High-Level Data Link Control (HDLC)-Kapselung verwendet. In diesem Test werden fünf Pakete mit 100 Byte übertragen:

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

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

Hier sind die Definitionen für Cisco HDLC-Frames:

• Flag - Start oder Ende des Frames = 0x7E

• address - Feldertyp des Frames:

  • 0x0F - Unicast-Frame

  • 0x80 - Broadcast-Frame

  • 0x40 - gepolsterter Rahmen

  • 0x20 - Komprimierter Frame

• Protocol - Ethernet-Typ der gekapselten Daten, z. B. 0x0800 für IP

Die Ausgabe des Befehls show policy interface für den seriellen Test zeigt 520 Byte an. Die zusätzlichen vier Bytes pro Frame enthalten nicht die Start- und End-Frame-Flags. Stattdessen enthalten die Bytes die Felder Adresse, Steuerung und Protokoll. Wichtig ist, dass die Bytes nicht die Frame Check Sequence (FCS) enthalten.

Schlussfolgerung

Es ist wichtig zu verstehen, dass die Anzahl der vom Layer-3-Warteschlangensystem gezählten Oktette und die Anzahl der Oktette, die tatsächlich von einem Paket verwendet werden, sobald es die physische Ebene erreicht hat, unterschiedlich ist. Die tatsächliche Bandbreite eines 64-Byte-Pakets ist auf einer ATM-Schnittstelle viel größer als auf einer Ethernet-Schnittstelle. Insbesondere sind bei CBWFQ und LLQ die beiden folgenden ATM-spezifischen Overhead nicht berücksichtigt:

• Padding - Stellt die letzte Zelle eines Pakets sogar ein Vielfaches von 48 Byte dar. Dieses Padding wird vom SAR hinzugefügt, sobald das Paket die ATM-Ebene erreicht.

• 5-Byte-ATM-Zell-Header

Mit anderen Worten: CBWFQ und LLQ schätzen 64 Byte auf 64 Byte, aber das Paket belegt tatsächlich 106 Byte und verwendet zwei Zellen auf der ATM- und der physischen Ebene. An allen Schnittstellen sind auch Flags und ein CRC vorhanden, jedoch nicht im Layer-3-Warteschlangensystem enthalten.

Die Cisco Bug-ID CSCdt85156 (nur registrierte Kunden) ist eine Funktionsanforderung zur Zählung des CRC. Es wird argumentiert, dass alle festen und vorhersehbaren Layer-2-Overhead, wie z. B. ein CRC, in die Prioritätsanweisung aufgenommen werden sollten, um diese Konfiguration so genau und so nahe wie möglich an dem zu machen, was tatsächlich von einem Fluss verbraucht wird, wenn er auf das physische Kabel trifft.

Zugehörige Informationen

• Voice-over-IP - Bandbreitennutzung pro Anruf
• Low Latency Queuing
• Ressourcen für den asynchronen Transfermodus (ATM)
• LAN-Produktunterstützung
• Technischer Support und Dokumentation - Cisco Systems