LLQ, IP RTP Priority, LFI et cRTP VoIP avec PPP avec QoS LLQ, IP RTP Priority, LFI et cRTP

Sommaire liaisons PPP • Introduction - Composants utilisés • Lignes directrices du modèle de QoS pour VoIP sur des liaisons PPP - Priorité stricte pour du trafic VoIP (IP RTP Priority ou LLQ) - Directives de configuration LLQ - Directives de configuration de IP RTP Priority - LFI (Link Fragmentation and Interleaving): PPP Multilink - cRTP (compressed Real Time Protocol) - Autres possibilités de réduction de la bande passante • Schéma du réseau • Configurations • Vérification et commandes pour résolution de problèmes • Sorties de commandes show et debug

Lignes directrices du modèle de QoS pour VoIP sur des liaisons PPP Introduction Cet exemple étudie une configuration VoIP avec PPP (Point to Point Protocol) sur une ligne louée à bande passante élevée. Ce document comprend un rappel technique sur les fonctionnalités configurées, les lignes directrices de conception et des straté- gies de base pour la vérification et la résolution de problèmes. Il est important de noter que dans la configuration ci-dessous, les deux routeurs sont connectés face à face par une ligne louée. Dans la majorité des topologies les routeurs avec des capacités voix peuvent être situés n'importe où. Normalement les routeurs voix utilisent une connectivité LAN vers d'autres routeurs qui ont une con- nectivité WAN (ligne louée avec PPP). Ceci est important car si vos routeurs voix ne sont pas directement connectés par PPP sur une ligne louée, toutes les configura- tions WAN doivent être faites sur les routeurs connectés au WAN et non sur les rou- teurs voix comme cela est montré dans la configuration ci-dessous. Composants utilisés Les informations présentées dans ce document ont été testées sur les versions logi- cielles et matérielles suivantes: ● Deux routeurs Cisco 3640 avec L'IOS Cisco Release 12.2.6a (IP Plus), IOS Cisco Release 12.2(19a) IP Plus ou tout autre IOS Cisco Release of 12.2, 12.2T, 12.3 ou 12.3T. ● IP RTP Priority introduit dans l'IOS Cisco Release 12.0(5)T. ● LLQ introduit dans l'IOS Cisco Release 12.0(7)T. ● LFI introduit dans l' IOS Cisco Release 11.3. ● Les releases de l' IOS Cisco au-delà de 12.0.5T contiennent des améliorations de performance très significatives pour cRTP. Lignes directrices du modèle de QoS pour VoIP sur des liaisons PPP Cette section fournit des lignes directrices pour configurer VoIP sur des lignes louées PPP (avec l'accent mis sur les lignes bas débit). Il y a deux exigences de base pour une bonne qualité de la voix: ● Délai minimal de bout en bout et limitation de la gigue (variation du délai). ● Bande passante de liaison garantie et correctement gérée. Pour satisfaire ces exigences il y a plusieurs lignes directrices à suivre. (voir tableau page suivante).

Lignes directrices Description Priorité stricte pour le trafic voix (IP RTP Priority ou LLQ) Méthode qui fournit une priorité stricte pour le trafic voix. LFI (Link Fragmentation and Interleaving) Peut être une exigence obligatoire pour les lignes bas débit. Compression RTP N'est pas requise pour fournir une bonne qualité de voix mais réduit la demande en bande passante pour une communication. Le conseil général concernant la compression RTP est de l'appliquer après avoir réalisé une configuration qui fonc- tionne avec une bonne qualité de voix. Call Admission Control (CAC) Non couvert dans ce document. CAC est utilisé pour contrôler le nombre de communications pouvant être établies sur la liaison. Par exemple si la liaison WAN entre les deux passe- relles a une bande passante pour transporter deux communications VoIP, admettre une troisième commu- cation peut affecter la qualité de la voix des trois communications. En résumé, pour les liaisons PPP bas débit avec uniquement des passerelles comme sources de trafic voix, deux fonctionnalités sont obligatoires: 1. Priorité stricte pour le trafic voix 2. LFI (Link Fragmentation and Interleaving) Priorité stricte pour le trafic voix (IP RTP Priority ou LLQ) A partir de l'IOS Cisco release 12.2, il y a deux méthodes principales pour fournir la priorité stricte pour le trafic voix. ● IP RTP Priority (appelée également PQ/WFQ -Priority Queue/ Weighted Fair Queuing) ● Low Latency Queuing (appelée également PQ/CBWFQ - Priority Queue/ Class Based Weighted Queuing).

