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.

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...

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 ...)

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...

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...

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

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.

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

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...

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.

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

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

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

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.
 

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.
 

C'est surtout la seule solution potable.

 
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.

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.

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.

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é).

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
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 et bien entendu il faut aussi qu'il mette en place de la QoS à l'intérieur de son tunnel

Ben j'ai des clients qui n'ont jamais pris aucune classe de service et ca marche fort bien
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.