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


Contenu


Introduction

Ce document fournit une introduction pour trafiquer la Mise en file d'attente qui utilise la technologie de Mise en file d'attente pondérée (WFQ).

WFQ a été introduit afin de permettre aux liens à basse vitesse, tels que des liaisons série de fournir le traitement équitable pour tous les types de trafic. Afin de faire ceci, WFQ classifie le trafic dans différents écoulements (également connus sous le nom de conversations) basés sur les informations de la couche trois et de la couche quatre, telles que des adresses IP et des ports TCP. Il fait ceci sans condition requise de vous de définir des Listes d'accès. Ceci signifie que le trafic de faible bande passante a efficacement la priorité au-dessus du trafic à grande bande passante parce que le trafic à grande bande passante partage les supports de transmission proportionnellement à son poids assigné.

Mais, WFQ a certaines limites :

la mise en file d'attente pondérée basée sur classe (CBWFQ) fournit une solution à ces limites.

À la différence de WFQ standard, CBWFQ te permet pour définir des classes du trafic. Vous pouvez également appliquer des paramètres, tels que la bande passante et les queues-limit, à elles. La bande passante que vous assignez à une classe est utilisée afin de calculer le poids de cette classe. Le poids de chaque paquet qui apparie les critères de classe est également calculé à partir de ceci. WFQ est alors appliqué aux classes, qui peuvent inclure plusieurs écoulements, plutôt que les écoulements eux-mêmes.

Référez-vous à ces documents pour plus d'informations sur la façon configurer CBWFQ :

Les interfaces ATM ne prennent en charge pas WFQ basé sur écoulement indigène configuré directement sur une interface avec la commande de foire-file d'attente. Mais, avec le logiciel qui prend en charge CBWFQ, vous pouvez configurer WFQ basé sur écoulement dans la classe par défaut, suivant les indications de cet exemple :

policy-map test
 class class-default
  fair-queue
!         
interface ATMx/y.z point-to-point
 ip address a.b.c.d M.M.M.M
 pvc A/B 
  service-policy output test

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.

Diagramme du réseau

Employez cette installation afin d'illustrer comment WFQ fonctionne :

/image/gif/paws/10049/wfq_illustrated.gif

Dans cette installation, des paquets peuvent être enregistrés dans une de ces deux files d'attente :

La file d'attente FIFO sur l'adaptateur de port enregistre les paquets avant qu'ils soient segmentés dans des cellules pour la transmission. Quand cette file d'attente est pleine, l'adaptateur ou le module réseau de port signale au logiciel IOS que la file d'attente est congestionnée. Ce mécanisme s'appelle la contre-pression. À la réception de ce signal, le routeur cesse d'envoyer des paquets à la file d'attente FIFO d'interface et enregistre les paquets en logiciel IOS jusqu'à ce que la file d'attente soit uncongested de nouveau. Quand les paquets sont enregistrés dans l'IOS, le système peut appliquer QoS.

Comment fixer la limite de boucle de transmission

Un problème avec ce mécanisme de mise en file d'attente est que, plus la file d'attente FIFO sur l'interface est grande, plus est long le retard avant que les paquets à l'extrémité de cette file d'attente peut être transmis. Ceci peut poser des graves problèmes de performances pour le trafic sensible au délai tel que le trafic vocal.

Les commandes enables de tx-ring-limit du circuit virtuel permanent (PVC) vous pour réduire la taille de la file d'attente FIFO.

interface ATMx/y.z point-to-point
 ip address a.b.c.d M.M.M.M
 PVC A/B 
  tx-ring-limit <size>

  service-policy output test

Le <size> que vous pouvez spécifier ici est un certain nombre de paquets, pour le Cisco 2600 et 3600 Routeurs, ou quantité de particules, pour le Cisco 7200 et 7500 Routeurs.

La réduction de la taille de la boucle de transmission a deux avantages :

Incidence de la limite de boucle de transmission

Regardez l'incidence de la limite de boucle de transmission qui utilise l'installation affichée dans le schéma de réseau précédent. Assumez ces derniers :

Regardez deux configurations qui emploie différentes limites de boucle de transmission afin de voir que l'incidence que ceci a.

