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

Présentation de la mise en file d'attente pondérée basée sur les classes sur les interfaces ATM

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 utilisant la technologie basée sur classe de la mise en file d'attente pondérée (CBWFQ).

Le Mise en file d'attente pondérée (WFQ) permet aux liens à basse vitesse, tels que des liaisons série, de fournir le traitement équitable pour tous les types de trafic. Il 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 exiger 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é. Cependant, WFQ a certaines limites :

  • Il n'est pas extensible si la quantité d'écoulement augmente considérablement.

  • WFQ indigène n'est pas disponible sur les interfaces ultra-rapides telles que des interfaces ATM.

CBWFQ fournit une solution à ces limites. À la différence de WFQ standard, CBWFQ te permet pour définir des classes du trafic et pour appliquer des paramètres, tels que la bande passante et les queues-limit, à ces classes. La bande passante que vous assignez à une classe est utilisée pour 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 appliqué aux classes (qui peuvent inclure plusieurs écoulements) plutôt que les écoulements eux-mêmes.

Pour plus d'informations sur configurer CBWFQ, cliquez sur en fonction les liens suivants :

Mise en file d'attente pondérée basée sur classe de Par-circuit virtuel (Par-circuit virtuel CBWFQ) sur 3600, et 2600 les Routeurs de Cisco 7200.

Mise en file d'attente pondérée basée sur classe de Par-circuit virtuel sur les Plateformes basées sur RSP.

Avant de commencer

Conventions

Pour plus d'informations sur les conventions des documents, référez-vous aux Conventions utilisées pour les conseils techniques de Cisco.

Conditions préalables

Aucune condition préalable spécifique 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.

Les informations présentées dans ce document ont été créées à partir de périphériques dans un environnement de laboratoire spécifique. Tous les périphériques utilisés dans ce document ont démarré avec une configuration effacée (par défaut). Si vous travaillez dans un réseau opérationnel, assurez-vous de bien comprendre l'impact potentiel de toute commande avant de l'utiliser.

Diagramme du réseau

Afin d'illustrer comment WFQ fonctionne, utilisons l'installation suivante :

/image/gif/paws/10406/wfq_illustrated.gif

Dans l'installation que nous utilisons ici, des paquets peut être enregistré dans une des deux files d'attente suivantes :

  • Les premiers à système premier entré, premier sorti de matériel (FIFO) s'alignent sur l'adaptateur et le module réseau de port.

  • La file d'attente en logiciel de ½ du ¿  de Cisco IOSï (sur la mémoire d'entrée/sortie de routeur [E/S]) où les caractéristiques de Qualité de service (QoS) telles que CBWFQ peuvent être appliquées.

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 des caractéristiques de QoS telles que CBWFQ.

Fixation de 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 
       service-policy output test

La limite (x) 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 :

  • Il réduit la durée de paquets attendent dans la file d'attente FIFO avant d'être segmentée.

  • Il accélère l'utilisation du QoS en logiciel IOS.

Incidence de la limite de boucle de transmission

Regardons l'incidence de la limite de boucle de transmission utilisant l'installation affichée dans notre schéma de réseau ci-dessus. Nous pouvons assumer ce qui suit :

  • Le générateur du trafic envoie le trafic (1500 paquets d'octet) au périphérique d'évier, et ce trafic surcharge le PVC 0/102 entre router1 et router2.

  • Routeur3 essais pour cingler router1.

  • CBWFQ est activé sur le routeur 2.

Permettez-maintenant nous regardent deux configurations utilisant différentes limites de boucle de transmission afin de voir que l'incidence que ceci a.

Exemple A

Dans cet exemple, nous avons placé la boucle de transmission à trois (TX-ring-limit=3). Voici ce que nous voyons quand nous cinglons 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

Exemple B

Dans cet exemple, nous avons placé la boucle de transmission à 40 (TX-ring-limit=40). Voici ce que nous voyons quand nous utilisons 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

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). Nous pouvons déduire de ceci qu'une grande limite de boucle de transmission peut mener aux retards significatifs par transmission.

Comment CBWFQ fonctionne

Maintenant que nous avons vu l'incidence de la taille de la file d'attente FIFO de matériel, permettez-nous voient exactement comment CBWFQ fonctionne.

