[cisco] class-maps & policy maps QOS

[Verwijderd]

Ik heb in een test-lab de volgende opstelling staan

FTP-Server -- ETH - C1720 - WIC-T1 64000 clockrate -- WIC-T1 - C1720 - FTP-Client

Nu wil ik de upload van de Ftp client naar de server
altijd voorrang geven, maar mag maar maximaal 80% van de bandbreedte
reservern.

In de config in de 1720 aan de FTP-client heb ik daarvoor het volgende gedaan

class-map ftpverkeer
match access-group 105
!
policy-map policy1
class ftpverkeer
priority percent 80
class class-default
fair-queue
!

int serial 0
service-policy output policy1
max-reserverd-bandwidth 80
!

access-list 105 permit ip any any eq ftp
access-list 105 permit ip any any eq ftp-data

nu doe ik het volgende:

Op de ftpclient, open ik het volgende commando
ping -t ftp-server

en krijg netjes binnen 18 ms een reply, nu open ik
een ftp connectie en mijn ping geeft ineens request timed out.

Ik gebruik 12.3.9 - IP PLUS IOS in beide 1720 routers hetzelfde
moet ik nog wat extra's toeveogen aan die policymaps?
hoe kan ik deze beter definieeren iemand enige ervaring hiermee?

[TrailBlazer]

waarop staat je bandwith statement. Als je bandwith hoger staat dan de lijn snelheid gaat dit namelijk fout. Om de een of andere vage rede kan een cisco niet aan de lijn zien hoe snel deze is
Kijk ook eens met show policy map interface serial0

ok klopt je acl niet helemaal volgens mij moet je de ftp-data poort ook de andere kant op specificeren of ben ik nu in de war met passive ftp transfer

[ Voor 24% gewijzigd door TrailBlazer op 14-07-2004 21:51 ]

[Adze]

Misschien is idd de "gevonden" bandbreedte hoger dan de werkelijke bandbreedte. Daarom is 80% misschien absoluut wel een veel hogere waarde geworden.

<offtopic>
Hiervoor stond iets totaal stoms....
</offtopic>

[ Voor 76% gewijzigd door Adze op 14-07-2004 23:45 ]

[Verwijderd]

de config van mijn serial link ziet er als volgt uit:

interface Serial0
bandwidth 64000
ip address 192.168.200.2 255.255.255.0
max-reserved-bandwidth 80
service-policy output myqospolicy
encapsulation ppp
clockrate 64000
ppp authentication chap
!

Router# sh policy-map int ser 0

Serial0

Service-policy output: myqospolicy

Class-map: critical-traffic (match-any)
0 packets, 0 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: access-group 105
0 packets, 0 bytes
5 minute rate 0 bps
Queueing
Output Queue: Conversation 265
Bandwidth 70 (%)
Bandwidth 44800 (kbps) Max Threshold 64 (packets)
(pkts matched/bytes matched) 0/0
(depth/total drops/no-buffer drops) 0/0/0

Class-map: class-default (match-any)
3492 packets, 290053 bytes
5 minute offered rate 0 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

Als je deze gegevens ziet , zou je denken dat die de class-map critical-traffic
niet matched met acl 105 vanwege de 0 packets, maar ik heb
voordat ik deze info kopieerde geen ftp sessie erdoorheen gezet, dus
de class-map matched de acl 105 (simpele test: als ik het drop statement toevoeg op class-map critical-traffic, dan is er geen ftp verkeer mogelijk)

[ Voor 15% gewijzigd door Verwijderd op 15-07-2004 08:31 ]

[Verwijderd]

voor de volledigheid hier de output, als ik aan het ftp-en ben

Serial0

Service-policy output: myqospolicy

Class-map: critical-traffic (match-any)
970 packets, 539520 bytes
5 minute offered rate 19000 bps, drop rate 0 bps
Match: access-group 105
970 packets, 539520 bytes
5 minute rate 19000 bps
Queueing
Output Queue: Conversation 265
Bandwidth 70 (%)
Bandwidth 44800 (kbps) Max Threshold 64 (packets)
(pkts matched/bytes matched) 911/506516
(depth/total drops/no-buffer drops) 17/0/0