Exemple A

Dans cet exemple, vous avez placé la boucle de transmission à trois (tx-ring-limit=3). Est ce ce que vous voyez quand vous cinglez router1 de router3 :

pound#ping ip
Target IP address: 6.6.6.6
Repeat count [5]: 100000
Datagram size [100]: 
Timeout in seconds [2]: 
Extended commands [n]: 
Sweep range of sizes [n]: 
Type escape sequence to abort.
Sending 100000, 100-byte ICMP Echos to 6.6.6.6, timeout is 2 seconds:
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!![snip]
Success rate is 98 percent (604/613), round-trip min/avg/max = 164/190/232 ms   

router2#show queue atm 4/0.102 
   Interface ATM4/0.102 VC 0/102 
   Queuing strategy: weighted fair 
   Total output drops per VC: 1505772 
   Output queue: 65/512/64/1505772 (size/max total/threshold/drops) 
    Conversations  2/3/16 (active/max active/max total)    
    Reserved Conversations 0/0 (allocated/max allocated)    

(depth/weight/discards/tail drops/interleaves) 1/32384/0/0/0    
   Conversation 2, linktype: ip, length: 58 
   source: 8.0.0.1, destination: 6.6.6.6, id: 0x2DA1, ttl: 254, prot: 1  
   
!--- ping 
   

(depth/weight/discards/tail drops/interleaves) 64/32384/1505776/0/0    
   Conversation 15, linktype: ip, length: 1494 
   source: 7.0.0.1, destination: 6.6.6.6, id: 0x0000, ttl: 63, prot: 255 
   
!--- This is traffic from the traffic generator. 

Exemple B

Dans cet exemple, vous avez placé la boucle de transmission à 40 (tx-ring-limit=40). Est ce ce que vous voyez quand vous utilisez le même ping que dans l'exemple A :

pound#ping ip
Target IP address: 6.6.6.6
Repeat count [5]: 10000
Datagram size [100]: 36
Timeout in seconds [2]: 10
Extended commands [n]: 
Sweep range of sizes [n]: 
Type escape sequence to abort.
Sending 10000, 36-byte ICMP Echos to 6.6.6.6, timeout is 10 seconds:
!!!!!!!!!!!!.
Success rate is 92 percent (12/13), round-trip min/avg/max = 6028/6350/6488 ms

Comme vous pouvez voir ici, plus la limite de boucle de transmission est grande, plus le Round-Trip Time de ping est grand (DURÉE DE TRANSMISSION). Vous pouvez déduire de ceci qu'une grande limite de boucle de transmission peut mener aux retards significatifs par transmission.

Comment calculer le poids

En atmosphère de show queue sortie dans l'exemple A, vous voyez qu'un poids est assigné à chaque conversation. Regardez ceci plus en détail :

router2#show queue ATM 4/0.102 
   Interface ATM4/0.102 VC 0/102 
   Queuing strategy: weighted fair 
   Total output drops per VC: 1505772 
   Output queue: 65/512/64/1505772 (size/max total/threshold/drops) 
    Conversations  2/3/16 (active/max active/max total)    
    Reserved Conversations 0/0 (allocated/max allocated)    

(depth/weight/discards/tail drops/interleaves) 1/32384/0/0/0    
   Conversation 2, linktype: ip, length: 58 
   source: 8.0.0.1, destination: 6.6.6.6, id: 0x2DA1, ttl: 254, prot: 1    

(depth/weight/discards/tail drops/interleaves) 64/32384/1505776/0/0    
   Conversation 15, linktype: ip, length: 1494 
   source: 7.0.0.1, destination: 6.6.6.6, id: 0x0000, ttl: 63, prot: 255  

Quand vous utilisez WFQ, vous pouvez calculer le poids de chaque conversation avec l'utilisation de cette formule :

Comment calculer l'heure de planification

Vous pouvez maintenant employer ces poids afin de calculer l'heure de planification de chaque paquet, quand le paquet est expédié de la file d'attente IOS à la file d'attente FIFO d'adaptateur ou de module réseau de port.

