QOS et VOIP

QOS et VOIP - Réseaux - Systèmes & Réseaux Pro

Marsh Posté le 11-03-2009 à 11:13:30    

Bonjour à tous,
je post car je suis en train de m'arracher les cheveux sur la QOS et la VOIP... Autant par moment je n'ai aucun problème autant par moment j'ai des sacrés soucis de hachure de la voix lors des appels en inter sites.
Déja je présente mon réseaux :
Les parties VOIP sont sur des réseaux différents de nos réseaux DATA.
http://merguez.free.fr/VOIP.JPG
la même chose mais via l'url http://merguez.free.fr/VOIP.JPG
 
Les PABXs et les serveurs de messagerie vocale ont une patte sur le réseaux dédiés VOIP et une patte sur le réseaux DATA.  
 
J'ai crée un VLAN voix sur le Switch 4208 et sur le switch 2626 principal de l'autre coté en me basant sur les ports physique utilisés. J'ai mis dedans les IPBXs et les serveurs mevo + le firewall. Ces ports sont taggés.  
 
Les vlans DATA comprennent tous les ports ( même ceux des ipbx, des serveurs de mevo , et du firewall ) mais en untagged.
 
Le VPN est monté par les 2 firewalls SonicWall Via les connexions COLT (2M/2M).
J'ai priorisé la VOIX sur les firewalls dans les règles( 20% min à 40% max du débit ( 2M)). Les liens COLT ne sont pas des liens dédiés au VPN. Ils servent pour le FTP et les mails.
J'ai priorisé la VOIX sur les switchs principaux en priorisant les vlan voix et en priorisant les ip des IPBX. Le type of service sur les switchs est en differencial services.
 
Lors d'un appel en intersite je voix bien les 2 IPBX discuter entre eux sur les firewalls en H323.
 
bref tout ca me parait bien mais ca continue a merder de temps a autres...  
une id ? une remarque ?
 
Je me pose la question suivante : est il nécéssaire de mettre le port du firewall dans le vlan de la téléphonie pour le priorisé aussi ?  
A votre avis faudrait il que je vois avec colt pour priorisé la voix sur leur routeur chez nous ? en sachant qu'elle doit etre encapsuler dans le vpn ?
merci d'avance de vos avis et de vos réponses...

Reply

Marsh Posté le 11-03-2009 à 11:13:30   

Reply

Marsh Posté le 11-03-2009 à 12:25:58    

Salut,
 
Je trouve ton archi quelques peu étonnante. Quelle est la passerelle par défaut de tes postes IP ? Pourquoi ne pas avoir fait une interconnexion entre ton switch Linksys et ton switch HP et propager tes VLANs Data et Voix jusqu'au Linksys ?  
 
Quels sont les codecs utilisés lors des communications intersites (G711, G729 ...) ? Combien de communications simultanées intersites as-tu au max ? As-tu vérifié que tes policies de QoS étaient bien appliquées au niveau de ton SonicWall avant l'encapsulation dans le tunnel IPSEC et comment ont-elles été définies (marquage DSCP ...)


Message édité par Pandinus2k4 le 11-03-2009 à 12:30:59

---------------
Le blog des nouvelles technologies réseaux, télécoms et du domaine de la sécurité
Reply

Marsh Posté le 11-03-2009 à 14:21:11    

Bonjour Pandinus2K4,
En fait si l'architecture est celle ci c'est tout simplement car au début le premier site a été equipé comme ca, il n'y avait pas d'interconnection de prévu entre les 2 sites et pas d'interconnexion entre la partie voix et la partie data ... Du coup les postes IP discute qu'avec leurs IPBXs qui lui retransmet a l'autre IPBX en cas de communication intersite ( ca je le voix bien sur le firewall lors d'une comme , c'est l'ip de l'IPBX qui dialogue avec l'autre )
Pour les communications je crois qu'on est en G729 (8K), il y a normalement maximum 4 communications intersites simultanés ( et c'est rare).  
Pour ce qui est des policies de QoS , elles ont été définies en 802.1p avec une priorité 6 sur les switchs. Je renforce la priorisation sur les Sonicwall en 802.1p en 6.
voila...

Reply

