QoS Konfig 3560

[123meins 10]

Hi Leute,

 

bin momentan Praktikant und sollte mal im Hinblick auf eine kommende VoIP-Anlage einen 3560er Switch mit QoS Parametern konfigurieren.

 

Habe ich auch gemacht, nun frag ich mich, wie man diese Konfiguration gescheit testen kann, sprich normalen Traffic erzeugen und dann Traffic mit höherwertigen DSCP Wert?

Momentan hängt der Switch nicht im Netz und hätte auch nur einen PC zur Verfügung (zur Not kann man sicherlich noch einen auftreiben).

 

Mal meine Konfig, wäre nett wenn man mir hier vielleicht schon hinweise auf fehler geben könnte:

conf t

mls qos

#nur mal 1 Beispielport an dem ein nicht Cisco IP-Phone hängt, vorausgesetzt, das #Telefon unterstützt CoS, ansonsten wäre trust dscp wohl ratsamer

 

conf t

int fa0/5

mls qos trust cos

switchport voice vlan 20

#Port würde ansonsten einem anderen Vlan angehören (sprich: switchport access vlan x, #switchport mode access)

 

int gi0/1

mls qos trust dscp

#oder doch besser trust cos auf den gigabit ports?

 

mls qos map cos-dscp 0 8 16 26 32 46 48 56

#default map angepasst

 

mls qos srr-queue input cos-map queue 1 threshold 1 2 //CoS 2 in Queue 1, Threshold-ID 1

mls qos srr-queue input cos-map queue 1 threshold 2 1 //CoS 1 in Q2 u. T-ID 2

mls qos srr-queue input cos-map queue 1 threshold 3 0 //CoS 0 zu Q1 und T-ID 3

mls qos srr-queue input cos-map queue 2 threshold 3 3 5 //CoS 3,5 in Q1 und T-ID 3

mls qos srr-queue input cos-map queue 2 threshold 2 6 7 //usw

mls qos srr-queue input cos-map queue 2 threshold 1 4

end

#analog dazu hab ich auch die input dscp map konfiguriert

 

mls qos srr-queue input priority-queue 2 bandwidth 10 //Q2 wird Prio-Q.

mls qos srr-queue input bandwidth 90 10 //Bandbreiteaufteilung Q1/Q2

mls qos srr-queue input threshold 1 50 80 //Q1 Th.-ID1 50% und ID2 80% ID3 100%

mls qos srr-queue input threshold 2 50 80 //Queue 2

mls qos srr-queue input buffers 70 30 //Zuteilung des Puffers auf Q1(70) u. Q2(30)

#ist ne Prio-Queue überhaupt ratsam? und mit dem Threshold u. Puffer Werten bin ich mir #auch nicht wirklich sicher. gibts denn irgendwelche erfahrungswerte bzw berechnungen, #wie man sowas optimal aufteilt?

 

##ausgangswarteschlagen##

mls qos srr-queue output cos-map queue 1 threshold 3 5 //CoS 5 in Q1 und T-ID3

mls qos srr-queue output cos-map queue 2 threshold 3 3 6 7 //CoS 3,6,7 in Q2 und T-ID3 usw

mls qos srr-queue output cos-map queue 3 threshold 3 2 4

mls qos srr-queue output cos-map queue 4 threshold 2 1

mls qos srr-queue output cos-map queue 4 threshold 3 0

#analog wieder dscp werte

 

mls qos queue-set output 1 buffers 10 10 30 50 //Q.-Set 1: Q1:10, Q2:10, Q3:30, Q4:50

mls qos queue-set output 2 buffers 15 10 20 55

 

int fa0/5

srr-queue bandwidth shape 10 0 0 0

srr-queue bandwidth share 10 10 50 30

#arbeitet Queue 1 nun nur im shaped Mode oder in beiden Modi (shaped und shared), #wenn ja, würde Q1 nun doch mehr als 10% der Bandbreite bekommen, falls die anderen #Queues leer sind? bin aus cisco guide nich so recht schlau geworden

 

mls qos queue-set output 1 threshold 1 130 130 90 130

mls qos queue-set output 1 threshold 2 130 130 90 400

mls qos queue-set output 1 threshold 3 40 80 100 320

mls qos queue-set output 1 threshold 4 20 55 70 400

mls qos queue-set output 2 threshold 1 140 140 100 140

mls qos queue-set output 2 threshold 2 115 115 100 235