Vous pouvez calculer le temps de planification de sortie avec l'utilisation de cette formule, où le queue_tail_time est l'heure de planification en cours :

queue_tail_time + pktsize*weight de time= de planification de sortie

Comment WFQ fonctionne

Cette section explique comment WFQ fonctionne. Le principe de WFQ est que les paquets avec un petit poids, ou les petits paquets, devraient obtenir la priorité quand ils sont envoyés.

Créez un écoulement qui comporte dix grands paquets de paquets et quatre plus petits paquets (de 82 octets) ces utilise un générateur du trafic afin de vérifier ceci.

Dans cet exemple, router2 est un routeur de Cisco 7200 avec un PA-A3 (adaptateur de port ATM). C'est important parce que la taille de la file d'attente FIFO de sortie sur l'adaptateur de port est exprimée en particules et pas en paquets. Voyez ce qui est une particule ? section pour de plus amples informations.

Quelle est une particule ?

Au lieu de l'allocation de l'une seule pièce de la mémoire contiguë pour une mémoire tampon, la mise en mémoire tampon de particules alloue les parties (dispersées) discontiguous de la mémoire, appelées les particules, et puis les joint ensemble afin de former un tampon de paquets logique. Ceci s'appelle une mémoire tampon de particules. Dans un tel schéma, un paquet peut alors être répandu à travers des plusieurs particules.

Dans le routeur 7200, la taille des particules est de 512 octets.

Utilisez les shows buffer commandent afin de vérifier si les Routeurs de Cisco 7200 utilisent des particules :

router#show buffers
[snip]
Private particle pools: 
FastEthernet0/0 buffers, 512 bytes (total 400, permanent 400):
  0 in free list (0 min, 400 max allowed)
  400 hits, 0 fallbacks
  400 max cache size, 271 in cache
ATM2/0 buffers, 512 bytes (total 400, permanent 400): 
  0 in free list (0 min, 400 max allowed)
  400 hits, 0 fallbacks
  400 max cache size, 0 in cache

Testez A

Ce sont quelques tests afin d'illustrer la fonctionnalité WFQ. Dans ce premier test, le regardez si la bande passante peut être partagée entre différentes conversations.

Dans ce test, vous avez fait le générateur du trafic envoyer le trafic assez rapidement pour surcharger le PVC 0/102 entre router1 et router2. Exécutez un ping de router3 à router1 à travers le même PVC :

pound#ping ip
Target IP address: 6.6.6.6
Repeat count [5]: 100000
Datagram size [100]: 
Timeout in seconds [2]: 
Extended commands [n]: 
Sweep range of sizes [n]: 
Type escape sequence to abort.
Sending 100000, 100-byte ICMP Echos to 6.6.6.6, timeout is 2 seconds:
......... (WFQ is enabled here)!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!.[break]
Success rate is 98 percent (604/613), round-trip min/avg/max = 164/190/232 ms

Comme vous pouvez voir du résultat présenté, jusqu'à ce que WFQ soit activé sur l'interface, le trafic empêche l'autre trafic d'aller et meurt de faim la ligne. Dès que WFQ sera activé, le ping est réussi.

Vous pouvez voir de ceci que, avec l'utilisation de WFQ, la bande passante peut être partagé entre différentes conversations sans on bloquant les autres.

Test B

C'est comment la bande passante est partagée.

L'écoulement que le générateur du trafic envoie est une rafale composée de dix grands paquets, suivi de quatre plus petits paquets de 82 octets. Vous envoyez ceci aux 100 Mbits/s à router2. Quand vous envoyez la rafale, la file d'attente de sortie sur l'interface ATM router2 est vide. Le Router2 envoie ces paquets par un PVC du KO 10 (c'est un PVC très lent) afin de s'assurer que l'encombrement se produit sur la file d'attente de sortie.

Effectuez ce test dans plusieurs étapes afin de simplifier ce processus :

Étape 1

