VoIP sur relais de trame avec qualité de service (fragmentation, formatage du trafic, LLQ / IP RTP Priority)

Introduction

Ce document fournit un exemple de configuration de voix sur IP (VoIP) sur un réseau Frame Relay avec la Qualité de service (QoS). Ce document contient des informations techniques de base sur les fonctionnalités, les directives de conception et les stratégies de vérification et de dépannage de base.

Il est important de noter que la configuration dans ce document a deux Routeurs de Voix qui sont connectés au réseau de Relais de trames. Dans beaucoup de topologies cependant, les routeurs activés de Voix peuvent exister n'importe où. Habituellement, les Routeurs de Voix utilisent la Connectivité de RÉSEAU LOCAL à d'autres Routeurs qui sont connectés au WAN. C'est important parce que si vos Routeurs de Voix ne sont pas directement connectés au réseau de Relais de trames, toutes les commandes de configuration BLÊMES doivent être configurées sur ces Routeurs connectés au WAN, et pas sur les Routeurs de Voix, suivant les indications des configurations dans ce document.

Conditions préalables

Conditions requises

Aucune spécification déterminée n'est requise pour ce document.

Composants utilisés

Les informations contenues dans ce document sont basées sur les versions de matériel et de logiciel suivantes :

• Routeur de Cisco 3640 avec la version de logiciel 12.2.6a de Cisco IOS® (Enterprise Plus)

• Routeur de Cisco 2621 avec la version du logiciel Cisco IOS 12.2.6a (Enterprise Plus)

• Basse latence s'alignant (LLQ) sur des circuits virtuels permanents en relais de trame (PVCs). Ceci est introduit dans la version du logiciel Cisco IOS 12.1.(2)T.

• Priorité de Protocole RTP (Real-Time Transport Protocol) IP de Relais de trames qui est introduite dans le Logiciel Cisco IOS version 12.0(7)T.

• Forum Frame Relay (fragmentation FRF).12 qui est introduite dans le Logiciel Cisco IOS version 12.0(4)T.

• Les versions du logiciel Cisco IOS plus tard que 12.0.5T contiennent des améliorations significatives des performances pour le RTP comprimé (cRTP).

Les informations contenues dans ce document ont été créées à partir des périphériques d'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 votre réseau est opérationnel, assurez-vous que vous comprenez l'effet potentiel de toute commande.

Conventions

Pour plus d'informations sur les conventions de documents, reportez-vous à Conventions relatives aux conseils techniques Cisco.

Directives de conception de QoS pour le VoIP sur frame relay

Il y a deux exigences de base pour la bonne qualité vocale :

• Retard de bout en bout et manière d'éviter minimaux de jitter (variation de délai).

• Bandes passantes nécessaires de lien optimisées et correctement machinées.

Pour garantir les conditions requises précédemment mentionnées, utilisez ces instructions :

• Priorité stricte pour le trafic vocal LLQ ou l'IP RTP Priority

• Formatage du trafic de relais de trames (FRTS) pour la Voix

• FRF.12 de fragmentation

• Réduction de bande passante

Priorité stricte pour le trafic vocal (LLQ ou IP RTP Priority)

Il y a deux méthodes primaires pour fournir la priorité stricte pour le trafic vocal :

• IP RTP Priority (également appelé file d'attente prioritaire/mise en file d'attente pondérée (PQ/WFQ))

