Comment puis-je raisonnablement vérifier que ma configuration QoS fonctionne?


10

Le contexte

J'ai déployé une configuration QoS standard sur un site client exécutant un routeur Cisco 891 avec IOS 15.1 (4) M4. La liaison WAN est une seule liaison ADSL2 + (24/1 Mbps) connectée à FE8.

J'ai déjà testé cette configuration sur un autre site en utilisant iperf à partir du LAN pour générer 1+ Mbps de trafic en amont et confirmé un changement notable dans la qualité des appels lors de l'activation de la QoS sur l'interface WAN. C'est ainsi que j'ai initialement confirmé que ma configuration fonctionnait.

J'ai récemment déployé cette même configuration sur un autre site, mais ils ont toujours des problèmes avec la bande passante VOIP en amont. Je voudrais raisonnablement confirmer que la QoS fonctionne sans aller à l'effort de saturer réellement le lien (en particulier parce qu'ils sont hors d'état et qu'il n'y a pas de technologie sur place). Et puis essayez d'isoler ce que je pourrais teck pour obtenir une meilleure qualité vocale.

Des questions

Compte tenu de la sortie de la carte de politique ci-dessous, en se concentrant spécifiquement sur la carte de classe VOICE à titre d'exemple, que signifient les statistiques suivantes?:

  • 3860628 paquets, 1070196895 octets: puis-je supposer qu'il s'agit du nombre total de paquets / octets mis en correspondance dans le class-map?

  • 5 minutes de débit offert 0 bps, drop rate 0 bps: Le "taux offert" est-il le taux en bps de trafic qui a été priorisé, sinon quoi? Et de même, le taux de chute est-il le taux de trafic excédentaire qui n'a pas pu être priorisé en raison du manque de bande passante? Cela indiquerait-il alors que nous avons besoin de X bps de bande passante de plus pour que VOICE puisse répondre à ces pics de trafic?

  • Priorité: 40% (340 kbps), octets de rafale 8500, dépassement des baisses n / b: 5: Dans cette ligne, je ne sais pas ce que le dépassement des baisses n / b signifie?

Enregistrement

Étant donné que ces statistiques sont susceptibles de changer (j'imagine) pendant les heures de pointe (c'est à ce moment que vous voudriez le plus les voir). Existe-t-il un moyen de consigner ces numéros, ou peut-être de les interroger via SNMP afin qu'ils puissent être représentés graphiquement par programme?

Apprentissage

Je comprends que la QoS est un sujet assez large. Lorsque j'essaie d'en savoir plus, je suis souvent submergé par différentes informations, soit parce que je lis sur différents types d'implémentations de QoS, soit en raison de versions IOS différentes (par exemple, d'anciens documents utilisant des commandes dont la syntaxe ou la sortie a changé).

À cette fin, quelqu'un peut-il recommander des documents de formation Cisco ou des cours vidéo qui pourraient m'aider à me concentrer sur une meilleure prise en main de l'utilisation de la QoS?

Quelques informations supplémentaires

Voici un exemple de configuration QoS:

class-map match-any SSH
 match protocol ssh
class-map match-any LogMeIn
 match access-group name LogMeIn
class-map match-any VOICE
 match protocol sip
 match protocol rtp

policy-map ADSLPrioritisationOutbound
 class VOICE
  priority percent 40
 class SSH
  bandwidth 80
 class LogMeIn
  priority percent 20
 class class-default
  fair-queue
policy-map ADSLPrioritisationOutboundParent
 class class-default
  shape average 850000
  service-policy ADSLPrioritisationOutbound

interface FastEthernet8
 no ip address
 ip virtual-reassembly in
 duplex auto
 speed auto
 pppoe-client dial-pool-number 1
 service-policy output ADSLPrioritisationOutboundParent

Et sortie de l'interface politique-carte:

FastEthernet8

Service-policy output: ADSLPrioritisationOutboundParent