mls qos queue-set output 2 threshold 3 45 70 100 270

mls qos queue-set output 2 threshold 4 45 70 100 240

#hier bin ich mir nun überhaupt nicht sicher, hab mich doch sehr an auto-qos orientiert

#queue-set 1 den fast-ethernet ports zugeordnet und q.-set 2 den gigabit ports

 

int fa0/5

priority-queue out

#und noch prio-schlangen zugeordnet (Q1 wird hier Prio Queue), auch hier die Frage, ist #das sinnvoll?

 

#fortsetzung beitrag 2

[123meins 10]

class-maps und policy maps hab ich keine konfiguriert, seh keinen richtigen sinn darin. wüsste auch nicht, welche werte ich für burstsize und rate-bps nehmen sollte, wenn jemand tipps hat, immer raus damit.

ist in meinen augen ja nun nicht ratsam, voip traffic herabzustufen, mit der konsequenz, das die pakete schneller verworfen werden.

 

und letzte frage:

funktionieren befehle wie "mls qos trust device cisco-phone" ausschließlich mit cisco telefonen? der befehl lässt das doch stark vermuten.

 

ich weiß es ist eine menge holz, was hier steht, bin aber für jeden kleinen tipp bzw hinweis sehr dankbar.

 

mfg

[daking 10]

Hallo,

 

#nur mal 1 Beispielport an dem ein nicht Cisco IP-Phone hängt, vorausgesetzt, das #Telefon unterstützt CoS, ansonsten wäre trust dscp wohl

==> das Phone muss 802.1Q Tagging unterstützen, um eine Trust Boundary zu erzeugen,da sonst jeder PC mit DSCP 46 in die SPQ kommen würde.

 

 

#oder doch besser trust cos auf den gigabit ports?

==> nach cisco design guides ist auf uplinks trust dscp besser. Bei einigen Switches gab es auch Probleme mit trust cos (3750).

 

#ist ne Prio-Queue überhaupt ratsam? und mit dem Threshold u. Puffer Werten bin ich mir #auch nicht wirklich sicher. gibts denn irgendwelche erfahrungswerte bzw berechnungen, #wie man sowas optimal aufteilt?

 

==> die input queues benutzte ich nicht, da die phones einen integrierten policer haben sollten, der das "Überleben" des Phones sichern sollte. Ich habe auch keine Messungen mit angepassten Inputqueues durchgeführt.

 

#arbeitet Queue 1 nun nur im shaped Mode oder in beiden Modi (shaped und shared), #wenn ja, würde Q1 nun doch mehr als 10% der Bandbreite bekommen, falls die anderen #Queues leer sind? bin aus cisco guide nich so recht schlau geworden

 