• LLQ (également appelé PQ/la mise en file d'attente pondérée basée par classe (PQ/CBWFQ))

IP RTP Priority

La Fonction Frame Relay IP RTP Priority crée une file d'attente prioritaire stricte sur un PVC de Relais de trames pour un ensemble d'écoulements de paquet de RTP qui appartiennent à une plage des destinations port de Protocole UDP (User Datagram Protocol). Tandis que les ports réels utilisés sont dynamiquement négociés entre les fin-périphériques ou les passerelles, tous les produits VoIP de Cisco utilisent la même chaîne de port UDP (16384 à 32767). Une fois que le routeur identifie le trafic VoIP, il le place dans le PQ strict. Quand le PQ est vide, les autres files d'attente sont traitées ont basé sur WFQ standard. L'IP RTP Priority ne devient pas actif jusqu'à ce qu'il y ait d'encombrement dans l'interface. Cette image illustre le fonctionnement de la priorité IP RTP :

Remarque: L'IP RTP Priority permet éclater le PQ quand il y a bande passante disponible sur la file d'attente par défaut (WFQ). Cependant, il maintient l'ordre strictement le contenu PQ quand il y a d'encombrement sur l'interface.

LLQ

LLQ est une caractéristique qui fournit un PQ strict à CBWFQ. LLQ active un PQ strict simple dans CBWFQ au niveau de classe. Avec LLQ, des données sensibles au délai (dans le PQ) sont retirées et envoyées de la file d'attente d'abord. Dans un VoIP avec l'implémentation LLQ, le trafic vocal est placé dans le PQ strict.

Le PQ est maintenu l'ordre pour s'assurer que les files d'attente équitables ne sont pas affamées de la bande passante. Quand vous configurez le PQ, vous spécifiez, dans le Kbps, la bande passante maximale disponible au PQ. Quand l'interface est congestionnée, le PQ est entretenu jusqu'à ce que le chargement atteigne la valeur configurée de Kbps dans la déclaration de priorité. Le trafic excédentaire est alors abandonné pour éviter le problème avec la configuration existante de la priority-group de Cisco de mourir de faim le PQs inférieur.

Remarque: Avec LLQ pour le Relais de trames, des files d'attente sont installées sur une base par-PVC. Chaque PVC a un PQ et un nombre assigné de files d'attente de foire.

Cette méthode est plus complexe et flexible que l'IP RTP Priority. Le choix entre les méthodes doit être basé sur les conformations du trafic dans votre réseau réel et vos besoins.

LLQ contre l'IP RTP Priority

Cette table récapitule les principales différences entre LLQ et IP RTP Priority et fournit des instructions de le moment où utiliser chaque méthode.

FRTS pour la Voix

FRTS fournit les paramètres qui sont utiles pour gérer l'encombrement du trafic réseau. FRTS élimine des étranglements dans des réseaux de Relais de trames avec des connexions à haut débit au lieu d'exploitation principal et des connexions à vitesse réduite aux filiales. Vous pouvez configurer des valeurs de régulation de débit pour limiter le débit auquel des données sont envoyées du circuit virtuel (circuit virtuel) au lieu d'exploitation principal.

Ces définitions sont liées à FRTS :

• Débit de données garanti (CIR) — Évaluez (bits par seconde) les garanties de fournisseur de relais de trame pour le transfert des données. Des valeurs de débit d'information garanti sont placées par le fournisseur de service de relais de trame et configurées par l'utilisateur sur le routeur.

  Remarque: Le port/taux d'accès de l'interface peut être le supérieur à CIR. Le débit est ramené à une moyenne sur une période commise de l'intervalle de mesure de débit (comité technique).

• Rafale validée (Bc) — Nombre maximal de bits que le réseau de Relais de trames commet pour transférer sur un comité technique. Comité technique = Bc/CIR.

• Rafale excédentaire (soyez) — Nombre maximal de bits non garantis que le commutateur de Relais de trames tente de transférer au delà du CIR sur le comité technique.

• Intervalle de mesure commis de débit (comité technique) — Intervalle de temps au-dessus dont Bc ou (Bc+ soit) des bits sont transmis. Le comité technique est calculé en tant que comité technique = Bc/CIR. La valeur comité technique n'est pas directement configurée sur des Routeurs de Cisco. On le calcule après Bc et des valeurs de débit d'information garanti sont configurées. Le comité technique ne peut pas dépasser 125 ms.

• Notification d'encombrement vers l'arrière explicite (BECN) — Un bit dans l'en-tête de trame Frame Relay qui indique l'encombrement dans le réseau. Quand un commutateur de Relais de trames identifie l'encombrement, il place le bit BECN sur des trames destinées pour le routeur de source et instruit le routeur réduire le débit de transmission.

La configuration de FRTS pour le trafic vocal est différente de celle du trafic formant pour des données seulement. En configurant FRTS pour la Qualité vocale, des compromissions sont faites avec les paramètres du trafic de données. Pour plus d'informations sur ces restrictions voyez la section de fragmentation (FRF.12) dans ce document.

Fragmentation (FRF.12)

Un défi important sur l'intégration voix-données est de contrôler l'un retard de bout en bout maximum de manière pour le trafic sensible à la durée tel que la Voix. Pour la bonne qualité vocale, ce retard doit être moins de 150 ms. Une partie importante de ce retard est le retard de fabrication en série sur l'interface. Cisco recommande que ce soit 10 ms et ne devrait pas dépasser Mme 20 que retard de fabrication en série est le temps il prend pour placer réellement les bits sur une interface.

Serialization Delay = frame size (bits) / link bandwidth (bps)

Par exemple, un paquet 1500-byte prend 214 ms pour laisser au routeur au-dessus de l'56 Kbps pour joindre. Si un paquet de données de temps machine de 1500 octets est envoyé, des paquets de données en temps réel (de Voix) sont alignés jusqu'à ce que le grand paquet de données soit transmis. Ce retard est inacceptable pour le trafic vocal. Si des paquets de données de temps machine sont fragmentés dans de plus petites trames, ils sont intercalés avec les trames en temps réel (de Voix). De cette façon, les deux trames voix et de données peuvent être portés ensemble sur des liaisons à bas débit sans entraîner le retard excessif au trafic vocal en temps réel.

Pour plus d'informations sur la fragmentation, référez-vous à la fragmentation de relais de trame pour la Voix.

Remarque: Dans les cas où vous avez une demi connexion dédiée de t1 (768 Kbps), vous n'avez pas besoin probablement d'une fonctionnalité de fragmentation. Cependant, vous avez besoin toujours d'un mécanisme de QoS (IP RTP Priority ou LLQ, dans ce cas). Le demi t1 ou les vitesses plus grandes offrent l'assez de bande passante pour permettre à des paquets vocaux pour entrer dans et laisser la file d'attente dans le retard de sérialisation recommandé pour s'étendre (10 ms, pas plus tard que 20 ms). En outre, vous n'avez pas besoin probablement de cRTP, qui aide à sauvegarder la bande passante en compressant des en-têtes de RTP IP, dans le cas d'un plein t1.

Réduction de bande passante

cRTP

Basé sur RFC 2508 , la caractéristique de cRTP compresse l'en-tête de paquet IP/UDP/RTP de 40 octets à 2 ou 4 octets. Ceci réduit la consommation de bande passante inutile. C'est un modèle de compression de saut par saut. Par conséquent, le cRTP doit être configuré sur les deux fins du lien, à moins que l'option passive soit configurée.

Remarque: le cRTP n'est pas exigé pour assurer la bonne qualité vocale. C'est une caractéristique qui réduit la consommation de bande passante. Configurez le cRTP après tout que d'autres conditions sont remplies et la Qualité vocale est bonne. Cette procédure épargne le temps de panne parce qu'elle isole les questions potentielles de cRTP.

Surveillez l'utilisation du processeur du routeur. Désactivez le cRTP s'il est au-dessus de 75 pour cent. À des débits de la liaison plus supérieurs, le gain de bande passante du cRTP pourrait potentiellement être été supérieur par le chargement supplémentaire CPU. Cisco recommande seulement utilisant le cRTP avec Kbps inférieur de liens des que 768, à moins que le routeur fonctionne à un bas débit d'utilisation du processeur.

Remarque: À défaut d'une norme, le cRTP pour le Relais de trames a été développé sur l'encapsulation de classe des propriétaires de Cisco. Par conséquent, cela ne fonctionne pas avec l'encapsulation de l'Internet Engineering Task Force (IETF) du Relais de trames. Récemment, FRF.20 a été mené à bonne fin pour rendre la Compression d'en-tête RTP possible sur l'encapsulation IETF. Cependant, en date de la dernière modification de ce document (mai, 2002), FRF.20 n'est pas pris en charge.

Le pour en savoir plus, se rapportent au protocole de transport en temps réel comprimé.

Sélection de codeur/décodeur (codec)

Les bas codecs de débit binaire d'utilisation sur le VoIP appellent des tronçons. G.729 (8 Kbps) est le codec par défaut pour l'homologue de numérotation VoIP.

Remarque: Bien que la double tonalité multifréquence (DTMF) soit habituellement transportée exactement quand des codecs de Voix de haute-bit-débit sont utilisés (comme G.711), des codecs de faible débit (tels que G.729 et G.723.1), sont fortement optimisés pour des modèles de Voix et tendent à tordre des tonalités DTMF. Cette approche peut avoir comme conséquence les problèmes accédant à des systèmes de la réponse vocale interactive (RVI). La commande de relais de DTMF résout le problème de distorsion de DTMF. Il transporte des tonalités DTMF hors bande ou séparé du flux voix encodé. Si vous utilisez les codecs de faible débit (G.729, G.723) activent la commande de relais de DTMF sous l'homologue de numérotation VoIP.

Détection d'activité vocale d'enable (VAD)

Une conversation typique pourrait potentiellement contenir 35 à 50 pour cent de silence. Des paquets de silence sont supprimés quand VAD est utilisé. Pour la planification de bande passante VoIP, supposez que VAD réduit la bande passante par 35 pour cent. VAD est configuré par défaut sous les homologues de numérotation VoIP.

Configurez

Cette section vous fournit des informations pour configurer les fonctionnalités décrites dans ce document.

Remarque: Pour obtenir des informations supplémentaires sur les commandes utilisées dans ce document, utilisez l'Outil de recherche de commande (clients enregistrés seulement).

LLQ

Employez cette procédure pour configurer LLQ :

1. Créez un class map pour le trafic VoIP et définissez le critère de correspondance.

   Ces commandes expliquent comment se terminer cette tâche :

   maui-voip-sj(config)#class-map ?
          WORD 		class-map name
          match-all 	Logical-AND all matching statements under this classmap
          match-any 	Logical-OR all matching statements under this classmap
   maui-voip-sj(config)#class-map match-all voice-traffic 
   
   !--- Choose a descriptive class_name. 
   
   
   maui-voip-sj(config-cmap)#match ?
     access-group         Access group
     any                  Any packets
     class-map            Class map
     cos                  IEEE 802.1Q/ISL class of service/user priority values
     destination-address  Destination address
     input-interface      Select an input interface to match
     ip                   IP specific values
     mpls                 Multi Protocol Label Switching specific values
     not                  Negate this match result
     protocol             Protocol
     qos-group            Qos-group
     source-address       Source address
   
   !--- In this example the access-group matching !--- option is used for its flexibility (it uses an access-list).
   
   
   maui-voip-sj(config-cmap)#match access-group ?
     <1-2699>  Access list index
     name      Named Access List
   maui-voip-sj(config-cmap)#match access-group 102 
   
   
   !--- Create the access-list to match the class-map access-group:
   
   
   maui-voip-sj(config)#access-list 102 permit udp any any range 16384 32767
   
   !--- The safest and easiest way is to match with UDP port range 16384-32767. !--- This is the port range Cisco IOS H.323 products utilize to transmit !--- VoIP packets.
   
   

   Ces Listes d'accès sont également utilisées pour apparier le trafic vocal avec l'ordre de match access-group :

   access-list 102 permit udp any any precedence critical
   
   !--- This list filters traffic based on the IP packet TOS: Precedence field. !--- Note: Ensure that the other non-voice traffic does not use the !--- same precedence value.
   
   
   access-list 102 permit udp any any dscp ef
   
   !--- In order for this list to work, ensure that VoIP packets are tagged !--- with the dscp ef code before they exit on the LLQ WAN interface. !--- For more information on DSCP, refer to !--- Implementing Quality of Service Policies with DSCP. !--- Note: If endpoints are not trusted on their packet marking, !--- mark incoming traffic by applying an inbound service policy on an !--- inbound interface. This procedure is out of the scope !--- of this document. 
   
   
   access-list 102 permit udp host 192.10.1.1 host 192.20.1.1
   
   !--- This access-list can be used in cases where the VoIP !--- devices cannot do precedence or DSCP marking and you !--- cannot determine the VoIP UDP port range.
    

   Ce sont d'autres méthodes assorties qui peuvent être utilisées au lieu des ordres d'access-group :

   • Avec la version du logiciel Cisco IOS 12.1.2.T et plus tard, la fonctionnalité d'IP RTP Priority est mise en application pour LLQ. Cette caractéristique apparie le contenu de classe prioritaire qui regardent les ports UDP configurés. Il est sujet à la limite de servir seulement les ports égaux dans le PQ.

     class-map voice
       match ip rtp 16384 16383
     

   • Ces deux méthodes fonctionnent dans la supposition que des paquets VoIP sont marqués aux hôtes de commencement ou appariés et marqués dans le routeur avant que l'exécution sortante LLQ soit appliquée :

     class-map voice 
        match ip precedence 5
     

     OU

     class-map voice
        match ip dscp ef
     

     Remarque: Dans la version du logiciel Cisco IOS 12.2.2T et plus tard, les homologues de numérotation VoIP peuvent marquer le support et les paquets de signalisation de Voix avant l'exécution LLQ. Ceci permet une manière extensible de marquer et apparier des paquets VoIP par des éléments de code de DSCP pour LLQ. Le pour en savoir plus, se rapportent à classifier la signalisation VoIP et les medias avec le DSCP pour QoS.

     Router(config-dial-peer)#ip qos dscp ?
     

2. Créez un class map pour la signalisation VoIP et définissez le critère de correspondance (facultatif).

   Utilisez ces commandes de se terminer cette tâche :

   class-map voice-signaling
     match access-group 103
   !
   access-list 103 permit tcp any eq 1720 any
   access-list 103 permit tcp any any eq 1720
   

   Remarque: Des appels VoIP peuvent être établis utilisant H.323, Protocole SIP (Session Initiation Protocol), Protocole MGCP (Media Gateway Control Protocol) ou Protocole SCCP (Skinny Call Control Protocol) - protocole propriétaire utilisé par le Cisco Call manager. L'exemple précédent suppose que H.323 rapide connectez. Cette liste sert de référence aux ports utilisés par la signalisation VoIP et les canaux de contrôle :

   • H.323/H.225 = TCP 1720

   • H.323/H.245 = TCP 11xxx (la norme se connectent)

   • H.323/H.245 = TCP 1720 (rapide connectez)

   • H.323/H.225 RAS = UDP 1718 (au garde-porte)

   • SCCP = TCP 2000-2002 (bis cm)

   • ICCP = TCP 8001-8002 (bis cm)

   • MGCP = UDP 2427, TCP 2428 (bis cm)

   • UDP 5060 SIP=, TCP 5060 (configurable)

3. Créez une carte de stratégie et associez-la aux class map VoIP.

   Le but de la carte de stratégie est de définir comment les ressources en lien sont partagées ou assignées aux différentes classes de carte. Utilisez ces commandes de se terminer cette tâche :

   maui-voip-sj(config)#policy-map VOICE-POLICY
   
   !--- Choose a descriptive policy_map_name.
   
   
   maui-voip-sj(config-pmap)#class voice-traffic
   maui-voip-sj(config-pmap-c)#priority ?
    <8-2000000>  Kilo Bits per second
   
   !--- Configure the voice-traffic class to the strict PQ !--- (priority command) and assign the bandwidth.
   
   
   maui-voip-sj(config-pmap)#class voice-signaling
   maui-voip-sj(config-pmap-c)#bandwidth 8
   
   !--- Assign 8 Kbps to the voice-signaling class.
   
   
   maui-voip-sj(config-pmap)#class class-default
   maui-voip-sj(config-pmap-c)#fair-queue 
   
   !--- The remaining data traffic is treated as WFQ.
   
   

   Remarque: Bien qu'il soit possible de mettre de divers types en file d'attente de trafic en temps réel au PQ, Cisco recommande que vous dirigiez seulement le trafic vocal vers lui. Le trafic en temps réel, tel que le vidéo, introduit potentiellement la variation du retard (le PQ est une première file d'attente (FIFO) à système premier entré, premier sorti). Le trafic vocal exige que le retard soit nonvariable afin d'éviter le jitter.

   Remarque: La somme des valeurs pour la priorité et les instructions de bande passante doivent être inférieur ou égal à minCIR pour le PVC. Autrement, la commande de service-stratégie ne peut pas être assignée au lien. le minCIR est moitié de CIR par défaut. Pour voir les messages d'erreur, assurez-vous que la commande de logging console est activée pour l'accès de console et la commande de terminal monitor est activée pour l'accès de telnet.

   Pour plus d'informations sur les commandes de bande passante et prioritaires, référez-vous à comparer les commandes de bande passante et prioritaires d'une stratégie de service QoS.

4. Enable LLQ en appliquant la carte de stratégie à l'interface WAN sortante.

   Utilisez ces commandes d'activer LLQ :

   maui-voip-sj(config)#map-class frame-relay VoIPovFR
   maui-voip-sj(config-if)#service-policy output VOICE-POLICY
   
   !--- The service-policy is applied to the PVC !--- indirectly by configuring !--- it under the map-class associated to the PVC.
   
   

IP RTP Priority

Si vous n'utilisez pas LLQ, utilisez ces instructions :

Router(config-map-class)#frame-relay ip rtp priority starting-rtp-port  
port-range  bandwidth 

• démarrer-rtp-port — Le numéro de port UDP démarrant. Le plus bas numéro de port auquel les paquets sont envoyés. Pour le VoIP, placez cette valeur à 16384.

• port-range — La plage des destinations port d'UDP. Le nombre, ajouté au démarrer-rtp-port, rapporte le numéro de port UDP le plus élevé. Pour le VoIP, placez cette valeur à 16383.

• bande passante — Bande passante de maximum autorisé dans le Kbps pour la file d'attente prioritaire. Placez ce numéro en fonction sur le nombre d'appels simultanés, ajoutant la bande passante de chaque appel par appel qui les assistances techniques.

Configuration d'échantillon :

map-class frame-relay VoIPovFR  frame-relay cir 64000
 frame-relay BC 600
 no frame-relay adaptive-shaping
 frame-relay fair-queue
 frame-relay fragment 80
 frame-relay ip rtp priority 16384 16383 45

Le trafic formant pour la Voix

Utilisez ces instructions quand vous configurez le trafic formant pour la Voix :

• Ne dépassez pas le CIR du PVC.

• Formatage adaptatif de relais de trame de débronchement.

• Placez Bc le bas de valeur ainsi le comité technique (intervalle de mise en forme) est 10 ms (comité technique = Bc/CIR). Configurez Bc la valeur pour forcer la valeur désirée comité technique.

• Placez la valeur d'être à 0.

Le pour en savoir plus de ces instructions, se rapportent au Formatage du trafic de relais de trames pour le VoIP et le vofr.

Remarque: Utilisation de quelques clients PVCs distinct pour des données et la Voix. Si vous avez deux PVCs distinct et voulez éclater dans le circuit de données PVC tandis que vous restez à ou en dessous du CIR pour le PVC de Voix, la Qualité vocale souffre toujours puisque ces utilisation de PVCs la même interface physique. En pareil cas, le fournisseur de relais de trame, aussi bien que le routeur, doivent donner la priorité au PVC de Voix. Ce dernier peuvent être faits par la queue de priorité d'interface PVC (PIPQ) disponible en date du Logiciel Cisco IOS version 12.1(1)T.

Fragmentation (FRF.12)

Activez la fragmentation pour des liaisons à bas débit (moins de 768 Kbps). Fixez la taille de fragment de sorte que des paquets vocaux ne soient pas fragmentés et n'éprouvent pas un retard de fabrication en série plus grand que 20 que Mme a fixé la taille de fragmentation basée sur la plus basse vitesse de port entre les Routeurs. Par exemple, s'il y a une topologie de relais de trame de hub and spoke où le hub a une vitesse de t1 et les Routeurs distants ont 64 vitesses du port K, la taille de fragmentation doit être fixée pour la vitesse 64 K sur les deux Routeurs. N'importe quel autre PVCs qui partagent la même nécessité d'interface physique de configurer la fragmentation à la taille l'a utilisé par le PVC de Voix. Employez ce tableau pour déterminer les valeurs de taille de fragmentation.

Configuration d'échantillon :

map-class frame-relay VoIPovFR 

!--- Some output is omitted.

 frame-relay fragment 80

Remarque: Pour 1536 Kbps, aucune fragmentation n'est techniquement nécessaire. Cependant, la fragmentation est nécessaire pour permettre au double système de mise en file d'attente FIFO d'assurer la Qualité vocale. Une taille de fragment de 1600 octets active le double FIFO. Cependant, depuis 1600 les octets est supérieur à l'unité de transmission maximale sur une interface série typique (MTU), de grands paquets de données ne sont pas fragmentés.

Diagramme du réseau

Ce document utilise la configuration réseau indiquée dans le diagramme suivant :

Configurations

Ce document utilise les configurations affichées ici :

• Maui-VoIP-sj (Cisco 3640)

• Maui-VoIP-Austin (Cisco 3640)

version 12.2
service timestamps debug datetime msec
service timestamps log datetime msec
service password-encryption
!
hostname maui-voip-sj
!
logging buffered 10000 debugging
enable secret 5 $1$MYS3$TZ6bwrhWB25b2cVpEVgBo1
!
ip subnet-zero
!

!--- Definition of the voice signaling and traffic class maps. !--- "voice-traffic" class uses access-list 102 for its matching criteria. !--- "voice-signaling" class uses access-list 103 for its matching criteria.

class-map match-all voice-signaling
 match access-group 103
class-map match-all voice-traffic
  match access-group 102
!

!--- The policy map defines how the link resources are assigned !--- to the different map classes. In this configuration, strict PQ !--- is assigned to the voice-traffic class !--- with a maximum bandwidth of 45 Kbps.
 

policy-map VOICE-POLICY
  class voice-traffic
  priority 45
  class voice-signaling
  bandwidth 8


!--- Assigns a queue for voice-signaling traffic that ensures 8 Kbps. !--- Note that this is optional and has nothing to do with good voice !--- quality. Instead, it is a way to secure signaling.


  class class-default
  fair-queue


!--- The class-default class is used to classify traffic that does !--- not fall into one of the defined classes. !--- The fair-queue command associates the default class WFQ queueing.

!
interface Ethernet0/0
  ip address 172.22.113.3 255.255.255.0
  half-duplex
!
interface Serial0/0
 bandwidth 128
 no ip address
 encapsulation frame-relay
 no fair-queue
frame-relay traffic-shaping
 frame-relay ip rtp header-compression

!--- Turns on traffic shaping and cRTP. If traffic-shaping is not !--- enabled, then map-class does not start and FRF.12 and LLQ does !--- not work.

!
interface Serial0/0.1 point-to-point
 bandwidth 128
 ip address 192.168.10.2 255.255.255.252
 frame-relay interface-dlci 300
  class VOIPovFR

!--- This command links the subinterface to a VoIPovFR map-class. !--- See the map-class frame-relay VoIPovFR command here: !--- Note: The word VoIPovFR is selected by the user. !

ip classless
ip route 172.22.112.0 255.255.255.0 192.168.10.1
!
map-class frame-relay VOIPovFR
 no frame-relay adaptive-shaping

!--- Disable Frame Relay BECNS. Note also that Be equals 0 by default.

frame-relay cir 64000
 frame-relay bc 640

!--- Tc = BC/CIR. In this case Tc is forced to its minimal !--- configurable value of 10 ms.

frame-relay be 0
 frame-relay mincir 64000

!--- Although adaptive shaping is disabled, make CIR equal minCIR !--- as a double safety. By default minCIR is half of CIR.

service-policy output VOICE-POLICY

!--- Enables LLQ on the PVC.

frame-relay fragment 80

!--- Turns on FRF.12 fragmentation and sets the fragment size equal to 80 bytes. !--- This value is based on the port speed of the slowest path link. !--- This command also enables dual-FIFO.

!
access-list 102 permit udp any any range 16384  32767
access-list 103 permit tcp any eq 1720 any
access-list 103 permit tcp any any eq 1720
!

!--- access-list 102 matches VoIP traffic !--- based on the UDP port range. !--- Both odd and even ports are put into the PQ. !--- access-list 103 matches VoIP signaling protocol. In this !--- case, H.323 V2 is uesd with the fast start feature.

!
voice-port 1/0/0
!
dial-peer voice 1 pots
 destination-pattern 5000
 port 1/0/0
!
dial-peer voice 2 voip
 destination-pattern 6000
 session target ipv4:192.168.10.1
 dtmf-relay cisco-rtp
 ip precedence 5

version 12.2
service timestamps debug datetime msec
service timestamps log datetime msec
service password-encryption
!
hostname maui-voip-austin
!
boot system flash slot1:c3640-is-mz.122-6a.bin
logging buffered 1000000 debugging
!
ip subnet-zero
!
class-map match-all voice-signaling
match access-group 103
class-map match-all voice-traffic
  match access-group 102
!
policy-map voice-policy
  class voice-signaling
   bandwidth 8
  class voice-traffic
    priority 45
  class class-default
   fair-queue
!
interface Ethernet0/0
 ip address 172.22.112.3 255.255.255.0
 no keepalive
 half-duplex
!
interface Serial0/0
 bandwidth 64
 no ip address
 encapsulation frame-relay
 no ip mroute-cache 
 no fair-queue
 frame-relay traffic-shaping
 frame-relay ip rtp header-compression
!
interface Serial0/0.1 point-to-point
 bandwidth 64
 ip address 192.168.10.1 255.255.255.252
 frame-relay interface-dlci 400
  class VOIPovFR
!
ip classless
ip route 172.22.113.0 255.255.255.0 192.168.10.2
!
map-class frame-relay VOIPovFR
no frame-relay adaptive-shaping
 frame-relay cir 64000
 frame-relay bc 640
 frame-relay be 0
 frame-relay mincir 64000
 service-policy output voice-policy
 frame-relay fragment 80
access-list 102 permit udp any any range 16384 32767
access-list 103 permit tcp any eq 1720 any
access-list 103 permit tcp any any eq 1720
!
voice-port 1/0/0
!
dial-peer voice 1 pots
 destination-pattern 6000
 port 1/0/0
!
dial-peer voice 2 voip
 destination-pattern 5000
 session target ipv4:192.168.10.2
 dtmf-relay cisco-rtp
 ip precedence 5

Vérifiez et dépannez

Cette section fournit les informations pour confirmer que votre configuration fonctionne correctement.

Certaines commandes show sont prises en charge par l'outil Output Interpreter Tool (clients enregistrés seulement). Ceci vous permet d'afficher une analyse de la sortie de la commande show.

Commandes LLQ/IP RTP Priority

Ceux-ci affichent et les commandes de débogage vous aident à vérifier vos configurations LLQ et d'IP RTP Priority.

• interface# séquentiel de show policy-map interface — Cette commande est utile pour visualiser l'exécution LLQ et toutes les baisses dans le PQ. Pour plus d'informations sur les divers champs de cette commande, référez-vous compréhension derrière des compteurs de paquet dans la sortie de show policy-map interface.

• policy_map_name de show policy-map — Affiche des informations au sujet de la configuration de la carte de stratégie.

• interface-nombre d'interface-type de show queue — Listes configuration de mise en file d'attente équitable et statistiques pour une interface spécifique.

• debug priority — Affiche des événements PQ et affiche si la baisse se produit dans cette file d'attente. Le pour en savoir plus, se rapportent à des suppressions de sortie de dépannage avec la file d'attente à priorité déterminée.

• class_name de show class-map — Affiche des informations au sujet du configuration de class-map.

• show call active voice — Checks for a perdu des paquets au niveau DSP.

• show frame-relay ip rtp header-compression — Statistiques de Compression d'en-tête RTP d'affichages.

Commandes de fragmentation

Utilisez ces derniers mettent au point et des commandes show de vérifier et dépanner des configurations de fragmentation.

• show frame-relay fragment — Affiche des informations au sujet de la fragmentation de relais de trame qui a lieu dans le routeur de Cisco.

• fragment de debug frame-relay — Affichages événement ou messages d'erreur liés à la fragmentation de relais de trame. Il est seulement activé au niveau PVC sur l'interface sélectionnée.

Relais de trames/commandes d'interface

Utilisez ces commandes show de vérifier et dépanner le Relais de trames/configurations d'interface.

• interface de show traffic-shape queue — L'affiche des informations au sujet des éléments s'est alignée au niveau de l'identificateur de connexion de liaison de données de circuit virtuel (DLCI). Utilisé pour vérifier le fonctionnement de la priorité IP RTP au-dessus du Relais de trames. Quand le lien est congestionné, des flux voix sont identifiés avec un poids de zéro. Ceci indique que le flux voix utilise le PQ. Voyez la sortie témoin ici.

• show traffic-shape — L'affiche des informations telle que le comité technique, Bc, soit, et le CIR a configuré des valeurs. Voyez la sortie témoin.

• dlci-# de show frame-relay pvc — Affiche des informations telle que des paramètres de formatage du trafic, des valeurs de fragmentation, et des paquets relâchés. Voyez la sortie témoin. Référez-vous également au dépannage de Frame Relay.

Problèmes identifiés

Une bogue a été identifiée avec par le circuit virtuel LLQ où le PQ a été strictement maintenu l'ordre même lorsqu'il n'y a aucun encombrement sur l'interface. Cette bogue a été réparée et maintenant des paquets vocaux non conformes sont lâchés seulement si l'encombrement se produit sur le circuit virtuel. Ceci fait au comportement du par circuit virtuel LLQ les mêmes que d'autres interfaces qui utilisent LLQ. Ce comportement a été changé avec le Logiciel Cisco IOS version 12.2(3) et plus tard.

Échantillonnez l'exposition et mettez au point la sortie de commande

C'est exposition d'échantillon et met au point la sortie de commande utilisée pour la vérification et le dépannage.

!--- To capture sections of this output, the LLQ PQ bandwidth !--- is lowered and large data traffic is placed !--- on the link to force packets drops. !--- Priority queue bandwidth is lowered to 10 Kbps to force drops from the PQ. !--- Note: To reset counters, use the clear counters command. 


maui-voip-sj#show policy-map inter ser 0/0.1
  Serial0/0.1: DLCI 300 -

  Service-policy output: VOICE-POLICY

Class-map: voice-traffic (match-all)
         26831 packets, 1737712 bytes
         5 minute offered rate 3000 bps, drop rate 2000 bps
         Match: access-group 102
         Weighted Fair Queueing
         Strict Priority
         Output Queue: Conversation 24
         Bandwidth 10 (kbps) Burst 250 (Bytes)
         (pkts matched/bytes matched) 26311/1704020
         (total drops/bytes drops) 439/28964

   Class-map: voice-signaling (match-all)
         80 packets, 6239 bytes
         5 minute offered rate 0 bps, drop rate 0 bps
         Match: access-group 103
         Weighted Fair Queueing
         Output Queue: Conversation 25
         Bandwidth 8 (kbps) Max Threshold 64 (packets)
         (pkts matched/bytes matched) 62/4897
         (depth/total drops/no-buffer drops) 0/0/0
    
   Class-map: class-default (match-any)
         14633 packets, 6174492 bytes
         5 minute offered rate 10000 bps, drop rate 0 bps
         Match: any
         Weighted Fair Queueing
         Flow Based Fair Queueing
         Maximum Number of Hashed Queues 16
         (total queued/total drops/no-buffer drops) 0/0/0

      

!--- These commands are useful to verify the LLQ configuration.
 
      
maui-voip-austin#show policy-map voice-policy
  Policy Map voice-policy
   Class voice-signaling
        Weighted Fair Queueing
           Bandwidth 8 (kbps) Max Threshold 64 (packets)
   Class voice-traffic
        Weighted Fair Queueing
         Strict Priority
             Bandwidth 45 (kbps) Burst 1125 (Bytes)
   Class class-default
        Weighted Fair Queueing
           Flow based Fair Queueing Max Threshold 64 (packets)

maui-voip-austin#show class-map
 Class Map match-all voice-signaling (id 2)
         Match access-group  103
 Class Map match-any class-default (id 0)
         Match any
 Class Map match-all voice-traffic (id 3)
         Match access-group 102


!--- Frame Relay verification command output.


maui-voip-sj#show frame-relay fragment
interface         dlci  frag-type    frag-size  in-frag    out-frag   dropped-frag
Serial0/0.1       300   end-to-end      80         4          4          0

maui-voip-sj#show frame-relay pvc 300

PVC Statistics for interface Serial0/0 (Frame Relay DTE)

DLCI = 300, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0/0.1

 input pkts 7 output pkts 7 in bytes 926
         out bytes 918 dropped pkts 0 in FECN pkts 0
         in BECN pkts 0 out FECN pkts 0 out BECN pkts 0
         in DE pkts 0 out DE pkts 0
         out bcast pkts 2 out bcast bytes 598
         pvc create time 1w2d, last time pvc status changed 1w2d
      service policy VOICE-POLICY

 Service-policy output: VOICE-POLICY

 Class-map: voice-traffic (match-all)
         0 packets, 0 bytes
         5 minute offered rate 0 bps, drop rate 0 bps
      Match: access-group 102
         Weighted Fair Queueing
      Strict Priority
         Output Queue: Conversation 24
         Bandwidth 45 (kbps) Burst 250 (Bytes)
         (pkts matched/bytes matched) 0/0
         (total drops/bytes drops) 0/0

 Class-map: voice-signaling (match-all)
         0 packets, 0 bytes
         5 minute offered rate 0 bps, drop rate 0 bps
         Match: access-group 103
         Weighted Fair Queueing
         Output Queue: Conversation 25
         Bandwidth 8 (kbps) Max Threshold 64 (packets)
         (pkts matched/bytes matched) 0/0
         (depth/total drops/no-buffer drops) 0/0/0

 Class-map: class-default (match-any)
         7 packets, 918 bytes
         5 minute offered rate 0 bps, drop rate 0 bps
         Match: any
         Weighted Fair Queueing
         Flow Based Fair Queueing
         Maximum Number of Hashed Queues 16
         (total queued/total drops/no-buffer drops) 0/0/0


 Output queue size 0/max total 600/drops 0
 fragment type end-to-end fragment size 80
 cir 64000 bc 640 be 0 limit 80 interval 10
 mincir 64000 byte increment 80 BECN response no
 frags 13 bytes 962 frags delayed 8 bytes delayed 642
 
 shaping inactive
 traffic shaping drops 0


!--- In this Frame Relay verification command !--- output, the PQ bandwidth is lowered and heavy traffic !--- is placed on the interface to force drops. 

maui-voip-sj#show frame-relay pvc 300

PVC Statistics for interface Serial0/0 (Frame Relay DTE)

DLCI = 300, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0/0.1

 input pkts 483 output pkts 445 in bytes 122731
         out bytes 136833 dropped pkts 0 in FECN pkts 0
         in BECN pkts 0 out FECN pkts 0 out BECN pkts 0
         in DE pkts 0 out DE pkts 0
         out bcast pkts 4 out bcast bytes 1196
         pvc create time 1w2d, last time pvc status changed 1w2d
         service policy VOICE-POLICY

 Service-policy output: VOICE-POLICY

 Class-map: voice-traffic (match-all)
         352 packets, 22900 bytes
         5 minute offered rate 2000 bps, drop rate 2000 bps
         Match: access-group 102
         Weighted Fair Queueing
         Strict Priority
         Output Queue: Conversation 24
         Bandwidth 10 (kbps) Burst 250 (Bytes)
         (pkts matched/bytes matched) 352/22900
         (total drops/bytes drops) 169/11188

 Class-map: voice-signaling (match-all)
         7 packets, 789 bytes
         5 minute offered rate 0 bps, drop rate 0 bps
         Match: access-group 103
         Weighted Fair Queueing
         Output Queue: Conversation 25
         Bandwidth 8 (kbps) Max Threshold 64 (packets)
         (pkts matched/bytes matched) 7/789
         (depth/total drops/no-buffer drops) 0/0/0

 Class-map: class-default (match-any)
         79 packets, 102996 bytes
         5 minute offered rate 4000 bps, drop rate 0 bps
         Match: any
         Weighted Fair Queueing
         Flow Based Fair Queueing
         Maximum Number of Hashed Queues 16
         (total queued/total drops/no-buffer drops) 5/0/0
         Output queue size 5/max total 600/drops 169
         fragment type end-to-end fragment size 80
         cir 64000 bc 640 be 0 limit 80 interval 10
         mincir 64000 byte increment 80 BECN response no
         frags 2158 bytes 178145 frags delayed 1968 bytes delayed 166021

 shaping active
         traffic shaping drops 169


!--- Notice that the Tc interval equals 10 ms, !--- CIR equals 64000 BPS, and BC equals 640. 

     
maui-voip-sj#show traffic-shape
Interface  Se0/0.1
       Access Target    Byte   Sustain   Excess    Interval  Increment Adapt
VC     List   Rate      Limit  bits/int  bits/int  (ms)      (bytes)   Active
300           64000     80     640       0          10        80         -



!--- This output is captured on an isolated lab enviroment where !--- the routers are configured with IP RTP Priority instead of LLQ.
 

maui-voip-austin#show frame-relay PVC 100

PVC Statistics for interface Serial0/1 (Frame Relay DTE)

DLCI = 100, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0/1.1

  input pkts 336           output pkts 474          in bytes 61713
  out bytes 78960          dropped pkts 0           in FECN pkts 0
  in BECN pkts 0           out FECN pkts 0          out BECN pkts 0
  in DE pkts 0             out DE pkts 0
  out bcast pkts 0         out bcast bytes 0         
  PVC create time 1w0d, last time PVC status changed 1w0d
 Current fair queue configuration:   
   Discard      Dynamic       Reserved
   threshold    queue count   queue count
   64            16              2
 Output queue size 0/max total 600/drops 0 
  fragment type end-to-end        fragment size 80
  cir 64000     BC   640      be 0     limit 125    interval 10
  mincir 32000    byte increment 125   BECN response no
  frags 1091      bytes 82880     frags delayed 671      bytes delayed 56000
  shaping inactive
  traffic shaping drops 0
  ip rtp priority parameters 16384 32767 45000


!--- This command displays information of the VoIP dial-peers.
 
      
maui-voip-austin#show dial-peer voice 2
VoiceOverIpPeer2
        information type = voice,
        tag = 2, destination-pattern = `5000',
        answer-address = `', preference=0,
        group = 2, Admin state is up, Operation state is up,
        incoming called-number = `', connections/maximum = 0/unlimited,
        application associated: 
     type = voip, session-target = `ipv4:192.168.10.2',  
        technology prefix:
     ip precedence = 5, UDP checksum = disabled,
         session-protocol = cisco, req-qos = best-effort, 
         acc-qos = best-effort, 
     dtmf-relay = cisco-rtp, 
        fax-rate = voice,   payload size =  20 bytes
     codec = g729r8,    payload size =  20 bytes,
        Expect factor = 10, Icpif = 30,signaling-type = cas,
     VAD = enabled, Poor QOV Trap = disabled, 
        Connect Time = 165830, Charged Units = 0,
        Successful Calls = 30, Failed Calls = 0,
        Accepted Calls = 30, Refused Calls = 0,
        Last Disconnect Cause is "10",
        Last Disconnect Text is "normal call clearing.",
        Last Setup Time = 69134010.

Informations connexes

• Mise en file d'attente à faible latence pour relais de trames
• Classification de la signalisation et des medias VoIP avec le DSCP pour QoS
• Commandes show pour le formatage du trafic Frame Relay
• Fonction Frame Relay IP RTP Priority
• Configurer le Relais de trames et le Formatage du trafic de relais de trames
• Configurer et dépannage de Frame Relay
• Voix au-dessus d'amélioration de queue de Relais de trames
• Assistance technique concernant la technologie vocale
• Support produit pour Voix et Communications IP
• Dépannage des problèmes de téléphonie IP Cisco
• Support technique - Cisco Systems