Cisco - QOS (DSCP) enabelen en in hoogste queue dumpen

[witchdoc]

'k gebruik een iets algemene titel voor en conreeet vraagje maar mogelijk volgen er nog meer als'k er zelf niet uit raak.

Anyway, ik ben qos aan't opzetten op een mixed netwerk en A van de merken van switches is cisco. De bron tagged de priority pakketjes door dscp 46. ik zou de cisco dus die dscp=46 pakketjes voorrang willen laten geven én cos=5 setten zodat echt elk apparaat snapt welke pakketjes voorrang hebben.

Ik dacht dit te doen door:

Switch(config-if)#mls qos trust dscp
Switch(config)#mls qos map dscp-cos 46 to 5

Alleen als'k naar die dscp->cos map kijk met commando "Switch#sh mls qos map dscp-cos" dan krijg'k volgende te zien:

code:

   Dscp-cos map:
     d1 :  d2 0  1  2  3  4  5  6  7  8  9 
     --------------------------------------
      0 :    00 00 00 00 00 00 00 00 01 01 
      1 :    01 01 01 01 01 01 02 02 02 02 
      2 :    02 02 02 02 03 03 03 03 03 03 
      3 :    03 03 04 04 04 04 04 04 04 04 
      4 :    05 05 05 05 05 05 05 05 06 06 
      5 :    06 06 06 06 06 06 07 07 07 07 
      6 :    07 07 07 07

Dit snap'k niet goed. Ik verwachtte een simpele output zoals:

code:

Dscp-cos map:
dscp: 0 8 10 16 18 24 26 32 34 40 46 48 56
-----------------------------------------------
cos: 0 1 1 1 2 2 3 3 4 4 5 6 7

Iemand een idee wat'k vergeet/verkeerd doe?

[ Voor 6% gewijzigd door witchdoc op 04-11-2005 15:24 ]

[ijdod]

Zelfde tabel, alleen is de 1e per mogelijke DSCP waarde, en de 2e voor een veel beperktere set van standaard waarden. Ik vermoed dat dit met de gebruikte IOS en/of de exacte features van de switch te maken heeft; er staat me bij dat niet alle switches alle mogelijke DSCP waarden ondersteunen. voor DSCP 46 zoek je de 4 is kolom d1, en de 6 in rij d2, en zie daar de COS waarde.

[ Voor 14% gewijzigd door ijdod op 05-11-2005 09:45 ]

[witchdoc]

ijdod schreef op zaterdag 05 november 2005 @ 09:43:
Zelfde tabel, alleen is de 1e per mogelijke DSCP waarde, en de 2e voor een veel beperktere set van standaard waarden. Ik vermoed dat dit met de gebruikte IOS en/of de exacte features van de switch te maken heeft; er staat me bij dat niet alle switches alle mogelijke DSCP waarden ondersteunen. voor DSCP 46 zoek je de 4 is kolom d1, en de 6 in rij d2, en zie daar de COS waarde.

waarom zag ik dat nou niet. Van 0 tot 63.. had ik toch echt moeten zien

[witchdoc]

Jij toevallig ervaring met deze zooi ijdod?

Inkomend is dscp reeds set dus hier hoef'k niets voor te doen.
Uitgaand moet'k het dan prioriteit geven. Volgens http://www.cisco.com/univ...os_c/fqcprt7/qcfdfsrv.htm kan dat dan met class-map's, policy-maps en service-policy's gaan werken.

Dus class map:

Switch(config)#class-map match-all voip46
Switch(config-cmap)#match ip dscp 46

policy map:

Switch(config)#policy-map voip46
Switch(config-pmap)#class voip46

Volgens de link hierboven kan'k hier dan een priority ingeven. Helaas pindakaas:

code:

Switch(config-pmap)#class voip46
Switch(config-pmap-c)#?
QoS policy-map class configuration commands:
  bandwidth  Bandwidth
  exit       Exit from QoS class action configuration mode
  no         Negate or set default values of a command
  trust      Set trust value for the class
  <cr>
  police     Police
  set        Set QoS values

Enige nuttige is bandwidth en da's totaal waardeloos want bandbreedte is het probleem niet. Om jitter te beperken moet'k dat verkeer gewoon onmiddelijk uitsturen, in priority queue dumpen dus.
Met andere woorden.. ik zit weer vast.

[ijdod]

