Welke bytes worden door IP naar ATM CoS-wachtrij geteld?

Inleiding

Dit document bevat informatie om u te helpen bepalen welke bytes door IP worden geteld naar de wachtrij van Asynchronous Transfer Mode (ATM).

Voorwaarden

Vereisten

Er zijn geen specifieke vereisten van toepassing op dit document.

Gebruikte componenten

Dit document is niet beperkt tot specifieke software- en hardware-versies.

Conventies

Raadpleeg Cisco Technical Tips Conventions (Conventies voor technische tips van Cisco) voor meer informatie over documentconventies.

Bepaal de waarde voor de Bandbreedteschatting in een QoS-servicebeleid

Q. Ik moet de waarde voor het bandbreedtestatement bepalen in mijn QoS-servicebeleid. Hoe wordt deze waarde op ATM permanente virtuele circuits (PVC’s) gemeten? telt het de gehele 53 bytes van de ATM-cellen?

A. De bandbreedte en prioriteitsopdrachten die in een servicebeleid zijn geconfigureerd om op klasse gebaseerde weging in de wachtrij (CBWFQ) en lage latency wachtrij (LLQ) mogelijk te maken, gebruiken respectievelijk een kbps waarde die dezelfde overhead-bytes telt die zijn geteld door de opdrachtoutput van showinterface. In het bijzonder, telt Layer 3 wachtrijen systeem deze:

Overheadveld	Lengte	Samengesteld in show policy-map interface
Logical Link Control/Subnetwork Access Protocol (LLC/SNAP)	8 (per pakje)	Ja
ATM Adapter Layer 5 (AAL5) trailer	4	Nr. AAL5-trailer en cyclische redundantie controle (CRC) wordt toegevoegd aan de segmentatie en hermontage (SAR) en is daarom nooit in IOS opgenomen. De 4 bytes die worden geteld zijn interne Virtual Circuit (VC) insluitingbytes.
Toevoegen om van de laatste cel een zelfs veelvoud van 48 bytes te maken	Variabel	Nee
ATM-celkoppen	5 (per cel)	Nee

Deze sectie toont u hoe u de tellers in de opdrachtoutput van de show beleid-map interface gebruikt om te bepalen welke overhead bytes worden geteld door Layer 3 wachtend systeem.

Traditioneel gebruiken Cisco-apparaten deze definities van AAL5PDU bytes en ATM-celbytes:

• ATM_cell_byte = afronding (aal5_pdu/48)*53

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

In deze test worden 50 pakketten per seconde (pps) van 60 bytes IP-lading naar PVC 0/3 verzonden, die voor AAL5SNAP-insluiting is geconfigureerd:

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 pakketten = 72 bytes per pakket

8 (SNAP header) + 60 IP betaald + 4 (eerste 4 bytes van AAL5 trailer) = 72

Na de test, toont de show beleid-map int opdracht 14349 pakketten en 1033128 bytes. Deze waarden tellen het aantal pakketten die aan de criteria van de klasse beantwoorden. De overeenkomende pkts/bytes hebben alleen een waarde aangepast als de VC op een computer wordt gezet of als het pakket op een procesknop wordt geschakeld. Alle proces-switched pakketten worden naar de Layer 3-wachtrij gestuurd.

Bevestig dat de show interface ATM opdracht dezelfde overhead bytes telt. In deze test worden vijf pings van 100 bytes verzonden:

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#

De uitvoer van de opdracht ATM-interface toont vijf pakketten van input en 540 bytes. De extra 40 bytes boven de 500 bytes van IP payload komen van dit:

• 40 bytes / 5 pakketten = 8 bytes overhead per pakket

• 8 bytes van LLC/SNAP header

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

Dit is een test die over een Ethernet interface wordt uitgevoerd, en die 100 pakketten van 74 bytes verzonden:

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

Zowel de opdracht van de show beleid-map interface als de opdracht Show interface Ethernet telde 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 IP-lading + 2 * 6 (bron- en doeladres) + 2 (protocoltype) = 74

Op basis van deze berekening kunt u zien dat Ethernet CRC niet in de show interface is opgenomen of dat de opdrachtoutput van de show wordt weergegeven. Belangrijk is dat beide waarden consistent zijn in het al dan niet opnemen van de CRC.

Tot slot, hier zijn de bytes die op een seriële interface zijn geteld die de insluiting van de gegevenslink Control (HDLC) op hoog niveau gebruikt. In deze test worden vijf pakketten van 100 bytes verzonden:

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

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

Hier zijn de definities van Cisco HDLC-frames:

• vlag—begin of einde van frame = 0x7E

• veld adres/type frame:

  • 0x0F—Unicast frame

  • 0x80—broadcast-frame

  • 0x40-toegevoegd frame

  • 0x20-gecomprimeerd frame

• protocol-Ethernet type van de ingekapselde gegevens, zoals 0x0800 voor IP

De output van het opdracht van de showbeleidsinterface voor de seriële test toont 520 bytes. De extra vier bytes per frame omvatten niet de begin- en eindparfums. In plaats daarvan omvatten de bytes het adres, de controle en de protocolvelden. Belangrijk is dat de bytes niet de frame check sequentie (FCS) omvatten.

Conclusie

Het is belangrijk om te begrijpen dat er een verschil is in het aantal octetten dat door het Layer 3-wachtsysteem is geteld en het aantal octetten dat daadwerkelijk door een pakje wordt gebruikt wanneer de fysieke laag is bereikt. De echte bandbreedte die door het pakje 64-bytes wordt gebruikt, is veel groter op een ATM-interface dan op een Ethernet-interface. In het bijzonder houden CBWFQ en LLQ geen rekening met deze twee reeksen ATM-specifieke overhead:

• Door deze optie te plaatsen maakt u de laatste cel van een pakje een nog groot aantal van 48 bytes. Deze vulling wordt door de SAR toegevoegd zodra het pakket de ATM-laag bereikt.

• 5-bits ATM-celheader

Met andere woorden, CBWFQ en LLQ schatten 64 bytes bij 64 bytes, maar het pakket neemt feitelijk 106 bytes in en gebruikt twee cellen bij ATM en fysieke lagen. Op alle interfaces zijn ook vlaggen en een CRC aanwezig, maar zijn niet opgenomen in Layer 3 wachtrijen-systeem.

Cisco bug-ID CSCdt85156 (alleen geregistreerde klanten) is een functieverzoek om de CRC te tellen. Hij betoogt dat alle vaste en voorspelbare Layer 2-overhead, zoals een CRC, in de prioriteitsverklaring moet worden opgenomen om deze configuratie zo nauwkeurig en dicht mogelijk te maken bij wat daadwerkelijk door een stroom wordt verbruikt wanneer hij de fysieke draad raakt.

Gerelateerde informatie

• Voice-over-IP - verbruik per gespreksband
• Low Latency Queueing
• Asynchronous Transfer Mode (ATM) bronnen
• LAN-productondersteuning
• Technische ondersteuning en documentatie – Cisco Systems