VOIP probleemp in relatie met QOS?

[Rotty]

Onlangs hier een SIP-trunk in gebruik genomen. Meteen kwamen er veel problemen naar voren.

in het kort de situatie... Onze voip centrale is uitgekoppeld via een tussen liggende switch op onze core (l3 3750 stack). De core switch heeft een L3 interface welke gekoppeld is aan een L3 switch van UPC. Deze L3 switch van UPC is op zijn beurt weer uitgekoppeld op het glastracé van UPC. Vrij plat dus allemaal.

Na wat analyse bleek dat er in onze core l3 switch heel veel packet loss was. Met wireshark heb ik kunnen vaststellen dat dit ook daarwerkelijk op onze core ontstaat (niet ervoor maar op de core). Daarnaast kunnen vaststellen dat het probleem enkel in de uitgaande stream zit (dus van mijn werkgever naar UPC). Tevens kan ik zien dat de DSCP value ook netjes aankomt op de core.

Op het gehele tracé wordt de QOS DSCP value getrust en op het gehele tracé heb ik priority-queue out commando gegeven op de interfaces. Ik zie als ik de counters op de L3 interface op de core bekijk ook veel "total output drops".

Ik heb inmiddels wat test apparatuur waarmee ik de problemen kan reproduceren. Hierbij valt mij het volgende op; Volgens het contract met UPC dient de l3 interface op onze core ingesteld te worden op 10mbit (vreemd maar goed) als ik 60 stream over de lijn gooi (g 711) dan zie ik veel packet loss en de output drops lopen enorm snel op. Als ik de interface op onze core op 100mbit zet (en uiteraard ook de nu gesimuleerde UPC switch L3 interface) heb ik geen problemen. Vreemd in mijn ogen want g 711 is 64kb per stream ik rond dat even af naar 100kbit dan zou ik nog steeds voldoende bandbreedte moeten hebben voor 60 gesprekken.

Er zit in onze core een aantal QOS statements waarvan ik niet voldoende weet wat het precies doet. Ik heb het vermoeden dat het nog wel eens de auto-COS functie van Cisco zou kunnen zijn. Ik heb ooit eens begrepen dat de auto QOS van cisco meer een soort reservering is dan echte QOS? Mijn vermoeden is nu dat er dus maar een beperkt deel van de beschikbare bandbreedte van een interface wordt gereserveerd voor voip/rtp en dat als ik boven een bepaalde hoeveelheid data kom dat er dan zaken gedropt worden. Als ik namelijk 20 stream opstart heb ik over 10mbit niet of nauwelijks problemen. Hoe kan ik zien of er inderdaad sprake is van auto qos ? Of hebben jullie anders een idee wat het probleem zou kunnen zijn?

Dit is de riedel aan QOS settings in mijn core router: (en helaas heb ik hier nog niet de kennis voor om dit goed te kunnen lezen)


mls qos map cos-dscp 0 8 16 24 32 46 48 56
mls qos srr-queue input bandwidth 70 30
mls qos srr-queue input threshold 1 80 90
mls qos srr-queue input priority-queue 2 bandwidth 30
mls qos srr-queue input cos-map queue 1 threshold 2 3
mls qos srr-queue input cos-map queue 1 threshold 3 6 7
mls qos srr-queue input cos-map queue 2 threshold 1 4
mls qos srr-queue input dscp-map queue 1 threshold 2 24
mls qos srr-queue input dscp-map queue 1 threshold 3 48 49 50 51 52 53 54 55
mls qos srr-queue input dscp-map queue 1 threshold 3 56 57 58 59 60 61 62 63
mls qos srr-queue input dscp-map queue 2 threshold 3 32 33 40 41 42 43 44 45
mls qos srr-queue input dscp-map queue 2 threshold 3 46 47
mls qos srr-queue output cos-map queue 1 threshold 3 4 5
mls qos srr-queue output cos-map queue 2 threshold 1 2
mls qos srr-queue output cos-map queue 2 threshold 2 3
mls qos srr-queue output cos-map queue 2 threshold 3 6 7
mls qos srr-queue output cos-map queue 3 threshold 3 0
mls qos srr-queue output cos-map queue 4 threshold 3 1
mls qos srr-queue output dscp-map queue 1 threshold 3 32 33 40 41 42 43 44 45
mls qos srr-queue output dscp-map queue 1 threshold 3 46 47
mls qos srr-queue output dscp-map queue 2 threshold 1 16 17 18 19 20 21 22 23
mls qos srr-queue output dscp-map queue 2 threshold 1 26 27 28 29 30 31 34 35
mls qos srr-queue output dscp-map queue 2 threshold 1 36 37 38 39
mls qos srr-queue output dscp-map queue 2 threshold 2 24
mls qos srr-queue output dscp-map queue 2 threshold 3 48 49 50 51 52 53 54 55
mls qos srr-queue output dscp-map queue 2 threshold 3 56 57 58 59 60 61 62 63
mls qos srr-queue output dscp-map queue 3 threshold 3 0 1 2 3 4 5 6 7
mls qos srr-queue output dscp-map queue 4 threshold 1 8 9 11 13 15
mls qos srr-queue output dscp-map queue 4 threshold 2 10 12 14
mls qos queue-set output 1 threshold 1 100 100 50 200
mls qos queue-set output 1 threshold 2 125 125 100 400
mls qos queue-set output 1 threshold 3 100 100 100 400
mls qos queue-set output 1 threshold 4 60 150 50 200
mls qos queue-set output 1 buffers 15 25 40 20

