[cisco] Quality of Service

[Verwijderd]

Het volgende ´probleem´

Er staat een 2811 router met daarop een DMZ. In de DMZ hangen een aantal webcams
Daarbij is er software die beelden van deze cameras opneemt. Er worden alleen beelden
opgenomen wanneer er beweging is. De opname°software staat op een online locatie.

Daarnaast zijn er nog remote users die met RDP verbinding maken naar de terminal server.
Nu snap je al wat er gebeurt. Zodra alle cameras beelden gaan uploaden, dan ´slipt´ de verbinding
dicht en wordt van alle remote users de RDP sessie verbroken.

Tijd voor Quality of Service dacht ik. Het eerste idee is als volgt:
reserveer standaard 128 kb voor de webcams en de rest vooor het overige verkeer.
Het eindidee is:
gebruik alle bandbreedte die over is voor webcams, waarij dus het RDP verkeer voorrang heeft.
Ik ben aan de slag gegaan met het eerste idee.
Nu heb ik het een en ander met class maps en policy maps gedaan, echter geeft mij
dit niet het resultaat wat ik wil hebben. Ik heb ook over rate limit en traffic shaping gelezen.
Nu vroeg ik mij ondertussen af of er medetweakers zijn die met een soortgelijk probleem te maken
hebben gehad, en hoe dit te hebben opgelost.

[Meester_J]

om te beginnen moet de IOS van de router wel QoS ondersteunen....

[Verwijderd]

Als je goed leest zie je dat ik al class maps etc heb gemaakt (wat volgens mij de manier is om QOS
te maken met een cisco router.) ga er dus van uit dat het IOS alles ondersteund

[Kabouterplop01]

Je moet natuurlijk wel rekening houden met je Bandbreedte.....
Als je QoS wil gebruiken, geef je eigenlijk aan dat je BB niet groot is.
Op het moment dat je of aan het een of aan het ander voorrang geeft en je BB limiet is bereikt, krijg je sowieso drops (lees: disconnects en lag in je webcam beelden)

Als je dus dezelfde kleur hebt gemaakt voor RDP en cam's ....enfin je snapt wat ik bedoel.
Welke kleuren gebruik je en wat voor een soort verbinding is het?

Eigenlijk hoef je hier maar 1 kleur toe te passen nl. die voor RDP, want die heeft voorrang op alles.

[ Voor 22% gewijzigd door Kabouterplop01 op 27-08-2005 13:13 ]

[Verwijderd]

Je beredenering is verkeerd, je reserveerd nu al ruimte voor het verkeer wat minder belangrijk is.

Gebruik je pat zo ja ligt daar je probleem aangezien je met een access-list op source adress niet kunt werken aangezien het aan de buitenkant maar 1 ip is.

Daar zijn opossingen voor, maar geef ons eerst eens wat meer info, post eens een config zou ik zo zeggen.

En ja ik heb redelijk wat ervaring met cisco QOS.

[ Voor 7% gewijzigd door Verwijderd op 28-08-2005 00:31 ]

[Verwijderd]

Een stukje config:

code:

class-map webcams 
 match access-group 105 

policy-map webcam
 class webcam 
   bandwith 128 
 class class-default 
  fair-queue

en dan op de Dialer interface heb ik dan

code:

service-policy webcam output staan

Access-list 105 bevat dan de publieke ip adressen van de webcam.

Ik gebruik geen pat, heb 16 publieke ip adressen waarvan ik er een aantal naar de webcams
routeer.

Ik heb zelf nog een andere configuratie gebprobeerd welke redlijk werkte alleen was t nog niet zoals
ik het wilde hebben :

code:

class-map webcams 
 match access-group 105 

policy-map webcam
 class webcam 
   priority 16
 class class-default 
  priority 128
  fair-queue

[StevenK]

't Is een tijd geleden, maar ik heb ooit voor een Citrix omgeving ook traffic shaping ingericht en dat werkte echt als een zonnetje: het ICA verkeer was gewoon gegarandeerd...

[Verwijderd]

Heb je gecontroleerd of je policy in de cisco functioneerd ?

[TrailBlazer]

met priority statements geef je ene max bandbreedte op met bandwith een gegarandeerde waar je dus eventueel overheen kan gaan als er ruimte is. Eventueel kan je ook een max bandbreedte speciferen dmv shaping en policing. Jouw 1e config ziet er naar mijn inziens beter uit.

[Verwijderd]

Heb het nu gedaan met de priority statements
maar er word niks gedropt:

code:

class-map match-any webcams 
match access-group 110 
! 
! 
policy-map webcams 
class webcams 
priority 64 
class class-default 
fair-queue 
random-detect

In class-default mag je overigens geen priority of bandwidth invullen

code:

router#sh policy-map interface dialer 1 
Dialer1 

Service-policy output: webcams 

Class-map: webcams (match-any) 
43845 packets, 58041869 bytes 
5 minute offered rate 152000 bps, drop rate 0 bps 
Match: access-group 110 
43845 packets, 58041869 bytes 
5 minute rate 152000 bps 
Queueing 
Strict Priority 
Output Queue: Conversation 264 
Bandwidth 64 (kbps) Burst 1600 (Bytes) 
(pkts matched/bytes matched) 0/0 
(total drops/bytes drops) 0/0 

Class-map: class-default (match-any) 
286544 packets, 67347014 bytes 
5 minute offered rate 7000 bps, drop rate 0 bps 
Match: any 
Queueing 
Flow Based Fair Queueing 
Maximum Number of Hashed Queues 256 
(total queued/total drops/no-buffer drops) 0/0/0 
exponential weight: 9 

class Transmitted Random drop Tail drop Minimum Maximum Mark 
pkts/bytes pkts/bytes pkts/bytes thresh thresh prob 
0 233103/55507954 0/0 0/0 20 40 1/10 
1 0/0 0/0 0/0 22 40 1/10 
2 0/0 0/0 0/0 24 40 1/10 
3 0/0 0/0 0/0 26 40 1/10 
4 0/0 0/0 0/0 28 40 1/10 
5 52013/11752151 0/0 0/0 30 40 1/10 
6 0/0 0/0 0/0 32 40 1/10 
7 0/0 0/0 0/0 34 40 1/10 
rsvp 0/0 0/0 0/0 36 40 1/10

wat nu raar is dat ik bij de class map webcams het volgende zie staan

code:

(pkts matched/bytes matched) 0/0 
(total drops/bytes drops) 0/0

echter op de ACL matched deze wel

code:

43845 packets, 58041869 bytes 
5 minute offered rate 152000 bps, drop rate 0 bps

[Verwijderd]

Priority betekend alleen maar dat er bij een verkeers aanbod van meer dan 64kbit uit die klasse 64kbit met prioriteit wordt afgehandeld de rest mag met het overige verkeer met de zelfde prioriteit worstelen.

als je nu alle permits in acl deny's maakt en vervolgens een permit ip any any aan het eind dan matched je acl op alle non webcam traffic.

dit zal dan betekenen dat het webcam verkeer alle ruimte krijgt mits er ander verkeer is.

dit ander verkeer krijgt prio tot 64kbit.

Vergeet echter niet om je bandwidth / bandwidth receive goed op de interface te configureren.

[ Voor 199% gewijzigd door Verwijderd op 01-09-2005 09:52 ]