Contenu

Introduction

Conditions préalables

Conditions requises

Components Used

Conventions

Déterminer la valeur de l'instruction de bande passante dans une stratégie de service QoS

Conclusion

Informations connexes

Introduction

Ce document fournit des informations pour vous aider à déterminer quels octets sont comptés par la mise en file d'attente du mode de transfert asynchrone (ATM) IP à IP.

Conditions préalables

Conditions requises

Aucune spécification déterminée n'est requise pour ce document.

Components Used

Ce document n'est pas limité à des versions de matériel et de logiciel spécifiques.

Conventions

Pour plus d'informations sur les conventions utilisées dans ce document, reportez-vous à Conventions relatives aux conseils techniques Cisco.

Déterminer la valeur de l'instruction de bande passante dans une stratégie de service QoS

Q. Je dois déterminer la valeur de l'instruction de bande passante dans ma stratégie de service QoS. Sur les circuits virtuels permanents ATM (PVC), comment cette valeur est-elle mesurée ? Compte-t-il l’ensemble des 53 octets des cellules ATM ?

A. Les commandes bandwidth et priority configurées dans une stratégie de service pour activer la mise en file d'attente CBWFQ (Weighted Fair Queueing) basée sur les classes et la mise en file d'attente à faible latence (LLQ), respectivement, utilisent une valeur en kbits/s qui compte les mêmes octets de surcharge comptés par la sortie de la commande show interface. Plus précisément, le système de mise en file d’attente de couche 3 compte les éléments suivants :

Champ Frais généraux

Longueur

Compté dans la commande show policy-map interface

Contrôle de liaison logique / protocole d'accès au sous-réseau (LLC/SNAP)

8 (par paquet)

Oui

Trailer de la couche d'adaptation ATM 5 (AAL5)

4

Non. La queue de bande AAL5 et le contrôle de redondance cyclique (CRC) sont ajoutés dans la segmentation et le réassemblage (SAR) et ne sont donc jamais pris en compte dans IOS. Les 4 octets qui sont comptés sont des octets d’encapsulation de circuit virtuel interne (VC).

Remplissage pour faire de la dernière cellule un multiple pair de 48 octets

Variable

Non

En-têtes de cellule ATM

5 (par cellule)

Non

Cette section explique comment utiliser les compteurs dans la sortie de commande show policy-map interface afin de déterminer quels octets de surcharge sont comptés par le système de mise en file d'attente de couche 3.

Traditionnellement, les périphériques Cisco utilisent ces définitions d'octets de PDU AAL5et d'octets de cellules ATM :

- ATM_cell_byte = résumé(aal5_pdu/48)*53

- aal5_pdu_byte = taille_ip + snap(8)+aal5_ovh(8) = taille_éther - 2

Dans ce test, 50 paquets par seconde (pps) de charge utile IP de 60 octets vers PVC 0/3 sont transmis, qui est configuré pour l'encapsulation 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 octets / 14349 paquets = 72 octets par paquet

8 (en-tête SNAP) + 60 IP paylod + 4 (4 premiers octets de la queue de bande AAL5) = 72

Après le test, la commande show policy-map int affiche 14349 paquets et 1033128 octets. Ces valeurs comptent le nombre de paquets qui correspondent aux critères de la classe. Les pkts correspondants/octets correspondants s'incrémentent uniquement lorsque le circuit virtuel est congestionné ou lorsque le paquet est commuté par processus. Tous les paquets à commutation de processus sont envoyés au moteur de file d'attente de couche 3.

Vérifiez que la commande show interface atm compte les mêmes octets de surcharge. Dans ce test, cinq requêtes ping de 100 octets sont envoyées :

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 sortie de la commande show interface atm affiche cinq paquets d'entrée et 540 octets. Les 40 octets supplémentaires au-dessus des 500 octets de données utiles IP proviennent de ceci :

- 40 octets / 5 paquets = 8 octets de surcharge par paquet

- 8 octets d'en-tête 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

Il s’agit d’un test effectué sur une interface Ethernet, qui envoie 100 paquets de 74 octets :

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

La commande show policy-map interface et la commande show interface ethernet ont compté 740 octets.

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 données utiles IP + 2 * 6 (adresse MAC source et de destination) + 2 (type de protocole) = 74

À partir de ce calcul, vous pouvez voir que le CRC Ethernet n'est pas inclus dans les sorties de commande show interface ou show policy-map. Il est important de noter que les deux valeurs sont cohérentes quant à l'inclusion ou non de la CRC.

Enfin, voici les octets comptés sur une interface série qui utilise l’encapsulation HDLC (High-Level Data Link Control). Dans ce test, cinq paquets de 100 octets sont transmis :

r3#show policy interface

Serial4/2:0

Service-policy output: test

Class-map: icmp (match-all)

5 packets, 520 bytes

Voici les définitions des trames HDLC Cisco :

- indicateur : début ou fin de la trame = 0x7E

- adresse : champ de type de trame :

- 0x0F : trame de monodiffusion

- 0x80 : trame de diffusion

- 0x40 : trame capitonnée

- 0x20 : trame compressée

- protocol : type Ethernet des données encapsulées, par exemple 0x0800 pour IP

La sortie de la commande show policy interface pour le test série affiche 520 octets. Les quatre octets supplémentaires par trame n’incluent pas les indicateurs de début et de fin de trame. Au lieu de cela, les octets incluent les champs d'adresse, de contrôle et de protocole. Surtout, les octets n'incluent pas la séquence de contrôle de trame (FCS).

Conclusion

Il est important de comprendre qu’il existe une différence dans le nombre d’octets comptés par le système de mise en file d’attente de couche 3 et dans le nombre d’octets réellement utilisés par un paquet une fois qu’il atteint la couche physique. La bande passante réelle utilisée par les paquets de 64 octets est beaucoup plus importante sur une interface ATM que sur une interface Ethernet. Plus précisément, CBWFQ et LLQ ne tiennent pas compte de ces deux ensembles de surcharge ATM :

- Remplissage : fait de la dernière cellule d'un paquet un multiple de 48 octets. Ce remplissage est ajouté par la SAR une fois que le paquet atteint la couche ATM.

- En-tête de cellule ATM à 5 octets

En d'autres termes, CBWFQ et LLQ estiment 64 octets à 64 octets, mais le paquet occupe en fait 106 octets et utilise deux cellules au niveau des couches ATM et physiques. Sur toutes les interfaces, des indicateurs et un CRC sont également présents, mais ne sont pas inclus par le système de mise en file d'attente de couche 3.

L'ID de bogue Cisco CSCdt85156 (clients enregistrés uniquement) est une demande de fonctionnalité pour compter le CRC. Il fait valoir que toute surcharge de couche 2 fixe et prévisible, telle qu'un CRC, doit être incluse dans l'instruction de priorité pour rendre cette configuration aussi précise et proche que possible de ce qui est réellement consommé par un flux lorsqu'il touche le câble physique.

Informations connexes

- Voix sur IP - Consommation de bande passante par appel

- Mise en file d'attente à faible latence (LLQ)

- Ressources ATM (Asynchronous Transfer Mode)

- Support pour les produits LAN

- Support et documentation techniques - Cisco Systems