Class-map: class-default (match-any)
69 packets, 4829 bytes
5 minute offered rate 0 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) 13/0/0

hierin is te zien dat de class-default, de queue volloopt...
vandaar de request timed out, alleen hoe dit op te lossen

[TrailBlazer]

code:

router(config-if)#bandwidth ?
  <1-10000000>  Bandwidth in kilobits
  inherit       Specify how bandwidth is inherited

router(config-if)#

Verwijderd schreef op 15 juli 2004 @ 08:22:
de config van mijn serial link ziet er als volgt uit:

interface Serial0
bandwidth 64000

Jij hebt geen 64 Mbit link je bandwith moet op 64 staan

Router# sh policy-map int ser 0

Serial0

Service-policy output: myqospolicy

Class-map: critical-traffic (match-any)
0 packets, 0 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: access-group 105
0 packets, 0 bytes
5 minute rate 0 bps
Queueing
Output Queue: Conversation 265
Bandwidth 70 (%)
Bandwidth 44800 (kbps) Max Threshold 64 (packets)
(pkts matched/bytes matched) 0/0
(depth/total drops/no-buffer drops) 0/0/0

Class-map: class-default (match-any)
3492 packets, 290053 bytes
5 minute offered rate 0 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

je reserveert dus 44.8 mBit voor je ftp op een 64 k lijntje

damn i'm good

[Flyduck]

TrailBlazer schreef op 15 juli 2004 @ 11:30:

code:

router(config-if)#bandwidth ?
  <1-10000000>  Bandwidth in kilobits
  inherit       Specify how bandwidth is inherited

router(config-if)#

[...]

Jij hebt geen 64 Mbit link je bandwith moet op 64 staan

[...]

je reserveert dus 44.8 mBit voor je ftp op een 64 k lijntje

damn i'm good

Lol
De waardes zijn in bits ...

[TrailBlazer]

werkt het nou al

[Verwijderd]

Ik heb gedaan wat jullie zeiden, echter blijft het probleem nog als ik de policy-map
als volgt definieer

policy-map myqospolicy
class critical-traffic
bandwidth percent 50

class class-default
fair-queue 16


Als ik na wat uitzoekwerk de policymap zo maak:

policy-map myqospolicy
class critical-traffic
bandwidth percent 50
shape average percent 50
class class-default
fair-queue 16
random-detect
random-detect exponential-weighting-constant 14

dan werkt het wel, echter is mij het niet helemaal duidelijk waarom de eerste
config niet werkt, en deze wel ?

[Verwijderd]

Verwijderd schreef op 19 juli 2004 @ 08:57:
Ik heb gedaan wat jullie zeiden, echter blijft het probleem nog als ik de policy-map
als volgt definieer

policy-map myqospolicy
class critical-traffic
bandwidth percent 50

class class-default
fair-queue 16


Als ik na wat uitzoekwerk de policymap zo maak:

policy-map myqospolicy
class critical-traffic
bandwidth percent 50
shape average percent 50
class class-default
fair-queue 16
random-detect
random-detect exponential-weighting-constant 14

dan werkt het wel, echter is mij het niet helemaal duidelijk waarom de eerste
config niet werkt, en deze wel ?

De eerste configuratie reserveerd alleen 50 procent bij congestie, de tweede schaped de matches af onafhankelijk van congestie.

[Verwijderd]

Oke, da's duidelijk maar ik weet nu niet precies of ik mijn doel heb bereikt
Mijn doel is, als ik een ftp upload doe naar de ftpserver, vanaf de client, dan
moet die ftp-transfer ongeacht wat er allemaal ge-upload wordt altijd 50% van de bandbreedte krijgen en als er meer bandbreedte vrij is, dan moet de ftp-transfer deze het liefst er ook nog bijpakken..

Vervolgens vraag ik mij af, als ik nu NIET een FTP - connectie heb, ofdat
ik dan wel alle bandbreedte kan gebruiken, of dat er nu default 50% v/d bandbreedte weg is, ook al genereer ik geen FTP-verkeer

[ Voor 23% gewijzigd door Verwijderd op 19-07-2004 16:34 ]