poohbeer schreef op maandag 07 november 2005 @ 15:15:
Jij toevallig ervaring met deze zooi ijdod?

Nee. Dik half jaar geleden de cursus gehad, maar er daarna nooit meer mee te maken gehad, dus dat is weer ver weggezakt....

Wat ik me zo 123 kan herinneren is dat bij Cisco switches waar QoS aanstaat, CoS 5 automatisch de priority queue ingaat. Ik heb alleen momenteel geen tijd om dit te verifieren.

[ Voor 4% gewijzigd door ijdod op 07-11-2005 20:02 ]

[DJ]

poohbeer schreef op maandag 07 november 2005 @ 15:15:
Jij toevallig ervaring met deze zooi ijdod?

Inkomend is dscp reeds set dus hier hoef'k niets voor te doen.
Uitgaand moet'k het dan prioriteit geven. Volgens http://www.cisco.com/univ...os_c/fqcprt7/qcfdfsrv.htm kan dat dan met class-map's, policy-maps en service-policy's gaan werken.

Dus class map:

Switch(config)#class-map match-all voip46
Switch(config-cmap)#match ip dscp 46

policy map:

Switch(config)#policy-map voip46
Switch(config-pmap)#class voip46

Volgens de link hierboven kan'k hier dan een priority ingeven. Helaas pindakaas:

code:

Switch(config-pmap)#class voip46
Switch(config-pmap-c)#?
QoS policy-map class configuration commands:
  bandwidth  Bandwidth
  exit       Exit from QoS class action configuration mode
  no         Negate or set default values of a command
  trust      Set trust value for the class
  <cr>
  police     Police
  set        Set QoS values

Enige nuttige is bandwidth en da's totaal waardeloos want bandbreedte is het probleem niet. Om jitter te beperken moet'k dat verkeer gewoon onmiddelijk uitsturen, in priority queue dumpen dus.
Met andere woorden.. ik zit weer vast.

Je moet eens kijken wat je kunt instellen aan de 'de-jitter' buffer. Die kan best eens op een hoge waarde staan. En dan wacht hij een vaste tijd (in miliseconden) voor hij voice doorstuurd.

Die kun je ook fixed maken op 10ms bijvoorbeeld. Zeker als bandwith geen probleem is en end-to-end delay dus ook binnen de 150ms valt moet je de de-jitter buffer eens bekijken.

[witchdoc]

DJ schreef op dinsdag 08 november 2005 @ 17:43:
[...]


Je moet eens kijken wat je kunt instellen aan de 'de-jitter' buffer. Die kan best eens op een hoge waarde staan. En dan wacht hij een vaste tijd (in miliseconden) voor hij voice doorstuurd.

Die kun je ook fixed maken op 10ms bijvoorbeeld. Zeker als bandwith geen probleem is en end-to-end delay dus ook binnen de 150ms valt moet je de de-jitter buffer eens bekijken.

mja, zorgen voor later.. ik krijg nu nog steeds niet eens verkeer met een bepaald dscp settign richting priority-queue gestuurd. Gek wordt'k ervan

De config nu:

code:

version 12.1 
no service pad 
service timestamps debug uptime 
service timestamps log uptime 
no service password-encryption 
! 
hostname Switch 
! 
enable password cisco 
! 
ip subnet-zero 
! 
mls qos 
! 
spanning-tree mode pvst 
spanning-tree extend system-id 
! 
! 
! 
! 
class-map match-all Voice 
match access-group 101 
! 
! 
policy-map Ingress-Policy 
class Voice 
trust dscp 
! 
! 
! 
interface FastEthernet0/1 
switchport mode dynamic desirable 
mls qos monitor dscp 0 46 
wrr-queue cos-map 1 0 1 
wrr-queue cos-map 2 2 3 
wrr-queue cos-map 3 4 
wrr-queue cos-map 4 5 6 7 
priority-queue out 
service-policy input Ingress-Policy 
! 
interface FastEthernet0/2 
switchport mode dynamic desirable 
wrr-queue cos-map 1 0 1 
wrr-queue cos-map 2 2 3 
wrr-queue cos-map 3 4 
wrr-queue cos-map 4 5 6 7 
priority-queue out 
! 
interface FastEthernet0/3 
switchport mode dynamic desirable 
! 
interface GigabitEthernet0/1 
switchport mode dynamic desirable 
! 
interface GigabitEthernet0/2 
switchport mode dynamic desirable 
! 
interface Vlan1 
ip address 10.0.2.111 255.255.255.0 
! 
interface Vlan10 
no ip address 
! 
ip classless 
ip http server 
! 
access-list 101 permit ip any any dscp ef 
! 
line con 0 
line vty 0 4 
password cisco 
login 
line vty 5 15 
password cisco 
login 
! 
! 
end

