Qualité de service (QoS) : Réglementation QoS

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

17 décembre 2015 - Traduction automatique
Autres versions: PDFpdf | Anglais (22 avril 2015) | Commentaires


Contenu


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 la sortie de la commande de rate-limit de l'interface x/x d'exposition affiche une valeur dépassée différente de zéro bps quand la valeur conformée bps est moins que le débit de données garanti configuré (CIR).

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.

Compréhension de la sortie de commande de débit d'interface d'exposition

Il y a trois conditions en lesquelles vous pouvez voir que différent de zéro dépassé évalue dans la sortie de cette commande :

  • Des valeurs de rafale sont placées si basses pour laisser un débit suffisant de débit. Par exemple, voir l'ID de bogue Cisco CSCdw42923 (clients enregistrés seulement) dans le Bug Toolkit, joint de la page d'outils et d'utilitaires (clients enregistrés seulement).

    Remarque: Vous devez être un utilisateur enregistré et ouvert une session afin d'utiliser le Bug Toolkit.

  • Question résolue avec la double comptabilité en logiciel de Cisco IOSÝ

  • Erreur de programmation dans le Cisco IOS

Regardez l'exemple de sortie d'une interface d'accès virtuel. Dans cette configuration, le RAYON est utilisé afin d'affecter un raté limit à l'interface d'accès virtuel dynamiquement créée.

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",

Employez la commande de rate-limit de l'interface X d'exposition afin de surveiller les performances du régulateur existant de Cisco, CAR. Dans cet exemple, la sortie de cette commande fournit des signes quant à pourquoi il y a des bps dépassées différentes de zéro. La valeur de rafale en cours est de 7392 octets, alors que la valeur de rafale validée (Bc), indiquée par la valeur limite, est placée à 7500 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

Quand vous configurez le CAR ou un plus nouveau régulateur de Cisco, maintien de l'ordre basé sur classe, vous devez configurer des valeurs de rafale suffisamment élevées afin d'assurer le débit prévu et afin de s'assurer que le régulateur relâche des paquets pour punir seulement l'encombrement à court terme.

Quand vous sélectionnez des valeurs de rafale, il est important de faciliter des augmentations passagères de la taille de file d'attente. Vous ne pouvez pas simplement supposer que les paquets arrivent et partent en même temps. Vous ne pouvez pas également supposer que la file d'attente change de vide en un paquet et que la file d'attente reste à un paquet basé sur une une heure d'arrivée cohérente in/one. Si le trafic typique est assez bursty, alors les valeurs de rafale doivent être également grandes afin de permettre l'utilisation de lien à mettre à jour acceptablement à un haut niveau. Une taille de rafale qui est si basse, ou un seuil minimum qui est si bas, peut avoir comme conséquence l'utilisation inadmissiblement basse de lien.

Une rafale peut être définie simplement pendant qu'une gamme de trames dos à dos et de taille d'une mtu, telles que les trames 1500-byte qui commencent sur un réseau Ethernet. Quand une rafale de telles trames arrive à une interface de sortie, elle peut accabler les mémoires tampons de sortie et dépasser la profondeur configurée du seau à jetons à un instant instantané. Avec l'utilisation d'un système de mesure symbolique, un régulateur prend une décision binaire au sujet de si un paquet de arrivée se conforme, dépasse, ou viole les valeurs de maintien de l'ordre configurées. Avec le trafic bursty, tel qu'un flot de FTP, le débit d'arrivée instantané de ces paquets peut dépasser les valeurs de rafale configurées et mener aux baisses de CAR.

En outre, le débit global en période de l'encombrement varient avec le type de trafic qui est évalué par le régulateur. Tandis que le trafic TCP est sensible à l'encombrement, d'autres écoulements ne sont pas. Les exemples des écoulements nonsensibles incluent les paquets basés sur UDP et basés sur ICMP.

Le TCP est basé sur l'accusé de réception positif avec la retransmission. Le TCP utilise une fenêtre glissante en tant qu'élément de son mécanisme d'accusé de réception positif. Les protocoles de fenêtre glissante utilisent la bande passante de réseau mieux parce qu'ils permettent à l'expéditeur pour transmettre des plusieurs paquets avant qu'ils attendent un accusé de réception. Par exemple, dans un protocole de fenêtre glissante avec une taille de la fenêtre de 8, on permet à l'l'expéditeur pour transmettre 8 paquets avant qu'il reçoive un accusé de réception. Si vous augmentez la taille de la fenêtre, le temps d'inactivité de réseau est en grande partie éliminé. Un protocole bien-accordé de fenêtre glissante maintient le réseau complètement saturé avec des paquets et met à jour le débit élevé.

Puisque les points finaux ne connaissent pas le statut spécifique d'encombrement du réseau, le TCP comme protocole est conçu réagissent à l'encombrement dans le réseau par la réduction ses débits de transmission quand l'encombrement se produit. Spécifiquement, il utilise deux techniques :

Technique Description
Manière d'éviter multiplicative d'encombrement de diminution Sur la perte d'un segment (l'équivalent d'un paquet au TCP), réduisez la fenêtre d'encombrement par moitié. La fenêtre d'encombrement est une deuxième valeur ou fenêtre qui sont utilisées pour limiter le nombre de paquets qu'un expéditeur peut transmettre dans le réseau avant qu'il attende un accusé de réception.
Ralentissez la reprise de début Quand vous commencez le trafic sur une nouvelle connexion ou augmentez le trafic après une période d'encombrement, commencez la fenêtre d'encombrement à la taille d'un segment simple et augmentez la fenêtre d'encombrement par un segment chaque fois que un accusé de réception arrive. Le TCP initialise la fenêtre d'encombrement à 1, envoie un premier segment, et attend. Quand l'accusé de réception arrive, il augmente la fenêtre d'encombrement à 2, envoie deux segments, et attend. Pour plus de détails, voir le RFC 2001leavingcisco.com .

