QoS voor VOIP

[BasXcore]

Wij hebben sinds kort een AVAYA VOIP oplossing gekregen. Nu zijn er diverse kleine problemen die nog spelen omtrend de qualiteit van de gesprekken intern en extern. De telecom geeft aan eerst QoS in het netwerk in te regelen voor VOIP. En het VOIP verkeer voorang tegenover overig verkeer te geven. Ik heb mij zwaar verdiept in het gehele QoS verhaal maar zit nog met wat vragen.

Eerst even de situatie:
- Core switch, HP 5412ZL met 192* 10/100/1000 POE poorten. 4 GBIC met LX naar 4 HP2650 PWR's.
- AVAYA IP 500 met VOIP (ingeprikt op de core switch HP 5412ZL)
- 75 Softphone's op Windows XP SP2
- 15 Hardphone's
- 75% van alle workstations en hardphone's bevinden zich op de HP 5412ZL, 25% op de HP2650 PWR's

Wat is er geconfigureerd:
- Op de switch is diffservices (DCSP) geactiveerd. Dit omdat de Softphone's DiffServ waarde 46 meeverstuurd op layer 3.
- Op de switch is de interface waar de IP OFFICE op zit op 802.1p prio 7 gezet.

Er is geen VLAN geconfigureerd voor de Hardphone's. Dus 802.1p op VLAN is (nog) niet geconfigureerd.

Mijn vragen:
- Heeft het uberhaubt zin om QoS in te stellen omdat 75% van alle VOIP hosts op de Coreswitch zelf zitten?
- Heeft het zin een tagged VLAN te maken voor 15 hardphone's, en daar 802.1p prio 7 aan te hangen?
- Er zit een Broadcom NIC in de PC's waar de Softphone op draait. Op die NIC zit een optie voor 802.1p support. Moet dit aan? Heeft dit zin als de PC in de default untagged VLAN 1 zit? Er wordt tenslotte al op DSCP niveau tag 46 meegegeven.
- Heeft het zin/nut om 802.1p IP based prio's op de core switch in te stellen voor de IP OFFICE 500?
- Zijn er nog meer aanbevelingen die ik kan doorvoeren?

[MoBi]

Ja het heeft nut om qos aan te zetten ook als ze op de core switch zitten. Dit geeft namelijk voip verkeer hogere prio boven het normale verkeer op je kabel tussen pc en (core) switch. Dus als je je connectie helemaal dicht trekt met een download of multicast verkeer dan zal voip daar geen problemen mee hebben die je misschien nu wel hebt.

[TrailBlazer]

ik heb serieus nog nooit een probleem gezien met voip op een LAN. ik vind het namelijk heel knap als je je lijn dicht weet trekken op ethernet. QoS op je wan is vaak wel nodig maar op je lan???

[Verwijderd]

Wordt er op die switch ook op layer 3 gerouteerd?
Anders zul je toch ook met CoS waardes moeten gaan werken.

Verder zoals TrailBlazer al zegt is het onwaarschijnlijk dat je problemen hebt op je LAN met je voip, zeker met deze hoeveelheden.

Misschien kun je wat meer achtergrond info geven mbt de problemen?

Welke codec gebruik je?

Uiteindelijk lijkt het me verstandig DiffServ te gaan gebruiken voor je WAN verbinding om hier problemen te voorkomen.

Ik ben niet zo bekend met de HP switches, misschien kun je kijken wat de drop rate is voor de interface naar de Avaya toe?

*Overigens is een VLAN indeling sowieso verstandig!

[ Voor 4% gewijzigd door Verwijderd op 25-10-2007 21:31 ]

[Bl@ckbird]

TrailBlazer schreef op donderdag 25 oktober 2007 @ 19:28:
ik heb serieus nog nooit een probleem gezien met voip op een LAN. ik vind het namelijk heel knap als je je lijn dicht weet trekken op ethernet. QoS op je wan is vaak wel nodig maar op je lan???

Het gaat er niet om of je wel of geen problemen hebt met VoIP op een LAN...
Het gaat er om dat je garandeert dat VoIP verkeer de bandbreedte krijgt die het nodig heeft.
( Hoe weinig dat ook hoeft te zijn... )

Traditionele telefonie is erg betrouwbaar en met VoIP wil je dezelfde betrouwbaarheid bieden.
(Als in: altijd 112 kunnen bellen als dat nodig is.)

[DJ]