Marsh Posté le 11-03-2009 à 14:53:15    

Sans même se pencher sur ton archi LAN, comment peux-tu envisager de la voip sans QoS sur les liens WAN, qui possèdent la bande passante la plus faible ?
 
Ticket Colt pour activation d'un pack QoS Voix (je sais pas comment ça marche chez eux) avant de réfléchir plus loin...

Reply

Marsh Posté le 11-03-2009 à 14:56:29    

As part que la voix est encapsulé par le tunnel ipsec ... donc je suis pas sur que le pack QoS voix serve a quelques chose ici

Reply

Marsh Posté le 11-03-2009 à 15:05:46    

Ah, ce que tu appelles VPN, c'est un tunnel qui tu as fait toi meme avec une connexion Internet.
Pas de QoS de bout en bout, c'est foutu. Tu ne maitrises que ton upload sur chaque site, tu ne peux pas obtenir de solution satisfaisante avec ton archi.

Reply

Marsh Posté le 11-03-2009 à 15:10:22    

C'est pas une banal connexion internet c'est du SDSL avec un débit garantie 2Mo/2Mo.

Reply

Marsh Posté le 11-03-2009 à 16:09:50    

dr4g0n69100 a écrit :

C'est pas une banal connexion internet c'est du SDSL avec un débit garantie 2Mo/2Mo.


Ca change rien. Tu serai sur le meme PE ca pourrait aller mais si tes sites sont sur 2 villes différentes tu transites par le backbone de l'opérateur, et comme tu montes toi meme ton VPN en IPsec... Qu'il y ait de la voix ou de la data qui passe dedans, l'opérateur n'en sait rien et s'il s'en fout.
Donc c'est normal que tes coms intersite merdent parfois. Si tu veux que ca marche il faut la classe voix sur le réseau de colt
 
Je sais pas si ILBC a été porté sur Avaya, si c'est le cas tente ton coup le codec est plus robuste. Sinon tu l'as dans l'os ^^
 
Ps : meme avis que ci-dessus, l'archi n'est vraiment pas belle :/


---------------
Jujudu44
Reply

Marsh Posté le 11-03-2009 à 16:21:32    

A prioris pas de ILBC :/
En fait les sites sont a 400 m l'un de l'autre a vol d'oiseau ... malheureusement en vrai ils ont d'un coté et l'autre d'un fleuve et on es pas sur le même dslam....
Effectivement l'archi est pas la meilleurs maintenant faire tout propre était trop contraignant pour juste mettre en place la téléphonie...
( et encore vous avez pas vu les brouettes que j'ai dégagé ... du NT4 pour des architectes c'est pas terrible :) )
Je vais tenté de voir si on peut faire quelques choses avec colt...

Reply

Marsh Posté le 11-03-2009 à 17:03:10    

Même si tu es sur le même PE, tu seras toujours géné par le download sur chaque lien Internet, que tu ne peux pas maitriser et qui entraine augmentation du délai, gigue voire perte de paquets.

Reply

Marsh Posté le 11-03-2009 à 17:03:10   

Reply

Marsh Posté le 11-03-2009 à 18:48:51    

Si il est sur le meme PE (pas garanti) il devrait pas être trop emmerdé, le transit est très réduit et on emprunte pas le backbone
Il peut gérer la congestion lui même sur ses FW en paramétrant correctement le rate limiting et cie
 
Maintenant si tes sites sont en vue directe ca peut valoir le coup de penser Hiperlan ou Laser ;)

Message cité 1 fois
Message édité par jujudu44 le 11-03-2009 à 18:49:59

---------------
Jujudu44
Reply

Marsh Posté le 12-03-2009 à 09:48:39    

et pourquoi pas demander l'option à Colt pour du MPLS et t'y colles une option QOS.

Reply

Marsh Posté le 12-03-2009 à 10:37:46    

C'est certainement le mieux mais c'est pas le meme prix :o


---------------
Jujudu44
Reply

Marsh Posté le 12-03-2009 à 11:23:04    

jujudu44 a écrit :

Si il est sur le meme PE (pas garanti) il devrait pas être trop emmerdé, le transit est très réduit et on emprunte pas le backbone
Il peut gérer la congestion lui même sur ses FW en paramétrant correctement le rate limiting et cie
 