Des paquets peuvent être perdus ou détruits quand les erreurs de transmission gênent des données, quand le matériel réseau échoue, ou quand les réseaux deviennent trop fortement chargés pour faciliter le chargement présenté. Le TCP suppose que les paquets perdus, ou les paquets qui ne reconnaissent pas dans l'intervalle synchronisé dû au retard extrême, indiquent l'encombrement dans le réseau.

Le système de mesure de seau à jetons d'un régulateur est appelé dès chaque arrivée de paquet. Spécifiquement, le débit conformé et dépassent le débit sont calculés a basé sur cette formule simple :

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

Puisque la formule calcule des débits sur une période 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 débit précédent de formule signifie efficacement que la sortie de commande show affiche une moyenne calculée sur potentiellement très une longue période, et les valeurs ne sont pas probablement signicatives dans la détermination du taux actuel.

Le débit moyen devrait apparier le débit de données garanti configuré (CIR) sur une période de temps. Les tailles de rafale accordent une durée de rafale maximale à un moment donné. S'il n'y a aucun trafic ou moins que la valeur du CIR du trafic et du seau à jetons ne remplit pas, une rafale très grande est encore limitée à une taille particulière calculée basée sur la rafale et la rafale étendue normales.

Les résultats de débit de baisse de ce mécanisme

  1. Notez le temps en cours.

  2. Mettez à jour le seau à jetons avec le nombre de jetons qui se sont accumulés continuellement depuis la dernière époque où un paquet est arrivée.

  3. Le nombre total de jetons accumulés ne peut pas dépasser la valeur de maxtokens. Jetons d'en excès de baisse.

  4. Vérifiez la conformité de paquet.

La limitation de débit peut également être réalisée avec le maintien de l'ordre. C'est une configuration d'échantillon afin de fournir la limitation de débit sur l'interface Ethernet que les utilisations classent le maintien de l'ordre basé.

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

Cette sortie témoin de la commande de show policy-map interface illustre correctement calculé et les valeurs synchronisées pour le débit offert et baisse évaluent aussi bien que s'est conformé et dépasse des débits bps.

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 le CAR et les compteurs de maintien de l'ordre basés sur classe

Ce tableau présente les questions résolues avec les compteurs affichés dans les commandes de rate-limit d'interface de show policy-map ou d'exposition. Les clients enregistrés qui sont ouverts une session peuvent visualiser l'informations sur le bogue dans le Bug Toolkit, joint de la page d'outils et d'utilitaires (clients enregistrés seulement).

Symptôme Id et contournements résolus de bogue
Diminuez que les compteurs prévus de baisse Quand une stratégie de service hiérarchique d'entrée utilise l'ordre de police aux niveaux de parent et d'enfant, le régulateur peut relâcher moins que le nombre prévu de paquets puisque le régulateur niveau du parent doit être congestionné avant qu'il relâche les paquets. C'est un exemple d'une telle stratégie :
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 
Comme contournement, créez les stratégies distinctes et appliquez un sur d'arrivée et un sur sortant afin d'éviter la configuration d'une politique hiérarchique.
Le double le débit prévu de baisses et de débit Le Technologie Cisco Express Forwarding (CEF) définit un mécanisme de commutation IOS qui en avant des paquets de l'entrée pour sortir l'interface. Avant les modifications mises en application de cet ID de bogue, le CEF et les mécanismes configurés de QoS tels que le CAR ou le maintien de l'ordre basé sur classe ont incrémenté les compteurs de paquet. Le résultat est soi-disant double comptabilité et valeurs de paquet et excédentaires conformées gonflées de baisse. Sur la gamme Cisco 12000, quand le CAR de sortie est activé et la carte de ligne d'entrée est Engine 2, les compteurs de sortie de sortie sont doublés. Cette comptabilité de double résulte de la façon dont des compteurs de sortie sont manipulés. Si vous activez globalement la commande distribuée d'ip cef sur un routeur de gamme Cisco 7500, une interface non-souple de carte de processeur d'interface (VIP) apparaît avec la commande enabled distribuée par ip route-cache par défaut. Les Non-VIPs ne prennent en charge pas le CEF distribué, et un effet secondaire rare de cette commande qui apparaît sur des non-VIPs est double comptabilité.
Aucune baisses ou un débit zéro de baisse Généralement quand vous appliquez les caractéristiques basées sur classe de QoS, la première étape dans le dépannage est de s'assurer que le mécanisme de classification QoS fonctionne correctement. En d'autres termes, assurez-vous que les paquets ont spécifié dans les déclarations de correspondance dans votre class-map frappent 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
La classification échoue quand le CEF, et pas le DCEF, n'est activé et une politique d'entrée est reliée à un PVC atmosphère. Dans la version du logiciel Cisco IOS 12.1T, la classification de sortie échoue quand le CEF, et pas le DCEF, n'est activé et une stratégie de sortie est reliée à un PVC atmosphère.
Débit anormal ou contradictoire de baisse Le débit de baisse affiché dans le class-map n'apparie pas les débits de baisse indiqués par l'action de police. Dans cet exemple de sortie, le débit de baisse pour la classe est de 745000 bps, alors que le débit de baisse affiché par action de police est de 1072000 bps.
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

Conversations connexes de la communauté de soutien de Cisco

Le site Cisco Support Community est un forum où vous pouvez poser des questions, répondre à des questions, faire part de suggestions et collaborer avec vos pairs.


Informations connexes


Document ID: 28882