Le grand trafic comporte dix paquets 482-byte. Puisque les particules sur le PA-A3 sont de 512 octets, chaque paquet, si grand ou petit, devrait prendre une particule quand il est enregistré dans la file d'attente de sortie d'adaptateur de port. Le routeur a une limite de boucle de transmission de trois (tx-ring-limit=3). C'est un exemple de ce que vous pouvez voir sur le périphérique d'évier :

   .Nov  7 15:39:13.776: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, len 482, rcvd 4 
   .Nov  7 15:39:13.776: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 482, unknown protocol 
   .Nov  7 15:39:14.252: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 482, rcvd 4 
   .Nov  7 15:39:14.252: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 482, unknown protocol 
   .Nov  7 15:39:14.732: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 482, rcvd 4 
   .Nov  7 15:39:14.732: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 482, unknown protocol 
   .Nov  7 15:39:15.208: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 482, rcvd 4 
   .Nov  7 15:39:15.208: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 482, unknown protocol 

   
!--- Congestion occurs at this point. 


   .Nov  7 15:39:15.512: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 82, rcvd 4 
   .Nov  7 15:39:15.516: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 82, unknown protocol 
   .Nov  7 15:39:15.644: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 82, rcvd 4 
   .Nov  7 15:39:15.644: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 82, unknown protocol 
   .Nov  7 15:39:15.776: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 82, rcvd 4 
   .Nov  7 15:39:15.776: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 82, unknown protocol 
   .Nov  7 15:39:15.904: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 82, rcvd 4 
   .Nov  7 15:39:15.904: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 82, unknown protocol 
   .Nov  7 15:39:16.384: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 482, rcvd 4 
   .Nov  7 15:39:16.384: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 482, unknown protocol 
   .Nov  7 15:39:16.860: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 482, rcvd 4 
   .Nov  7 15:39:16.860: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 482, unknown protocol 
   .Nov  7 15:39:17.340: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 482, rcvd 4 
   .Nov  7 15:39:17.340: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 482, unknown protocol 
   .Nov  7 15:39:17.816: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 482, rcvd 4 
   .Nov  7 15:39:17.820: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 482, unknown protocol 
   .Nov  7 15:39:18.296: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 482, rcvd 4 
   .Nov  7 15:39:18.296: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 482, unknown protocol 
   .Nov  7 15:39:18.776: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 482, rcvd 4 
   .Nov  7 15:39:18.776: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 482, unknown protocol 

Vous pouvez voir les quatre paquets de 482 octets envoyés avant les paquets 82-byte, qui devraient normalement obtenir la priorité. C'est pourquoi ceci se produit.

Puisque la rafale se compose principalement de dix paquets 482-byte, ceux-ci atteignent le routeur d'abord, suivi des paquets 82-byte. Puisque les paquets 482-byte arrivent à un moment où il n'y a aucun encombrement, car il n'y a aucun trafic, un paquet est immédiatement aligné à la segmentation d'adaptateur de port et au réassemblage (SAR) à chunked dans des cellules et envoyés en fonction le fil. En d'autres termes, la boucle de transmission est encore vide.

Vous pouvez calculer que le temps nécessaire pour envoyer un paquet 482-byte est plus grand que le moment nécessaire pour le générateur du trafic afin d'envoyer toute la rafale. Vous pouvez donc supposer que, quand le premier paquet 482-byte est aligné à l'adaptateur de port, plus de paquets 482-byte de la rafale sont déjà présents dans le routeur. Par conséquent, plus de paquets 482-byte peuvent être alignés à la boucle de transmission. Trois paquets supplémentaires de 482 octets sont alignés en présence de l'utilisation des trois particules libres là.

Remarque: Des paquets sont alignés dans la boucle de transmission dès qu'il y aura une particule libre, même si ils ont besoin de plus d'une particule pour être enregistrée.

En ce moment, il y a d'encombrement, puisque les trois particules sont pleines. Par conséquent, débuts de queue dans l'IOS. Quand les quatre paquets 82-byte atteignent finalement le routeur, il y a d'encombrement. Ces quatre paquets sont alignés et WFQ est utilisé sur les deux écoulements. Regardez la file d'attente atmosphère qui emploie la commande atmosphère de show queue afin de voir ceci :