Maar:

Switch#sh queueing interface fa0/1
Interface FastEthernet0/1 queueing strategy: none
Switch#sh queueing interface fa0/2
Interface FastEthernet0/2 queueing strategy: none

en

Switch#sh int fa0/1
...
input flow-control is off, output flow-control is unsupported
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: fifo

En dat'k het niet helemaal snap blijkt wel weer, hoezo egress incoming? Egress is toch net uitgaand verkeer?

Switch#sh mls qos interface Fa0/1 statistics
FastEthernet0/1
Ingress
dscp: incoming no_change classified policed dropped (in bytes)
0 : 1037482 1037482 2347651 0 0
46: 51340335 48992940 0 0 0
Others: 5259285 5257356 1673 0 0
Egress
dscp: incoming no_change classified policed dropped (in bytes)
0 : 47354638 n/a n/a 0 0
46: 62 n/a n/a 0 0
Others: 5362380 n/a n/a 0 0

[ Voor 71% gewijzigd door witchdoc op 09-11-2005 09:51 ]

[DJ]

Kun je geen gebruik maken van NBAR? Als je op je FastEthernet interface het commando

code:

ip nbar protocol-discovery

Als je dat kan dan kun je eventueel op de Switch alsnog je pakketjes markeren.

Je moet dan je ClassMap aanpassen

code:

oud:
class-map match-all Voice 
match access-group 101 

nieuw:
class-map match-all Voice
match protocol rtp (de voice stream zelf)

Als dit wel werkt dan heb je nu nog alleen je Voice Stream zelf getagged en doe je er iets mee. Je Signalling valt nog onder de gewone pakketjes. Als dat geen probleem is dan laat je dat zo, anders moet je een AccessList bouwen die je signalling afvangt en die in dezelfde Class-Map invoegen.

Succes!

[witchdoc]

DJ schreef op woensdag 09 november 2005 @ 20:28:
Kun je geen gebruik maken van NBAR? Als je op je FastEthernet interface het commando

code:

ip nbar protocol-discovery

Als je dat kan dan kun je eventueel op de Switch alsnog je pakketjes markeren.

Je moet dan je ClassMap aanpassen

code:

oud:
class-map match-all Voice 
match access-group 101 

nieuw:
class-map match-all Voice
match protocol rtp (de voice stream zelf)

Als dit wel werkt dan heb je nu nog alleen je Voice Stream zelf getagged en doe je er iets mee. Je Signalling valt nog onder de gewone pakketjes. Als dat geen probleem is dan laat je dat zo, anders moet je een AccessList bouwen die je signalling afvangt en die in dezelfde Class-Map invoegen.

Succes!

ik vermoed dat het probleem niet bij het marken ligt.
De pakketjes worden door de endnodes namelijk al voorzien van dscp=46. De class en policy-map vangen dit dan toch netjes op met die trust dscp dacht'k?

Grootste probleem is dat cisco blijkbaar geen commando heeft om te kijken hoeveel pakketjes in welke queue verdwijnen? (ik en google vinden er geen althans) Ik ben dus ook niet absoluut zeker of m'n config hierboven nu werkt of niet. De pakketjes komen er wel weer uit met dscp=46 maar of ze nu ook echt voorrang hebben gehad op al de andere?

Ik vermoed dat die "wrr-queue cos-map 4 5" door de interne dscp->cos map ervoor zorgt dat alle dscp=46 pakketjes in queue 4 terrechtkomen dewelke door "priority-queue out" dan absolute prioriteit zouden moeten krijgen. Eventueel kan'k in de class-map en policy-map nog een set cos=5 bijzetten. Da's niet echt het probleem denk'k dus.

Probleem is dat'k niet snap hoe ik iets in queue's kan zetten terwijl de switch First-In-FirstOut geeft als queueing strategy. Probleem is dus dat'k nergens een commando vind om simpel te kunnen zien of de queue's ook gebruikt worden. Probleem is dat'k niet eens redelijkz eker weet of al die commando's nu op de inkomende interface poort, de uitgaande interface poort of beiden gezet moeten worden, ....