[Vicarious]

mls qos srr-queue input bandwidth 70 30

Volgens mij stel je zo in dat je 70% voor de 'normale' queue gebruikt en 30% voor de priority queue. Met 60 streams kom je op 3600 kbit terwijl je lijn 10000 kbit is. Dan is 3600 meer dan 30% en gaat ie droppen.

[Razwer]

Vicarious schreef op dinsdag 11 september 2012 @ 18:25:
mls qos srr-queue input bandwidth 70 30

Volgens mij stel je zo in dat je 70% voor de 'normale' queue gebruikt en 30% voor de priority queue. Met 60 streams kom je op 3600 kbit terwijl je lijn 10000 kbit is. Dan is 3600 meer dan 30% en gaat ie droppen.

10000kbit?
http://www.matisse.net/bi...=megabits&notation=legacy
kb of KB?

[ Voor 7% gewijzigd door Razwer op 11-09-2012 19:02 ]

[Vicarious]

10.000 kilobits.... dat klopt toch?

[Razwer]

In bandbreedte rekenen we volgens mij met 1024 kilobits in een megabit etc. Maargoed, maakt weinig verschil voor je reactie. was een beetje pietlutterig

[Vicarious]

Razwer schreef op dinsdag 11 september 2012 @ 19:17:
In bandbreedte rekenen we volgens mij met 1024 kilobits in een megabit etc. Maargoed, maakt weinig verschil voor je reactie. was een beetje pietlutterig

oh bedoel je het zo Dan moet ik mn rekenmachine erbij pakken en dat was niet zo relevant in deze situatie.

[Rotty]

Kijk

Vicarious schreef op dinsdag 11 september 2012 @ 18:25:
mls qos srr-queue input bandwidth 70 30

Volgens mij stel je zo in dat je 70% voor de 'normale' queue gebruikt en 30% voor de priority queue. Met 60 streams kom je op 3600 kbit terwijl je lijn 10000 kbit is. Dan is 3600 meer dan 30% en gaat ie droppen.

Dat klinkt idd logisch maar waarom heb ik dan output drops? Ik ziou in dat geval verwachten dat je input drops hebt. Daarnaast vraag ik mij af of deze qos instellingen wel handig zijn.. Lijkt mij wat meer op traffic shaping waarbij je echt bandbreedte reserveerd, dit is in mijn beleving niet echt efficient. Kan iemand bevestigen of de QOS riedel in mn switch inderdaad een resultaat is van auto QOS?

[jvanhambelgium]

Wat staat er eigenlijk op de INTERFACE (naar UPC) zelf geconfigged ? Staan daar ook specifieke statement rond QoS want de output hierboven lijkt me in de global config..

[Rotty]

jvanhambelgium schreef op woensdag 12 september 2012 @ 08:38:
Wat staat er eigenlijk op de INTERFACE (naar UPC) zelf geconfigged ? Staan daar ook specifieke statement rond QoS want de output hierboven lijkt me in de global config..

Klopt de riedel is enkel in de global... op de interface naar UPC staat enkel een trust statement mls trust qos dscp en een priority queue out command.. verder niks bijzonders..

[jvanhambelgium]

Ja, dan zou het wel eens kunnen dat je met die 30% op de priority-queue niet toekomt zoals hierboven al aangegeven is...
Kan je ook eens met een aantal "show" commands aan de slag om te zien hoe het nu zit met de verschillende queues, de drops erop etc.
(dus niet gewoon via "sh int" commando)

eerder zoiets als

show platform pm if-numbers => zoek welke "port" overeenkomt met de interface die naar UPC loopt
show platform port-asic stats drop port X (X is dan de port-nummer die je met vorig commando kon linken aan de uplink UPC port)

[Rotty]

Hier had ik ook al eens naar gekeken maar zoals ik eerder al aangaf... kan ik de output niet echt goed interpreteren...

Interface Gi4/0/11 TxQueue Drop Statistics
Queue 0
Weight 0 Frames 0
Weight 1 Frames 0
Weight 2 Frames 126125603
Queue 1
Weight 0 Frames 0
Weight 1 Frames 0
Weight 2 Frames 0
Queue 2
Weight 0 Frames 0
Weight 1 Frames 0
Weight 2 Frames 7536
Queue 3
Weight 0 Frames 0
Weight 1 Frames 0
Weight 2 Frames 0
Queue 4
Weight 0 Frames 0
Weight 1 Frames 0
Weight 2 Frames 0
Queue 5
Weight 0 Frames 0
Weight 1 Frames 0
Weight 2 Frames 0
Queue 6
Weight 0 Frames 0
Weight 1 Frames 0
Weight 2 Frames 0
Queue 7
Weight 0 Frames 0
Weight 1 Frames 0
Weight 2 Frames 0

[jvanhambelgium]

Bekijk dit ander eens

http://www.cisco.com/en/U...ote09186a0080883f9e.shtml


...het brengt mischien wat licht in de duisternis ;-)

[Vicarious]

Queue 0 is ongekleurd verkeer en dus gewoon data. Strange...