[Verwijderd]

Verwijderd schreef op 19 juli 2004 @ 14:26:
Oke, da's duidelijk maar ik weet nu niet precies of ik mijn doel heb bereikt
Mijn doel is, als ik een ftp upload doe naar de ftpserver, vanaf de client, dan
moet die ftp-transfer ongeacht wat er allemaal ge-upload wordt altijd 50% van de bandbreedte krijgen en als er meer bandbreedte vrij is, dan moet de ftp-transfer deze het liefst er ook nog bijpakken..

Vervolgens vraag ik mij af, als ik nu NIET een FTP - connectie heb, ofdat
ik dan wel alle bandbreedte kan gebruiken, of dat er nu default 50% v/d bandbreedte weg is, ook al genereer ik geen FTP-verkeer

Je kunt je doel niet bereikt hebben omdat je geen matches op je critcal class hebt op je laatst geposte show policy-map , ik doe deze zaken bij voorkeur met nbar.

dan wordt het :

match protocol ftp in je class map

[ Voor 6% gewijzigd door Verwijderd op 19-07-2004 18:31 ]

[Verwijderd]

Verwijderd schreef op 19 juli 2004 @ 18:28:
[...]


Je kunt je doel niet bereikt hebben omdat je geen matches op je critcal class hebt, ik doe deze zaken bij voorkeur met nbar.

dan wordt het :

Ik heb het gevoel dat je iets vergeten bent, maar ik zeg lekker niet wat

[Verwijderd]

Verwijderd schreef op 19 juli 2004 @ 18:31:
[...]

Ik heb het gevoel dat je iets vergeten bent, maar ik zeg lekker niet wat

kwas nog bezig

[Verwijderd]

De match en de access list dat gaat helemaal goed.
Waar ik me zorgen over maak is de traffic shape in policy map
Als ik geen ftp verkeer door de lijn heen stuur kan ik dan wel alle bandbreedte gebruiken ? en als ik geen gebruik maak van de lijn en alleen ftp-verkeer erdoorheen stuur, wordt er dan maar 50% van de bandbreedte gebruitk door de traffic shape ?

[Verwijderd]

Verwijderd schreef op 20 juli 2004 @ 08:25:
De match en de access list dat gaat helemaal goed.
Waar ik me zorgen over maak is de traffic shape in policy map
Als ik geen ftp verkeer door de lijn heen stuur kan ik dan wel alle bandbreedte gebruiken ? en als ik geen gebruik maak van de lijn en alleen ftp-verkeer erdoorheen stuur, wordt er dan maar 50% van de bandbreedte gebruitk door de traffic shape ?

De configuratie met shaping zorgt er voor dat ftp nooit boven de cir waarde uit gaat komen ook niet als hier ruimte voor is.

alle anedere protocollen kunnen de volledige bandbreedte gebruiken daar ze onder je default class vallen waar geen regels aan vast zitten in jouw config.

[Verwijderd]

oké dat is duidelijk. Had dat ook wel een beetje verwacht, is het eventueel mogelijk om het voor elkaar te krijgen, dat als er bandbreedte aanwezig is, deze gebruikt wordt ? Dus ipv de shaping iets anders ?

[Verwijderd]

Verwijderd schreef op 20 juli 2004 @ 10:10:
oké dat is duidelijk. Had dat ook wel een beetje verwacht, is het eventueel mogelijk om het voor elkaar te krijgen, dat als er bandbreedte aanwezig is, deze gebruikt wordt ? Dus ipv de shaping iets anders ?

Van wat ik begrijp is het de bedoeling om ftp vekeer tijdens congestie niet meer bandbreedte dan 50% geven ?

dan zou

class-map match-all ftp
match protocol ftp

policy-map ftp
class class-default
bandwidth percent 50

het moeten doen

en natuurlijk een
service policy output ftp

op je congested interface

om het even uit te leggen

met de class-map ftp trekken we ftp uit de class-default

met de policy map geven we dus alles wat niet ftp is een minimale bandbreedte van 50% toegewezen krijgt tijdens congestie.

[ Voor 37% gewijzigd door Verwijderd op 21-07-2004 16:33 ]