suivante illustre le fonctionnement de IP RTP Priority. IP RTP Priority crée une file d'attente de priorité stricte pour un ensemble de flux de paquets voix compris dans un intervalle de ports UDP destination. Comme ces ports sont des ports négociés dynamiquement entre les équipements d'extrémité ou les passerelles, tous les équipements Cisco utilisent le même intervalle de ports UDP (16384 à 32767). Dès que le routeur reconnaît le trafic VoIP, il place celui-ci dans la file d'attente de priorité stricte. Quand la file d'attente de priorité stricte est vide, les autres files d'attente sont traitées selon le standard WFQ (Weighted Fair Queuing). IP RTP Priority n'est pas actif tant qu'il n'y a pas congestion sur l'interface. La figure suivante illustre le fonctionnement de IP RTP Priority. Voix (Highest) 1 PQ 1 2 3 4 V V Données (High, IP Prec 4) 2 2 Données (Medium, IP Prec 2) Circuit WAN 3 WFQ Données (Low, IP Prec 0) 4 Note: IP RTP Priority permet d'augmenter la Priority Queue (PQ) quand il y a de la bande passante disponible sur la file d'attente par défaut (WFQ) mais gère le contenu de la "Priority Queue" de manière stricte s'il y a congestion sur l'interface. Low Latency Queuing LLQ est une fonctionnalité qui fournit une file d'attente de priorité stricte à CB-WFQ (Class Based Weighted Fair Queuing). LLQ permet une file d'attente PQ unique dans CB-WFQ au niveau classe. Avec LLQ, les données sensibles au délai (PQ) sont sorties de la file d'attente et transmises en premier. Dans VoIP avec une implémentation LLQ le trafic voix est placé dans la file d'attente PQ. La file PQ est policée pour assurer que les files d'attente "Fair Queue" ne sont pas privées de bande passante. Quand vous configurez la file PQ, vous spécifiez en Kb/s la valeur maximum de bande passante disponible pour PQ. Quand l'interface est congestionnée, la file PQ est servie jusqu'à ce que la charge atteigne la valeur max (en kb/s) configurée par l'instruction priority. Le trafic en excès est alors éliminé pour éviter le problème de privation de bande passante pour les files d'attente dont la priorité est plus faible.

