Mode de transfert asynchrone (ATM) : Classe de service IP à ATM

Octets comptabilisés par la mise en file d'attente CoS d'IP à ATM

18 octobre 2016 - Traduction automatique
Autres versions: PDFpdf | Anglais (22 août 2015) | Commentaires


Contenu


Introduction

Ce document fournit des informations pour vous aider à déterminer quels octets sont comptés par l'IP à la queue de Mode de transfert asynchrone (ATM).

Conditions préalables

Conditions requises

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

Composants utilisés

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éterminez la valeur pour l'instruction de bande passante dans une stratégie de service QoS

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

R. Les commandes de bande passante et prioritaires configurées dans une stratégie de service pour activer le Mise en file d'attente pondérée basée sur les classes (CBWFQ) et la basse latence s'alignant (LLQ), respectivement, utilisent une valeur de Kbps qui compte les mêmes octets supplémentaires comptés par la sortie de commande d'interface d'exposition. Spécifiquement, le système de mise en file d'attente de la couche 3 compte ces derniers :

Champ supplémentaire Longueur Compté dans le show policy-map interface
Protocole d'accès de Logical Link Control/sous-réseau (LLC/SNAP) 8 (par paquet) Oui
Trailer de la couche d'adaptation ATM 5 (AAL5) 4 Non La remorque AAL5 et le contrôle de redondance cyclique (CRC) est ajoutée dans la segmentation et le réassemblage (SAR), et par conséquent pas rendu jamais e compte dans l'IOS. Les 4 octets qui sont comptés sont les octets internes d'encapsulation de circuit virtuel (circuit virtuel).
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 t'affiche comment utiliser les compteurs dans la sortie de commande de show policy-map interface afin de déterminer quels octets supplémentaires sont comptés par le système de mise en file d'attente de la couche 3.

Traditionnellement, les périphériques de Cisco utilisent ces définitions des octets d'octets AAL5PDU et de cellules atmosphère :

  • ATM_cell_byte = roundup(aal5_pdu/48)*53

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

Dans ce test, 50 paquets par seconde (PPS) de la charge utile d'IP 60-byte à 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

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

Après que le test, la commande du show policy-map international affiche 14349 paquets et 1033128 octets. Ces valeurs comptent le nombre de paquets qui apparient les critères de la classe. Les paquets appariés/octets ont apparié des incréments de valeur seulement quand le circuit virtuel est congestionné ou quand le paquet est commuté par processus. Tous les paquets commutés par processus sont envoyés à l'engine de queue de la couche 3.

Confirmez que la commande d'interface atm d'exposition compte les mêmes octets supplémentaires. Dans ce test, cinq pings de 100 octets sont envoyés :

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 d'interface atm d'exposition affiche cinq paquets d'entrée et de 540 octets. Les frais supplémentaires 40 octets au-dessus des 500 octets de charge utile d'IP proviennent ceci :

  • 40 octets/5 paquets = 8 octets de supplémentaire 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

C'est un test fait au-dessus d'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 de show policy-map interface et l'exposition relient la commande d'Ethernets 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 charges utiles d'IP + 2 * 6 (source et adresse MAC de destination) + 2 (type de protocole) = 74

De ce calcul, vous pouvez voir que le CRC d'Ethernets n'est pas inclus dans les sorties de commande d'interface ou de show policy-map d'exposition. D'une manière primordiale, les deux valeurs sont cohérentes dedans si le CRC est inclus.

En conclusion, voici les octets comptés sur une interface série qui utilise l'encapsulation de High-Level Data Link Control (HDLC). 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 de HDLC Cisco :

/image/gif/paws/10420/bytes_counted.gif

  • indicateur — début ou fin de trame = de 0x7E

  • adresse — champ de type de trame :

    • 0x0F — Trame de monodiffusion

    • 0x80 — Trame d'émission

    • 0x40 — Trame complétée

    • 0x20 — Trame comprimée

  • protocole — Type d'Ethernets des données encapsulées, telles que 0x0800 pour l'IP

La sortie de la commande d'interface de stratégie d'exposition pour le test séquentiel affiche 520 octets. Les quatre octets supplémentaires par trame n'incluent pas les indicateurs de trame de début et de fin. Au lieu de cela, les octets incluent les champs d'adresse, de contrôle et de protocole. D'une manière primordiale, les octets n'incluent pas le Frame Check Sequence (FCS).

Conclusion

Il est important de comprendre qu'il y a une différence dans le nombre d'octets comptés par le système de mise en file d'attente de la couche 3 et le nombre d'octets qui réellement sont utilisés par un paquet une fois il atteint la couche physique. La vraie bande passante utilisée par le paquet 64-bytes est beaucoup plus grande sur une interface ATM que sur une interface Ethernet. Spécifiquement, CBWFQ et LLQ n'expliquent pas ces deux ensembles de temps système d'Atmosphère-particularité :

  • Compléter — Fait à la dernière cellule d'un paquet un multiple égal de 48 octets. Cette remplissage est ajoutée par le SAR une fois que le paquet atteint la couche atmosphère.

  • en-tête de cellule ATM 5-byte

En d'autres termes, l'évaluation CBWFQ et LLQ 64 octets à 64 octets, mais le paquet réellement occupe 106 octets et utilise deux cellules à l'atmosphère et aux couches physiques. Sur toutes les interfaces, les indicateurs et un CRC sont également présents, mais ne sont pas inclus par le système de mise en file d'attente de la couche 3.

L'ID de bogue Cisco CSCdt85156 (clients enregistrés seulement) est une demande de caractéristique de compter le CRC. Il argue du fait que tous réparés et la couche prévisible 2 supplémentaire, comme un CRC, devraient être inclus dans la déclaration de priorité pour rendre cette configuration aussi précise et proche comme possible de ce qui est consommé réellement par un écoulement quand il frappe le fil physique.


Informations connexes


Document ID: 10420