==> Das gesamte Queueing zieht nur wenn Überlast auf der Schnittstelle entsteht, sprich gepuffert werden muss. Das shaping und sharing (custom-qeueing) zieht in Q1 nur , wenn priority-queue out nicht gesetzt ist. Falls du nur zwei Datentypen hast (Voice und Data) zieht das custom-qeueuing nicht, da nur eine Klasse in diesem Modus betrieben wird. Falls du zwei Datentypen hättest. Teilt sich die Gewichtung der Queues auf (eine wird dann nicht benutzt). Falls du Shaping aktiviert hast wird die Queue auch bei nicht vorhandenen Traffic in den anderen Queues delayed (10 = 90 Teile der Bandbreite der Queue ==> ist bei dem 3(5/7)xx Series sehr ungenau.

 

#und noch prio-schlangen zugeordnet (Q1 wird hier Prio Queue), auch hier die Frage, ist #das sinnvoll?

==> Für VoIP ist ein xPxQxT (wichtig ist das P) Vorraussetzung

 

zu Beitrag 2 Teil1:

 

class und policy-maps machen bei Softphones sinn, da dort 1. keine Trust Boundary gebildet werden kann und 2. andere Daten ein wenig gebremst werden können.

 

mls qos trust device cisco-phone

==> richtig! Falls IPP CDP Pakete sendet wird dynamisch ein Trust Cos generiert.

 

Ciao

[123meins 10]

hoi

 

danke für die antwort, nur aus 1-2 sachen bin ich nich wirklich schlau geworden.

also sharing und shaping würde bei gesetzter prio-queue ignoriert werden, sprich bei einer last-situation wird traffic die in der prio queue ist solang bedient werden bis sie leer ist und dann kommen die anderen Queues dran.

setze ich keine prio queue, so würden die shaped u. shared werte der ehemaligen prio-queue wieder in die aufteilung mit einbezogen werden, richtig?

nehmen wir mal an, ich hab für jede der 4 Queues Traffic parat, auch so das jede ausgelastet wäre, dann käme die bandbreitenaufteilung in kraft, wie ich sie mit "srr-queue bandwidth share 10 10 50 30" konfiguriert habe.

tritt nun der fall ein, das queue 1 keinen entsprechend für sich klassifizierten traffic erhält, bleibt ihr trotzdem die zugesicherte bandbreite (srr-queue bandwidth shape 10 0 0 0) erhalten, passiert das analog mit q2,3 oder 4, stellen die ihre nicht genutzt bandbreite zur verfügung. so hätte ich das verstanden.

 

und zu den policers:

gibts denn da erfahrungswerte ohne ähnliches? ab welcher rate oder burst-size würde man voip sprach-paketen "sagen" ihr seid out-of-profile, und ich werte sie ab?

in meinen augen bringt das insofern keinen vorteil, da die pakete nun einen noch größeren risiko ausgeliefert sind "zu spät" anzukommen oder gar nicht.

beispielsweise auto-qos funktion eines 3560, class-map für traffic mit dscp ef und eine für cs3 bzw af31, dann dazugehörige policy map, wo ich diesen traffic nochmal explizit mit den dscp werten markiere, sie jedoch herabstufe wenn rtp-traffic werte von 320.000bps und 8000byte burstsize überschreitet. (analog dazu voice control traffic nur 32.000bps).

wie gesagt, in meinen augen noch nicht so ganz logisch.

[fu123 10]

Hi Leute,

 

bin momentan Praktikant und sollte mal im Hinblick auf eine kommende VoIP-Anlage einen 3560er Switch mit QoS Parametern konfigurieren.

 

Ganz schöne Aufgabe als Praktikant. Aber die machen ja meist eh die richtige Arbeit. :-)

 

Habe ich auch gemacht, nun frag ich mich, wie man diese Konfiguration gescheit testen kann, sprich normalen Traffic erzeugen und dann Traffic mit höherwertigen DSCP Wert?

Momentan hängt der Switch nicht im Netz und hätte auch nur einen PC zur Verfügung (zur Not kann man sicherlich noch einen auftreiben).

 

Du könntest dir einen Router nehmen und den Traffic darüber markieren. Eventuell auch MGEN. Weiß aber nicht ob es das auch für Win gibt.

 

 

Wie sind eigentlich die Ports verteilt? An deinem F0/5 ist dein Telefon und am Gi0/1 ist dein Ausgang zum Backbone oder direkt zur Anlage?

 

Der 3560 kann wohl auch eine service-policy auf einem Interface im Gegensatz zu manch anderem. Damit könntest du ja auch mit einer ACL matchen und dann prio auf deinem Gi0/0 interface einrichten (MQC).

 

 

Fu

[daking 10]

Hallo,

 

setze ich keine prio queue, so würden die shaped u. shared werte der ehemaligen prio-queue wieder in die aufteilung mit einbezogen werden, richtig?

 

==> richtig

 

nehmen wir mal an, ich hab für jede der 4 Queues Traffic parat, auch so das jede ausgelastet wäre, dann käme die bandbreitenaufteilung in kraft, wie ich sie mit "srr-queue bandwidth share 10 10 50 30" konfiguriert habe.

 

==> fast richtig. ist jedoch keine bandbreitenaufteilung sondern "nur" custom queueing. Die Werte bestimmen, wie oft x Bytes aus der Queue genommen werden dürfen.

Alle Queues werden somit x mal abgearbeitet ==> TCP Sessions werden nicht ganz runter gezogen. Du kannst jedoch nicht sagen, dass die Q3 50% der Bandbreite bekommt.

 

tritt nun der fall ein, das queue 1 keinen entsprechend für sich klassifizierten traffic erhält, bleibt ihr trotzdem die zugesicherte bandbreite (srr-queue bandwidth shape 10 0 0 0) erhalten, passiert das analog mit q2,3 oder 4, stellen die ihre nicht genutzt bandbreite zur verfügung. so hätte ich das verstanden.

 