WFQ indigène assigne un poids à chaque conversation, et puis programme le moment de transmission pour chaque paquet des différents écoulements. Le poids est une fonction de la Priorité IP de chaque écoulement, et l'heure de planification dépend de la longueur de paquet. A cliquez ici pour plus de détails sur WFQ.

CBWFQ assigne un poids à chaque classe configurée au lieu de chaque écoulement. Ce poids est proportionnel à la bande passante configurée pour chaque classe. Plus avec précision, le poids est une fonction de la bande passante d'interface divisée par la bande passante de classe. Par conséquent, plus le paramètre de bande passante est grand, plus le poids est petit.

Nous pouvons calculer l'heure de planification de paquet utilisant la formule suivante :

scheduling tail_time= queue_tail_time + pktsize * weight 

Division de bande passante totale de l'interface

Les regardons comment le routeur divise la bande passante totale de l'interface entre les classes différentes. Afin d'entretenir les classes, le routeur utilise des files d'attente de calendrier. Chacune de ces files d'attente de calendrier enregistre les paquets qui doivent être transmis au même scheduling_tail_time. Le routeur entretient alors ces files d'attente de calendrier un par un. Regardons ce processus :

  1. Si l'encombrement se produit sur l'adaptateur de port quand un paquet arrive sur l'interface de sortie, ceci entraîne la queue dans IOS (CBWFQ dans ce cas).

  2. Le routeur calcule une heure de planification pour ce paquet de arrivée et l'enregistre dans la file d'attente de calendrier correspondant à cette heure de planification. Seulement un paquet par classe peut être enregistré dans une file d'attente particulière de calendrier.

  3. Quand il est temps d'entretenir la file d'attente de calendrier dans laquelle le paquet a été enregistré, l'IOS vide cette file d'attente et envoie les paquets à la file d'attente FIFO sur l'adaptateur de port lui-même. La taille de cette file d'attente FIFO est déterminée par la limite de boucle de transmission décrite ci-dessus.

  4. Si la file d'attente FIFO est trop petite pour adapter tous les paquets étant tenus dans la file d'attente service de calendrier, le routeur remet les paquets qui ne peuvent pas être enregistrés pour l'heure de planification suivante (correspondant à leur poids) et les place à plus tard dans la file d'attente s'accordante de calendrier.

  5. Quand tout ceci est fait, l'adaptateur de port traite les paquets dans sa file d'attente FIFO et envoie les cellules sur le fil et l'IOS se déplace à la prochaine file d'attente de calendrier.

    Grâce à ce mécanisme, chaque classe reçoit statistiquement une partie de la bande passante d'interface correspondant aux paramètres configurés pour elle.

Mécanisme de file d'attente de calendrier contre la taille de la boucle de transmission

Regardons les relations entre le mécanisme de file d'attente de calendrier et la taille de la boucle de transmission. Une petite boucle de transmission permet au QoS pour démarrer plus rapidement et réduit la latence pour les paquets attendant d'être transmis (qui est importante pour le trafic sensible au délai tel que la Voix). Cependant, s'il est trop petit, il peut entraîner le débit inférieur pour certaines classes. C'est parce que beaucoup de paquets peuvent devoir être remis à plus tard si la boucle de transmission ne peut pas les faciliter.

Il n'y a, malheureusement, aucune valeur idéale pour la taille de la boucle de transmission et la seule manière de trouver la meilleure valeur est par l'expérimentation.

Partager de bande passante

Nous pouvons regarder le concept de la bande passante partageant utilisant l'installation affichée dans notre schéma de réseau, en haut. Le générateur de paquet produit différents écoulements et les envoie au périphérique d'évier. Le trafic total représenté par ces écoulements est assez pour surcharger le PVC. Nous avons mis en application CBWFQ sur le Router2. Voici ce qui ressemble à notre configuration :

access-list 101 permit ip host 7.0.0.200 any 
   access-list 101 permit ip host 7.0.0.201 any 
   access-list 102 permit ip host 7.0.0.1 any 
   ! 
   class-map small 
     match access-group 101 
   class-map big 
     match access-group 102
   !
   policy-map test
   policy-map test 
     small class 
      bandwidth <x>
     big class 
      bandwidth <y>
    interface atm 4/0.102 
     pvc 0/102 
       TX-ring-limit 3 
       service-policy output test 
       vbr-nrt 64000 64000