router2#show queue ATM 4/0.102 vc 0/102 
   Interface ATM4/0.102 VC 0/102 
   Queuing strategy: weighted fair 
   Total output drops per VC: 0 
   Output queue: 10/512/64/0 (size/max total/threshold/drops) 
     Conversations  2/4/16 (active/max active/max total)    
     Reserved Conversations 0/0 (allocated/max allocated)    

(depth/weight/total drops/no-buffer drops/interleaves) 4/32384/0/0/0    
   Conversation 6, linktype: ip, length: 82 
   source: 7.0.0.200, destination: 6.6.6.6, id: 0x0000, ttl: 63, prot: 255    

(depth/weight/total drops/no-buffer drops/interleaves) 6/32384/0/0/0    
   Conversation 15, linktype: ip, length: 482 
   source: 7.0.0.1, destination: 6.6.6.6, id: 0x0000, ttl: 63, prot: 255  

Vous pouvez voir dans met au point que les quatre premiers paquets de 482 octets sont suivis par les paquets 82-byte. Ces petits paquets sortent du routeur avant les grands paquets. Ceci indique que, dès que l'encombrement se produira, les petits paquets obtiennent la priorité au-dessus de grands paquets.

Utilisez les formules de poids et heure de planification données dans le calcul de la section de poids afin de vérifier ceci.

Étape 2

Si vous augmentez la limite de boucle de transmission à cinq et les grands paquets sont de 482 octets alors, dans l'accord à la sortie précédente, vous devraient voir six paquets de 482 octets avant que l'encombrement se produise, suivis de quatre paquets de 82 octets, puis encore quatre paquets de 482 octets :

   .Nov  7 15:49:57.365: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 482, rcvd 4 
   .Nov  7 15:49:57.365: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 482, unknown protocol 
   .Nov  7 15:49:57.841: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 482, rcvd 4 
   .Nov  7 15:49:57.845: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 482, unknown protocol 
   .Nov  7 15:49:58.321: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 482, rcvd 4 
   .Nov  7 15:49:58.321: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 482, unknown protocol 
   .Nov  7 15:49:58.797: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 482, rcvd 4 
   .Nov  7 15:49:58.801: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 482, unknown protocol 
   .Nov  7 15:49:59.277: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 482, rcvd 4 
   .Nov  7 15:49:59.277: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 482, unknown protocol 
   .Nov  7 15:49:59.757: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 482, rcvd 4 
   .Nov  7 15:49:59.757: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 482, unknown protocol 
   .Nov  7 15:49:59.973: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 82, rcvd 4 
   .Nov  7 15:49:59.973: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 82, unknown protocol 
   .Nov  7 15:50:00.105: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 82, rcvd 4 
   .Nov  7 15:50:00.105: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 82, unknown protocol 
   .Nov  7 15:50:00.232: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 82, rcvd 4 
   .Nov  7 15:50:00.232: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 82, unknown protocol 
   .Nov  7 15:50:00.364: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 82, rcvd 4 
   .Nov  7 15:50:00.364: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 82, unknown protocol 
   .Nov  7 15:50:00.840: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 482, rcvd 4 
   .Nov  7 15:50:00.844: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 482, unknown protocol 
   .Nov  7 15:50:01.320: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 482, rcvd 4 
   .Nov  7 15:50:01.320: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 482, unknown protocol 
   .Nov  7 15:50:01.796: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 482, rcvd 4 
   .Nov  7 15:50:01.800: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 482, unknown protocol 
   .Nov  7 15:50:02.276: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 482, rcvd 4 
   .Nov  7 15:50:02.276: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 482, unknown protocol  

Comme vous pouvez voir ici, c'est en effet ce qui se produit.

Étape 3

