Présentation des compteurs de paquets dans la sortie de la commande show interface rate avec CAR (Committed Access Rate)

Options de téléchargement

  • PDF     (272.6 KB)
    Consulter à l'aide d'Adobe Reader sur un grand nombre d'appareils
Mis à jour:15 février 2019
ID du document:28882

Langage exempt de préjugés

Dans le cadre de la documentation associée à ce produit, nous nous efforçons d’utiliser un langage exempt de préjugés. Dans cet ensemble de documents, le langage exempt de discrimination renvoie à une langue qui exclut la discrimination en fonction de l’âge, des handicaps, du genre, de l’appartenance raciale de l’identité ethnique, de l’orientation sexuelle, de la situation socio-économique et de l’intersectionnalité. Des exceptions peuvent s’appliquer dans les documents si le langage est codé en dur dans les interfaces utilisateurs du produit logiciel, si le langage utilisé est basé sur la documentation RFP ou si le langage utilisé provient d’un produit tiers référencé. Découvrez comment Cisco utilise le langage inclusif.

À propos de cette traduction

Cisco a traduit ce document en traduction automatisée vérifiée par une personne dans le cadre d’un service mondial permettant à nos utilisateurs d’obtenir le contenu d’assistance dans leur propre langue. Il convient cependant de noter que même la meilleure traduction automatisée ne sera pas aussi précise que celle fournie par un traducteur professionnel.

Introduction

Le Committed Access Rate (CAR) est une fonctionnalité de limitation du débit pouvant servir à offrir des services de classification et de contrôle. Le CAR peut être utilisé pour classer des paquets selon certains critères tels que l'adresse IP et les valeurs de port qui utilisent des listes d'accès. Les mesures à prendre peuvent être définies pour les paquets qui respectent la valeur limite de débit et pour ceux qui la dépassent. Consultez le document Configurer le Committed Access Rate pour en savoir plus sur la configuration du CAR.

Ce document explique pourquoi le résultat de la commande show interface x/x rate-limit montre une valeur de bit/s dépassée non nulle lorsque la valeur de bit/s conforme est inférieure au débit d'informations garanti (CIR) configuré.

Conditions préalables

Exigences

Aucune exigence spécifique n'est associée à 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.

Présentation du résultat de la commande show interface rate

Il existe trois conditions dans lesquelles vous pouvez voir des taux de dépassement non nuls dans le résultat de cette commande :

  • Les valeurs de rafale sont trop faibles pour permettre un débit suffisant. Par exemple, consultez l'ID de bogue Cisco CSCdw42923 (clients enregistrés seulement).

  • Problème résolu avec la comptabilité double dans le logiciel Cisco IOS®

  • Bogue logiciel dans Cisco IOS

Examinez l'exemple de sortie d'une interface d'accès virtuel. Dans cette configuration, RADIUS est utilisé afin d'attribuer une limite de débit à l'interface d'accès virtuel créée dynamiquement. 

AV Pair from Radius 
Cisco-AVPair = "lcp:interface-config#1=rate-limit input 256000 7500 7500 
conform-action continue 
exceed-action drop", 
Cisco-AVPair = "lcp:interface-config#2=rate-limit output 512000 7500 7500 
conform-action continue 
exceed-action drop",

Utilisez la commande show interface x rate-limit afin de surveiller les performances du contrôleur hérité de Cisco, CAR. Dans cet exemple, le résultat de cette commande fournit des indications sur la raison pour laquelle il y a un dépassement de bit/s non nul. La valeur de rafale actuelle est de 7 392 octets, tandis que la valeur de rafale validée (Bc), indiquée par la valeur limite, est définie sur 7 500 octets. 

router#show interfaces virtual-access 26 rate-limit 
Virtual-Access26 Cable Customers 
  Input 
    matches: all traffic 
      params:  256000 bps, 7500 limit, 7500 extended limit 
      conformed 2248 packets, 257557 bytes; action: continue 
      exceeded 35 packets, 22392 bytes; action: drop 
      last packet: 156ms ago, current burst: 0 bytes 
      last cleared 00:02:49 ago, conformed 12000 bps, exceeded 1000 bps 
  Output 
    matches: all traffic 
      params:  512000 bps, 7500 limit, 7500 extended limit 
      conformed 3338 packets, 4115194 bytes; action: continue 
      exceeded 565 packets, 797648 bytes; action: drop 
      last packet: 188ms ago, current burst: 7392 bytes 
      last cleared 00:02:49 ago, conformed 194000 bps, exceeded 37000 bps