Maintenant si tes sites sont en vue directe ca peut valoir le coup de penser Hiperlan ou Laser ;)


Dans le cas où il ne fait QUE de la voip, pas de problème. Mais il fait aussi passer son trafic Internet sur ses lien (FTP...). Donc non, ça ne va pas.
 

edouardj a écrit :

et pourquoi pas demander l'option à Colt pour du MPLS et t'y colles une option QOS.


Du MPLS, ce n'est q'une techno. Je bosse pas chez Colt, mais il y a fort à parier que leur backbone soit MPLS et qu'il est déjà dessus... Il a besoin d'une liaison VPN inter-site, sur laquelle il pourra s'affranchir de l'ipsec et mettre en place les mécanismes de QoS de bout en bout.
 

jujudu44 a écrit :

C'est certainement le mieux mais c'est pas le meme prix :o


C'est surtout la seule solution potable.

Reply

Marsh Posté le 12-03-2009 à 12:03:52    

AirbaT a écrit :


Dans le cas où il ne fait QUE de la voip, pas de problème. Mais il fait aussi passer son trafic Internet sur ses lien (FTP...). Donc non, ça ne va pas.
 


 
Ben si ça va.
Le contrôle de congestion est effectué sur les équipements du client, il suffit d'appliquer le modèle diffserv de chaque coté (on va pas rentrer dans les détails techniques).
Certains boites ne retiennent pas les classes de services quand elles sont sur une zone géograhique proche. Des boitiers ipanema et cie bien paramétrés donnent des resultats excellents et la voix est nickel alors qu'il y a zero QoS sur le backbone opérateur.
La classe que tu payes c'est pour assurer un traitement spécifique des flux sur le réseau de l'opérateur. Maintenant si le transit est très court t'en a pas vraiment besoin et la QoS tu la gères toi meme...

Message cité 1 fois
Message édité par jujudu44 le 12-03-2009 à 12:20:06

---------------
Jujudu44
Reply

Marsh Posté le 12-03-2009 à 12:32:26    

jujudu44 a écrit :


 
Ben si ça va.
Le contrôle de congestion est effectué sur les équipements du client, il suffit d'appliquer le modèle diffserv de chaque coté (on va pas rentrer dans les détails techniques).
Certains boites ne retiennent pas les classes de services quand elles sont sur une zone géograhique proche. Des boitiers ipanema et cie bien paramétrés donnent des resultats excellents et la voix est nickel alors qu'il y a zero QoS sur le backbone opérateur.
La classe que tu payes c'est pour assurer un traitement spécifique des flux sur le réseau de l'opérateur. Maintenant si le transit est très court t'en a pas vraiment besoin et la QoS tu la gères toi meme...


Non ça ne va pas !
Son trafic voip est dans un tunnel ipsec, en parallèle de son trafic Internet.
En upload, pas de problème, il peut prioriser.
Mais en download, sur le PE, sur ses petits 2 Mbps, que va t'il se passer quand le téléchargement FTP ou le mail avec la pièce jointe de 5 Mo va arriver pendant qu'une conférence téléphonique est en cours ?
 
S'il n'y avait que le trafic voip qui passait par le tunnel, je dirais comme toi, la solution est viable. A partir du moment où le lien est aussi utilisé pour du trafic vers Internet, ça devient du bricolage.

Reply

Marsh Posté le 12-03-2009 à 16:05:58    

je voulais dire VPN MPLS de colt avec option Qos pour prioriser les flux + sortie web sur firewall mutualisé de colt (ou il prend une adsl pour faire du net)
Ouai c'est pas le même prix ça ok. Il peut aussi se tourner sur d'autre FAI pro pour faire jouer la concurence car colt je crois que c'est pas donné aussi par rapport à d'autres.

Reply

Marsh Posté le 12-03-2009 à 16:27:19    

AirbaT a écrit :


Non ça ne va pas !
Son trafic voip est dans un tunnel ipsec, en parallèle de son trafic Internet.
En upload, pas de problème, il peut prioriser.
Mais en download, sur le PE, sur ses petits 2 Mbps, que va t'il se passer quand le téléchargement FTP ou le mail avec la pièce jointe de 5 Mo va arriver pendant qu'une conférence téléphonique est en cours ?
 