La taille des particules est de 512 octets. Par conséquent, si la boucle de transmission est exprimée en particules, et vous utilisez les paquets légèrement plus grands que la taille des particules, chacun prend deux particules. Ceci est illustré en employant des paquets de 582 octets et une boucle de transmission de trois. Avec ces paramètres, vous devriez voir trois paquets de 582 octets. Un est envoyé sans le trafic sur l'interface ATM, cette des feuilles que trois particules libèrent. Par conséquent, deux paquets supplémentaires peuvent être alignés, suivi de quatre paquets de 82 octets et puis de sept paquets de 582 octets :

   .Nov  7 15:51:34.604: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 582, rcvd 4 
   .Nov  7 15:51:34.604: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 582, unknown protocol 
   .Nov  7 15:51:35.168: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 582, rcvd 4 
   .Nov  7 15:51:35.168: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 582, unknown protocol 
   .Nov  7 15:51:35.732: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 582, rcvd 4 
   .Nov  7 15:51:35.736: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 582, unknown protocol 
   .Nov  7 15:51:35.864: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 82, rcvd 4 
   .Nov  7 15:51:35.864: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 82, unknown protocol 
   .Nov  7 15:51:35.996: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 82, rcvd 4 
   .Nov  7 15:51:35.996: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 82, unknown protocol 
   .Nov  7 15:51:36.124: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 82, rcvd 4 
   .Nov  7 15:51:36.124: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 82, unknown protocol 
   .Nov  7 15:51:36.256: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 82, rcvd 4 
   .Nov  7 15:51:36.256: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 82, unknown protocol 
   .Nov  7 15:51:36.820: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 582, rcvd 4 
   .Nov  7 15:51:36.820: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 582, unknown protocol 
   .Nov  7 15:51:37.384: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 582, rcvd 4 
   .Nov  7 15:51:37.388: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 582, unknown protocol 
   .Nov  7 15:51:37.952: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 582, rcvd 4 
   .Nov  7 15:51:37.952: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 582, unknown protocol 
   .Nov  7 15:51:38.604: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 582, rcvd 4 
   .Nov  7 15:51:38.604: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 582, unknown protocol 
   .Nov  7 15:51:39.168: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 582, rcvd 4 
   .Nov  7 15:51:39.168: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 582, unknown protocol 
   .Nov  7 15:51:39.732: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 582, rcvd 4 
   .Nov  7 15:51:39.736: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 582, unknown protocol 
   .Nov  7 15:51:40.300: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 582, rcvd 4 
   .Nov  7 15:51:40.300: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 582, unknown protocol  

Étape 4

Prenez une longueur de paquet de 1482 (trois particules) et définissez une boucle de transmission de cinq. Si la boucle de transmission est définie dans les particules, vous voyez quelque chose semblable :

   .Nov  8 07:22:41.200: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   .Nov  8 07:22:41.200: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 1482, unknown protocol 
   .Nov  8 07:22:42.592: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   .Nov  8 07:22:42.592: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 1482, unknown protocol 
   .Nov  8 07:22:43.984: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   .Nov  8 07:22:43.984: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 1482, unknown protocol 
   .Nov  8 07:22:44.112: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 82, rcvd 4 
   .Nov  8 07:22:44.112: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 82, unknown protocol 
   .Nov  8 07:22:44.332: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 82, rcvd 4 
   .Nov  8 07:22:44.332: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 82, unknown protocol 
   .Nov  8 07:22:44.460: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 82, rcvd 4 
   .Nov  8 07:22:44.460: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 82, unknown protocol 
   .Nov  8 07:22:44.591: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 82, rcvd 4 
   .Nov  8 07:22:44.591: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 82, unknown protocol 
   .Nov  8 07:22:45.983: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   .Nov  8 07:22:45.983: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 1482, unknown protocol 
   .Nov  8 07:22:47.371: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   .Nov  8 07:22:47.375: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 1482, unknown protocol 
   .Nov  8 07:22:48.763: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   .Nov  8 07:22:48.767: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 1482, unknown protocol 
   .Nov  8 07:22:50.155: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   .Nov  8 07:22:50.155: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 1482, unknown protocol 
   .Nov  8 07:22:51.547: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   .Nov  8 07:22:51.547: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 1482, unknown protocol 
   .Nov  8 07:22:53.027: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   .Nov  8 07:22:53.027: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 1482, unknown protocol 
   .Nov  8 07:22:54.415: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   .Nov  8 07:22:54.419: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 1482, unknown protocol 

Résumé

Des tests effectués, vous pouvez conclure ces derniers :


Informations connexes


Document ID: 10049