Bonjour,
 
J'aimerais que certains puissent éclairer mon esprit sur la QoS dans la mise en place de la ToIP.
Je vais utiliser des switchs Cisco et IPBX + téléphones IP Alcatel.
J'ai vu qu'il y avait différentes manières de faire de la QoS : Intserv, Diffserv, paquets classifié, policiés, marqués, ....    
Toutes ces méthodes sont différentes ou s'additionne ?
 
Bref merci à tous

Petit up !!
 
Je me suis renseigné sur les mécanismes de QoS (qui s'ajoutent dans certains cas !!).
 
Par contre j'avais une question : selon vous, la qos est-elle nécessaire lorsque l'utilisation de la ToIP est faite en locale (LAN 100MBits) ?
 
Merci d'avance

Salut,
 
Je pense qu'elle n'est pas nécessaire à tous les coups sur le LAN. Cela dépend si tu as des pics de charge sur ton LAN qui sature complètement tes switches et si tu as des grosses interconnexions sur des LANs étendus et qu'elles sont très sollicitées.
 
En fonction du profil de ton LAN, tu devras ou non implémenter de la QoS sur ton LAN. Pour ma part, je pense que ce n'est pas un impératif à la base.

si, il faut le faire, meme en LAN. La téléphonie reste la téléphonie, les utilisateurs ne tolèrent pas la moindre perturbation.
Pour ca, surtout avec des cisco, c'est facile.
Tu place le COS à 5 sur les ports ou tu mets des IP Phone, et c'est réglé.
C'est facile, et ca permet de prioritiser le trafic voix.
Par contre, sur un lan, t'amuse pas avec diffserv, policy-based qos et autres principes de QoS qui sont plus orientés WAN.

Vu les débits actuels disponibles sur le LAN et les performances des équipements, je ne pense vraiment pas que ce soit nécessaire partout. A mon sens, il y a bon nombres de LAN moyens qui sont largement sous-utilisés, et qui peuvent donc laisser la place au trafic voix sans que celui-ci soit altéré par le reste.  
 
Après, c'est sûr que ça ne coûte pas grand chose d'en faire sur du Cisco (sauf si c'est inclus dans de la prestation), mais je ne suis pas vraiment convaincu de son intérêt dans pas mal d'environnements.

ça sert sur le LAN le jour où t'as une merde (un virus qui blaste le réseau ou autres), la voix reste prioritaire.

meme pas forcement une merde, tu as régulièrement des congestions sur un LAN, mais c'est tout a fait transparent pour du trafic standard.
Par contre, pour la voix, ca peut poser des problèmes.
Je prends le risque de me répéter : les utilisateurs ne pardonnent jamais des perturbations du système téléphonique.

Un multicast mal géré et on en reparle de pas mettre de qos sur un lan...
A titre perso, je recois comme il faut les pros qui viennent me dire que de la qos sur un lan pour la toip ca sert a rien. Ils se font aimablement allumer avec des exemples précis, et je leur demande benoitement si ils viendront s'expliquer devant les users ce jour la

Je suis d'accord avec vous au niveau des utilisateurs; surtout que dans mon cas, on va passer de la téléphonie "classique" à la téléphonie IP. Donc les utilisateurs s'attendent à avoir la même qualité !!
 
Je vais le mettre en place en prévention
 
A tout hasard, quelqu'un l'aurait mis en place sur du Cisco ? Car la doc est un peu flou pour moi !
 
Merci à tous pour vos réponses

auto qos voip

Humm ... auto qos ca me dit pas trop ...
Je préfère avoir le contrôle et savoir ce que je fais !! Jamais eu trop confiance dans les mécanismes auto ...

Ca t'évite de te palucher a la main les mappages l2/l3 et la gestion des files d'attentes.
C'est l'interet d'avoir du full cisco. cdp et auto qos ftw.
L'important c'est de comprendre ce qui se passe par derriere. Mais l'interet de tout se taper a la mano je vois pas trop.

Oui mais je ne suis pas en full Cisco Les téléphones sont des Alcatel.
 
Mais l'auto qos est réellement opérationnelle ?

Ca changera pas grand chose si tu fais ce qu'il faut sur ton OXE (ou OXO?)
Pas de cdp dispo donc soit tu paramètres tes téléphones a la main, soit tu utilises l'AVA (pour les vlans).
Il faut définir dans tes domaines IP de l'OXE le marquage L2/L3. Le mieux est de réutiliser les marquages que préconise cisco. En 802.1p c'est 5 mais pour le dscp je crois pas qu'ils utilisent la valeur 46. Dreamer18 doit connaitre ca par coeur, sinon ca se trouve sans pb sur leur site.
Ainsi tes téléphones parleront dans le bon vlan avec les bons marquages. Ensuite je pense que l'auto qos devrait donner les memes résultats meme si c'est un téléphone alcatel.
Sinon a toi les cos to dscp map, wrr etc

Encore une petite question ..
Dans la doc Cisco, voilà comment il présente la commande auto qos : auto qos voip {cisco-phone | cisco-softphone | trust}
Le trust est utilisé lorsque le port est connecté à un routeur / switch trusted.
 
Dois-je en déduire que seul les équipements Cisco sont compatibles ?
 
Merci beaucoup

sur le port en question, il te suffit de faire
switchport priority extend cos 5
C'est tout.
Ces histoire de mappage l2/l3, et autre queues ...
Dans le moteur meme du switch, la COS L2 est implémentée de base, donc tu set le champ dans ta trame, et le reste est géré nativement ....

Faudra que tu m'expliques comment tu te passes de mappage l2/l3 dans un contexte multisite, sachant que très souvent l'opérateur ne monte pas de trunk avec le réseau local du client... C'est pas tiptop pour gérer la qos de se baser sur les @IP/ports udp-tcp.

et chérie ... tu peux répondre a la question du monsieur ??
"Par contre j'avais une question : selon vous, la qos est-elle nécessaire lorsque l'utilisation de la ToIP est faite en locale (LAN 100MBits) ? "
On peut se lancer dans de grands débats QoS, personnellement je suis assez ouvert .. mais ou sera l'intérêt, vu qu'il s'en cogne ?

J'avais zappé son 2eme message, effectivement ca règle en partie le pb.
Par contre je reste "ferme" sur le fait qu'il faut un queeing dédié au flux voix, ne serait-ce que pour se protéger de floods non maitrisés (type ghost multicast, deja vu et ca fait mal à la voix)

 
Donc c'est simplement le champs COS ?
Pas de traitement des queues ingress et egress, politique, ... ?
 
Encore merci ^^

non, le switch gere ca nativement.
Pour la gestion plus fine des queues, sauf si tu avais un reseau complexe, tu n'en as pas besoin.

juju : bah oui, mais en lan, gereant settant le COS pour les flux voix suffit a régler le problème. Tu as lu ma réponse ?

Oui j'ai lu ta réponse mais je vois pas ce que la commande switchport priority extend cos 5 toute seule va apporter au final. Tu forces le port physique à marquer tous les flux qui en sorte à 5.
Si tu n'as pas de file dédiée pour ta cos 5 ca n'est pas suffisant. Generalement il y a 8 files par ports et il y a un mappage entre ces files et le 802.1p. C'est la qu'il faut vérifier que la cos 5 se trouve bien dans une file qui lui est réservée et a laquelle on alloue une bp garantie. Je sais pas si c'est natif chez cisco mais chez enterasys il vaut mieux fixer soit meme la bp par file, sinon on tombe dans un algo wrr qui sera pas tiptop en cas de flood important sur le réseau...

"auto qos"

 
oui mais pour des téléphones Alcatel ...
 
Sinon voilà ce que j'ai fait :
1. Activation de la QoS :

2. Classement des paquets en entrée :

3. Réglage des files d'entrée :

Merci pour vos remarques

juste une question tu est parti sur un BIV de chez OBS ? car tu peux leurs demander de gérer la Qos si c'est cela.

@keke man : attention avec le qos trust dscp. Normalement si on veut faire les choses dans les règles de l'art on force la réécriture du champ dscp.
En effet ya des applis sur PC qui envoie des trames avec du dscp taggué... Certains jeux videos le font et tu peux te retrouver a prioriser du flux a la con sans vraiment l'avoir voulu.
Les amis qui déploient de la toip en université ne trust jamais la qos et forcent la réécriture au niveau du port réseau.
Je sais que sur les postes IP cisco on peut leur dire de ne pas faire confiance a ce que le pc envoie. Avec de l'alcatel je n'ai pas regardé.
Si t'es en entreprise t'as pas trop besoin de te prendre la tete avec ca, mais si c'est dans une école/université etc... gaffe aux ptits malins

Oui mais forcer la réécriture du port, sachant qu'il y a un PC derrière le téléphone, le problème est encore là .. Je vais essayer de regarder pour les téléphones Alcatel, on sait jamais
 
De toute façon je préfère forcer la réécriture. Je pense faire une ACL pour la plage d'IP réservée aux téléphones. Je vais regarder et surement vous la poster pour savoir ce que vous en pensez ^^
 
Merci encore

Alors voilà ce que je me disais .. Faire des ACL suivant l'IP ..
 

 
Ce que j'ai du mal à comprendre, c'est comment le switch ne va pas prioriser un flux venant du PC avec une valeur de dscp égale à celui provenant du téléphone ??
 
Merci d'avance

parce que ce que tu fais la c'est des ACL layer 3.
Ca repond pas a ton besoin. Tu geres des queue en fonction d'ACL.
Pour que ca fonctionne, il faut que tu l'applique a l'interface ( layer 3 ) d'un routeur; et ca ne fonctionnera que pour le trafic routé.
Pourquoi ma solution efficace et bien plus simple ne te plait-t-elle pas ? pas assez compliquée ?

@trictrac : ya pas le risque que les flux data du PC derriere le poste IP beneficient aussi du marquage L2 a 5? Dans ce cas on transfert le pb vers la couche 2 et on a pas bcp avancé...?

si, c'est le risque, mais avec des IPPhones alcatel, j'ai pas trouvé de solutions simples (dans la mesure ou très peu de PC sont connectés derrière le Tel chez moi, pas trop de prob dans mon cas pratique).

 
Nan ce n'est pas ça .. Mais dans la doc Cisco, j'ai trouvé pour ce "switchport priority extend cos 5" : "Sets the priority of data traffic received from the IP Phone access port. The cos value will tell the phone to override the priority received from the PC or attached device with a CoS value of 5." C'est pas ce que je recherche !!
 
Pour ce qui est du traffic du PC derrière le téléphone, je ne vois pas vraiment de solution .. Après je ne pense pas que beaucoup d'applications utilisent cette valeur de COS ..
 
Bref c'est un peu le flou

Ben j'ai vraiment eu aucun soucis sur mon LAN enterasys avec les postes alcatel perso...  
Pour rappel il faut modifier les caractéristique du/des domaines IP (via les index de qualité de service) pour définir les valeurs cos/dscp.
Ensuite les téléphones marqueront automatiquement les flux sans qu'il n'y ai rien à faire => flux voip 5/46, flux data du pc derriere rien (ni lvl2, ni lvl3).
Donc sur le port de ton switch tu obtiens les flux voix comme il faut. Par contre tu peux te retrouver avec une appli à la con sur le PC qui va aller modifier le TOS. Si tu maitrises bien ton parc pas de soucis, sinon il va falloir gérer ces flux. La solution que je vois est de faire une acl de lvl3 pour détecter les PC, et ensuite de créer une policy qui forcera la réécriture du TOS à 0 en la mappant sur ton acl. Ensuite tu appliques cette policy à chaque port physique des switchs ou il y a des téléphones et c'est réglé.
Reste enfin à gérer tes files d'attentes en collant la cos 5 dans une file dédiée et en lui affectant ensuite une bp minimale garantie.
C'est pas si compliqué que ça.
Naturellement le sniffer reste le juge de paix pour valider que tout est ok au final
 
Méfiance pour les cartes intip/GD/PCS et callserver. Il faut modifier en hard sur les cartes les paramètres de QoS et ca nécessite un reboot du matos dans la foulée. J'ai du lutter avec l'acse d'obs pour qu'il finisse par le faire

Et serait-ce trop demandé d'avoir un exemple de conf pour la gestion des files d'attente ?
 
Merci !

La CLI est toute simple sur mon matos :
set port priority-queue fe.1.1 y z
Sur le 1er port fe du 1er switch de la stack j'indique qu'il doit mapper la priorité 802.1p y sur la file z. Sachant que j'ai 8 files mais que 6 dispos vu que 2 dernieres sont réservées par le système (cisco fait pareil).
Ensuite j'affecte une BP à chaque file sur un port :
set port txq fe.1.1 0 10 20 30 40 0
J'indique que sur le port la file 0 aura 0% de bp, la file 1 10% etc
L'algo est du wrr, et à partir du moment ou un seul octet se présente dans la file immédiatement l'intégralité de la bp définie est réservée. C'est certes pas l'optimum mais pour du LAN classique c'est amplement suffisant. Le 0 est l'équivalent du best effort.