Dit document bevat informatie om u te helpen bepalen welke bytes door IP worden geteld naar de wachtrij van Asynchronous Transfer Mode (ATM).
Er zijn geen specifieke vereisten van toepassing op dit document.
Dit document is niet beperkt tot specifieke software- en hardware-versies.
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.
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.
Revisie | Publicatiedatum | Opmerkingen |
---|---|---|
1.0 |
03-Nov-2006 |
Eerste vrijgave |