Ik gebruik altijd VLAN's om VoIP en overig te scheiden. Zelfs al gaat het maar om één telefoon! Het is erg eenvoudig om VLAN's te implementeren en je netwerk layout wordt duidelijker. Je hebt niet dat VoIP en DATA in hetzelfde logische netwerk gaan vechten om bandbreedte.

Ik vindt het wel knap als je in een LAN omgeving (waar je ook GigaBit hebt zo te zien) VoIP problemen zou kunnen hebben binnen je LAN. Dat duidt in mijn boekje dan ook op een ander probleem. Wellicht zit er ergens een interface te klapperen . . . begin bij de basis te troubleshooten (bottom-up dus).

Verder zijn gegevens als welke Codec je gebruikt ook handig om te weten. Vooral als je ook WAN verbindingen hebt waarover je met VoIP gaat.

Ik weet niet in hoeverre het met die HP Switch mogelijk is om per poort te kijken wat voor packets er langs komen en of er errors zijn etc. Ik ken wat dat betreft alleen Cisco Switches . . .

Dus, troubleshooten vanaf de bodem (kabels, connectors nalopen) en dan langzaam verder omhoog gaan. Dan zul je het probleem gegarandeerd ontdekken . . .

Succes!

[TrailBlazer]

Bl@ckbird schreef op donderdag 25 oktober 2007 @ 22:40:
[...]


Het gaat er niet om of je wel of geen problemen hebt met VoIP op een LAN...
Het gaat er om dat je garandeert dat VoIP verkeer de bandbreedte krijgt die het nodig heeft.
( Hoe weinig dat ook hoeft te zijn... )

Traditionele telefonie is erg betrouwbaar en met VoIP wil je dezelfde betrouwbaarheid bieden.
(Als in: altijd 112 kunnen bellen als dat nodig is.)

De kans dat die bandbreedte er niet is zonder QoS is gewoon heel klein. Op het moment dat je gaat bellen staat die sessie tussen twee telefoons en een userpoort die de volle 100mbit trekt is zeldzaam.
Behalve als je trunks hebt die erg vol zitten kan je problemen krijgen met een lokaal gesprek.

[Bl@ckbird]

Eens.
Maar het gaat om het garanderen.
QoS is voor een VoIP installatie net zo gewoon, als dat men redundant uplinks gebruikt.
(Op het LAN en WAN.) Het werkt zonder, maar de vraag is of het slim is.

QoS is niet voor niets opgenomen in elke Voice guide van Cisco.
Bovendien is het standaard onderdeel van het CCIE Voice examen
en voor het CCVP traject is er een dedicated examen voor.

Voor de rest --> With DJ:
Eerst trouble shooten en QoS implementeren als laatste vangnet.

[TrailBlazer]

Bl@ckbird schreef op maandag 29 oktober 2007 @ 14:29:
Eens.
Maar het gaat om het garanderen.
QoS is voor een VoIP installatie net zo gewoon, als dat men redundant uplinks gebruikt.
(Op het LAN en WAN.) Het werkt zonder, maar de vraag is of het slim is.

QoS is niet voor niets opgenomen in elke Voice guide van Cisco.
Bovendien is het standaard onderdeel van het CCIE Voice examen
en voor het CCVP traject is er een dedicated examen voor.

Voor de rest --> With DJ:
Eerst trouble shooten en QoS implementeren als laatste vangnet.

ik ben het dus ook eens met eerst naar andere oorzaken gaan zoeken QoS is namelijk niet zaligmakend natuurlijk

[BasXcore]

Als eerst, sorry voor de late reply. Er is intussen een hoop gebeurt. Mede dankzij jullie input!

Het QoS verhaal is on-hold gezet, uitleg volgt:

Ik heb door intens troubleshouten, packets sniffers en andere mogelijkheden vast gesteld dat de problematiek niet door de switching/routing onderdergrond veroorzaakts wordt. Daarmee is het balletje terug gerolt naar de telecom partner. Die heeft met hulp van AVAYA het volgende gevonden:

De Softphone van AVAYA bevat, blijkt nu, veel fouten in combinatie met de software release op de VOIP centrale (IP OFFICE 500). In deze build zaten diverse fouten zoals, spontane resets, lijnen verbreken op doorverbinden, slechte lijn qualiteit. Al met al te veel om op te noemen. Inmiddels is er door AVAYA voor ons een "special build" versie gemaakt. Hiermee zijn inmiddels veel fouten ge-elimineerd.