Lorsque vous configurez CAR ou un régulateur plus récent de Cisco, la réglementation basée sur les classes, vous devez configurer des valeurs de rafale suffisamment élevées afin de garantir le débit attendu et de vous assurer que le régulateur abandonne les paquets uniquement pour punir la congestion à court terme.

Lorsque vous sélectionnez des valeurs de rafale, il est important de prendre en compte les augmentations transitoires de la taille de la file d'attente. Vous ne pouvez pas simplement supposer que les paquets arrivent et partent en même temps. Vous ne pouvez pas non plus supposer que la file d'attente passe de vide à un paquet et qu'elle reste à un paquet en fonction d'une heure d'arrivée cohérente. Si le trafic typique est relativement en rafales, alors les valeurs de rafale doivent être proportionnellement importantes afin de permettre le maintien de l'utilisation de la liaison à un niveau acceptable. Une taille de rafale trop faible ou un seuil minimal trop faible peut entraîner une utilisation de liaison trop faible.

Une rafale peut être définie simplement comme une série de trames dos à dos, de la taille d’une MTU, telles que des trames de 1 500 octets qui proviennent d’un réseau Ethernet. Lorsqu'une rafale de telles trames arrive à une interface de sortie, elle peut submerger les tampons de sortie et dépasser la profondeur configurée du compartiment à jetons à un moment instantané dans le temps. Avec l'utilisation d'un système de mesure de jeton, un régulateur prend une décision binaire sur le fait qu'un paquet entrant est conforme, dépasse ou viole les valeurs de régulation configurées. Avec un trafic en rafales, tel qu'un flux FTP, le taux d'arrivée instantané de ces paquets peut dépasser les valeurs de rafale configurées et entraîner des abandons CAR.

En outre, le débit global en temps de congestion varie en fonction du type de trafic évalué par le régulateur. Alors que le trafic TCP est sensible à la congestion, les autres flux ne le sont pas. Les paquets basés sur UDP et ICMP sont des exemples de flux non réactifs.

Le protocole TCP est basé sur un accusé de réception positif avec retransmission. Le protocole TCP utilise une fenêtre glissante dans son mécanisme d’accusé de réception positif. Les protocoles à fenêtre glissante utilisent mieux la bande passante réseau, car ils permettent à l’expéditeur de transmettre plusieurs paquets avant d’attendre un accusé de réception. Par exemple, dans un protocole à fenêtre glissante avec une taille de fenêtre de 8, l'expéditeur est autorisé à transmettre 8 paquets avant de recevoir un accusé de réception. Si vous augmentez la taille de la fenêtre, le temps d'inactivité du réseau est en grande partie éliminé. Un protocole à fenêtre glissante bien réglé maintient le réseau complètement saturé de paquets et maintient un débit élevé.

Étant donné que les points d’extrémité ne connaissent pas l’état d’encombrement spécifique du réseau, le protocole TCP est conçu pour réagir à l’encombrement du réseau en réduisant ses débits de transmission en cas d’encombrement. Plus précisément, il utilise deux techniques :

Technique Description
Réduction multiplicative de la congestion En cas de perte d’un segment (l’équivalent d’un paquet pour le protocole TCP), réduisez de moitié la fenêtre d’encombrement. La fenêtre d’encombrement est une seconde valeur ou fenêtre utilisée pour limiter le nombre de paquets qu’un expéditeur peut transmettre au réseau avant d’attendre un accusé de réception.
Récupération lente au démarrage Lorsque vous démarrez le trafic sur une nouvelle connexion ou que vous augmentez le trafic après une période d'encombrement, démarrez la fenêtre d'encombrement à la taille d'un seul segment et augmentez la fenêtre d'encombrement d'un segment chaque fois qu'un accusé de réception arrive. TCP initialise la fenêtre d'encombrement à 1, envoie un segment initial et attend. Lorsque l'accusé de réception arrive, il augmente la fenêtre d'encombrement à 2, envoie deux segments et attend. Pour plus de détails, consultez RFC 2001icon_popup_short.gif.

Les paquets peuvent être perdus ou détruits lorsque des erreurs de transmission interfèrent avec les données, lorsque le matériel du réseau tombe en panne ou lorsque les réseaux sont trop chargés pour supporter la charge présentée. Le protocole TCP suppose que les paquets perdus, ou les paquets dont l’accusé de réception n’a pas été reçu dans l’intervalle de temps en raison d’un retard extrême, indiquent un encombrement du réseau.

Le système de mesure de compartiment à jeton d'un régulateur est appelé à chaque arrivée de paquet. Plus précisément, le débit conforme et le débit de dépassement sont calculés à partir de cette formule simple : 