[DJ]

Ik ben nu toevallig bezig met de QoS training van Cisco. Ik zal de boeken er eens op naslaan en morgen an de docent vragen hoe dit moet.

De config die jij nu zo laat zien en de verhalen die je verteld zien er goed uit.

I'll get back to you!

[witchdoc]

DJ schreef op donderdag 10 november 2005 @ 22:42:
Ik ben nu toevallig bezig met de QoS training van Cisco. Ik zal de boeken er eens op naslaan en morgen an de docent vragen hoe dit moet.

De config die jij nu zo laat zien en de verhalen die je verteld zien er goed uit.

I'll get back to you!

Al nieuws toevallig?

[DJ]

Hoi,

Sorry dat het zo lang duurde, maar ik heb het een beetje druk gehad . . .

Volgens mij moet je met een Class-Map en een Policy-Map kunnen zien of je pakketjes inderdaad netjes dscp waarde 46 gekregen hebben.

code:

class-map match-all check-dscp
 match dscp ef
!
policy-map check-dscp
 class match-dscp

Als je die in je Switch zet zie je dan ook netjes de pakketjes voorbij komen als je

code:

show policy interface fa0/1 (of welke dan ook waar je je policy op gezet hebt)

intypt dan moet je in je output zien wat hij daadwerkelijk getagged heeft langs zien komen. Hij doet verder niets met die policy-map, alleen maar kijken.

Als je Switch dit niet ondersteund, dan zou je een Cisco router kunnen configureren die je op die Switch zet. Je moet er dan wel voor ozrgen dat het verkeer wat je wilt checken ook over die router gaat. Vervolgens de Class-Map en Policy-Map die ik heb voorgesteld op de router zetten en kijken wat je ziet.

Let me know!

[witchdoc]

Heheh, zoals ik eerder al zei, krijgen die pakketjes buiten de switch bij de bron al die dscp=46 mee. Dat ze dat hebben staat buiten kijf dus.
't Belangrijkste wat ik nu nog zou willen weten is hoe ik kan verifiëren in welke queue de pakketjes gedropt worden en waarom ik dan nog steeds "fifo" als queueing strategy te zien krijg.
Ik vermoed dat ik het juist geconfigureerd heb alleen alleen blijkt dit niet uit testen en kan ik dit niet verifiëren.

Anyway, ik klasseer dit voorlopig maar eventjes onder "nog te doen"

[DJ]

Maar ik denk dan toch dat ik eerst eens wil zien dat die dscp marking ook echt gebeurd. Als je die policy-map en class-map kunt invoeren zou ik dat gewoon even doen. Dan zie je meteen of die dscp mapping goed is.

De tweede stap is dan het controleren van je queueing strategy.

[witchdoc]

DJ schreef op donderdag 17 november 2005 @ 07:08:
Maar ik denk dan toch dat ik eerst eens wil zien dat die dscp marking ook echt gebeurd. Als je die policy-map en class-map kunt invoeren zou ik dat gewoon even doen. Dan zie je meteen of die dscp mapping goed is.

De tweede stap is dan het controleren van je queueing strategy.

Heb nu effe vakantie dus geen switches bij de hand.

Anyway,dat inkomend ze effectief DSCP=46 hebben was al duidelijk dacht'k. In een vorige post hier van me vind je namelijk dit:

code:

Switch#sh mls qos interface Fa0/1 statistics 
FastEthernet0/1 
Ingress 
dscp: incoming no_change classified policed dropped (in bytes) 
0 : 1037482 1037482 2347651 0 0 
46: 51340335 48992940 0 0 0 
Others: 5259285 5257356 1673 0 0 
Egress 
dscp: incoming no_change classified policed dropped (in bytes) 
0 : 47354638 n/a n/a 0 0 
46: 62 n/a n/a 0 0 
Others: 5362380 n/a n/a 0 0

Alleen snapte ik hier dus niet waarom ik enkel een fatsoenlijk aantal dscp pakkets ingress heb terwijl ik nergens iets aan de egress doe.

In poohbeer in "Cisco - QOS (DSCP) enabelen en in hoogst..." vind je de betreffende config terug trouwens.
Maar ik zal maandag die access-list er eens uitsmijten en jouw manier proberen. Gaat volgens mij wel hetzelfde resultaat geven hoor.