S'il n'y avait que le trafic voip qui passait par le tunnel, je dirais comme toi, la solution est viable. A partir du moment où le lien est aussi utilisé pour du trafic vers Internet, ça devient du bricolage.


Ptain mais lol.
Si il met un rate limiting à 1mb sur ses équipement pour le flux internet EN RECEPTION tu crois qu'il va se passer quoi sur le lien SDSL a 2Mb? Que Colt va quand meme envoyer 2mb et qu'il y a 1mb qui va etre dropé...?
(W)RED et la fenetre glissante TCP ca date pas de ce matin  


---------------
Jujudu44
Reply

Marsh Posté le 12-03-2009 à 16:42:38    

jujudu44 a écrit :


Ptain mais lol.
Si il met un rate limiting à 1mb sur ses équipement pour le flux internet EN RECEPTION tu crois qu'il va se passer quoi sur le lien SDSL a 2Mb? Que Colt va quand meme envoyer 2mb et qu'il y a 1mb qui va etre dropé...?
(W)RED et la fenetre glissante TCP ca date pas de ce matin  


C'est du bricolage. Son lien reste sans contrôle en download, la congestion avoidance ne "fonctionne" qu'avec le TCP, et il n'y a pas de priorisation ! Donc gigue lorsque le débit Internet augmente, même en restant sous les 2 Mbps.

Reply

Marsh Posté le 12-03-2009 à 17:20:24    

AirbaT a écrit :


C'est du bricolage. Son lien reste sans contrôle en download, la congestion avoidance ne "fonctionne" qu'avec le TCP, et il n'y a pas de priorisation ! Donc gigue lorsque le débit Internet augmente, même en restant sous les 2 Mbps.


Sachant que le trafic UDP représente un montant infinitésimal, genre 1/2%... Le mec est pas à l'abri d'un DOS en UDP mais bon. Dans la pratique on a autant de chance d'en etre victime que de gagner au loto.
Concernant la prio je vois pas en quoi c'est pertinent si le mec est sur le meme PE. Les trames seront commutées en moins d'une millisec.
Gigue, perte, latence et cie, je maintiens qu'osef si on est sur un meme PE (si l'opérateur fait pas l'enculé).

Message cité 1 fois
Message édité par jujudu44 le 12-03-2009 à 17:20:50

---------------
Jujudu44
Reply

Marsh Posté le 12-03-2009 à 18:12:23    

jujudu44 a écrit :


Concernant la prio je vois pas en quoi c'est pertinent si le mec est sur le meme PE. Les trames seront commutées en moins d'une millisec.
Gigue, perte, latence et cie, je maintiens qu'osef si on est sur un meme PE (si l'opérateur fait pas l'enculé).

 

Ben pas vraiment... ce qui engendre le plus de gigue c'est la nature des flux que tu fais passer dans un même tuyau :o
Si t'as des paquets voix <200octets qui se battent en rang serré avec des gros paquets de 1500octets ça devient rapidement le bordel :/

 

Sinon pour ça il faudrait qu'il puisse avoir 2 classes de service sur son accès Internet et qu'il fasse passer dans la classe haute sont trafic VPN et dans la classe basse le reste :jap: et bien entendu il faut aussi qu'il mette en place de la QoS à l'intérieur de son tunnel :whistle:


Message édité par twins_ le 12-03-2009 à 18:14:44
Reply

Marsh Posté le 12-03-2009 à 21:27:07    

Ben j'ai des clients qui n'ont jamais pris aucune classe de service et ca marche fort bien :o
Seule difference le VPN était géré par l'opérateur (MPLS). Mais 0 classe, tout géré chez le client et jamais une plainte sur de mauvaises perf de la voix.
J'ai vraiment du mal a croire qu'on se prenne plus 50ms de gigue en commut sur un PE. Ok l'ideal c'est moins de 20ms, maison sera en dessous dans bcp de cas.


---------------
Jujudu44
Reply

Marsh Posté le    

Reply

Sujets relatifs:

Leave a Replay

Make sure you enter the(*)required information where indicate.HTML code is not allowed