(conformed bits since last clear counter)/(time in seconds elapsed since last clear counter)

Puisque la formule calcule les taux sur une période à partir de la dernière fois que les compteurs ont été effacés, Cisco recommande d'effacer les compteurs afin de surveiller le taux actuel. Si les compteurs ne sont pas effacés, alors le taux de formule précédent signifie effectivement que la sortie de la commande show affiche une moyenne calculée sur une période potentiellement très longue, et les valeurs ne sont peut-être pas significatives dans la détermination du taux actuel.

Le débit moyen doit correspondre au débit de données garanti (CIR) configuré sur une période donnée. Les tailles de rafale permettent une durée de rafale maximale à un moment donné. S'il n'y a pas de trafic ou moins que la valeur de trafic du CIR et que le compartiment de jeton ne se remplit pas, une rafale très importante est toujours limitée à une taille particulière calculée sur la base d'une rafale normale et d'une rafale étendue.

Le taux de chute résulte de ce mécanisme

  1. Notez l'heure actuelle.

  2. Mettez à jour le compartiment de jetons avec le nombre de jetons qui se sont accumulés en continu depuis la dernière arrivée d'un paquet.

  3. Le nombre total de jetons cumulés ne peut pas dépasser la valeur maxtokens. Abandonnez les jetons excédentaires.

  4. Vérifier la conformité des paquets.

La limitation du débit peut également être réalisée avec la police. Ceci est un exemple de configuration afin de fournir une limitation de débit sur l'interface Ethernet qui utilise la réglementation basée sur la classe. 

class-map match-all rtp1
   match ip rtp 2000 10
!
   policy-map p3b
   class rtp1
   police 200000 6250 6250 conform-action transmit exceed-action drop violate-action    drop
policy-map p2
   class rtp1
   police 250000 7750 7750 conform-action transmit exceed-action drop violate-action    drop
   !
interface Ethernet3/0
   service-policy output p3b
   service-policy input p2

Cet exemple de sortie de la commande show policy-map interface illustre des valeurs correctement calculées et synchronisées pour le débit offert et le taux de perte, ainsi que des débits en bits/s conformes et supérieurs. 

router#show policy-map interface ethernet 3/0 
  Ethernet3/0 

   Service-policy input: p2 

     Class-map: rtp1 (match-all) 
       88325 packets, 11040625 bytes 
       30 second offered rate 400000 bps, drop rate 150000 bps 
       Match: ip rtp 2000 10 
       police: 
         250000 bps, 7750 limit, 7750 extended limit 
         conformed 55204 packets, 6900500 bytes; action: transmit 
         exceeded 33122 packets, 4140250 bytes; action: drop 
         conformed 250000 bps, exceed 150000 bps violate 0 bps 

       Service-policy : p3b 

         Class-map: rtp1 (match-all) 
           88325 packets, 11040625 bytes 
           30 second offered rate 400000 bps, drop rate 50000 bps 
           Match: ip rtp 2000 10 
           police: 
             200000 bps, 6250 limit, 6250 extended limit 
             conformed 44163 packets, 5520375 bytes; action: transmit 
             exceeded 11041 packets, 1380125 bytes; action: drop 
             conformed 200000 bps, exceed 50000 bps violate 0 bps 

         Class-map: class-default (match-any) 
           0 packets, 0 bytes 
           30 second offered rate 0 bps, drop rate 0 bps 
           Match: any

Problèmes connus avec les compteurs CAR et de contrôle basé sur les classes

Ce tableau répertorie les problèmes résolus avec les compteurs affichés dans les commandes show policy-map ou show interface rate-limit. Les clients enregistrés qui sont connectés peuvent afficher les informations de bogue dans l'Outil de recherche de bogue.

Symptôme  ID de bogue résolu et solutions de contournement
Compteurs de branchement inférieurs aux attentes

  • ID de bogue Cisco CSCdv41231 (clients enregistrés uniquement)

    Lorsqu'une stratégie de service hiérarchique d'entrée utilise la commande police aux niveaux parent et enfant, le régulateur peut abandonner moins que le nombre de paquets attendu, car le régulateur de niveau parent doit être encombré avant d'abandonner les paquets. Voici un exemple d'une telle politique :

    policy-map child 
   class dscp1 
      police cir 100000 bc 3000 conform-action transmit exceed-action drop 
! 
policy-map parent 
   class rtp1 
      police cir 250000 bc 7750 conform-action transmit exceed-action drop 
    service-policy child

    Pour contourner ce problème, créez des stratégies distinctes et appliquez-en une en entrée et une en sortie afin d'éviter la configuration d'une stratégie hiérarchique.