==> (fast) richtig. Falls keine Überlast vorhanden ist und alle verschiedenen Classifier erfüllt werden, werden jedoch keine Queues angezogen ==> es gibt keinen Grund QOS zu verwenden, da nichts gepuffert werden muss. Falls Überlast vorhanden ist und in einer Q nichts vorhanden ist, werden die weights aufgeteilt. Mit dem shape kommando wird keine Bandbreite reserviert oder Streams priorisiert. Hierbei wird der Traffic nur gebremst (shaping). Das Shaping erzeugt künstlich eine Überlast bei 90% der Bandbreite. Die Q1 würde früher die QOS Mechanismen aktivieren als die anderen Q. Diese Konfiguration ist mit VoIP ohne spq absoluter Schwachsinn (hier. nicht bei DSL verbindung ==> hierachisches Queueing).

 

 

 

und zu den policers:

gibts denn da erfahrungswerte ohne ähnliches? ab welcher rate oder burst-size würde man voip sprach-paketen "sagen" ihr seid out-of-profile, und ich werte sie ab?

in meinen augen bringt das insofern keinen vorteil, da die pakete nun einen noch größeren risiko ausgeliefert sind "zu spät" anzukommen oder gar nicht.

 

==> wenn du LLQ mit Cisco Routern konfigurierst wird alles über der priority bandwidth durch den integrierten policer gedroppt. Die Bandbreite muß somit sauber kalkuliert werden. Der Einsatz eines Policer wird nie Pakete verzögern. Wenn die max Bandbreite überschritten wird, werden die Pakete gedropped oder neu markiert. Für VoIP ist ein remarking durch eine policer nicht sinnvoll, da Delay, Jitter und PKT Loss Werte stabil seien müssen. Da sollen eher andere Anwendungen (non udp) leiden ==> managing the unfairness..

 

Sinnvoll ist der Einsatz von Policern mit Softphones ==> da sind einige Networkers 2005 Präsentationen interessant...

 

dann dazugehörige policy map, wo ich diesen traffic nochmal explizit mit den dscp werten markiere, sie jedoch herabstufe wenn rtp-traffic werte von 320.000bps und 8000byte burstsize überschreitet. (analog dazu voice control traffic nur 32.000bps).

 

==> die kalkulierten Werte können nicht überschritten werden, da sonst falsch kalkuliert wurde (WAN). Da solltest du eher die Thresholds der Queues anpassen, um schon vor der Entstehung des Probelms (kann bei konfigurierter spq eh nicht passieren) die uninteressanet Q präventiv droppen lassen ((W)RED).

 

 

Im LAN Umfeld ist die Reservierung von Bandbreite für VoIP eher uninteressant, da durch das geringe Queueing und Serialization Delay (GBit/10Gbit) der Einsatz von Strict Priority Queueing (spq) keine Probleme macht. Bei einer Neuinstallation müssen so oder so vorher die vorhandenen Backplane, Uplink Bandbreiten mit den angeschlossenen Komponenten + VoIP überprüft werden. QOS bringt nur in guten Designs etwas (was passiert in Extermfällen ==> Virus..).

==>

 

Only use QoS to make a good situation better.

Never use QoS hoping to improve a poor or marginal situation to “good enough.”

 

Ciao

[123meins 10]

danke erstmal für die antworten ^^.

@fu

im moment hängt dieser switch noch lose rum, aber wäre vorstellbar das an den fa0/5 ein voip-phone hängt (und an dem dann der pc) und der gigabit port geht ins backbone des netzes.

wie gesagt, ich sollte erstmal nur ne beispiel-konfig an so nen switch durchführen, weil er am häufigsten in dem lan vorkommt und zumeist auch die ganzen endgeräte dranhängen.

sind noch ein paar 65xx (einer davon is coreswitch) vorhanden. backbone mit 155 bzw 655mbit angebunden.

 

@daking

sorry für meine ****en fragen, aber sonst raff ichs nich ^^.

nochmals zum shaping in den output queues:

so wie ich dich verstanden habe, ist dieses shape bandwith bla bla nicht das wahre (auch wenn cisco den befehl in der auto-qos funktion umsetzt), und man wäre im fall einer lastsituation mit einer prio-queue besser bedient (rest der queues mit share bandwith usw konfig.)?

 

weiterhin bringen solche qos mechanismen nich wirklich viel, in nen reinen lan, wenn die auslastung des netzes sowieso nicht sehr hoch ist, sollte jedoch nicht schaden, es trotzdem zu konfigurieren, um im falle eines falles gerüstet zu sein?!

 