Dans notre exemple, le Router2 est un routeur de Cisco 7200. C'est important parce que la limite de boucle de transmission est exprimée en particules, pas des paquets. Des paquets sont alignés dans la file d'attente FIFO de la carte de port dès qu'une particule libre sera disponible, même si plus d'une particule est nécessaire pour enregistrer le paquet.

Quelle est une particule ?

Au lieu d'allouer 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) dis-contiguës de la mémoire, appelées les particules, et puis les joint ensemble pour 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 que nous utilisons ici, la taille des particules est 512 octets.

Nous pouvons vérifier si les Routeurs de Cisco 7200 utilisent des particules à l'aide de la commande de shows buffer :

router2#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
     ATM4/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

Les « petites » et « grandes » classes que nous utilisons pour ce test sont remplies de la façon suivante :

  • Petite classe - nous avons configuré les paramètres de bande passante à 32 Kbps. Cette classe enregistre dix paquets de 1500 octets de 7.0.0.200, suivis de dix paquets de 1500 octets de 7.0.0.201

  • Grande classe - nous avons configuré le paramètre de bande passante aux 16 Kbit/s. Cette classe enregistre un écoulement de dix paquets 1500-bytes de 7.0.0.1.

Le générateur du trafic envoie une rafale de trafic destiné pour le périphérique d'évier aux 100 Mbits/s au Router2 dans l'ordre suivant :

  1. Dix paquets de 7.0.0.1.

  2. Dix paquets de 7.0.0.200.

  3. Dix paquets de 7.0.0.201.

Vérifier le poids d'écoulement

Regardons le poids appliqué aux différents écoulements. Pour faire ceci, nous pouvons utiliser la commande atmosphère x/y.z de show queue.

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

  (depth/weight/total drops/no-buffer drops/interleaves) 7/128/0/0/0    
     Conversation 25, linktype: ip, length: 1494 
     source: 7.0.0.201, destination: 6.6.6.6, id: 0x0000, ttl: 63, prot: 255  

  (depth/weight/total drops/no-buffer drops/interleaves) 2/256/0/0/0    
     Conversation 26, linktype: ip, length: 1494 
     source: 7.0.0.1, destination: 6.6.6.6, id: 0x0000, ttl: 63, prot: 255

Quand tous les paquets de 7.0.0.200 ont été alignés hors du routeur, nous pouvons voir ce qui suit :

alcazaba#show queue ATM 4/0.102 
     Interface ATM4/0.102 VC 0/102 
     Queueing strategy: weighted fair 
     Total output drops per VC: 0 
     Output queue: 9/512/64/0 (size/max total/threshold/drops) 
        Conversations  2/3/16 (active/max active/max total)    
        Reserved Conversations 2/2 (allocated/max allocated)
 
  (depth/weight/total drops/no-buffer drops/interleaves) 7/128/0/0/0    
     Conversation 25, linktype: ip, length: 1494 
     source: 7.0.0.201, destination: 6.6.6.6, id: 0x0000, ttl: 63, prot: 255
  
  (depth/weight/total drops/no-buffer drops/interleaves) 2/256/0/0/0    
     Conversation 26, linktype: ip, length: 1494 
     source: 7.0.0.1, destination: 6.6.6.6, id: 0x0000, ttl: 63, prot: 255  

Comme vous pouvez voir ici, les écoulements de 7.0.0.200 et de 7.0.0.201 ont le même poids (128). Ce poids est demi la taille du poids assigné à l'écoulement de 7.0.0.1 (256). Ceci correspond au fait que notre petite bande passante de classe est deux fois plus grande que notre grande classe.

Vérifier la distribution de bande passante

Ainsi comment pouvons-nous vérifier la distribution de bande passante entre les différents écoulements ? La méthode de mise en file d'attente FIFO est utilisée dans chaque classe. Notre petite classe est remplie de dix paquets à partir du premier écoulement et de dix paquets à partir du deuxième écoulement. Le premier écoulement est enlevé de la petite classe à 32 Kbps. Dès qu'ils seront envoyés, les dix paquets de l'autre écoulement sont aussi bien envoyés. Dans le même temps, des paquets de notre grande classe sont retirés aux 16 Kbit/s.