Eindelijk werkt het zoals we het willen hebben.

Maar, dat rest niet dat ik wel QoS "voor het geval dat" wil implementeren. Hier heb ik ook al een aanzet voor gemaakt.

Wij hebben dus een layer 3 switch. Ik heb hierop als test 4 VLAN's gedefineerd:
- VLAN 1: Default (10.10.10.X/24)
- VLAN 10: Servers (10.10.11.X/24)
- VLAN 20: IP Phone's (10.10.12.X/24)
- VLAN 30: Workstations (10.10.13.X/24)

Elke VLAN heeft op de switch een IP adres, en IP routing is aan gezet. Alle delen kunnen goed met elkaar communiceren door (layer 3) routing op de switch. Een poort waarop een test server staat is in Untagged VLAN 10 gezet. Tevens een test IPPhone in untagged VLAN 20 gezet. Als laatst ook een PC is in een untagged VLAN 30 gezet.

Nu de grote vraag, naar mijn weten kan er alleen QoS informatie aan de VLAN tag 802.3Q worden teogevoegd als de packet uberhaubt getagged is. In mijn opzet zijn mijn poorten untagged (dus alleen bereikbaar door traffic komende van desbetreffende VLAN ID). Of sla ik hier de plank mis???

Tevens, is deze opzet wel verstandig? Ga ik zo niet onnodig veel Layer 3 CPU tijd van mijn Switch vragen?

Nogmaals dank voor jullie input.

[TrailBlazer]

Ik kan enkel praten voor cisco switches maar die werken als volgt. Aan elk pakket wordt op basis van de DSCP header in het pakket een interne COS toegewezen . Deze interne COS wordt dan weer naar een bepaade queue gemapped. Het ligt aan het type switch hoeveel queues je hebt per interface . Je kan wel vaak 1 van die queues als expedite queue definieren en dat is dan wat je wil.
Overigens een behoorlijke switch doet dit allemaal in ASICS dus die processor wordt nauwlijks belast.

zo queueing op L2 van cisco switches in een notendop.

[ Voor 10% gewijzigd door TrailBlazer op 06-11-2007 21:12 ]

[Verwijderd]

Op de uplinks van de switches zou ik prio queue maken voor VoIP.

De telefoons zoals je zij geven al DSCP waarde van 46 (standaard Prio Queue bij normale mapping)
Het enige wat je dus moet doen is een queue aanmaken op de uplinks en ook in je router.

Verder kun je op de andere poorten een DSCP waarde aan packets gaan geven, zodat je eventueel ook applicaties voorrang kunt geven in de queue.

DSCP (layer 3) zit in IP Header
CoS (layer 2) zit in Frame header

Voor zover ik zie moet dit voldoende zijn, met sniffer achteraf makkelijk te zien welke pakketjes eruit komen met welke DSCP waardes..

Mocht ik iets missen of ergens overheen gelezen heb, hoor ik het wel

Edit: Overigens wordt vaak een CoS waarde van 6 (wordt op layer 3 gemapped naar DSCP 46) ook als toebehorend aan de prio Queue gezien

[ Voor 9% gewijzigd door Verwijderd op 14-11-2007 23:12 ]

[Verwijderd]

Hallo BasXcore

Op je HP Switches zit een optie IGMP (multicast filter) deze moet uit staan anders heb je ook problemen met in loggen op je softphones/phone mangers, binnen je Lan heb je geen Qos nodig. VLan's zijn wel aan te raden, voor de VOIP toestellen laten wij door de Data DHCP-server een extra optie meezenden met het Vlan ID en vervolgens start het toestel opnieuw op in het juiste Vlan en daar krijgt deze gewoon via de AVAYA een DHCP adres.
Voor de softphone mag je alleen bij; Extension > Toestelnummer > tab VOIP het vinkje Out of band DTMF aan zetten. In je Softphone kun je Faststart proberen te veranderen.

knip, groeten hoeft niet, en spammen al helemaal niet..

[ Voor 5% gewijzigd door Equator op 16-11-2007 07:35 ]

[TrailBlazer]

basboers welkom op GoT.
De topicstarter heeft de oplossing al aangegeven er zit namelijk gewoon een bug in de software van die phones. Sowieso is je post niet echt de bedoeling omdat het spammen van het bedrijf waar je werkt niet is toegestaan.