zu den networker präsis. war auf deren seite, aber hab da nich wirklich was passendes gefunden und google spuckt auch nix passendes aus. hättest du da nen link bzw zufällig eine auf deinem pc, die du mir mailen könntest ^^?

 

nochmals danke. ist schon komisch, da denkt man, man hat etwas einigermaßen kapiert und dann erkennt man, das es doch nicht so ist ;).

[123meins 10]

ick nochmal.

 

wie schaut das eigentlich aus bei softphones? da bringt die ganz obige konfiguration der interfaces ja herzlich wenig, wenn ich das richtig verstehe.

 

momentan sähe die folgendermaßen aus, bei hardware ip-phone:

 

interface FastEthernet0/5

switchport access vlan 8 //

switchport mode access

switchport voice vlan 20

mls qos trust cos

spanning-tree portfast

end

 

sprich daten normal über vlan 8 und voip pakete über vlan 20, nur scheint das ja wie gesagt nur bei hardware-phones zu gehen. wie krieg ich die voip pakete bei nen angeschlossenen pc, mit irgendeiner softphone-variante ins passende vlan "gelenkt"?

 

edit:

Der 3560 kann wohl auch eine service-policy auf einem Interface im Gegensatz zu manch anderem. Damit könntest du ja auch mit einer ACL matchen und dann prio auf deinem Gi0/0 interface einrichten (MQC).

hm hättest du da mal ein kleines beispiel für mich wie das im falle für voip aussehen könnte?

etwa so: access-list 100 permit any any dscp 46

dann ne class-map, die diese acl "matched", dann policy-map mit der voip class und per "priority"(oder bandwith) befehl dieser klasse prio zuweisen?

oder ne acl aufgrund der ports? (hatte da mal nen thread gefunden gehabt, nur find ich den nich mehr :p)

 

wieder nen haufen fragen. in der theorie sah das einfacher aus ^^.

[daking 10]

Hallo,

 

so stellt sich das Cisco vor:

 

CAT2970(config)#mls qos map policed-dscp 0 24 46 to 8

! Excess traffic marked 0 or CS3 or EF will be remarked to CS1

CAT2970(config)#

CAT2970(config)#class-map match-all SOFTPHONE-VOICE

CAT2970(config-cmap)# match access-group name SOFTPHONE-VOICE

CAT2970(config-cmap)#class-map match-all SOFTPHONE-SIGNALING

CAT2970(config-cmap)# match access-group name SOFTPHONE-SIGNALING

CAT2970(config-cmap)#exit

CAT2970(config)#

CAT2970(config)#policy-map SOFTPHONE-PC

CAT2970(config-pmap)#class SOFTPHONE-VOICE

CAT2970(config-pmap-c)# set ip dscp 46 ! Softphone VoIP is marked DSCP EF

CAT2970(config-pmap-c)# police 128000 8000 exceed-action policed-dscp-transmit

! Out-of-profile SoftPhone VoIP is marked down to Scavenger (CS1)

CAT2970(config-pmap-c)#class SOFTPHONE-SIGNALING

CAT2970(config-pmap-c)# set ip dscp 24 ! Call-Signaling is marked DSCP CS3

CAT2970(config-pmap-c)# police 32000 8000 exceed-action policed-dscp-transmit

! Out-of-profile SoftPhone Signaling is marked down to Scavenger (CS1)

CAT2970(config-pmap-c)#class class-default

CAT2970(config-pmap-c)# set ip dscp 0

CAT2970(config-pmap-c)# police 5000000 8000 exceed-action policed-dscp-transmit

! Out-of-profile data traffic is marked down to Scavenger (CS1)

CAT2970(config-pmap-c)# exit

CAT2970(config-pmap)#exit

CAT2970(config)#

CAT2970(config)#interface GigabitEthernet0/1

CAT2970(config-if)# service-policy input SOFTPHONE-PC

CAT2970(config-if)#exit

CAT2970(config)#

CAT2970(config)#ip access-list extended SOFTPHONE-VOICE

CAT2970(config-ext-nacl)# permit udp any any range 16384 32767 ! VoIP ports

CAT2970(config-ext-nacl)#

CAT2970(config-ext-nacl)#ip access-list extended SOFTPHONE-SIGNALING

CAT2970(config-ext-nacl)# permit tcp any any range 2000 2002 ! SCCP ports

 

 

Ciao

 

Thomas

[123meins 10]

danke schön :).

 

Ihr seid wirklich spitze.