Low Latency Queuing Link Fragmentation & Police CBWFQ V 1 2 3 V V Routeur VoIP SNA Données Low Latency Queuing Link Fragmentation & Interleave PQ Voix Police PQ Vidéo Conf TX Interleave Classe= X CBWFQ Paquets sortants Paquets entrants Fragment Classe = Y WFQ Default Cette méthode est plus complexe et plus flexible que IP RTP Priority. Le choix entre les deux méthodes doit être basé sur des motifs de trafic dans votre réseau actuel et selon vos besoins actuels. LLQ contre IP RTP Priority Le tableau suivant résume les différences principales entre LLQ et IP RTP Priority et fournit quelques indications sur l'utilisation de chaque méthode. Low Latency Queuing IP RTP Priority Correspondance du trafic voix basée sur : ● Listes d'accès (pour l'intervalle de ports UDP), adresses de hosts, champ Tos de l'en-tête IP ( IP Precedence, DSCP,etc..) ● Intervalle de ports RTP ● ToS IP (Type of Service): DSCP et/ou IP Precedence. ● Protocoles et Interfaces d'entrée. ● Tout critère de correspondance valide dans CBWFQ. ● Basée sur l'intervalle de ports RTP/UDP : 16384-32767. Avantages: ● Configuration simple Inconvénients: ● Trafic RTCP (Signalisation VoIP) servi dans la file WFQ.

Low Latency Queuing IP RTP Priority Avantages: ● Plus flexible sur la correspondan- ce du trafic et son aiguillage vers les files PQ et CBWFQ. ● Peut configurer des classes addi- tionnelles pour garantir de la bande passante pour d'autres trafics tels que: Signalisation VoIP et Vidéo. Inconvénients: ● Configuration plus complexe Note: Le protocole RTP utilise RTCP (Real Time Control Protocol) pour contrôler la remise des paquets RTP. RTP utilise des numéros de ports pairs alors que RTCP utilise des numéros de ports impairs dans le même intervalle. IP RTP Priority place les ports RTP dans la file PQ alors que les ports RTCP sont servis par la file par défaut de WFQ. ● Sert le trafic VoIP dans la file PQ mais tout autre trafic qui a besoin d'un traitement préférentiel et une bande passante garantie est servi dans WFQ. Bien WFQ puisse différencier les flux avec des poids ( IP Precedence) il ne peut pas garantir la bande passante pour aucun flux. Lignes directrices ● Le choix entre les deux méthodes doit être basé sur des motifs de trafic dans votre réseau actuel et selon vos besoins actuels. ● Si vous avez besoin de fournir une priorité stricte à votre trafic voix et le reste du trafic peut être traité comme un seul type (données) alors IP RTP Priority sera un bon choix pour votre réseau avec une configuration simple. ● Si vous planifier de donner une priorité au trafic voix basée sur d'autres critères que les ports UDP (par exemple Diffserv PHB) alors LLQ est néces- saire.

Directives de configuration de LLQ Suivez ces étapes pour configurer LLQ: 1. Créez une Class-map pour le trafic VoIP et définissez les critères de correspondance. Les commandes suivantes expliquent comment réaliser 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 !-- Choissisez un nom de classe significatif. 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 !-- Dans cet exemple nous utilisons une option de correspondance !-- access-group pour sa flexibilité (elle utilise une liste d'accès) 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 !-- Maintenant , créons la liste d'accès pour faire correspondre !-- la class-map et l'access-group: maui-voip-sj(config)#access-list 102 permit udp any any range 16384 32776 !-- Le moyn le plus sûr et le plus aisé est de faire la correspondance !-- avec les ports UDP dans l'intervalle 16384-32767. C'est l'intervalle !-- de ports que les produits Cisco IOS H.323 utilisent pour transmettre !-- des paquets VoIP.

tion LLQ en sortie. class-map voice Les listes d'accès suivantes peuvent être également utilisées pour le filtrage du trafic voix avec la commande access-group. access-list 102 permit udp any any precedence critical !-- Cette liste filtre le trafic sur la base du ToS du paquet IP: Champ !-- Precedence. !-- Note: Assurez-vous que d'autres trafic non-voix n'utilise pas la même !-- valeur de precedence. access-list 102 permit udp any any dscp ef !-- Pour que cette liste fonctionne, assurez-vous que les paquets VoIP !-- sont marqués avec le code dscp ef avant qu'ils quittent l'interface !-- LLQ WAN. !-- Note: Si les extrémités n'ont pas confiance en leur marquage de !-- paquets, vous pouvez marquer le trafic entrant en appliquant une !-- politique de service entrante sur une interface en entrée. Cette !-- procédure est hors de la portée de ce document. Access-list 102 permit udp host 192.10.1.1 host 192.20.1.1 !-- Cette liste d'accès peut être utilisée dans les cas où les équipements !-- VoIP ne peuvent pas faire le marquage de precedence ou dscp et que vous !--ne pouvez pas déterminer l'intervalle de ports UDP VoIP. Voici d'autres méthodes de correspondance qui peuvent être utilisées à la place des access-groups: ● Introduite dans l'IOS Cisco release 12.1.2T, IP RTP Priority est implémenté pour LLQ. Cette fonctionnalité fait la correspondance avec la classe de priorité concer- nant les ports UDP configurés et est limitée au service des ports UDP dans PQ. class-map voice match ip rtp 16384 16383 ● Les deux méthodes suivantes supposent que les paquets voix sont marqués par les hosts d'origine ou filtrés et marqués dans le routeur avant d'appliquer l'opéra- tion LLQ en sortie. class-map voice match ip precedence 5 ou class-map voice match ip dscp ef Note: A partir de l'IOS Cisco release 12.2.2T, les "dial-peer" VoIP peuvent marquer le service voix et les paquets de signalisation avant l'opération LLQ. Ceci donne un moyen évolutif de marquage et de repérage de paquets VoIP via les valeurs de code DSCP pour LLQ.

2. Définissez une Class-map pour la signalisation VoIP et définissez les critères de correspondance (optionnel). Les commandes suivantes expliquent comment réaliser 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 Note: Les communications VoIP peuvent être établies en utilisant H.323, SIP, MGCP ou SCCP (propriétaire Cisco utilisé par le CallManager). Les exemples ci-dessous supposent l'utilisation de H.323 Fast Connect. La liste suivante sert de référence pour les ports utilisés par la signalisation/canaux de commande VoIP. ● H.323/H.225 = TCP 1720 ● H.323/H.245 = TCP 11xxx (Standard Connect) ● H.323/H.245 = TCP 1720 (Fast Connect) ● H.323/H.225 RAS = TCP 1719 ● Skinny = TCP 2000-2002 (CallManager) ● ICCP = TCP 8001-8002 (CM Encore) ● MGCP = UDP 2427, TCP 2428 (CallManager) ● SIP= UDP 5060, TCP 5060 (configurable) 3. Créez une policy-map et associez-là aux Class-maps VoIP. Le but de la Policy-map est de définir comment les ressources de la liaison seront partagées ou affectées à différentes classes. Les commandes suivantes spécifient comment exécuter cette tâche: maui-voip-sj(config)#policy-map VOICE-POLICY !-- Choisissez un policy_map_name significatif. maui-voip-sj(config-pmap)#class voice-traffic maui-voip-sj(config-pmap-c)#priority ? <8-2000000> Kilo Bits per second !-- Configurez la classe voice-traffic la Priority Queue !-- (commande priority ) et affectez la bande passante. maui-voip-sj(config-pmap)#class voice-signaling maui-voip-sj(config-pmap-c)#bandwidth 8 !-- Affectez 8 Kb/s à la classe voice-signaling maui-voip-sj(config-pmap)#class class-default maui-voip-sj(config-pmap-c)#fair-queue !-- Le reste du trafic de données est traité par la !-- Weighted Fair Queue.

Directives de configuration de IP RTP Priority Note: Bien qu'il soit possible de mettre en file d'attente différents types de trafic temps-réel dans la file PQ, nous recommandons que seul le trafic voix soit dirigé vers celle-ci. Le trafic temps-réel tel que la vidéo peut introduire des variations du délai (la file PQ est FIFO (First In First Out)). Le trafic voix exige que le délai varie le moins possible pour éviter le phénomène de gigue. Note: La somme des valeurs pour les commandes priority et bandwidth doit être inférieure ou égale à 75% de la bande passante de la liaison sinon le service-policy ne pourra être affecté à la liaison (pour voir le message assurez-vous que les com- mandes logging console et terminal monitor sont configurées). Note: Quand on configure VoIP sur une liaison à 64 Kb/s pour supporter deux communications voix, il est commun d'allouer plus de 75% (48 Kb/s) de la bande passante de la liaison vers la file PQ. Pour de tels cas vous pouvez utiliser la com- mande max-reserve-bandwidth 80 pour augmenter la bande passante disponible à 80% (51 Kb/s). 4. Validez LLQ. Appliquez la policy-map à l'interface de sortie WAN. Les commandes suivantes expliquent comment réaliser cette tâche: maui-voip-sj(config)#interface multilink 1 maui-voip-sj(config-if)#service-policy output VOICE-POLICY !-- Dans ce scénario (MLPPP LFI), le service de politique est !-- appliqué à l'interface Multilink. Directives de configuration de IP RTP Priority Pour configurer IP RTP Priority suivez ces directives: ● Router(config-if)#ip rtp priority starting-rtp-port port-range bandwidth Commande Description starting-rtp-port Plus petit numéro de port UDP sur lequel les paquets voix sont trans- mis. Pour VoIP fixer cette valeur à 16384. port-range Nombre de ports UDP. Ce nombre ajouté à starting-rtp-port donne le plus grand numéro de port UDP utilisé. Pour VoIP fixer cette valeur à 16383 (32767-16384 = 16383). bandwidth Bande passante maximum allouée (Kb/s) dans la PQ. Fixer ce nombre selon nombre de communications simultanées que le système supporte.

Exemple de configuration: interface Multilink1 !--- Sortie supprimée bandwidth 64 ip address 172.22.130.2 255.255.255.252 ip tcp header-compression fair-queue no cdp enable ppp multilink ppp multilink fragment-delay 10 ppp multilink interleave multilink-group 1 ip rtp header-compression iphc-format ip rtp priority 16384 16383 45 LFI (Link Fragmentation and Interleaving): PPP Multilink Tandis que 1500 octets est un taille commune pour les paquets de données, un pa- quet VoIP typique (transportant des trames voix G.729) a une taille de 66 octets (20 octets de charge utile, 6 octets d'en-tête de couche 2, 20 octets d'en-tête IP et 20 octets d'en-tête UDP et RTP). Maintenant imaginez une ligne louée à 56 Kb/s sur laquelle des trafics voix et don- nées coexistent. Si un paquet voix est prêt à être transmis sur la liaison quand un paquet de données commence à être transmis alors cela va poser un problème. Le paquet voix sensible au délai devra attendre 214 ms avant d'être transmis (cela prend 214 ms pour sérialiser 1500 octets sur une ligne série à 56 Kb/s). Comme vous pouvez le voir, de grands paquets de données peuvent malencontreuse- ment retarder la remise de petits paquets, diminuant la qualité de la voix. Fragmenter ces grands paquets de données en petits paquets et entrelacer les paquets voix avec les fragments réduit la gigue et le délai. La fonctionnalité LFI (Line Fragmentation and Interleaving) aide à satisfaire les exigences de temps-réel de la VoIP. La figure suivante illustre le fonctionnement de LFI.

Link Fragmentation and Interleaving (LFI) Paquets IP voix Paquets IP Data Fragmentation Paquets IP Voix Fragments entrelacés avec en-tête multilink Les paquets IP voix ne sont pas fragmentés Paquet IP Data Classification Comme cela est montré dans le tableau suivant, le délai total de sérialisation (temps mis pour émettre les bits sur l'interface) introduit par les liaisons WAN bas débit peut être très significatif en considérant que le délai de bout en bout à atteindre dans un sens ne doit pas excéder 150 ms (La recommandation UIT-T G.114 spécifie 150 ms de bout en bout dans un sens. 1 Octet 64 Octets 128 Octets 256 Octets 512 Octets 1024 Octets 1500 Octets 56 Kb/s 143 µs 9 ms 18 ms 36 ms 72 ms 144 ms 214 ms 64 125 µs 8 ms 16 ms 32 ms 64 ms 126 ms 187 ms 128 62,5 µs 4 ms 63 ms 93,5 ms 256 Kb/s 31,25 µs 2 ms 31,5 ms 46,75 ms 512 Kb/s 15,6 µs 1 ms 16,25 ms 32,4 ms 768 Kb/s 10 µs 640 µs 1,28 ms 2,56 ms 5,12 ms 10,24 ms 15 ms 1536 Kb/s 5 µs 320 µs 7,5 ms Note: Pour les applications voix, le délai de sérialisation recommandé (par saut) est de 10 ms et ne doit pas excéder 20 ms. La taille du fragment liaison est configurable en millisecondes avec la commande ppp multilink fragment-delay. LFI requiert que ppp multilink soit configurée sur l'interface avec ppp multilink interleave validé.

Note: Dans les cas où vous disposez d'une liaison dont le débit est supérieur à 768 Kb/s, vous n'avez pas besoin de fragmentation (vous aurez cependant toujours besoin d'un mécanisme de QoS tel que LLQ ou IP RTP Priority). Le débit d'une liaison T1 ou E1 offre assez de bande passante pour permettre aux paquets voix d'entrer et de sortir de la file d'attente sans problème de délai. Vous n'aurez peut-être pas besoin de cRTP (compressed RTP) qui permet d'économiser de la bande passante en com- pressant les en-têtes IP RTP dans le cas d'une liaison à 768 Kb/s. cRTP (compressed Real Time Protocol) Note: cRTP n'est pas requis pour assurer une bonne qualité de la voix. C'est une fonctionnalité qui réduit la demande en bande passante. Configurez cRTP après que toutes les autres conditions aient été satisfaites et que la qualité de la voix est bonne. Cette procédure peut permettre de gagner du temps de résolution de problèmes en isolant les problèmes cRTP potentiels. Basée sur le RFC 2508, la compression de l'en-tête RTP compresse les en-têtes IP/ UDP/RTP de 40 à 2 ou 4 octets réduisant ainsi la bande passante nécessaire. C'est un système de compression saut par saut; par conséquent cRTP doit être configuré au deux extrémités de la liaison ( à moins que l'option passive soit configurée). Pour configurer cRTP, utilisez la commande suivante au niveau interface: ● Router(config-if)#ip rtp header-compression [passive] Comme le processus de compression peut demander des ressources CPU, la compres- sion d'en-têtes RTP est implémentée dans le chemin "Fast Switching" et dans CEF à partir de la release 12.0(7)T de l'IOS Cisco. quelques fois ces implémentations sont indisponibles et le seul moyen de fonctionnement sera par processus commuté. Cisco recommande d'utiliser cRTP avec des liaisons dont le débit est inférieur à 768 kb/s sauf si le routeur opère avec un faible taux d'utilisation de sa CPU. Note: Quand vous configurez la commande ip rtp header-compression, le routeur ajoute par défaut la commande ip tcp header-compression dans la configuration. Ceci est utilisé pour compresser les en-têtes IP/TCP. La compression d'en-têtes est particulièrement utile dans les réseaux avec un grand pourcentage de petits paquets tels que ceux supportant les connexions Telnet. La technique de compression des en-têtes TCP, décrite dans le RFC 1144, est supportées sur les lignes série utilisant des encapsulations HDLC ou PPP. Pour compresser les en-têtes TCP sans valider cRTP, utilisez la commande suivante: ● Router(config-if)#ip tcp header-compression [passive] Autres possibilités de réduction de bande passante ● Utilisez des codecs (codeur/décodeur) bas débit sur les tronçons de communica- tions VoIP. G.729 (8 Kb/s) est recommandé (c'est le Codec par défaut sur les ex- trémités d'appel (dial-peers)). Pour configurer des Codecs différents, utilisez la commande router(config-dial-peer)#codec sous l'extrémité d'appel désirée. ● ●

Schéma du réseau Configurations ● Bien que les tonalités DTMF soient transportées de manière fiable en utilisant des Codecs haut débit tel que G.711, les Codecs bas débit (tels que G.729 et G.723.1) sont très optimisés pour des motifs voix et tendent à déformer les tonalités DTMF. Cette approche peut causer des problèmes pour l'accès à des systèmes vocaux in- teractifs (IVR). La commande dtmf relay résoud ce problème de déformation des tonalités DTMF en transportant ces tonalités hors bande ou séparément des flux voix. Si des Codecs bas débit sont utilisés, configurez dtmf relay dans l'extrémité d'appel VoIP. ● Une conversation typique peut contenir 30 à 50% de silence. Avec l'utilisation de la VAD (Voice Activity Detection) les paquets de silence sont supprimés. Pour la planification de bande passante VoIP, estimez que la VAD va réduire la bande passante de 35%. La VAD est configurée par défaut sous l'extrémité d'appel VoIP. Pour valider/dévalider la VAD, utilisez les commandes suivantes: router(config-dial-peer)#vad et router(config-dial-peer)# no vad Schéma du réseau S0/0 maui-voip-sj Ligne louée 128 Kb/s PPP 172.22.13.2 172.22.130.1 5000 6000 maui-voip-austin Configurations maui-voip-sj (3640) version 12.2service timestamps debug datetime msec !-- < sortie supprimée > ! hostname maui-voip-sj ip subnet-zero no ip domain-lookup !-- Définition des class-maps pour le trafic voix et la !-- signalisation !-- La classe "voice-traffic" utilise l'access-list 102 pour ses !-- critères de correspondance. !-- La classe "voice-signaling" utilise l'access-list 103 pour ses class-map match-all voice-signaling match access-group 103 class-map match-all voice-traffic match access-group 102

!-- La policy-map définit comment les ressources de la liaison !-- sont affectées aux différentes class-map. Dans cette configu- !-- ration, la file de priorité stricte est affectée à la classe !-- "voice-traffic" class avec (basée sur l'ACL dans la classe !-- voice) avec une bande passante maximum de 45 Kbps. policy-map VOICE-POLICY class voice-traffic priority 48 class voice-signaling bandwidth 8 !-- Affecte une file pour le trafic "voice-signaling" et assure !-- 8kb/s. Notez que ceci est optionnel et n'a rien à voir avec !-- la qualité de la voix mais plutôt un moyen de sécuriser la !-- signalisation. class class-default fair-queue !-- La classe class-default est utilisée pour classifier le trafic !-- qui ne correspond pas aux classes définies. !-- La commande fair-queue associe WFQ à la classe par défaut. ! call rsvp-sync !-- Notez que MLPPP est un mécanisme strictement LFI. Il ne !-- groupe pas plusieurs interfaces serial sur la même interface !-- virtuelle comme son nom l'indique. Ce groupement est fait pour !-- les données et n'est pas recommandé pour la voix. La manifes- !-- tation finale pourrait être de la gigue. interface Multilink1 ip address 172.22.130.1 255.255.255.252 ip tcp header-compression iphc-format service-policy output VOICE-POLICY !-- LLQ est une opération en sortie et appliquée à l'interface !-- WAN de sortie. no cdp enable ppp multilink ppp multilink fragment-delay 10 !-- La valeur 10 configurée fixe la taille des fragments pour que !-- tous les fragments aient un délai de sérialisation maximum de !-- 10ms. ppp multilink interleave multilink-group 1 ip rtp header-compression iphc-format interface Ethernet0/0 ip address 172.22.113.3 255.255.255.0 no keepalive half-duplex

! interface Serial0/0 bandwidth 128 !-- La commande bandwidth doit être correctement appliquée pour !-- que la bonne taille de fragment soit calculée. no ip address encapsulation ppp clockrate 128000 ppp multilink multilink-group 1 !-- Cette commande lie l'interface multilink à l'interface serial !-- physique. router eigrp 69 network 172.22.0.0 auto-summary no eigrp log-neighbor-changes !-- L'access-list 102 correspond au trafic VoIP basé sur l'inter- !-- valle de ports UDP. !-- Les ports pairs et impairs sont placés dans la file PQ. !-- L'access-list 103 is correspond au trafic du protocole de !-- signalisation VoIP. Dans ce cas nous utilisons H.323 V2 avec !-- la fonctionnalité "fast start". 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 voice-port 1/0/1 voice-port 1/1/0 voice-port 1/1/1 dial-peer cor custom dial-peer voice 1 pots destination-pattern 5000 port 1/0/0 dial-peer voice 2 voip destination-pattern 6000 session target ipv4:172.22.130.2

maui-voip-austin (3640) version 12.2 service timestamps debug datetime msec ! hostname maui-voip-austin boot system flash slot1:c3640-is-mz.122-6a.bin 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 48 class class-default fair-queue interface Multilink1 bandwidth 128 ip address 172.22.130.2 255.255.255.252 ip tcp header-compression iphc-format service-policy output voice-policy no cdp enable ppp multilink ppp multilink fragment-delay 10 ppp multilink interleave multilink-group 1 ip rtp header-compression iphc-format !-- Configurez cRTP après avoir testé votre configuration. !-- Ceci vous aidera à isoler des problèmes potentiels liés !-- cRTP. Interface Ethernet0/0 ip address 172.22.112.3 255.255.255.0 no keepalive half-duplex interface Serial0/0 no ip address encapsulation ppp no ip mroute-cache

Vérification et commandes pour résolution de problèmes router eigrp 69 network 172.22.0.0 auto-summary no eigrp log-neighbor-changes ! 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 voice-port 1/0/1 voice-port 1/1/0 voice-port 1/1/1 dial-peer cor custom dial-peer voice 1 pots destination-pattern 6000 port 1/0/0 dial-peer voice 2 voip destination-pattern 5000 session target ipv4:172.22.130.1 Vérification et commandes pour résolution de problèmes Après avoir entré les configurations dans les routeurs, vérifier qu'ils fonctionnent cor- rectement. Ces commandes et leurs sorties respectives montrent une implémentation réussie des configurations. ● Commandes pour interface : - show interface [serial | multilink] - Utilisez cette commande pour vérifier l'état de l'interface serial. Assurez-vous que l'interface serial et l'interface multilink sont "up" et "open". - Voir le document "Résoudre les problèmes des lignes Serial" ● Commandes LFI : - show ppp multilink - Cette commande affiche l'information pour les groupe- ments PPP Multilink. - debug ppp multilink fragments - Cette command debug affiche des informa- tions sur les fragments multilink et les événements d'entrelacements. Cette sortie de command identifie également le numéro de séquence du paquet et les tailles des fragments.

● Commandes pour LLQ / IP RTP Priority : - show policy-map interface multilink interface - Cette commande est très utile pour voir le fonctionnement de LLQ et de voir les éliminations dans la file PQ - show policy-map policy_map_name - Affiche les informations de configura- tion de la policy-map. - show queue interface-type interface-number - Liste la configuration de la file d'attente et les statistiques pour une interface particulière. - Debug priority - Cette commande debug affiche l'évènement de la file priori- taire et montre si des éliminations se produisent dans cette file. - show class-map class_name - affiche les informations au sujet de la confgu- ration des class-map. - Show call active voice - Cette commande est très utile pour vérifier la perte de paquets au niveau DSP. ● Autres Commandes / Références: - show ip rtp header-compression - Affiche les statistiques de compression d'en-tête RTP. - Debug et résolution de problèmes de communications VoIP - Les Bases - Commandes debug VoIP ● Directives: La résolution de problème de base débute dès que la liaison PPP est "up" et opé- rationnelle (MLPPP, Fragmentation, Interleaving): 1. show call active voice - Pour vérifier la perte de paquets au niveau DSP.. 2. show interface - Pour déceler les problèmes généraux d'une ligne serial ou d'une interface. Les éliminations au niveau de l'interface ne sont pas forcément un problème mais il est préférable d'éliminer un paquet de la file de basse priorité avant qu'il passe dans la file de l'interface. 3. show policy-map interface - Pour vérifier les éliminations LLQ et la configu- ration de file d'attente. Ne rapporte pas les éliminations dues à un non respect de la politique. 4. show ip rtp header-compression - Pour déceler des problèmes spécifiques à cRTP.

Sorties de commandes show et debug !--------------------------------------------------------------- !---- Pour les sections de capture de cette sortie, la bande !---- passante LLQ PQ a été diminuée et un grand volume de trafic !---- de données a été placé sur la liaison pour forcer la perte !---- de quelques paquets. !---- Vérification d'élimination de paquets (Durant une communi- !---- cation active) !--- En supposant que votre liaison PPP est "up" et opération- !--- nelle, la première étape de vérification des problèmes de !--- qualité de la voix est de vérifier la perte de paquets au !--- niveau du DSP. Utilisez la commande: "show call active !--- voice" maui-voip-austin#show call active voice Total call-legs: 2 !--- Indique que la connexion est établie et que deux tronçons !--- existent. GENERIC: SetupTime=155218260 ms Index=1 PeerAddress=5000 PeerSubAddress= PeerId=2 PeerIfIndex=13 LogicalIfIndex=0 ConnectTime=155218364 CallDuration=00:00:27 CallState=4 !--- Indique que c'est la communication active !--- (#define D_callActiveCallState_active 4). CallOrigin=2 ChargedUnits=0 InfoType=2 TransmitPackets=365 TransmitBytes=7300 ReceivePackets=229 ReceiveBytes=4580

VOIP: !--- C'est la passerelle de terminaison de cette communication. !--- Le tronçon VoIP commence à cette passerelle. ConnectionId[0x18872BEB 0x1A8911CC 0x808CBE60 0x6D946FC6] IncomingConnectionId[0x18872BEB 0x1A8911CC 0x808CBE60 0x6D946FC6] RemoteIPAddress=172.22.130.1 !--- Indique de quelle adresse IP est originaire le flux !--- RTP. RemoteUDPPort=18778 RemoteSignallingIPAddress=172.22.130.1 !--- Indique de quelle adresse IP sont issus les messages !--- de signalisation. RemoteSignallingPort=11010 RemoteMediaIPAddress=172.22.130.1 RemoteMediaPort=18778 RoundTripDelay=50 ms SelectedQoS=best-effort tx_DtmfRelay=inband-voice FastConnect=TRUE Separate H245 Connection=FALSE H245 Tunneling=FALSE SessionProtocol=cisco SessionTarget= OnTimeRvPlayout=4570 GapFillWithSilence=20 ms GapFillWithPrediction=1840 ms GapFillWithInterpolation=0 ms GapFillWithRedundancy=0 ms HiWaterPlayoutDelay=70 ms LoWaterPlayoutDelay=51 ms ReceiveDelay=51 ms LostPackets=90 EarlyPackets=1 LatePackets=0 !--- Indique la présence de gigue, de paquets perdus ou !--- de paquets corrompus. VAD = enabled CoderTypeRate=g729r8 CodecBytes=20

GENERIC: SetupTime=155218260 ms Index=2 PeerAddress=6000 PeerSubAddress= PeerId=1 PeerIfIndex=12 LogicalIfIndex=6 ConnectTime=155218364 CallDuration=00:00:34 CallState=4 CallOrigin=1 ChargedUnits=0 InfoType=2 TransmitPackets=229 TransmitBytes=4580 ReceivePackets=365 ReceiveBytes=7300 TELE: ConnectionId=[0x18872BEB 0x1A8911CC 0x808CBE60 0x6D946FC6] IncomingConnectionId=[0x18872BEB 0x1A8911CC 0x808CBE60 TxDuration=35360 ms VoiceTxDuration=730 ms FaxTxDuration=0 ms CoderTypeRate=g729r8 NoiseLevel=-46 ACOMLevel=2 OutSignalLevel=-58 InSignalLevel=-42 InfoActivity=2 ERLLevel=7 SessionTarget= ImgPages=0Total call-legs: 2

!--------------------------------------------------------------- !--- Vérification d'interface !--- Assurez-vous que vous voyez: !--- LCP Open, multilink Open: Link control protocol (LCP) open !--- indique que la connexion est établie. !--- Open:IPCP. Indique que le trafic IP peut être transmis via !--- la liaison PPP. maui-voip-sj#show interface multilink 1 Multilink1 is up, line protocol is up Hardware is multilink group interface Internet address is 172.22.130.1/30 MTU 1500 bytes, BW 128 Kbit, DLY 100000 usec, reliability 255/255, txload 1/255, rxload 1/255 Encapsulation PPP, loopback not set Keepalive set (10 sec) DTR is pulsed for 2 seconds on reset LCP Open, multilink Open Open: IPCP Last input 00:00:01, output never, output hang never Last clearing of "show interface" counters 00:25:20 Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 91 Queueing strategy: weighted fair Output queue: 0/1000/64/37/383 (size/max total/threshold/drops /interleaves) Conversations 0/3/32 (active/max active/max total) Reserved Conversations 1/1 (allocated/max allocated) Available Bandwidth 38 kilobits/sec 5 minute input rate 0 bits/sec, 0 packets/sec 5 minute output rate 0 bits/sec, 0 packets/sec 8217 packets input, 967680 bytes, 0 no buffer Received 0 broadcasts, 0 runts, 0 giants, 0 throttles 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort 13091 packets output, 1254194 bytes, 0 underruns 0 output errors, 0 collisions, 0 interface resets 0 output buffer failures, 0 output buffers swapped out 0 carrier transitions

---------------------------------------------------------------------- !-- Note: Il n'y a pas d'élimination au niveau interface. !-- Tout le trafic qui est éliminé par l'application de politique, est !-- éliminé avant qu'il passe dans la file d'attente d'interface. maui-voip-austin#show interface serial 0/0Serial0/0 is up, line protocol is up Hardware is QUICC Serial MTU 1500 bytes, BW 128 Kbit, DLY 20000 usec, reliability 255/255, txload 49/255, rxload 47/255 Encapsulation PPP, loopback not set Keepalive set (10 sec) LCP Open, multilink Open Last input 00:00:00, output 00:00:00, output hang never Last clearing of "show interface" counters 00:22:08 Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0 Queueing strategy: weighted fair [suspended, using FIFO] FIFO output queue 0/40, 0 drops 5 minute input rate 24000 bits/sec, 20 packets/sec 5 minute output rate 25000 bits/sec, 20 packets/sec 4851 packets input, 668983 bytes, 0 no buffer Received 0 broadcasts, 0 runts, 0 giants, 0 throttles 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort 4586 packets output, 657902 bytes, 0 underruns 0 output errors, 0 collisions, 0 interface resets 0 output buffer failures, 0 output buffers swapped out 0 carrier transitions DCD=up DSR=up DTR=up RTS=up CTS=up !---------------------------------------------------------------------- !--- Vérification LLQ maui-voip-austin#show policy-map int multilink 1 Multilink1 Service-policy output: voice-policy Class-map: voice-signaling (match-all) !--- C'est la classe pour le trafic de signalisation voix. 10 packets, 744 bytes 5 minute offered rate 0 BPS, drop rate 0 BPS Match: access-group 103 Weighted Fair Queueing Output Queue: Conversation 42 Bandwidth 8 (kbps) Max Threshold 64 (packets) (pkts matched/bytes matched) 10/744 (depth/total drops/no-buffer drops) 0/0/0

Class-map: voice-traffic (match-all) !--- C'est la classe PQ pour le trafic voix. 458 packets, 32064 bytes 5 minute offered rate 0 BPS, drop rate 0 BPS Match: access-group 102 Weighted Fair Queueing Strict Priority Output Queue: Conversation 40 Bandwidth 15 (kbps) Burst 375 (Bytes) !--- Notez que la bande passante de PQ a été très diminuée pour !--- forcer l'élimination de paquets. (pkts matched/bytes matched) 458/29647 (total drops/bytes drops) 91/5890 !--- Quelques paquets ont été éliminés. Dans une liaison !--- bien conçue cela ne doit pas arriver pour la classe PQ. Class-map: class-default (match-any) 814 packets, 731341 bytes 5 minute offered rate 27000 BPS, drop rate 0 BPSMatch: any Flow Based Fair Queueing Maximum Number of Hashed Queues 32 (total queued/total drops/no-buffer drops) 0/0/0 !--------------------------------------------------------------------- !--- Vérification de la configuration de la class-map 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 !--- Vérification des Access-lists des Class-Maps maui-voip-austin#show access-lists Extended IP access list 102 permit udp any any range 16384 32767 (34947 matches) Extended IP access list 103 permit tcp any eq 1720 any (187 matches) permit tcp any any eq 1720 (86 matches)

!--- Vérification de la configuration de la Policy-Map 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 Strict Priority Bandwidth 50 (kbps) Burst 1250 (Bytes) Class class-default Flow based Fair Queueing Max Threshold 64 (packets) --------------------------------------------------------------------- !--- La commande Debug priority fournit un retour = immédiat dans le !--- cas d'élimination de paquets VoIP. !--- La sortie ci-dessous montre le message d'erreur quand des paquets !--- VoIP sont éliminés de la file d'attente de priorité stricte. maui-voip-sj#debug priority priority output queueing debugging is on maui-voip-sj# Mar 17 19:47:09.947: WFQ: dropping a packet from the priority queue 0 Mar 17 19:47:09.967: WFQ: dropping a packet from the priority queue 0 Mar 17 19:47:09.987: WFQ: dropping a packet from the priority queue 0 !--- Vérification de LFI (Link Fragmentation and Interleaving) maui-voip-sj#show ppp multilink !--- Affiche la taille des fragments et l'état multilink Multilink1, bundle name is maui-voip-austin Bundle up for 00:08:04 0 lost fragments, 0 reordered, 0 unassigned 0 discarded, 0 lost received, 1/255 load 0x6D received sequence, 0x6E sent sequence Member links: 1 active, 0 inactive (max not set, min not set) Serial0/0, since 00:08:09, last rcvd seq 00006C 160 weight !--- Notez que la taille des fragments est de 160 octets. Nous !--- avons configuré la liaison avec une bande passante de 128 Kb/S !--- et le délai de sérialisation est de 10 msec. Taille du !--- Fragment(en bits) = bande passante * délai de sérialisation.

------------------------------------------------------- !--- Vérification de LFI (Link Fragmentation and Interleaving) !--- Test de Multilink PPP LFI !--- la sortie suivante affiche les informations de fragmentation et !--- d'entrelacement quand la liaison PPP à 128 Kb/s est chargée avec !--- beaucoup de paquets de données et des paquets VoIP. maui-voip-sj#debug ppp multilink fragments Multilink fragments debugging is on 1w3d: Se0/0 MLP: O frag 800004CF size 160 1w3d: Se0/0 MLP: O frag 000004D0 size 160 1w3d: Se0/0 MLP: I ppp IP (0021) size 64 direct 1w3d: Mu1 MLP: Packet interleaved from queue 40 1w3d: Se0/0 MLP: O ppp IP (0021) size 64 1w3d: Se0/0 MLP: O frag 400004D1 size 106 1w3d: Se0/0 MLP: O ppp IP (0021) size 64 direct 1w3d: Se0/0 MLP: I frag 800004E0 size 160 direct 1w3d: Se0/0 MLP: I frag 000004E1 size 160 direct --------------------------------------------------------------------- !--- Extrait de la sortie de la commande ip rtp header-compression. maui-voip-sj#show ip tcp header-compression TCP/IP header compression statistics: Interface Multilink1: Rcvd: 10 total, 6 compressed, 0 errors 0 dropped, 0 buffer copies, 0 buffer failures Sent: 10 total, 7 compressed, 230 bytes saved, 99 bytes sent 3.32 efficiency improvement factor Connect: 16 rx slots, 16 tx slots, 2 long searches, 1 misses 0 collisions, 0 negative cache hits 90% hit ratio, five minute miss rate 0 misses/sec, 0 max

!--- Cette commande affiche des informations sur les dial-peers VoIP. maui-voip-sj#show dial-peer voice 2 VoiceOverIpPeer2 information type = voice, tag = 2, destination-pattern = `6000', 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-tMarget = `ipv4:172.22.130.2', technology prefix: ip precedence = 0, UDP checksum = disabled, session-protocol = cisco, req-qos = best-effort, acc-qos = best-effort, 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 = 283, Charged Units = 0, Successful Calls = 1, Failed Calls = 0, Accepted Calls = 1, Refused Calls = 0, Last Disconnect Cause is "10 ", Last Disconnect Text is "normal call clearing.", Last Setup Time = 93793451. ---------------------------------------------------------------------- !--- L'utilisation CPU du routeur ne doit pas excéder 50-60% pendant !--- chaque intervalle de cinq minutes. maui-voip-austin#show processes cpu CPU utilization for five seconds: 12%/8%; one minute: 11%; five minutes: 9% PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process 1 148 310794 0 0.00% 0.00% 0.00% 0 Load Meter 2 76 23 3304 0.81% 0.07% 0.01% 0 Exec