Nous pouvons voir que, puisque le générateur du trafic envoie une rafale aux 100 Mbits/s, le PVC sera surchargé. Cependant, car il n'y a aucun trafic sur le PVC quand le test est commencé et, puisque les paquets de 7.0.0.1 sont les premiers pour atteindre le routeur, quelques paquets de 7.0.0.1 sera envoyé avant que des débuts CBWFQ en raison de l'encombrement (en d'autres termes, avant la boucle de transmission est plein).

Puisque la taille des particules est de 512 octets et la taille de la boucle de transmission est trois particules, nous pouvons voir que deux paquets de 7.0.0.1 sont envoyés avant que l'encombrement se produise. Un est immédiatement envoyé sur le fil et le deuxième est enregistré dans les trois particules formant la file d'attente FIFO de la carte de port.

Nous pouvons voir que met au point ci-dessous sur le périphérique d'évier (qui est simplement un routeur) :

Nov 13 12:19:34.216: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, len 1482, rcvd 4 
   Nov 13 12:19:34.428: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 

   
!--- congestion occurs here.


   Nov 13 12:19:34.640: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   Nov 13 12:19:34.856: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   Nov 13 12:19:35.068: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   Nov 13 12:19:35.280: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   Nov 13 12:19:35.496: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   Nov 13 12:19:35.708: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   Nov 13 12:19:35.920: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   Nov 13 12:19:36.136: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   Nov 13 12:19:36.348: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   Nov 13 12:19:36.560: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   Nov 13 12:19:36.776: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   Nov 13 12:19:36.988: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   Nov 13 12:19:37.200: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   Nov 13 12:19:37.416: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   Nov 13 12:19:37.628: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   Nov 13 12:19:37.840: IP: s=7.0.0.201 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   Nov 13 12:19:38.056: IP: s=7.0.0.201 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   Nov 13 12:19:38.268: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   Nov 13 12:19:38.480: IP: s=7.0.0.201 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   Nov 13 12:19:38.696: IP: s=7.0.0.201 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   Nov 13 12:19:38.908: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   Nov 13 12:19:39.136: IP: s=7.0.0.201 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   Nov 13 12:19:39.348: IP: s=7.0.0.201 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   Nov 13 12:19:39.560: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   Nov 13 12:19:39.776: IP: s=7.0.0.201 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   Nov 13 12:19:39.988: IP: s=7.0.0.201 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   Nov 13 12:19:40.200: IP: s=7.0.0.201 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   Nov 13 12:19:40.416: IP: s=7.0.0.201 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4  

Puisque les longueurs de paquet pour les deux écoulements sont identiques, basé sur la formule heure de planification, nous devrions voir deux paquets de notre petite classe étant envoyée pour chaque paquet de notre grande classe. Est exactement ce ce que nous voyons dans met au point en haut.

Test B

Pour notre deuxième test, permettez-nous remplissent classes de la façon suivante :

  • Petite classe - nous avons configuré le paramètre de bande passante à 32 Kbps. Dix paquets de 500 octets de 7.0.0.200 sont générés, suivi de dix paquets de 1500 octets de 7.0.0.201.

  • Grande classe - nous avons configuré le paramètre de bande passante aux 16 Kbit/s. Les mémoires de classe un écoulement de 1500 paquets d'octets provenant 7.0.0.1.

Le générateur du trafic envoie une rafale de trafic aux 100 Mbits/s au Router2 dans l'ordre suivant :

  1. Dix paquets 1500-byte de 7.0.0.1.

  2. Dix paquets 500-byte de 7.0.0.200.

  3. Dix 1500 paquets d'octet de 7.0.0.201.

Le FIFO est configuré dans chaque classe.

Vérifier le poids d'écoulement

L'étape suivante est de vérifier le poids appliqué aux écoulements classifiés :

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

  (depth/weight/total drops/no-buffer drops/interleaves) 15/128/0/0/0    
     Conversation 25, linktype: ip, length: 494 
     source: 7.0.0.200, destination: 6.6.6.6, id: 0x0000, ttl: 63, prot: 255  

  (depth/weight/total drops/no-buffer drops/interleaves) 8/256/0/0/0    
     Conversation 26, linktype: ip, length: 1494 
     source: 7.0.0.1, destination: 6.6.6.6, id: 0x0000, ttl: 63, prot: 255 

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

  (depth/weight/total drops/no-buffer drops/interleaves) 8/128/0/0/0    
     Conversation 25, linktype: ip, length: 1494 
     source: 7.0.0.201, destination: 6.6.6.6, id: 0x0000, ttl: 63, prot: 255  

  (depth/weight/total drops/no-buffer drops/interleaves) 5/256/0/0/0    
     Conversation 26, linktype: ip, length: 1494 
     source: 7.0.0.1, destination: 6.6.6.6, id: 0x0000, ttl: 63,

Comme vous pouvez voir dans la sortie ci-dessus, les écoulements de 7.0.0.200 et de 7.0.0.201 ont reçu le même poids (128). Ce poids est demi la taille du poids assigné à l'écoulement de 7.0.0.1. Ceci correspond au fait que la petite classe a une bande passante deux fois la taille de notre grande classe.

Vérifier la distribution de bande passante

Nous pouvons produire le suivant met au point du périphérique d'évier :

Nov 14 06:52:01.761: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   Nov 14 06:52:01.973: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 

   
!--- Congestion occurs here.
 

   Nov 14 06:52:02.049: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 482, rcvd 4 
   Nov 14 06:52:02.121: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 482, rcvd 4 
   Nov 14 06:52:02.193: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 482, rcvd 4 
   Nov 14 06:52:02.269: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 482, rcvd 4 
   Nov 14 06:52:02.341: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 482, rcvd 4 
   Nov 14 06:52:02.413: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 482, rcvd 4 
   Nov 14 06:52:02.629: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   Nov 14 06:52:02.701: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 482, rcvd 4 
   Nov 14 06:52:02.773: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 482, rcvd 4 
   Nov 14 06:52:02.849: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 482, rcvd 4 
   Nov 14 06:52:02.921: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 482, rcvd 4 
   Nov 14 06:52:03.149: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   Nov 14 06:52:03.361: IP: s=7.0.0.201 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   Nov 14 06:52:03.572: IP: s=7.0.0.201 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   Nov 14 06:52:03.788: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   Nov 14 06:52:04.000: IP: s=7.0.0.201 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   Nov 14 06:52:04.212: IP: s=7.0.0.201 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   Nov 14 06:52:04.428: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   Nov 14 06:52:04.640: IP: s=7.0.0.201 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   Nov 14 06:52:04.852: IP: s=7.0.0.201 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   Nov 14 06:52:05.068: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   Nov 14 06:52:05.280: IP: s=7.0.0.201 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   Nov 14 06:52:05.492: IP: s=7.0.0.201 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   Nov 14 06:52:05.708: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   Nov 14 06:52:05.920: IP: s=7.0.0.201 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   Nov 14 06:52:06.132: IP: s=7.0.0.201 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   Nov 14 06:52:06.348: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   Nov 14 06:52:06.560: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4

Dans ce scénario, les écoulements dans notre petite classe n'ont pas la même longueur de paquet. Par conséquent, la distribution des paquets n'est pas aussi insignifiante que pour le test A, en haut.

Heures de planification

Allons voir un oeil plus attentif les heures de planification pour chaque paquet. L'heure de planification pour des paquets est calculée utilisant la formule suivante :

scheduling tail_time= sub_queue_tail_time + pktsize *
     weight

Pour différentes longueurs de paquet, l'heure de planification utilise la formule suivante :

500 bytes (small class): scheduling tail_time = x + 494 * 128
     = x + 63232 
     1500 bytes (small class): scheduling tail_time = x + 1494 *
     128 = x + 191232 
     1500 bytes (big class): scheduling tail_time = x + 1494 *
     256 = x + 382464

De ces formules, nous pouvons voir que six paquets de 500 octets de notre petite classe sont transmis pour chaque paquet de 1500 octets de notre grande classe (affichée dans la sortie de débogage ci-dessus).

Nous pouvons également voir que deux paquets de 1500 octets de notre petite classe sont envoyés pour un paquet de 1500 octets de notre grande classe (affichée dans la sortie de débogage ci-dessus).

De nos tests ci-dessus, nous pouvons conclure ce qui suit :

  • La taille de la boucle de transmission (tx-ring-limit) détermine à quelle rapidité le mécanisme de mise en file d'attente commence fonctionner. Nous pouvons voir l'incidence avec l'augmentation de la DURÉE DE TRANSMISSION de ping où la limite de boucle de transmission augmente. Par conséquent, si vous implémentez CBWFQ ou basse latence faisant la queue [LLQ]), envisagez de réduire la limite de boucle de transmission.

  • CBWFQ permet partager équitable de la bande passante d'interface entre les classes différentes.


Informations connexes


Document ID: 10406