Class-map: class-default (match-any)
  18968101 packets, 6998385051 bytes
  5 minute offered rate 3000 bps, drop rate 0 bps
  Match: any
  Queueing
  queue limit 64 packets
  (queue depth/total drops/no-buffer drops) 0/93737/0
  (pkts output/bytes output) 18874363/6936577128
  shape (average) cir 850000, bc 3400, be 3400
  target shape rate 850000

  Service-policy : ADSLPrioritisationOutbound

    queue stats for all priority classes:

      queue limit 64 packets
      (queue depth/total drops/no-buffer drops) 0/0/0
      (pkts output/bytes output) 3860623/1070194985

    Class-map: VOICE (match-any)
      3860628 packets, 1070196895 bytes
      5 minute offered rate 0 bps, drop rate 0 bps
      Match: protocol sip
        97348 packets, 49867304 bytes
        5 minute rate 0 bps
      Match: protocol rtp
        3763280 packets, 1020329591 bytes
        5 minute rate 0 bps
      Match: access-group name NEC-PBX
        0 packets, 0 bytes
        5 minute rate 0 bps
      Priority: 40% (340 kbps), burst bytes 8500, b/w exceed drops: 5


    Class-map: SSH (match-any)
      89497 packets, 19838544 bytes
      5 minute offered rate 2000 bps, drop rate 0 bps
      Match: protocol ssh
        89497 packets, 19838544 bytes
        5 minute rate 2000 bps
      Queueing
      queue limit 64 packets
      (queue depth/total drops/no-buffer drops) 0/0/0
      (pkts output/bytes output) 89497/19838544
      bandwidth 80 kbps

    Class-map: LogMeIn (match-any)
      0 packets, 0 bytes
      5 minute offered rate 0 bps, drop rate 0 bps
      Match: access-group name LogMeIn
        0 packets, 0 bytes
        5 minute rate 0 bps
      Priority: 20% (170 kbps), burst bytes 4250, b/w exceed drops: 0


    Class-map: class-default (match-any)
      15017976 packets, 5908349612 bytes
      5 minute offered rate 0 bps, drop rate 0 bps
      Match: any
      Queueing
      queue limit 64 packets
      (queue depth/total drops/no-buffer drops/flowdrops) 0/93732/0/93732
      (pkts output/bytes output) 14924243/5846543599
      Fair-queue: per-flow queue limit 16

Je suppose que vous voulez dire la version 15.1 d'IOS dans la première phrase? Je veux juste clarifier avant de faire un montage.
Brett Lykins

Hé, oui. Pardon. Je ne sais pas ce qui se passe ... Les clés se coincent ce soir. Beaucoup de fautes de frappe.
Geekman

Réponses:


10

Votre question est assez large. Il existe de nombreuses commandes différentes que vous pouvez utiliser pour dépanner et surveiller la QoS, donc je vais me concentrer sur la question principale que vous avez, qui est de savoir comment vérifier raisonnablement que votre configuration de QoS fonctionne et comment lire la sortie de l'interface Policy-Map.

La seule vraie façon de vérifier que la QoS fonctionne est de brancher un générateur de trafic et de surveiller votre taux d'abandon dans différentes files d'attente. Étant donné que cela n'est généralement pas possible, en particulier dans un environnement de production, tout ce que vous pouvez vraiment faire est de vérifier que le trafic est correctement marqué et classé.

Ce que vous cherchez vraiment, lorsqu'il s'agit de vérifier si votre configuration QoS fonctionne, est d'incrémenter les compteurs de la commande d'interface policy-map.

Ainsi, par exemple, dans la sortie que vous avez fournie:

Class-map: VOICE (match-any)
  3860628 packets, 1070196895 bytes
  5 minute offered rate 0 bps, drop rate 0 bps
  Match: protocol sip
    97348 packets, 49867304 bytes
    5 minute rate 0 bps
  Match: protocol rtp
    3763280 packets, 1020329591 bytes
    5 minute rate 0 bps
  Match: access-group name NEC-PBX
    0 packets, 0 bytes
    5 minute rate 0 bps
  Priority: 40% (340 kbps), burst bytes 8500, b/w exceed drops: 5

Vous pouvez voir que vous voyez des paquets sous SIP et RTP, mais pas NEC-PBX. Si vous savez que vous obtenez du trafic SIP et RTP sur une liaison, vous devriez voir l'incrémentation du nombre de paquets et c'est une façon raisonnable de savoir que votre configuration fonctionne fondamentalement.


Merci. Qu'entendez-vous par «surveiller le taux de chute dans diverses files d'attente»? S'agit-il du "drop rate X bps"? En ce qui concerne mon exemple de besoin d'un shaper parent pour ADSL QoS, j'avais initialement décidé que QoS fonctionnait quand j'ai vu le trafic se faire correspondre - mais à la fin cela ne faisait pas vraiment de bien. Je suis d'accord que la question est toujours large (j'ai même essayé de la réécrire avant de poster!). J'apporterai quelques modifications sous peu et j'apprécierais tout renseignement. Merci encore!
Geekman

Ok là. Je pense que si j'ai au moins bien compris ces éléments sur la sortie de la carte de stratégie, je serais en mesure de comprendre ce qui se passe.
Geekman

1
Il y a deux choses en particulier que vous devez regarder lorsque vous vérifiez la configuration. Le premier est le nombre total de paquets et le taux pour toute la classe et chaque ligne "Match" individuelle. Cela vous dira si les paquets correspondent aux politiques et sont classifiés / marqués / hiérarchisés de manière appropriée (selon le type de politique que vous regardez). L'autre chose est également le taux de chute sous chacun. Dans des conditions de réseau normales, vous ne devriez probablement pas voir de baisses dans la plupart des classes, donc un 0 n'est pas un problème. Mais si vous êtes congestionné, vous verrez des gouttes.
totallystubby
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.