Doubler le taux de pertes et le débit attendus

  • ID de bogue Cisco CSCds23924 (clients enregistrés uniquement)

    Cisco Express Forwarding (CEF) définit un mécanisme de commutation IOS qui transfère les paquets de l'interface d'entrée à l'interface de sortie. Avant les modifications implémentées à partir de cet ID de bogue, les mécanismes CEF et QoS configurés, tels que CAR ou la réglementation basée sur les classes, incrémentaient les compteurs de paquets. Le résultat est ce qu'on appelle la comptabilité double et les paquets conformes gonflés et les valeurs d'abandon en excès.

     

  • ID de bogue Cisco CSCdr40598 (clients enregistrés uniquement)

    Sur la gamme Cisco 12000, lorsque la sortie CAR est activée et que la carte de ligne d'entrée est Engine 2, les compteurs de sortie de sortie sont doublés. Cette double comptabilisation résulte de la façon dont les compteurs de sortie sont gérés.

     

  • ID de bogue Cisco CSCdv84259 (clients enregistrés uniquement)

    Si vous activez globalement la commande ip cef distributed sur un routeur de la gamme Cisco 7500, une interface de carte VIP (non-Versatile Interface Processor) apparaît avec la commande ip route-cache distributed activée par défaut. Les non-VIP ne prennent pas en charge le CEF distribué, et un effet secondaire rare de cette commande qui apparaît sur les non-VIP est la double comptabilisation.
Aucune perte ou taux de perte nul En général, lorsque vous appliquez des fonctionnalités QoS basées sur les classes, la première étape du dépannage consiste à s'assurer que le mécanisme de classification QoS fonctionne correctement. En d'autres termes, assurez-vous que les paquets spécifiés dans les instructions match dans votre class-map atteignent les classes correctes. 
router#show policy-map interface 
 ATM4/0.1 

  Service-policy input: drop-inbound-http-hacks (1061) 

    Class-map: http-hacks (match-any) (1063/2) 
      149 packets, 18663 bytes 
      5 minute offered rate 2000 bps, drop rate 0 bps 
      Match: protocol http url "*cmd.exe*" (1067) 
        145 packets, 18313 bytes 
        5 minute rate 2000 bps 
      Match: protocol http url "*.ida*" (1071) 
        0 packets, 0 bytes 
        5 minute rate 0 bps 
      Match: protocol http url "*root.exe*" (1075) 
        4 packets, 350 bytes 
        5 minute rate 0 bps 
      Match: protocol http url "*readme.eml*" (1079) 
        0 packets, 0 bytes 
        5 minute rate 0 bps 
      police: 
        1000000 bps, 31250 limit, 31250 extended limit 
        conformed 0 packets, 0 bytes; action: drop 
        exceeded 0 packets, 0 bytes; action: drop 
        violated 0 packets, 0 bytes; action: drop 
        conformed 0 bps, exceed 0 bps violate 0 bps

  • ID de bogue Cisco CSCds3478 (clients enregistrés uniquement)

    La classification échoue lorsque CEF, et non DCEF, est activé et qu'une stratégie d'entrée est associée à un circuit virtuel permanent ATM. Dans le logiciel Cisco IOS Version 12.1T, la classification de sortie échoue lorsque CEF, et non DCEF, est activé et qu'une politique de sortie est attachée à un circuit virtuel permanent ATM.
Taux de chute anormal ou incohérent

  • ID de bogue Cisco CSCdw50583 (clients enregistrés uniquement)

    Le taux d'abandon affiché dans la carte-classe ne correspond pas aux taux d'abandon indiqués par l'action de police. Dans cet exemple de sortie, le taux de perte pour la classe est de 745000 bits/s, tandis que le taux de perte indiqué par l'action de la police est de 1072000 bits/s.

    router#show policy-map interface 
  Serial3/0.1: DLCI 13 - 

   Service-policy output: out 

     Class-map: c2 (match-all) 
       172483 packets, 91760956 bytes 
       30 second offered rate 1384000 bps, drop rate 745000 bps 
       Match: ip precedence 0 
       police: 
         384000 bps, 1500 limit, 1500 extended limit 
         conformed 38903 packets, 20696396 bytes; action: transmit 
         exceeded 133580 packets, 71064560 bytes; action: drop 
         conformed 311000 bps, exceed 1072000 bps violate 0 bps

Informations connexes

Historique de révision

Révision Date de publication Commentaires
1.0
18-Nov-2002
Première publication

Ce document vous est-il utile?

FeedbackCommentaires

Contacter Cisco

Ce document s’applique à ces produits