La qualité de service (QoS) fait référence aux outils que les périphériques réseau peuvent utiliser pour gérer plusieurs caractéristiques liées aux paquets qui transitent dans un réseau. Plus précisément, ces outils gèrent la bande passante mise à la disposition d’un paquet, le délai paquet de transmission, la gigue (variation de délai). Ces outils équilibrent les types de trafic recevant les ressources du réseau et le moment, en donnant plus de préférence à certains trafics et moins à d’autres. Les outils QoS définissent les actions qu’un équipement peut appliquer à un message entre le moment où il entre dans l’équipement et celui où il quitte l’équipement. QoS définit ces actions et ainsi peut retarder le message, le rejeter ou même modifier les champs d’en-tête.
Introduction à la QoS
Les routeurs se trouvent généralement à la périphérie du WAN, avec à la fois des interfaces WAN et des interfaces LAN. Ces interfaces LAN fonctionnent généralement à des vitesses beaucoup plus rapides que les interfaces WAN. Lorsque l’interface WAN plus lente est occupée à envoyer les paquets en attente dans le routeur, des centaines, voire des milliers de paquets IP supplémentaires pourraient arriver dans les interfaces LAN, tous devant être transférés vers cette même interface WAN. Que doit faire le routeur ? Les envoyer tous, dans le même ordre dans lequel ils sont arrivés? Prioriser les paquets, en envoyer certains plus tôt que d’autres, préférer un type de trafic à un autre? Supprimer certains des paquets lorsque le nombre de paquets en attente de sortie du routeur devient trop important? Le routeur pourrait mettre en file d’attente les paquets en attendant que l’interface WAN soit disponible, il pourrait également utiliser un algorithme de planification de file d’attente pour déterminer quels paquets doivent être envoyés en premier, en utilisant un autre ordre que l’ordre d’arrivée – donnant à certains paquets une meilleur qualité de service.
Cisco propose une large gamme d’outils QoS sur les routeurs et les commutateurs. Tous ces outils vous donnent les moyens de gérer quatre caractéristiques du trafic réseau:
- Bande passante
- Retard
- Gigue
- Perte
La bande passante fait référence à la vitesse d’un lien, en bits par seconde (bps). Mais si nous considérons la bande passante comme une vitesse, il est utile de penser également à la bande passante comme la capacité du lien, en termes de nombre de bits pouvant être envoyés sur le lien par seconde. Les outils QoS du périphérique réseau déterminent quel paquet est l’ordre des paquets envoyé sur la liaison, de sorte que le périphérique réseau contrôle quels messages utilise la bande passante et quelle part de cette bande passante (capacité) est alloué aux types de trafic. Prenons l’exemple d’un routeur qui a des centaines de paquets en attente. Un administrateur réseau peut configurer un outil de mise en file d’attente pour réserver 10% de la bande passante pour le trafic vocal, 50% pour les applications de données critiques, et laisser le reste de la bande passante pour tous les autres types de trafic.
Le retard peut être décrit comme un retard unidirectionnel ou un retard bidirectionnel. Le délai unidirectionnel fait référence au temps entre l’envoi d’un paquet et l’arrivée de ce même paquet à l’hôte de destination. Le délai bidirectionnel compte le délai unidirectionnel plus le temps nécessaire au récepteur du premier paquet de renvoyer un paquet – en d’autres termes, le temps nécessaire pour envoyer un paquet entre deux hôtes et en recevoir un. De nombreuses actions individuelles différentes peuvent avoir un impact sur le retard.La gigue fait référence à la variation du délai unidirectionnel entre des paquets envoyés consécutivement par la même application. Par exemple, imaginons qu’une application envoie quelques centaines de paquets à un hôte particulier. Le délai unidirectionnel du premier paquet est de 300 millisecondes (300 ms ou 0,3 seconde). Le délai unidirectionnel du paquet suivant est de 300 ms; il en va de même pour le troisième; etc. Dans ce cas, il n’y a pas de gigue. Cependant, si à la place le premier paquet a un retard unidirectionnel de 300 ms, le suivant a un retard unidirectionnel de 310 ms, et le suivant a 325 ms, alors il y a une certaine variation dans le retard; 10 ms entre les paquets 1 et 2, et 15 ms supplémentaires entre les paquets 2 et 3. Cette différence est appelée gigue.
Type de trafic
La raison qui peut amener un administrateur réseau de prioriser des flux dans un réseau peut être de plusieurs nature. La première des raisons peut être motivé par l’architecture de l’infrastructure informatique. En effet, si les applications critiques de l’entreprise se trouve dans un sous réseau spécifique, l’administrateur réseau peut prendre la décision de prioriser les flux d’entrée / sortie de ce réseau. Dans d’autres cas, le choix de la façon d’appliquer les outils QoS est lié à la nature des différents types d’applications. Certaines applications ont des besoins QoS différents des autres.
Applications de données
Tout d’abord, considérons une application Web de base, avec un utilisateur sur un PC ou une tablette. L’utilisateur saisit un URI pour demander une page Web. Cette demande peut nécessiter qu’un seul paquet soit envoyé au serveur Web, mais elle peut générer le retour de centaines ou de milliers de paquets vers le client Web.
Alors, quel est l’impact de la bande passante, du retard, de la gigue et de la perte sur une application Web interactive? Premièrement, les paquets nécessitent une certaine capacité de bande passante. En ce qui concerne le retard, chacun de ces paquets du serveur au client prend une certaine quantité de retard unidirectionnel, avec également une certaine gigue. La logique TCP du serveur sera de retransmettre les données perdues, ce qui fera que certaines parties de la page Web risquent de ne pas s’afficher immédiatement.
Alors que les outils QoS se concentrent sur la gestion de la bande passante, du retard, de la gigue et de la perte, l’utilisateur se soucie principalement de la qualité de l’expérience globale. Par exemple, avec une application Web, combien de temps après avoir cliqué voyez-vous quelque chose d’utile dans votre navigateur Web? Ainsi, en tant qu’utilisateur, vous vous souciez de la qualité d’expérience (QoE), qui est un terme faisant référence à la perception des utilisateurs de leur utilisation de l’application sur le réseau. Les outils QoS ont un impact direct sur la bande passante, le retard, la gigue et la perte, ce qui devrait alors avoir un effet globalement positif pour influencer la QoE des utilisateurs. Et vous pouvez utiliser les outils QoS pour créer une meilleure QoE pour un trafic plus important; par exemple, vous pouvez donner à certaines applications critiques pour l’entreprise un meilleur traitement QoS, ce qui améliore la QoE pour les utilisateurs de ces applications.
En revanche, une application de données non interactive (historiquement appelée trafic par lots) – par exemple, la sauvegarde de données ou les transferts de fichiers – a des exigences de QoS différentes de celles des applications de données interactives. Les applications par lots envoient généralement plus de données que les applications interactives, mais comme personne n’est assis là à attendre de voir quelque chose apparaître à l’écran, le retard et la gigue n’ont pas beaucoup d’importance. Il est beaucoup plus important pour ces applications de répondre au besoin d’accomplir la tâche plus importante (transfert de fichiers) dans un laps de temps plus large. Les outils QoS peuvent être utilisés pour fournir une bande passante suffisante pour répondre aux besoins de capacité de ces applications et gérer les pertes pour réduire le nombre de retransmissions.
Flux vidéo et voix
Les flux vidéo et la voix s’appuie sur le protocole UDP, qui, comme nous l’avons plus tôt est un protocole pour utiliser pour la priorisation des flux, il n’y aura donc pas de correction d’erreur ce qui peut, potentiellement générer des pertes de paquet.
Pour rappel, l’utilisation des flux vidéo et voix s’appuie sur l’utilisation d’un codec, ce qui revient à traiter l’information avant sont utilisation et qui aura un impact sur le délai de retransmission et sur la gigue. En effet,
Si nous ne prioriserons pas les flux vidéo et voix la QoE sera très largement impacté lorsque nous utilisons ce type de flux. Une vidéo sera de moins bonne qualité, ce qui entrainera une insatisfaction utilisateur, il en va de même si un échange téléphonique devient inaudible. Il devient donc logique d’attribuer une priorisation en utilisant les outils QoS fournit par les équipements réseaux
Outils QoS
Les outils QoS ce compte au nombre des quatre :
- «Classification et marquage» concerne le marquage des paquets et la définition des limites de confiance.
- « La mise en file d’attente » décrit la planification des paquets pour donner à un type de paquet la priorité sur un autre.
- « Stratégie et formatage » sont utilisés aux extrémités opposées d’un lien.
- « La prévention de la congestion » explique comment gérer la perte de paquets qui se produit lorsque les périphériques réseau sont trop occupés
Classification et marquage
Le premier outil QoS discuté dans ce chapitre, la classification et le marquage, ou simplement le marquage, fait référence à un type d’outil QoS qui classe les paquets en fonction de leur contenu d’en-tête, puis marque le message en modifiant certains bits dans des champs d’en-tête spécifiques.
Principes de base de la classification
Les outils QoS s’inscrivent dans le chemin emprunté par les paquets lorsqu’ils sont transmis via un routeur ou un commutateur, tout comme le positionnement des ACL. Comme les ACL, les outils QoS sont activés sur une interface. Tout comme les ACL, les outils QoS sont activés pour une direction: les paquets entrant dans l’interface(avant la décision de transfert) ou pour les messages sortant de l’interface (après la décision de transfert).
Le terme classification fait référence au processus de mise en correspondance des champs dans un message pour faire le choix de prendre une action QoS. Donc, encore une fois en comparant les outils QoS aux ACL, les ACL effectuent la classification et le filtrage; c’est-à-dire que les ACL correspondent (classifient) les en-têtes de paquets. Les ACL peuvent avoir pour but (action) de choisir les paquets à rejeter. Les outils QoS effectuent une classification (mise en correspondance des champs d’en-tête) pour décider sur quels paquets effectuer certaines actions QoS. Ses actions pourront être :
- Mise en attente
- Stratégie et formatage
- Prévention de la congestion
Les commutateurs et les routeurs ont la capacité de créer un marquage qui sera ensuite utilisé pour classifier le paquet. Le marquage peut d’effectuer en entrée ou en sortant de vos équipements réseau. Selon la complexité de la classification, cela peut prendre du temps et des ressources matériels qui pourrait engendrer une dégradation de service de vos réseaux. Il est donc recommandé de marque les paquets dès la conception de son entrée dans le réseau.
Marquage de l’en-tête IP
Le marquage d’un champ QoS dans l’en-tête IP fonctionne bien avec QoS car l’en-tête IP existe pour tout le chemin de l’hôte source à l’hôte de destination. Lorsqu’un hôte envoie des données, l’hôte envoie une trame de liaison de données qui encapsule un paquet IP. Chaque routeur qui transmet le paquet IP rejette l’ancien en-tête de liaison de données et ajoute un nouvel en-tête. Étant donné que les routeurs ne suppriment pas et ne réinsèrent pas les en-têtes IP, les champs de marquage dans l’en-tête IP restent avec les données du premier endroit où ils sont marqués jusqu’à ce qu’ils atteignent l’hôte de destination.
IPv4 définit un octet de type de service (ToS) dans l’en-tête IPv4. La RFC d’origine définissait un champ IP Precedence (IPP) 3 bits pour le marquage QoS. Ce champ nous a donné huit valeurs de 000 à 111 soit en décimale de 0 à 7.
Le concept est encore valable aujourd’hui même si le terme IPP n’est plus utilisé et qu’il a été remplacé par le DSCP qui est un concept introduit dans la RFC 2474. Le DSCP va permettre de faire de la différentiation de service (Diffserv) et par conséquent permettre de classifier le trafic en fonction du service (VOIP, Video, etc). Le champs DSCP pèse 6 octets ce qui nous permet d’avoir 64 valeurs distant.
Marquage de l’en-tête Ethernet 802.1Q
Un autre champ de marquage utile existe dans l’en-tête 802.1Q, dans un champ initialement défini par la norme IEEE 802.1p. Ce champ se trouve dans le troisième octet de l’en-tête 802.1Q de 4 octets, sous la forme d’un champ de 3 bits, fournissant huit valeurs possibles à marquer Il porte deux noms différents : Classe de service ou CoS, et Point de code prioritaire, ou PCP.
Bon à savoir
La champs CoS pourra être utilisé exclusivement sur les liaisons « trunké »
Zone de confiance de marquage DSCP
Le périphérique de l’utilisateur final peut marquer le champ DSCP et même le champ CoS si le trunk est utilisée sur la liaison. En tant qu’administrateur réseau, feriez-vous confiance à ces paramètres par défaut et laisser vos périphériques réseau faire confiance et réagir à ces marquages pour leurs différentes actions QoS?
La plupart d’entre nous ne le feraient pas du fait qu’un utilisateur pourrait avoir la possibilité de modifier le marquage DSCP de son poste client en indiquant par exemple un marquage DSCP 46 qui correspond à une marque dédiée au donnée voix.
Lorsque nous créons un plan de qualité de service, il faudra définir qu’elle DSCP sera de confiance. Par exemple en excluant les PC des utilisateurs. En revanche le téléphone IP sera généralement la limite de confiance.
Les valeurs de marquage suggéré par DiffServ
Les valeurs DSCP sont indiqué dans des RFC, ce qui permet aux constructeurs de l’implémenter directement dans les équipements. Ainsi lorsque sur vous brancherez un téléphone, il sera marqué par une valeur DSCP adéquate pour classifier les flux comme des flux voix. Les DSCP est caractérisé par 3 éléments :
- Transfère accélérer
- Expédition assurer
- Sélecteur de classe
Transfère accélérer
DiffServ définit la valeur DSCP transfère accélérer ou Expedited Forwarding (EF) qui est une valeur unique qui est suggéré pour une utilisation pour les paquets qui nécessitent une faible latence (retard), une faible gigue et une faible perte. La RFC Expedited Forwarding (RFC 3246) définit la valeur DSCP spécifique (décimal 46) et un nom explicite (Expedited Forwarding). Les commandes de configuration QoS permettent l’utilisation de la valeur décimale ou du nom de texte. Pour une facilité de mémorisation, l’utilisation de l’acronyme EF sera utilisé.
Le plus souvent, les plans QoS utilisent EF pour marquer les paquets de charge utile vocale. Avec les appels vocaux, certains paquets transportent des données voix et d’autres paquets transportent des messages de signalisation d’appel. Les messages de signalisation d’appel configurent (créent) l’appel vocal entre deux appareils et ne nécessitent pas de faible délai, gigue et perte. Les paquets transportant les données voix ont besoin d’une meilleure qualité de service. Par défaut, les téléphones IP Cisco marquent la charge utile vocale avec EF et marquent les paquets de signalisation vocale envoyés par le téléphone avec une autre valeur appelé CS3.
Expédition assurer
Le DiffServ RFC (2597) Assured Forwarding (AF) définit un ensemble de 12 valeurs DSCP destinées à être utilisées de concert les unes avec les autres. Premièrement, il définit le concept de quatre files d’attente distinctes dans un système de file d’attente. Ensuite, il définit trois niveaux de priorité de dépôt dans chaque file d’attente à utiliser avec les outils d’évitement de congestion.
Avec quatre files d’attente et trois classes de priorité de suppression par file d’attente, vous avez besoin de 12 marquages DSCP différent.
Les noms DSCP suivent un format AFXY, X faisant référence à la file d’attente (1 à 4) et Y faisant référence à la priorité de suppression (1 à 3).
Par exemple, si nous marquons les paquets avec les 12 valeurs, ceux avec AF11, AF12 et AF13 iraient tous dans la file d’attente A; ceux avec AF21, AF22 et AF23 entreraient dans la file d’attente B, etc… Dans la file d’attente avec tout le trafic AF2y, vous traiteriez les AF21, AF22 et AF23 chacun différemment en ce qui concerne les actions de suppression (évitement de la congestion), AF21 obtenant le traitement préféré à AF23.
Sélecteur de classe
À l’origine, l’octet ToS était défini avec un champ IP Precedence (IPP) de 3 bits. Lorsque DiffServ a redéfini l’octet ToS, il était logique de créer huit valeurs DSCP pour une compatibilité descendante avec les valeurs IPP. Les valeurs DSCP du sélecteur de classe (CS) sont ces paramètres. Fondamentalement, les valeurs DSCP ont les mêmes 3 premiers bits que le champ IPP, et avec des 0 binaires pour les 3 derniers bits, comme indiqué sur le côté gauche de la figure. CSx représente les noms de texte, où x est la valeur IPP correspondante (0 à 7).
Exemple de plan de QoS
DSCP EF: voix
AF4x: vidéo interactive (par exemple, vidéoconférence)
AF3x: vidéo en streaming
AF2x: données à haute priorité (faible latence)
CS0: données standard
Les files d’attentes
Tous les périphériques réseau utilisent des files d’attente. Les périphériques réseau reçoivent des messages, prennent une décision de transfert, puis envoient le message, mais parfois l’interface sortante est occupée. Ainsi, l’appareil garde le message sortant dans une file d’attente, en attendant que l’interface sortante soit disponible.
Le terme mise en file d’attente fait référence à l’ensemble d’outils QoS pour gérer les files d’attente qui contiennent des paquets pendant qu’ils attendent leur tour pour quitter une interface. Dans un routeur, lorsque les paquets sont en file d’attente, le routeur peut être amené à faire des actions sur ce dernier, c’est le cas lorsque que nous avons configurer le NAT ou les ACL où là il y a eu un traitement du paquet. Dans ce cas, la file d’attente n’est pas seulement un sasse d’attente où chaque paquet attends passivement son tour.
Un équipement réseau, comme nous l’avons vu plus tôt peut avoir plusieurs files d’attente. Nous allons donc avoir besoin d’un ordonnanceur pour hiérarchiser et prioriser les files d’attentes.
Ordonnancement Round-Robin
Un des algorithmes utilisé par les routeurs et commutateur CISCO utilise une logique circulaire. Dans sa fonction le plus simple, le round robin parcours les files d’attentes dans l’ordre. Sur chaque file d’attente, il laissera passer un certain nombre de paquet. Le nombre de paquet peut être pondéré. Pour la mise en place de cette pondération, le round-robin va s’appuyer sur un élèment clé des équipement réseau appelé le Class-Based Weighted Fair Queuing (CBWFQ) qui permet d’allouer un minimum de bande passante par classe. C’est en fait la valeur du CBWFQ qui va être pondéré avec un pourcentage.
File d’attente à faible latence
L’ordonnancement à bien des qualités mais il peut poser un problème. En effet, en nous appuyons sur le schéma précédent, imaginons qu’un utilisateur souhaite passer un appel téléphonique juste après que l’ordonnancement à fini de traiter la file d’attente des paquets voix, l’utilisateur devra attendre que l’ordonnanceur Round Robin termine de traiter la file d’attente Vidéo et Data, ce qui entrainera un latence et augmentera la gigue (pour information la téléphonie nécessite une gigue inférieur à 30 ms).
Pour pallier cela, nous nous appuierons sur la technologie de la file d’attente à faible latence, plus souvent appelé LLQ (Low Latence Queuing). Cette technologie permettra de marquer des paquets en flux prioritaire et ne sera pas concerné par l’ordonnanceur.
Là aussi nous avons un problème, en effet imaginons que la file d’attente voix dans l’illustration précédente ait toujours du flux en continu, cela ne laissera pas de place pour les autres flux. Nous devrons donc mettre en place une stratégie de gestion des flux. Nous verrons ce point dans le chapitre suivant.
Stratégie et formatage
La régulation et la mise en forme surveillent le débit binaire des messages combinés qui transitent par un périphérique. Une fois activé, le régulateur ou le shaper (pour le formatage) note chaque paquet qui passe et mesure le nombre de bits par seconde au fil du temps. Les deux tentent de maintenir le débit binaire à ou en dessous de la vitesse configurée, mais en utilisant deux actions différentes: les régulateurs rejettent les paquets et les shaper maintiennent les paquets dans des files d’attente pour retarder les paquets.
Les shaper et les régulateurs surveillent le débit de trafic (les bits par seconde qui se déplacent dans le shaper ou le régulateur) par rapport à un débit de mise en forme ou à un taux de régulation.
Evitement de la congestion
La fonctionnalités évitement de la congestion s’appuient sur les segments TCP. Pour rappel, le protocole TCP, permet de faire de la correction, c’est-à-dire, de récupérer les paquets perdus. En prenant en considération, cette particularité du protocole TCP, un paquet pourra être supprimé de sa file d’attente pour libérer de la place et pourra être redemander par le biais du protocole TCP.
Le faites de supprimer des paquets de la file d’attentes permettra d’éviter de la congestion, c’est à dires des « embouteillage » de données. Ainsi nous pourrons définir que nous ne devons pas dépasser un taux de remplissage de la file d’attente.
Mise en place d’une QoS
Pour la mise en place de ce lab, nous utiliserons Cisco Packet Tracer, ce qui nous évitera de déployer des outils de téléphonie sur IP ou encore de la vidéo par IP.
Dans ce schéma, nous avons 3 Vlan distinct, un vlan voix, vidéo et données. Nous pouvons voir que le commutateur SW1 est un point de congestion. Comme pour un carrefour routier, nous allons y intégrer des règles. Le vlan voix sera paramétré avec le LLQ, le vlan vidéo et données par le biais du CBWFQ en réservant 60 % de la bande passante pour la vidéo et 40 % pour la donnée. Nous créerons 2 files d’attentes et nous laisserons le vlan data avec la configuration par défaut.
Sur le commutateur, seul les VLAN sont créés et les ports configurés soit la configuration suivante.
Switch>enable
Switch#configure terminal
Switch(config)#hostname SW1
SW1(config)#vlan 2
SW1(config-vlan)#name VOIX
SW1(config-vlan)#vlan 3
SW1(config-vlan)#name VIDEO
SW1(config-vlan)#vlan 4
SW1(config-vlan)#name DATA
SW1(config-vlan)#interface range gig 1/0/1-2
SW1(config-if-range)#switchport mode access
SW1(config-if-range)#switchport voice vlan 2
SW1(config-if-range)#interface range gig 1/0/3-4
SW1(config-if-range)#switchport mode access
SW1(config-if-range)#switchport access vlan 3
SW1(config-if-range)#interface gig 1/0/5
SW1(config-if)#switchport mode access
SW1(config-if)#switchport access vlan 4
SW1(config-if)#interface gig 1/0/6
SW1(config-if)#switchport trunk encapsulation dot1q
SW1(config-if)#switchport mode trunk
SW1(config-if)#switchport trunk allowed vlan 2-4 Dans cette configuration, nous pouvons noter que sur les interfaces Gig 1/0/1 et Gig 1/0/2, nous précisons que c’est un vlan voix. De plus, vous aurez remarqué qu’une liaison trunk est créer entre le routeur et le commutateur. En effet, c’est notre routeur qui hébergera nos passerelles. De plus sur le routeur, nous configurerons un serveur DHCP.
Router>enable
Router#configure terminal
Router(config)#interface fa0/0
Router(config-if)#no shutdown
Router(config-if)#interface fa0/0.2
Router(config-subif)#encapsulation dot1q 2
Router(config-subif)#ip address 192.168.0.254 255.255.255.0
Router(config-subif)#interface fa 0/0.3
Router(config-subif)#encapsulation dot1q 3
Router(config-subif)#ip address 192.168.1.254 255.255.255.0
Router(config-subif)#interface fa 0/0.4
Router(config-subif)#encapsulation dot1Q 4
Router(config-subif)#ip address 192.168.2.254 255.255.255.0
Router(config-subif)#ip dhcp pool VLAN2
Router(dhcp-config)#network 192.168.0.0 255.255.255.0
Router(dhcp-config)#default-router 192.168.0.254
Router(dhcp-config)#ip dhcp pool VLAN3
Router(dhcp-config)#network 192.168.1.0 255.255.255.0
Router(dhcp-config)#default-router 192.168.1.254
Router(dhcp-config)#ip dhcp pool VLAN4
Router(dhcp-config)#network 192.168.2.0 255.255.255.0
Router(dhcp-config)#default-router 192.168.2.254
Router(dhcp-config)#ip dhcp excluded-address 192.168.0.254
Router(config)#ip dhcp excluded-address 192.168.1.254
Router(config)#ip dhcp excluded-address 192.168.2.254 Pour la partie téléphonie sur IP nous allons configurer le call manager.
Router(config)#telephony-service Nous allons ensuite indiquer le nombre de téléphone maximum qui pourra être supporté par le call manager. Ici, nous avons 2 téléphones, c’est donc cette valeur que nous allons renseigner.
Router(config-telephony)#max-ephone 2Nous allons également indiquer combien de numéro privé nous allons gérer
Router(config-telephony)#max-dn 2Nous indiquons l’adresse serveur de notre call manager ainsi que son port d’écoute
Router(config-telephony)#ip source-address 192.168.0.254 port 2000Nous allons également créer nos téléphones, ainsi le téléphone demandera au call manager une configuration, cela évitera de configurer manuellement les téléphones. Ici, nous allons configurer 2 numéros de téléphone privé
Router(config-telephony)#auto assign 1 to 2Router(config-telephony)#ephone-dn 1
Router(config-ephone-dn)#number 100
Router(config-ephone-dn)#ephone-dn 2
Router(config-ephone-dn)#number 101Pour que les téléphones puissent récupérer cette configuration (TFTP), nous devons ajouter une option dans l’étendue VLAN2.
Router(config-subif)#ip dhcp pool VLAN2
Router(dhcp-config)#option 150 ip 192.168.0.254Noter que l’option 150 du DHCP permet d’indiquer une liste d’adresse IP de serveurs TFTP. C’est une particularité du Call Manager. Bien souvent chez d’autres éditeurs de solution VoIP, vous ne pourrez renseigner qu’une seule adresse (ou nom de machine) TFTP. Dans ce cas, il faudra utiliser l’option 66.
Les téléphones devraient maintenant être correctement configuré est avoir un numéro.
Le premier avec le numéro 100 et le second avec le numéro 101.
Pour le Vlan vidéo, il y aura donc une caméra, qui est un IoT, il nous faudra donc un serveur (passerelle IoT), c’est la raison pour laquelle, vous avez un serveur dans ce VLAN. Avant de commencer à configurer le serveur pour notre IoT, prenez en considération les adresse IP suivantes :
- Caméra : 192.168.1.1
- Serveur : 192.168.1.2
Sur Packet Tracer, fait un double-clic sur le serveur, puis dans la fenêtre de configuration du serveur, rendez-vous dans l’onglet « Services ». Dans le menu latéral, sélectionner « IoT » est activé le service. Une fois que cela est fait, vous pouvez fermer la fenêtre.
Rendez-vous maintenant sur l’onglet « Desktop » puis sélectionner l’outil « Web Brower »
Dans le champ « URL » renseigner l’adresse IP du serveur précédé de http://. Puis créer un compte en cliquant sur le lien « Sign up now »
Indiquer ensuite un nom d’utilisateur et un mot de passe, puis valider en cliquant sur le bouton « Create »
Une fois le compte créer, nous allons configurer l’IoT (webcam). Pour cela, nous devons faire un double-clic sur la caméra, puis nous rendre dans l’onglet config. En bas de la partie principale, sélectionner « Remote Server » est renseigné les champs Server Adresse, Admin, Password. Terminer par cliquer sur le bouton « Connect »
Retourner sur l’interface Web de votre serveur IoT, vous devrez voir votre Webcam. Cliquer sur bouton « Rouge » Pour allumer votre « Webcam »
QoS VLAN VOIX
Sans rentrer dans le détail la voix sur IP se fait en deux temps :
- Signalisation avec le protocole SIP ou SCCP
- L’envoie des flux voix (RTP)
QoS Signalisation
Vu que nous utilisons CISCO Packet tracer le protocole de signalisation qui est utilisé est le SCCP.
En nous référant à la RFC 2474, nous marquerons les paquets de signalisation, c’est à dire le protocole SCCP avec un DSCP 40 (101000) soit un Classe Selector de 5.
Sur le commutateur, nous commencerons par classifier les paquets SCCP, on créera une classe map que l’on nommera QoS_SCCP
SW1(config)#class-map QoS_SCCP
SW1(config-cmap)#match protocol skinny
SW1(config-cmap)#exitNous créerons une stratégie qui s’appliquera sur la classe QoS_SCCP que nous avons précédemment créer.
Dans cette stratégie, nous indiquons le code 40 du service de la différentiation de service (DSCP), ce qui se traduit par la valeur CS5.
SW1(config)#policy-map strategie_qos
SW1(config-pmap)#class QoS_SCCP
SW1(config-pmap-c)#set ip dscp cs5Pour terminer, nous indiquerons à notre commutateur que cette stratégie s’appliquera pour tous les paquets qui sortirons par l’interface gig 1/0/6.
SW1(config-pmap-c)#interface gig 1/0/6
SW1(config-if)#service-policy output strategie_qosPour vérifier que la configuration fonctionne bien, sur Cisco Packet Tracer, nous passerons en mode simulation, puis nous cliquerons sur le bouton « Show All/None ».
Puis sur le bouton « Edit Filters »
Dans l’onglet « Misc », cochez « SCCP »
Cliquer ensuite sur le premier téléphone et appeler le second.
Dans les outils Play Control appuyer 1 fois sur le bouton (Capture then Forward)
L’enveloppe SCCP doit être sur le Switch. Ouvrez cette enveloppe en faisant un double-clic dessus, puis rendez-vous sur l’onglet « Inbound PDU Details », qui est le message d’entrée. Nous voyons que le DSCP à une valeur de 0x00 donc un CS0.
Intéressons-nous au PDU de sortie, celle qui doit être modifier par la configuration que nous avons mis en place. Cliquons sur l’onglet « Outbound PDU Details », nous constatons que le DSCP à une valeur hexadécimal de 28 soit en binaire 101000, c’est-à-dire CS5. La stratégie que nous avons mis en place est donc bien fonctionnelle.
QoS des flux voix
Comme nous l’avons indiqué le protocole pour le transport de la voix est le RTP (Real-Time Protocole). Nous allons donc créer une classification s’appuyant sur ce protocole puis nous ajouterons cette classe à la stratégie précédemment créer.
Ici, la stratégie sera de faire du LLQ Latence Low Queuing, c’est-à-dire faire un marquage EF (Expedition forwarding)
SW1(config-if)#class-map QoS_RTP
SW1(config-cmap)#match protocol rtp
SW1(config-cmap)#policy-map strategie_qos
SW1(config-pmap)#class QoS_RTP
SW1(config-pmap-c)#set ip dscp ef
SW1(config-pmap-c)#bandwidth 2000Noter que nous allouons une bande passante de 2Mb/s, cette limite permettra de laisser passer les autres flux à un moment données (La bande passante pour la VoIP se calcul en prenant en compte les codecs utilisées, si nous utilisons le codec G.711, avec 2Mb/s nous pourrions avoir 20 conversation téléphonique en simultanées en considérant que la bande passant est de 100 kb/s )
QoS VLAN VIDEO
Ici, nous nous baserons sur le VLAN et non plus sur le protocole, nous allouerons à ce VLAN 60 % de la bande passant laissant ainsi les 40 % restant pour le VLAN Data.
Nous devons observer la même logique que celle utiliser pour le VLAN Voix, c’est-à-dire :
- Classifier
- Définir la stratégie à cette classe
- Indiquer l’interface concernée.
Ici, nous ne classifierons pas par protocole mais par adresse IP. Il nous faut créer une liste de nos adresses. Nous créerons donc une ACL étendue.
SW1(config)#access-list 100 permit ip 192.168.1.0 0.0.0.255 anyNotre ACL, nous permettra de classifier toutes les machines du VLAN 3, dans une classe que nous appellerons QoS_VIDEO.
SW1(config)#class-map QoS_VIDEO
SW1(config-cmap)#match access-group 100Nous allons maintenant créer la stratégie pour cette classe.
SW1(config-pmap)#policy-map strategie-video
SW1(config-pmap)#class QoS_VIDEO
SW1(config-pmap-c)#set ip dscp af31
SW1(config-pmap-c)#priority percent 60Ici, nous utiliserons le dscp af qui nous permet assurer l’envoie de la trame. La priorité de la file d’attente est de 3 sur 4. Ce choix est dû au fait que nous réserverons la priorité 4 aux vidéos interactifs, comme de la visio (Microsoft Teams, Cisco Webex, ZOOM). Ici, nous somme plus sur de la vidéo surveillance. Nous indiquerons tout de même une priorité 1 qui est la plus basse concernant la priorité de suppression du paquet.